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.