+
+15.2. LoST Relax NG Schema Registration
+
+ URI: urn:ietf:params:xml:ns:lost
+
+ Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
+ (Hannes.Tschofenig@siemens.com).
+
+ Relax NG Schema: The Relax NG schema to be registered is contained
+ in Section 13. Its first line is
+
+ default namespace = "urn:ietf:params:xml:ns:lost1"
+
+ and its last line is
+
+ }
+
+15.3. LoST Namespace Registration
+
+ URI: urn:ietf:params:xml:ns:lost
+
+ Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
+ (Hannes.Tschofenig@siemens.com).
+
+ XML:
+
+ BEGIN
+
+
+
+
+
+ LoST Namespace
+
+
+ Namespace for LoST
+ urn:ietf:params:xml:ns:lost
+ See RFCXXXX
+ [NOTE TO IANA/RFC-EDITOR:
+ Please replace XXXX with the RFC number of this
+ specification.].
+
+
+ END
+
+15.4. Registration Template
+
+ This registration template is in accordance with [8].
+
+ URL scheme name:
+
+ lost
+
+ URL scheme syntax:
+
+ See Section 10
+
+ Character encoding considerations:
+
+ See Section 10
+ Intended Use:
+
+ The intended usage is described in this document.
+
+ Application and protocols which use this scheme:
+
+ The usage of the LoST URL scheme is targeted for this document and
+ hence for location-based services that make use of the mapping
+ protocol specified in this document.
+
+ Interoperability considerations:
+
+ None
+
+ Security considerations:
+
+ See Section 16
+
+ Relevant publications:
+
+ This document provides the relevant context for this URL scheme.
+
+ Contact:
+
+ Hannes Tschofenig, Hannes.Tschofenig@siemens.com
+
+ Author/Change controller:
+
+ The IESG
+
+16. Security Considerations
There are multiple threats to the overall system of which service
mapping forms a part. An attacker that can obtain service contact
URIs can use those URIs to attempt to disrupt those services. An
attacker that can prevent the lookup of contact URIs can impair the
reachability of such services. An attacker that can eavesdrop on the
communication requesting this lookup can surmise the existence of an
emergency and possibly its nature, and may be able to use this to
launch a physical attack on the caller.
- To avoid that an attacker can modify the query or its result, LoST
- RECOMMENDS the use of channel security, such as TLS.
+ To avoid that an attacker can modify the query or its result, the
+ authors RECOMMEND the use of channel security, such as TLS, with
+ LoST.
A more detailed description of threats and security requirements are
provided in [4].
- [Editor's Note: A future version of this document will describe the
- countermeasures based on the security requirements outlined in[4].]
+17. Acknowledgments
-14. Open Issues
+ [Editor's Note: Names need to be added here. Forgot it...Sorry.]
+
+18. Open Issues
Please find open issues at: http://www.ietf-ecrit.org:8080/lost/
-15. References
+19. References
-15.1. Normative References
+19.1. Normative References
[1] World Wide Web Consortium, "XML Schema Part 2: Datatypes",
W3C XML Schema, October 2000,
.
[2] World Wide Web Consortium, "XML Schema Part 1: Structures",
W3C XML Schema, October 2000,
.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, BCP 14, March 1997.
+ Levels", BCP 14, RFC 2119, March 1997.
[4] Taylor, T., "Security Threats and Requirements for Emergency
- Call Marking and Mapping", draft-ietf-ecrit-security-threats-01
- (work in progress), April 2006.
+ Call Marking and Mapping", draft-ietf-ecrit-security-threats-03
+ (work in progress), July 2006.
[5] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies",
- draft-ietf-ecrit-requirements-10 (work in progress), June 2006.
+ draft-ietf-ecrit-requirements-12 (work in progress),
+ August 2006.
[6] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
- draft-ietf-ecrit-service-urn-03 (work in progress), May 2006.
+ draft-ietf-ecrit-service-urn-05 (work in progress),
+ August 2006.
- [7] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
- and DHCPv6) Option for Civic Addresses Configuration
- Information", draft-ietf-geopriv-dhcp-civil-09 (work in
- progress), January 2006.
+ [7] Mealling, M., "The IETF XML Registry",
+ draft-mealling-iana-xmlns-registry-05 (work in progress),
+ June 2003.
- [8] Mealling, M., "The IETF XML Registry",
- draft-mealling-iana-xmlns-registry-03 (work in progress),
- November 2001.
+ [8] Petke, R. and I. King, "Registration Procedures for URL Scheme
+ Names", BCP 35, RFC 2717, November 1999.
- [9] OpenGIS, "Open Geography Markup Language (GML) Implementation
+ [9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
+ January 2005.
+
+ [10] OpenGIS, "Open Geography Markup Language (GML) Implementation
Specification", OGC OGC 02-023r4, January 2003.
- [10] Peterson, J., "A Presence-based GEOPRIV Location Object
+ [11] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
-15.2. Informative References
+ [12] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
+ RFC 3023, January 2001.
- [11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
+ [13] Freed, N. and J. Klensin, "Media Type Specifications and
+ Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+ [14] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+ Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+ [16] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
+ for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-02 (work in
+ progress), April 2006.
+
+ [17] Daigle, L., "Domain-based Application Service Location Using
+ URIs and the Dynamic Delegation Discovery Service (DDDS)",
+ draft-daigle-unaptr-00 (work in progress), June 2006.
+
+19.2. Informative References
+
+ [18] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
- [12] Schulzrinne, H., "Location-to-URL Mapping Architecture and
- Framework", draft-schulzrinne-ecrit-mapping-arch-00 (work in
- progress), October 2005.
+ [19] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
+ and DHCPv6) Option for Civic Addresses Configuration
+ Information", draft-ietf-geopriv-dhcp-civil-09 (work in
+ progress), January 2006.
- [13] Daigle, L. and A. Newton, "Domain-Based Application Service
+ [20] Schulzrinne, H., "Location-to-URL Mapping Architecture and
+ Framework", draft-ietf-ecrit-mapping-arch-00 (work in
+ progress), August 2006.
+
+ [21] Rosen, B. and J. Polk, "Best Current Practice for
+ Communications Services in support of Emergency Calling",
+ draft-rosen-sos-phonebcp-01 (work in progress), June 2006.
+
+ [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+ Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+ Session Initiation Protocol", RFC 3261, June 2002.
+
+ [23] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
+ Methodology for Network Address Translator (NAT) Traversal for
+ Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in
+ progress), August 2006.
+
+ [24] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005.
+Appendix A. Non-Normative RELAX NG Schema in XML Syntax
+
+
+
+
+
+
+ Location-to-Service Translation Protocol (LoST)
+
+ A LoST XML instance has three "root" types:
+ the findServiceByLocation query, the listServices query,
+ and the response to these queries.
+
+
+
+
+
+
+
+
+
+
+ The queries.
+
+
+
+
+
+
+
+
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The response.
+
+
+
+
+
+
+
+ 2xx responses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 3xx, 4xx, and 4xx responses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Query pattern.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ recursive
+
+
+
+
+
+
+
+
+ A result.
+
+
+
+
+ 2xx response.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [0-9]+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Non-result responses.
+
+
+
+
+ 5xx response.
+
+
+
+
+
+
+
+
+
+ 3xx response.
+
+
+
+
+
+
+
+
+
+
+
+
+ 4xx response.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Status pattern.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Patterns for inclusion of elements from schemas in
+ other namespaces.
+
+
+
+
+ A wildcard pattern for including any
+ element from any other namespace.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A point where future extensions
+ (elements from other namespaces)
+ can be added.
+
+
+
+
+
+
+
+
+ A pattern to include the GEOPRIV civil location elements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A definition of civic location from GEOPRIV.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ A pattern to include GML elements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Authors' Addresses
Ted Hardie
Qualcomm, Inc.
Email: hardie@qualcomm.com
Andrew Newton
SunRocket
8045 Leesburg Pike, Suite 300
@@ -913,21 +1772,37 @@
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Phone: +49 89 636 40390
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
-Intellectual Property Statement
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
@@ -937,30 +1812,14 @@
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
Acknowledgment
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).