--- 1/draft-ietf-ecrit-lost-06.txt 2008-02-08 02:12:17.000000000 +0100 +++ 2/draft-ietf-ecrit-lost-07.txt 2008-02-08 02:12:17.000000000 +0100 @@ -1,23 +1,24 @@ ECRIT T. Hardie Internet-Draft Qualcomm, Inc. Intended status: Standards Track A. Newton -Expires: February 11, 2008 TranTech, Inc. +Expires: August 10, 2008 American Registry for Internet + Numbers H. Schulzrinne Columbia University H. Tschofenig Nokia Siemens Networks - August 10, 2007 + February 7, 2008 LoST: A Location-to-Service Translation Protocol - draft-ietf-ecrit-lost-06.txt + draft-ietf-ecrit-lost-07.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,25 +29,25 @@ 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. - This Internet-Draft will expire on February 11, 2008. + This Internet-Draft will expire on August 8, 2008. Copyright Notice - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). Abstract This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. Table of Contents @@ -104,48 +105,50 @@ 17.2. Content-type registration for 'application/lost+xml' . . . 51 17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53 17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53 17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54 18. Security Considerations . . . . . . . . . . . . . . . . . . . 55 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 20.1. Normative References . . . . . . . . . . . . . . . . . . . 58 20.2. Informative References . . . . . . . . . . . . . . . . . . 59 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 60 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74 - Intellectual Property and Copyright Statements . . . . . . . . . . 75 + Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 74 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 + Intellectual Property and Copyright Statements . . . . . . . . . . 76 1. Introduction Protocols such as NAPTR records and the Service Location Protocol (SLP) can be used to discover servers offering a particular service. However, for an important class of services the appropriate specific service instance depends both on the identity of the service and the geographic location of the entity that needs to reach it. Emergency telecommunications services are an important example; here, the service instance is a Public Safety Answering Point (PSAP) that has jurisdiction over the location of the user making the call. The desired PSAP isn't necessarily the one that is topologically or even line-of-sight closest to the caller; rather, it is the one that - serves the callers location based on jurisdictional boundaries. + serves the caller's location based on jurisdictional boundaries. This document describes a protocol for mapping a service identifier - (service URNs) [9] and location information compatible with PIDF-LO - [6], namely revised civic location information [10] and a subset of - the PIDF-LO profile [13] and consequently with the Geo-Shapes [12] - defined for GML [11]) to one or more service URLs. Example service - URL schemes include sip [14], xmpp [15], and tel [16]. While the - initial focus is on providing mapping functions for emergency - services, it is likely that the protocol is applicable to other - service URNs. For example, in the United States, the "2-1-1" and - "3-1-1" service numbers follow a similar location-to-service behavior - as emergency services. + and location information compatible with PIDF-LO PIDF-LO [6] to one + or more service URIs. Service identifiers take the form of the + service URNs described in [9]. Location information here includes + revised civic location information [10] and a subset of the PIDL-LO + profile [13] which consequently includes the Geo-Shapes [12] defined + for GML [11]. Example service URI schemes include sip [14], xmpp + [15], and tel [16]. While the initial focus is on providing mapping + functions for emergency services, it is likely that the protocol is + applicable to other service URNs. For example, in the United States, + the "2-1-1" and "3-1-1" service numbers follow a similar location-to- + service behavior as emergency services. This document names this protocol "LoST", for Location-to-Service Translation. LoST Satisfies the requirements [18] for mapping protocols. LoST provides a number of operations, centered around mapping locations and service URNs to service URLs and associated information. LoST mapping queries can contain either civic or geodetic location information. For civic addresses, LoST can indicate which parts of the civic address are known to be valid or invalid, thus providing address validation, as described in Section 3.5 of [18]. LoST indicates errors in the location data to @@ -345,24 +348,24 @@ 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is an indication that the mapping should not be cached. The value of 'NO-EXPIRATION' is an indication that the mapping does not expire. On occasion, a server may be forced to return an expired mapping if it cannot reach the authoritative server or the server fails to return a usable answer. Clients and servers MAY cache the mapping so that they have at least some information available. Caching servers that have such stale information SHOULD re-attempt the query each time a client requests a mapping. Since the expired mapping will be - returned to the client as a non-error/non-warning response it is the - responsibility of the client to check the 'expires' attribute - associated with mapping data returned in a LoST response to determine - whether the mapping is fresh. + returned to the client as a non-error/non-warning response ,the + client MUST check the 'expires' attribute; if the mapping has + expired, local policy at the client determines whether it discards + the answer and tries again later or uses the possibly stale response. 5.3. Describing the Service with the Element Zero or more elements describe the service with a string that is suitable for display to human users, each annotated with the 'xml:lang' attribute that contains a language tag to aid in the rendering of text. 5.4. The Mapped Service: the Element @@ -458,24 +461,23 @@ 'sips'. 6. Path of a Request: the Element To prevent loops and to allow tracing of request and response paths, all requests that allow recursion include a element that contains one or more elements, each possessing an attribute containing a LoST application unique string (see Section 4). The order of elements corresponds to the order of LoST servers, i.e., the first element identifies the server that initially - received the request from the client issuing the request. The - element is inserted logically on receipt of the request, so that - every server in a recursive query operation is included in the - element. + received the request from the client issuing the request. Every + server in a recursive query operation is included in the + elelment, including the first server to receive it. The server that answers the request instead of forwarding it, such as the authoritative server, copies the element verbatim into the response. The element is not modified in responses as the responses traverses the server chain back to the querying client. If a query is answered iteratively, the querier includes all servers that it has already contacted. When a cached mapping is returned then the element cached @@ -489,21 +491,21 @@ 7. Identifying the Location Element Used for Mapping: Several of the requests can provide one or more elements, among which the server gets to choose. It is useful for the client to be able to determine which one was actually used in producing the result. For that purpose, the tag MUST contain an 'id' attribute that uniquely identifies the element. The format of the identifier is left to the client; it could, for example, use a hash of the location information. The server returns the identifier for the element it used in the - tag. + tag. See Section 8.3.1 for more details. 8. Mapping a Location and Service to URLs: 8.1. Overview The query constitutes the core of the LoST functionality, mapping civic or geodetic locations to URLs and associated data. After giving an example, we enumerate the elements of the query and response. @@ -653,24 +655,24 @@ Figure 5: A civic address answer 8.3. Components of the Request - The request includes attributes that govern whether the - request is handled iteratively or recursively, whether location - validation is performed and which elements may be contained in the - response. + The request includes attributes and elements that + govern whether the request is handled iteratively or recursively, + whether location validation is performed and which elements may be + contained in the response. 8.3.1. The Element The query communicates location information using one or more elements, which MUST conform to a location profile (see Section 12). There MUST NOT be more than one location element for each distinct location profile. The order of location elements is significant; the server uses the first location element where it understands the location profile. @@ -938,20 +940,24 @@ urn:service:sos.animal-control urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.marine urn:service:sos.physician urn:service:sos.poison urn:service:sos.police urn:service:sos.suicide + + + + Figure 13: Example of 11. List Services By Location: A LoST client can ask a LoST server for the list of services it knows about for a particular area. The query contains one or more elements, each from a different location profile (Section 12), and may contain the element. @@ -1021,21 +1027,21 @@ 12. Location Profiles LoST uses location information in elements in requests and elements in responses. Such location information may be expressed in a variety of ways. This variety can cause interoperability problems where a request or response contains location information in a format not understood by the server or the client, respectively. To achieve interoperability, this document defines two mandatory-to-implement baseline location profiles to define the manner in which location information is transmitted. It - is possible to standardize other profiles in the future. The three + is possible to standardize other profiles in the future. The baseline profiles are: geodetic-2d: a profile for two-dimensional geodetic location information, as described in Section 12.2; civic: a profile consisting of civic address location information, as @@ -1149,21 +1155,22 @@ This is possible because both Client X and Server Y understand the baseline profile. - + 42.556844 -73.248157 36.6 42.656844 -73.248157 36.6 42.656844 -73.348157 36.6 42.556844 -73.348157 36.6 @@ -1171,21 +1178,21 @@ 2.4 - + 42.656844 -73.348157 urn:service:sos.police Figure 16: Example of a query with baseline profile interoperability @@ -1208,20 +1215,21 @@ 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 sip:nypd@example.com + 911 Figure 17: Example of a message with baseline profile interoperability @@ -1502,21 +1510,26 @@ POST method. The HTTP request MUST use the Cache-Control response directive "no-cache" to HTTP-level "caching even by caches that have been configured to return stale responses to client requests." All LoST responses, including those indicating a LoST warning or error, are carried in 2xx responses, typically 200 (OK). Other 2xx responses, in particular 203 (Non-authoritative information) may be returned by HTTP caches that disregard the caching instructions. 3xx, 4xx and 5xx HTTP response codes indicates that the HTTP request itself failed or was redirected; these responses do not contain any - LoST XML elements. + LoST XML elements. The 3xx responses are distinct from the redirects + which are described in Section 13.3; the 13.3 redirects occur after a + LoST server processes the request. Where an HTTP-layer redirect will + be general, a LoST server redirect as described in 13.3 might be + specific to a specific service or be the result of other processing + by the LoST server. The HTTP URL is derived from the LoST server name via U-NAPTR application, as discussed above. 15. Relax NG Schema This section provides the Relax NG schema used by LoST protocol in the compact form. The verbose form is included in Appendix A. namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" @@ -1540,54 +1553,54 @@ | getServiceBoundaryResponse | errors | redirect ## ## The queries. ## div { findService = element findService { - element location { locationInformation }+, + requestLocation, commonRequestPattern, attribute validateLocation { xsd:boolean >> a:defaultValue [ "false" ] }?, attribute serviceBoundary { ("reference" | "value") >> a:defaultValue [ "reference" ] }?, attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? } listServices = element listServices { commonRequestPattern } listServicesByLocation = element listServicesByLocation { - element location { locationInformation }*, + requestLocation, commonRequestPattern, attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? } getServiceBoundary = element getServiceBoundary { serviceBoundaryKey, extensionPoint } } ## ## The responses. ## div { findServiceResponse = element findServiceResponse { - mapping+, locationValidation?, commonResponsePattern + mapping+, locationValidation?, commonResponsePattern, locationUsed } listServicesResponse = element listServicesResponse { serviceList, commonResponsePattern } listServicesByLocationResponse = element listServicesByLocationResponse { - serviceList, commonResponsePattern + serviceList, commonResponsePattern, locationUsed } getServiceBoundaryResponse = element getServiceBoundaryResponse { serviceBoundary, commonResponsePattern } } ## ## A pattern common to some of the queries. ## @@ -1596,20 +1609,31 @@ } ## ## A pattern common to responses. ## div { commonResponsePattern = warnings*, path, extensionPoint } ## +## Location in Requests +## +div { + requestLocation = + element location { + attribute id { xsd:token }, + locationInformation + }+ +} + +## ## Location Information ## div { locationInformation = extensionPoint+, attribute profile { xsd:NMTOKEN }? } ## ## Service Boundary @@ -1635,20 +1659,31 @@ ## places through which information flowed ## div { path = element path { element via { source, extensionPoint }+ } } ## +## Location Used +## + +div { + locationUsed = + element locationUsed { + attribute id { xsd:token } + }? +} + +## ## Expires pattern ## div { expires = attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } } ## ## A QName list ## @@ -1663,21 +1698,21 @@ mapping = element mapping { element displayName { xsd:string, attribute xml:lang { xsd:language } }*, service, (serviceBoundary | serviceBoundaryReference)?, element uri { xsd:anyURI }*, element serviceNumber { - xsd:string { pattern = "[0-9*#]+" } + xsd:token { pattern = "[0-9*#]+" } }?, extensionPoint, expires, attribute lastUpdated { xsd:dateTime }, source, attribute sourceId { xsd:token }, message } } @@ -1762,25 +1799,25 @@ message, extensionPoint } } ## ## Some common patterns. ## div { message = - (attribute message { xsd:string }, + (attribute message { xsd:token }, attribute xml:lang { xsd:language })? service = element service { xsd:anyURI }? appUniqueString = - xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } + xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } source = attribute source { appUniqueString } serviceList = element serviceList { list { xsd:anyURI* } } } ## ## Patterns for inclusion of elements from schemas in ## other namespaces. @@ -1901,21 +1939,21 @@ This specification is a work item of the IETF ECRIT working group, with mailing list address . Change controller: The IESG 17.3. LoST Relax NG Schema Registration - URI: urn:ietf:params:xml:ns:lost1 + URI: urn:ietf:params:xml:schema:lost1 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com). Relax NG Schema: The Relax NG schema to be registered is contained in Section 15. Its first line is default namespace = "urn:ietf:params:xml:ns:lost1" and its last line is @@ -1970,22 +2008,26 @@ There are several 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, the use - of channel security, such as TLS, is RECOMMENDED. + To avoid that an attacker can modify the query or its result, TLS + MUST be implemented and SHOULD be used. Use is RECOMMENDED both for + clients' queries to servers and for queries among servers; this + latter recommendation is to help avoid cache poisoning attacks by + replacing answers given to caching servers. The use of server + identity checks is also RECOMMENDED, as described in [4] Generally, authentication and authorization is not required for mapping queries. If it is, authentication mechanism of the underlying transport mechanism, such as HTTP basic and digest authentication, MAY be used. (Basic authentication SHOULD only be used in combination with TLS.) A more detailed description of threats and security requirements are provided in [17]. @@ -2077,20 +2119,22 @@ o Wonsang Song o Jong-Yul Kim o Anna Makarowska o Krzysztof Rzecki o Blaszczyk Piotr + We would like to thank Jon Peterson for his IESG review comments. + 20. References 20.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. @@ -2107,69 +2151,74 @@ [6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [7] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [8] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007. - [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", - draft-ietf-ecrit-service-urn-06 (work in progress), March 2007. + [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency + and Other Well-Known Services", draft-ietf-ecrit-service-urn-07 + (work in progress), August 2007. [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format - for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in - progress), February 2007. + for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in + progress), December 2007. [11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, "Geographic information - Geography Markup Language (GML)", OGC Standard OpenGIS 03-105r1, April 2004. [12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification , December 2006. 20.2. Informative References - [13] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, - Considerations and Recommendations", - draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), - July 2007. + [13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV + PIDF-LO Usage Clarification, Considerations and + Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work + in progress), October 2007. [14] 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. [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004. [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [17] Taylor, T., "Security Threats and Requirements for Emergency - Call Marking and Mapping", draft-ietf-ecrit-security-threats-04 - (work in progress), April 2007. + Call Marking and Mapping", draft-ietf-ecrit-security-threats-05 + (work in progress), August 2007. [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-13 (work in progress), March 2007. [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and - Framework", draft-ietf-ecrit-mapping-arch-02 (work in - progress), July 2007. + Framework", draft-ietf-ecrit-mapping-arch-03 (work in + progress), September 2007. [20] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", - draft-ietf-ecrit-phonebcp-01 (work in progress), March 2007. + draft-ietf-ecrit-phonebcp-03 (work in progress), November 2007. + +URIs + + [21] Appendix A. Non-Normative RELAX NG Schema in XML Syntax @@ -2194,25 +2243,21 @@
The queries. - - - - - + false @@ -2232,25 +2277,21 @@ - - - - - + true @@ -2260,44 +2301,45 @@
The responses. - + + @@ -2326,20 +2368,37 @@
+ Location in Requests + + + + + + + + + + + + +
+ +
+ Location Information @@ -2397,20 +2456,36 @@
+ Location Used + + + + + + + + + + + +
+ +
+ Expires pattern NO-CACHE NO-EXPIRATION @@ -2454,21 +2528,21 @@ - + [0-9*#]+ @@ -2518,20 +2592,23 @@ + + + @@ -2584,26 +2660,33 @@ + + + + + + + @@ -2678,21 +2761,21 @@
Some common patterns. - + @@ -2694,23 +2777,22 @@ - - + ([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+ @@ -2773,62 +2855,67 @@ can be added.
+ Figure 25 +Appendix B. Examples On-line + + The XML examples and Relax NG schemas may be found on-line [21]. + Authors' Addresses Ted Hardie Qualcomm, Inc. Email: hardie@qualcomm.com Andrew Newton - TranTech, Inc. - 4900 Seminary Road, Suite 215 - Alexandria, VA 22311 + American Registry for Internet Numbers + 3635 Concorde Parkway, Suite 200 + Chantilly, VA 20151 US - Phone: +1 703 671 9873 + Phone: +1 703 227 9894 Email: andy@hxr.us Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu Hannes Tschofenig Nokia Siemens Networks - Otto-Hahn-Ring 6 - Munich, Bavaria 81739 - Germany + Linnoitustie 6 + Espoo 02600 + Finland - Phone: +49 89 636 40390 + Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com Full Copyright Statement - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF