402 A user could type the data extracted from this URI into a electronic
403 navigation device, or even use it to locate the identified location
404 on a paper map.
406 6.2. Hyperlink
408 'geo' URIs could (like any other URI scheme) also be embedded as
409 hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet
410 with such a hyperlink could look like:
412 one of Vienna's most popular sights is the Karlskirche
415 6.3. Header Field
417 Many protocols support the use of arbitrary URI schemes, for example
418 in their header Fields. A Session Initiation Protocol (SIP) [7]
419 REGISTER request could contain a 'Contact' header with a 'geo' URI,
420 to reflect the geographic location to be used to contact the
421 registering entity physically:
423 REGISTER sip:geoaware.example.com SIP/2.0
424 Via: SIP/2.0/UDP mypc.example.org:5060;branch=z9hG4bKnashds7
425 Max-Forwards: 70
426 To: Joe Geo
427 From: Joe Geo ;tag=456248
428 Call-ID: aaafafff-84230@7afagggdd
429 CSeq: 42 REGISTER
430 Contact:
431 Contact:
433 6.4. Web Mapping Services
435 A rather common method for accessing geographic information on the
436 Internet are web mapping services (WMS) [6]. An image containing a
437 map is delivered by a mapserver as response to a WMS request. WMS
438 requests usually contain a bounding box (enclosing rectangle), the
439 spatial reference system (e.g. 'EPSG:4326' for WGS84), displayed
440 layers (e.g. roads, borders), image dimensions and image format (e.g.
441 'image/png'):
443 http://map.example.org/maps/wms.cgi?BBOX=16,48,18,50&SRS=EPSG:4326 \
444 &LAYERS=roads,borders&WIDTH=400&HEIGHT=400&FORMAT=image/png
446 A location identified by a 'geo' URI could be used to support input
447 parameters in terms of a center point of a WMS request. Query
448 parameters could be used to reflect the requested type of service,
449 eg. a 'geo' URI could be mapped to a WMS request as follows:
451 geo:48.20833,16.37278,171?service=wms&scale=5000&layers=roads,borders
452 \ &height=400&width=400&format=image/png
454 A bounding box can be calculated by given scale, height and width.
455 In our case, based on an output scale of 1:5000 and 400px image
456 height and width the bounding box width and height is 0.00634
457 degrees. A 'geo' URI is limited to one spatial reference system,
458 thus 'SRS=EPSG:4326' is a constant parameter in WMS transformations.
459 The resulting WMS request could look like:
461 http://map.example.org/maps/wms.cgi?BBOX=16.05690,47.89167, \
462 16.69142,48.52619&SRS= EPSG:4326&LAYERS=roads,borders&WIDTH=400 \
463 &HEIGHT=400&FORMAT=image/png
465 7. IANA Considerations
467 This document requests assignment of the 'geo' URI scheme in the IETF
468 part of the URI scheme tree, according to the guidelines in BCP 115
469 (RFC 4395) [4]. The definitions required for the assignment are
470 contained in Section 4.
472 8. Security Considerations
474 Because the 'geo' URI is not tied to any specific protocol, and
475 identifies a physical location rather than a network resource, most
476 of the general security considerations on URIs (Section 7 of RFC
477 3986) do not apply. However, the following (additional) issues
478 apply:
480 8.1. Invalid Locations
482 The URI syntax (Section 4.3) makes it possible to construct valid
483 'geo' URIs which don't identify a valid location on earth.
484 Applications MUST NOT use URIs which such invalid values, and SHOULD
485 warn the user when such URIs are encountered.
487 An example of such an invalid URI would be (latitude
488 "beyond" north pole).
490 8.2. Location Privacy
492 Location information about individuals is an extremely sensitive
493 topic, especially when location is combined with Personally
494 Identifyable Information (PII).
496 In cases where location information about individuals is used in a
497 publicly available 'geo' URI, the explicit consent of the individual
498 is REQUIRED.
500 8.3. Malicious Locations
502 As with other URI schemes, the information provisioned in 'geo' URIs
503 cannot be trusted unless some kind of trust relation with the author
504 of a URI is in place. Applications of the 'geo' URI SHOULD consider
505 methods of validating and protecting URIs.
507 9. References
509 9.1. Normative References
511 [1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
512 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
513 January 2005.
515 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
516 Levels", BCP 14, RFC 2119, March 1997.
518 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
519 Specifications: ABNF", RFC 4234, October 2005.
521 9.2. Informative References
523 [4] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
524 Registration Procedures for New URI Schemes", BCP 115, RFC 4395,
525 February 2006.
527 [5] National Imagery and Mapping Agency, "Department of Defense
528 World Geodetic System 1984, Third Edition", NIMA TR8350.2,
529 January 2000.
531 [6] Open GIS Consortium Inc., "Web Map Service Implementations
532 Specification, Version 1.1.1", OGC 01-068r3, January 2002.
534 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
535 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
536 Session Initiation Protocol", RFC 3261, June 2002.
538 Authors' Addresses
540 Alexander Mayrhofer
541 enum.at GmbH
542 Karlsplatz 1/9
543 Wien A-1010
544 Austria
546 Phone: +43 1 5056416 34
547 Email: alexander.mayrhofer@enum.at
548 URI: http://www.enum.at/
550 Christian Spanring
551 OIR-Informationsdienste GmbH
552 Franz-Josefs-Kai 27
553 Wien A-1010
555 Phone: +43 1 5338747 36
556 Email: spanring@oir.at
557 URI: http://www.oir.at/
559 Full Copyright Statement
561 Copyright (C) The IETF Trust (2007).
563 This document is subject to the rights, licenses and restrictions
564 contained in BCP 78, and except as set forth therein, the authors
565 retain all their rights.
567 This document and the information contained herein are provided on an
568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
570 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
571 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
572 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
575 Intellectual Property
577 The IETF takes no position regarding the validity or scope of any
578 Intellectual Property Rights or other rights that might be claimed to
579 pertain to the implementation or use of the technology described in
580 this document or the extent to which any license under such rights
581 might or might not be available; nor does it represent that it has
582 made any independent effort to identify any such rights. Information
583 on the procedures with respect to rights in RFC documents can be
584 found in BCP 78 and BCP 79.
586 Copies of IPR disclosures made to the IETF Secretariat and any
587 assurances of licenses to be made available, or the result of an
588 attempt made to obtain a general license or permission for the use of
589 such proprietary rights by implementers or users of this
590 specification can be obtained from the IETF on-line IPR repository at
591 http://www.ietf.org/ipr.
593 The IETF invites any interested party to bring to its attention any
594 copyrights, patents or patent applications, or other proprietary
595 rights that may cover technology that may be required to implement
596 this standard. Please address the information to the IETF at
597 ietf-ipr@ietf.org.
599 Acknowledgment
601 Funding for the RFC Editor function is provided by the IETF
602 Administrative Support Activity (IASA).