idnits 2.17.1 draft-daviel-html-geo-tag-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 487. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 30, 2007) is 6022 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'HTML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XHTML' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' -- Obsolete informational reference (is this intentional?): RFC 2445 (ref. 'ICAL') (Obsoleted by RFC 5545) -- Obsolete informational reference (is this intentional?): RFC 2426 (ref. 'VCARD') (Obsoleted by RFC 6350) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Vancouver Webpages 3 October 30, 2007 4 Expires: May 2, 2008 5 Intended status: Standards Track 7 Geographic registration of HTML documents 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 1, 2008. 34 Abstract 36 This memo describes a method of registering HTML documents with a 37 specific geographic location through means of embedded META tags. 38 The content of the META tags gives the geographic position of the 39 resource described by the HTML document in terms of Latitude, 40 Longitude, and optionally Elevation in a simple, machine-readable 41 manner. This information may be used for automated resource 42 discovery by means of an HTML indexing agent or search engine. META 43 tags giving a civic location of a resource are also described. 45 1. Introduction 47 Many resources described by HTML documents on the World-Wide-Web are 49 Oct 2007 (Expires May 2008) 51 associated with a particular place on the Earth's surface. While 52 resource discovery on the Web has thus far focussed on document title 53 and open-text keyword searching, in these cases it may be beneficial 54 to facilitate geographic searching. Examples of this kind of 55 resource include pages describing restaurants, shipwrecks, retail 56 stores etc. Consumers may use this information in order to select the 57 closest facility, and in order to navigate towards a resource by 58 road, on foot or by other means. 60 Although some resources, such as restaurants, have a street address 61 which may be mapped to geographic location by existing tools, other 62 objects on the Web, such as a photograph of a mountain, may not. 64 This draft describes a method of adding static location data to 65 legacy HTML documents using a construct that is familiar to many HTML 66 authors. It is intended to be concise, unambiguous, simple to use 67 and compatible with existing editing tools. The intended use is to 68 provide location data to Web robots that typically revisit pages 69 every few weeks. 71 It is anticipated that in many cases this location data will be added 72 manually by persons unfamiliar with GIS terminology or metadata 73 standards. For this reason a minimal data set with few options is 74 preferred over a more complex and extensible one. 76 The method described in this draft is not intended to preempt 77 existing or future metadata encapsulation schemes which may better 78 serve the needs of a particular community, such as geographic 79 information systems (GIS). Nor is it intended to preempt richer, more 80 structured data encapsulations such as RDF or XML, which typically 81 require software to generate correctly. 83 2. Coordinate Systems 85 Resource positions on the Earth's surface should be expressed in 86 degrees North of Latitude, degrees East of Longitude as signed 87 decimal numbers. 89 Where the precision of the coordinates is such that the datum used is 90 significant, typically more precise than one kilometre distance, 91 positions should be converted to the WGS 84 datum [WGS84]. 92 Elevations, if given, should be in metres above datum. Positions 93 given by a GPS set [GPS] with datum set to "WGS 84" will in most 94 cases be adequate, of the order of 15 metres accuracy in horizontal 95 position and 25 metres in elevation. 97 It should be noted that elevations referred to the WGS 84 geoid will 98 in some areas differ appreciably from those measured with respect to 100 Oct 2007 (Expires May 2008) 102 local datum in coastal regions, which may be Mean High Water Springs, 103 Mean Sea Level, Higher High Water or a similar reference level, and 104 will differ substantially from "ground level". Use of elevation is 105 not recommended unless its value may be reliably determined. 107 3. Implementation 109 XHTML, HTML or WML markup should be added to the document in the form 110 of a META statement. This should be placed in the document head in 111 accordance with the XHTML specification [XHTML]. 113 There are several possible GEO identifiers: 114 The identifier "geo.position" is used for Latitude, Longitude and 115 optionally Elevation data. 116 The identifier "geo.country" is used for the two-letter country code 117 from ISO 3166 [ISO3166], e.g. "US" (United States), "DE" (Germany). 118 The identifiers "geo.a1", "geo.a2" etc. are used to define a civic 119 address, as in RFC 4776 [RFC4776]. 121 For resources within the United States and Canada, the "geo.a1" 122 identifier corresponds to and the common 2-character State/Province 123 codes [STATES][PROVINCES], e.g. "BC" (British Columbia), "CA" 124 (California) 126 To facilitate machine indexing, wherever possible a controlled list 127 should be used for civic elements. For instance, ISO 3166-2 128 [ISO3166-2] might be used for "geo.a1" 130 Use of the numeric "geo.position" is generally recommended to ensure 131 accurate indexing. However, if the resource described is localized 132 to a country or region, but not to a single point, the civic 133 identifiers "geo.country", "geo.a1" etc. may be used alone without a 134 corresponding "geo.position" identifier. 136 It is the intention of this draft to provide a means to associate a 137 single point with an XHTML, HTML or WML document. Some consideration 138 should be given to the choice of location when describing a resource, 139 given that positioning mechanisms may provide an accuracy of the 140 order of ten metres in horizontal position. For instance, when 141 describing a retail store or small business, it may be more 142 meaningful to give the position of the street entrance rather than 143 the position of the center of the property. 145 Although the XHTML specification [XHTML] states that the name field 146 is in general case-sensitive, these GEO tags should be recognized by 148 Oct 2007 (Expires May 2008) 150 compliant agents regardless of case. Coordinates should be ordered 151 (Latitude ; Longitude) as for RFC 2426, RFC 2445 (vCard and iCal 152 specifications) [ICAL][VCARD]. If elevation is given, coordinates 153 should be ordered (Latitude ; Longitude ; Elevation). 155 3.1 Migration from earlier versions 157 To migrate documents and applicaitons written against earlier 158 versions of this draft, the following correspondences are noted: 160 geo.position geo.position 161 geo.region geo.country (2 character region) 162 geo.region geo.country and geo.a1 (extended region XX-YYY) 163 geo.placename geo.lmk (landmark or vanity address) 165 4. Examples 167 169 describes a resource 115 metres above datum at position 170 48.54 degrees North, 123.84 degrees West, while 172 174 describes a resource at position 10 degrees South, 175 60 degrees East. 177 178 179 181 describes a resource in London, Ontario, Canada, 182 while 184 185 186 188 describes a resource in London, England (Great Britain). 190 5. Semantics 192 Values for latitude and longitude shall be expressed as decimal 193 fractions of degrees. Whole degrees of latitude shall be represented 194 by a decimal number ranging from 0 through 90. Whole degrees of 195 longitude shall be represented by a decimal number ranging from 0 196 through 180. When a decimal fraction of a degree is specified, it 197 shall be separated from the whole number of degrees by a decimal 199 Oct 2007 (Expires May 2008) 201 point (the period character, "."). Decimal fractions of a degree 202 should be expressed to the precision available, with trailing zeroes 203 being used as placeholders if required. A decimal point is optional 204 where the precision is less than one degree. Some effort should be 205 made to preserve the apparent precision when converting from another 206 datum or representation, for example 41 degrees 13 minutes should be 207 represented as 41.22 and not 41.21666, while 41 13' 11" may be 208 represented as 41.2197. 210 Latitudes north of the equator MAY be specified by a plus sign (+), 211 or by the absence of a minus sign (-), preceding the designating 212 degrees. Latitudes south of the Equator MUST be designated by a 213 minus sign (-) preceding the digits designating degrees. Latitudes 214 on the Equator MUST be designated by a latitude value of 0. 216 Longitudes east of the prime meridian shall be specified by a plus 217 sign (+), or by the absence of a minus sign (-), preceding the 218 designating degrees. Longitudes west of the prime meridian MUST be 219 designated by a minus sign (-) preceding the digits designating 220 degrees. Longitudes on the prime meridian MUST be designated by a 221 longitude value of 0. A point on the 180th meridian shall be taken 222 as 180 degrees West, and shall include a minus sign. 224 Any spatial address with a latitude of +90 (90) or -90 degrees will 225 specify a position at the True North or True South Poles, 226 respectively. The component for longitude may have any legal value. 228 The vertical coordinate (Elevation) must be expressed in meters 229 above WGS-84 (EGM96) datum. Points having zero elevation must not 230 have a negative sign. 232 5.1 Interpretation 234 User agents should accept metadata written according to the HTML or 235 XHTML specifications [HTML][XHTML]. 237 Whitespace within a position value shall be ignored. 239 An interpreting agent shall internally mark position values either 240 valid or invalid. If a position is marked invalid, it shall not be 241 used to index or qualify the containing document. 243 A position having a Latitude greater than 90 degrees, or less than 244 -90 degrees, shall be marked invalid. 246 Oct 2007 (Expires May 2008) 248 A position having a Longitude greater than 180 degrees, or less than 249 -180 degrees, shall be marked invalid. 251 Where a value is given for geo.country, and the latitude and 252 longitude values given for geo.position fall outside the recognized 253 boundaries of this region, the position may be marked invalid. For 254 example, if a country code of "US" is given for a location in the US 255 mainland, the position may be marked invalid if the Latitude is 256 negative or the Longitude is positive. 258 No formal reliance shall be placed on the precision implicit in 259 position data. It is likely that few content providers are qualified 260 to determine reliable precision or accuracy data, and may use 261 position data from other sources which does not give the datum. 263 5.2. Terminology 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 267 document are to be interpreted as described in [RFC2119]. 269 6. Formal Syntax 271 DIGIT = %x30-39 ; 0-9 272 PLUS = %x2B ; + 273 MINUS = %x2D ; - 274 DECIMAL = %x2E ; . 275 SEMI = %x3B ; ; 276 CRLF = %x0D.%x0A ; return, linefeed 277 SP = %x20 ; space 278 HTAB = %x09 ; tab 279 WSP = SP / HTAB ; 280 LWSP = (WSP / CRLF WSP) ; linear whitespace 281 UCASE = %x41-5A ; A-Z 282 HYPHEN = %x2D ; - 283 USCORE = %x5F ; _ 284 country = 2UCASE ; 2-letter code from ISO3166 285 TEXT = 286 placename = 1*TEXT 287 delimiter = SEMI 289 latitude = [ MINUS / PLUS ] 0*2DIGIT [ DECIMAL *DIGIT] 290 longitude = [ MINUS / PLUS ] 0*3DIGIT [ DECIMAL *DIGIT] 291 elevation = [ MINUS / PLUS ] 0*DIGIT [ DECIMAL *DIGIT] 292 position = latitude longitude [ elevation ] 294 geocivic = TEXT ; civic address elements as per RFC 4776 296 Oct 2007 (Expires May 2008) 298 XHTML or WML syntax: 299 300 301 303 HTML (legacy) syntax: 304 305 306 308 7. Applicability 310 As stated in the introduction, certain HTML documents may be 311 associated with a geographic position, while other documents are not. 312 For proper use of the GEO tags as described in this draft, the 313 resource described in an HTML document should be associated with a 314 particular geographic location for the lifetime of the document. The 315 tags may thus be properly used to describe an object fixed on the 316 surface of the earth (or more properly, fixed in position relative to 317 the surface of the earth) such as a retail store, a mountain peak or 318 a railway station. They may not be used to describe a non-localized, 319 moving, or intangible object such as a multinational company, river, 320 aircraft or mathematical theory. 322 The geographic position given is associated with the resource 323 described by the HTML document, not with the physical location of the 324 document [RFC1876], or the location of the company responsible for 325 publishing or hosting the document. Thus, in some cases the country 326 code used in "geo.country" may differ from the country code forming 327 part of the host address in the document URL. 329 Since the position given is associated with the content of the 330 document, not the author, publishing and document conversion tools 331 should not cache position data or store it in a template. 333 In cases where the object being described is an area, such as a lake 334 or a building, the position of the object should not in general be 335 given to greater precision than the width of the object. If desired, 336 features within the object may be described in another page and their 337 position given with greater precision. In the case of an object such 338 as a place of business, where only one page exists, the position of 339 the entrance may be given rather than the position of the centroid. 341 8. Security Considerations 342 Oct 2007 (Expires May 2008) 344 The intended use of GEO metadata as described in this draft raises no 345 privacy issues beyond those associated with normal use of the Web. 346 It is assumed that information present in public Web pages has been 347 published in accordance with applicable privacy regulations and 348 guidelines. 350 If the location data describes the position of a mobile Internet 351 device, filters applicable to possible end recipients (typically, the 352 public Internet) should be applied. The webserver in this case acts 353 as a Location Recipient [RFC3693]. 355 9. Internationalization considerations 357 HTML meta element content, including geo elements, is coded using the 358 character set of the containing document, typically UTF-8 or 359 ISO8859-1. 361 Geo.country and geo.position tag content should contain only ASCII 362 characters. 364 10.1 Normative References 366 [HTML] Raggett, Le Hors, Jacobs, "HTML 4.01 Specification", 367 http://www.w3.org/TR/1999/REC-html401-19991224, W3C, December 368 1999 370 [XHTML] W3C HTML Working Group, "XHTML 1.0 The Extensible HyperText 371 Markup Language (Second Edition)", 372 http://www.w3.org/TR/2002/REC-xhtml1-20020801, W3C, 373 26 January 2000, revised 1 August 2002 375 [ISO3166] International Organization For Standardization / 376 Organisation 377 Internationale De Normalisation (ISO), "Standard ISO 378 3166-1:1997: Codes for the Representation of Names of 379 Countries and their subdivisions -- Part 1: Country codes", 380 1997. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 10.2 Informative References 387 [RFC3693] Cuellar, Morris et al., "Geopriv Requirements", RFC 3693, 388 February 2004 389 http://www.ietf.org/rfc/rfc3693.txt 391 Oct 2007 (Expires May 2008) 393 [RFC1876] Davis et al., "A Means for Expressing Location Information 394 in 395 the Domain Name System", RFC 1876, January 1996 396 http://www.ietf.org/rfc/rfc1876.txt 398 [RFC4776] H. Schulzrinne, "Dynamic Host Configuration Protocol 399 (DHCPv4 and DHCPv6) Option 400 for Civic Addresses Configuration Information", RFC 4776, 401 November 2006 402 http://www.ietf.org/rfc4776.txt 404 [ISO3166-2] International Organization For Standardization / 405 Organisation 406 Internationale De Normalisation (ISO), "Standard ISO 407 3166-2:1998: Codes for the Representation of Names of Countries 408 and their subdivisions -- Part 2: Country subdivision code", 409 1998. 411 [GPS] ARINC Research Corporation, "Navstar GPS Space Segment / 412 Navigation User Interfaces", IRN-200C-002, September 1997 414 [WGS84] United States Department of Defense; DoD WGS-1984 - Its 415 Definition and Relationships with Local Geodetic Systems; 416 Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R- 417 138-R; CV, KV; 419 [ICAL] Dawson & Stenerson, Internet Calendaring and Scheduling Core 420 Object Specification (iCalendar), RFC 2445, November 1998 421 http://www.ietf.org/rfc/rfc2445.txt 423 [VCARD] Dawson & Howes, vCard MIME Directory Profile, RFC 2426, 424 September 1998 425 http://www.ietf.org/rfc/rfc2426.txt 427 [STATES] United States Postal Service, Official Abbreviations - 428 States and Possessions, 429 http://www.usps.gov/ncsc/lookups/abbr_state.txt 431 [PROVINCES] Canada Postal Guide, Province and Territory Symbols 432 http://www.canadapost.ca/tools/pg/manual/b03-e.asp 434 11. Acknowledgments Rohan Mahy and Patrik Faltstrom of Cisco Systems, 435 for semantics. 437 12. Authors' Addresses 439 Andrew Daviel, BSc. 440 Vancouver Webpages, Box 357 442 Oct 2007 (Expires May 2008) 444 185-9040 Blundell Rd 445 Richmond BC 446 V6Y 1K3 447 Canada 449 Tel. (604)-377-4796 450 Fax. (604)-270-8285 451 advax@triumf.ca 453 Felix A. Kaegi 454 Dipl.Informatik Ing. ETH (M.Sc.) 455 Friedensgasse 51 456 CH-4056 Basel 457 SWITZERLAND 459 Phone +41 61 383 10 01 460 Fax +41 79 625 27 41 461 skype felix_kaegi 462 felix.kaegi@gmail.com 464 Oct 2007 (Expires May 2008) 466 Intellectual Property Statement 467 The IETF takes no position regarding the validity or scope of any 468 Intellectual Property Rights or other rights that might be claimed to 469 pertain to the implementation or use of the technology described in 470 this document or the extent to which any license under such rights 471 might or might not be available; nor does it represent that it has 472 made any independent effort to identify any such rights. Information 473 on the procedures with respect to rights in RFC documents can be 474 found in BCP 78 and BCP 79. 476 Copies of IPR disclosures made to the IETF Secretariat and any 477 assurances of licenses to be made available, or the result of an 478 attempt made to obtain a general license or permission for the use of 479 such proprietary rights by implementers or users of this 480 specification can be obtained from the IETF on-line IPR repository at 481 http://www.ietf.org/ipr. 483 The IETF invites any interested party to bring to its attention any 484 copyrights, patents or patent applications, or other proprietary 485 rights that may cover technology that may be required to implement 486 this standard. Please address the information to the IETF at ietf- 487 ipr@ietf.org. 489 Disclaimer of Validity 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 493 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 494 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 495 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Copyright Statement 499 Copyright (C) The IETF Trust (2007). 501 This document is subject to the rights, licenses and restrictions 502 contained in BCP 78, and except as set forth therein, the authors 503 retain all their rights. 505 Acknowledgment 506 Funding for the RFC Editor function is currently provided by the 507 Internet Society. 509 15a. IANA Considerations 511 This document does not introduce any IANA considerations.