INTERNET-DRAFT Vancouver Webpages April 2000 (Expires Nov. 2000) Daviel. A Geographic registration of HTML documents Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo describes a method of registering HTML documents with a specific geographic location through means of embedded META tags. The content of the META tags gives the geographic position of the resource described by the HTML document in terms of Longitude, Latitude and optionally Elevation in a simple, machine-readable manner. This information may be used for automated resource discovery by means of an HTML indexing agent or search engine. 1. Introduction Many resources described by HTML documents on the World-Wide-Web are associated with a particular place on the Earth's surface. While resource discovery on the Web has thus far focussed on document title and open-text keyword searching, in these cases it may be beneficial to facilitate geographic searching. Examples of this kind of resource include pages describing restaurants, shipwrecks, wildlife refuges etc. A.Daviel [Page 1] April 2000 (Expires Nov. 2000) 2. Coordinate Systems Resource positions on the Earth's surface should be expressed in degrees North of Latitude, degrees East of Longitude as signed decimal numbers, separated by a semicolon. The number of decimal places given should reflect the precision of the coordinates, with zeroes being used as placeholders. A decimal point is optional where the precision is less than one degree. Where the precision of the coordinates is such that the datum used is significant, typically more precise than one kilometre distance, positions should be converted to the WGS 84 datum [3]. Positions given by a GPS set [4] with datum set to "WGS 84" will in most cases be adequate, of the order of 200 metres accuracy. 3. Implementation HTML markup should be added to the document in the form of a META statement. This should be placed in the document head in accordance with the HTML 4 specification [1]. The identifier "geo.position" is used for Latitude and Longitude data. The identifier "geo.placename" is used for a free text representation of the position, for example "city, province" or "town, county, state". The identifier "geo.region" is used for the country subdivision code from ISO 3166-2 [10]. For resources within the United States and Canada, the "geo.region" identifier as given by ISO 3166-2 is typically constructed from the 2-character country code [5] as used in Internet domain names, and the common 2-character State/Province codes [8][9], joined with an underscore, for example "CA_BC" for British Columbia, Canada. Where the official subdivision code is unknown, the 2-character country code alone may be used in "geo.region", for example "DE" for Germany. It is anticipated that the "geo.placename" tag be used for resource recognition, rather than resource discovery, due to possible ambiguities in naming convention, language, word ordering and placename duplicates. Although the HTML specification [1] states that the name field is in general case-sensitive, these "geo" tags should be recognized by compliant agents regardless of case. Coordinates should be ordered (Latitude ; Longitude) as for RFC 2426, RFC 2445 (vCard and iCal specifications) [6][7]. This is at variance with common GIS practice, but better matches the intended audience of this Draft. A.Daviel [Page 2] April 2000 (Expires Nov. 2000) 4. Examples describes a resource at position 48.54 degrees North, 123.84 degrees West, while describes a resource at position 10 degrees South, 60 degrees West. describes a resource in London, Ontario, Canada while describes a resource in London, England (Great Britain). 5. Applicability As stated in the introduction, certain HTML documents may be associated with a geographic position, while other documents are not. For proper use of the "geo" tags as described in this draft, the resource described in an HTML document should be associated with a particular location for the lifetime of the document. The tags may be properly used to describe, for instance, a retail store, a mountain peak or a railway station but not a multinational company, river, aircraft or mathematical theory. The geographic position given is associated with the resource described by the HTML document, not with the physical location of the document [2], or the location of the company responsible for publishing or hosting the document. Thus, in some cases the country code used in "geo.position" may differ from the country code forming part of the host address in the document URL. 6. Further information Further information may be obtained at http://geotags.com/geo 7. Security Considerations This draft raises no security issues. A.Daviel [Page 3] April 2000 (Expires Nov. 2000) 8. Internationalization considerations The "geo.placename" tag content is free text, and should obey the internationalization rules of HTML 4. "lang" and "dir" modifiers may be used to specify the language of the content. Multiple instances of geo.placename may be used with different "lang" modifiers. Geo.placename content is coded using the character set of the containing document. Geo.position and geo.region tag content should use US-ASCII or UTF-8. 9. References [1] Raggett, Le Hors, Jacobs, "HTML 4.0 Specification", http://www.w3.org/TR/1998/REC-html40-19980424 , W3C, April 1998 [2] Davis et al., "A Means for Expressing Location Information in the Domain Name System", RFC 1876, January 1996 http://www.freenic.net/rfcs/rfc1800/rfc1876.html [3] United States Department of Defense; DoD WGS-1984 - Its Definition and Relationships with Local Geodetic Systems; Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R- 138-R; CV, KV; [4] ARINC Research Corporation, "Navstar GPS Space Segment / Navigation User Interfaces", IRN-200C-002, September 1997 [5] International Organization For Standardization / Organisation Internationale De Normalisation (ISO), "Standard ISO 3166-1:1997: Codes for the Representation of Names of Countries and their subdivisions -- Part 1: Country codes", 1997. [6] Dawson & Stenerson, Internet Calendaring and Scheduling Core Object Specification (iCalendar), RFC 2445, November 1998 http://www.freenic.net/rfcs/rfc2400/rfc2445.html [7] Dawson & Howes, vCard MIME Directory Profile, RFC 2426, September 1998 http://www.freenic.net/rfcs/rfc2400/rfc2426.html [8] United States Postal Service, Official Abbreviations - States and Possessions, http://www.usps.gov/ncsc/lookups/abbr_state.txt [9] Canada Post, the Postal Code, two-letter abbreviations, http://www.canadapost.ca/CPC2/addrm/addrguide/prov_symbols.html A.Daviel [Page 4] April 2000 (Expires Nov. 2000) [10] International Organization For Standardization / Organisation Internationale De Normalisation (ISO), "Standard ISO 3166-2:1998: Codes for the Representation of Names of Countries and their subdivisions -- Part 2: Country subdivision code", 1998. 10. Author's Address Andrew Daviel Vancouver Webpages, Box 357 185-9040 Blundell Rd Richmond BC V6Y 1K3 Canada Tel. (604)-377-4796 Fax. (604)-270-8285 mailto:andrew@vancouver-webpages.com A.Daviel [Page 5]