--- 1/draft-ietf-ecrit-lost-01.txt 2006-10-24 22:12:32.000000000 +0200 +++ 2/draft-ietf-ecrit-lost-02.txt 2006-10-24 22:12:32.000000000 +0200 @@ -1,23 +1,23 @@ Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. Intended status: Standards Track A. Newton -Expires: March 8, 2007 SunRocket +Expires: April 25, 2007 SunRocket H. Schulzrinne Columbia U. H. Tschofenig Siemens - September 4, 2006 + October 22, 2006 LoST: A Location-to-Service Translation Protocol - draft-ietf-ecrit-lost-01.txt + draft-ietf-ecrit-lost-02.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,1116 +28,1354 @@ 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 March 8, 2007. + This Internet-Draft will expire on April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes an XML-based protocol for mapping service - identifiers and geospatial or civic location information to 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 - 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4. Resolving Service URNs Using LoST . . . . . . . . . . . . . . 8 - 5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5.1. Location Information Element . . . . . . . . . . . . . . . 9 - 5.2. Service Element . . . . . . . . . . . . . . . . . . . . . 9 - 5.3. Validate Attribute . . . . . . . . . . . . . . . . . . . . 9 - 5.4. Query Message Examples . . . . . . . . . . . . . . . . . . 9 - 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 6.1. Uniform Resource Identifiers (URI) Element . . . . . . . . 11 - 6.2. Display Name Element . . . . . . . . . . . . . . . . . . . 11 - 6.3. Service Element . . . . . . . . . . . . . . . . . . . . . 11 - 6.4. ServiceBoundary Element . . . . . . . . . . . . . . . . . 12 - 6.5. ServiceNumber Element . . . . . . . . . . . . . . . . . . 12 - 6.6. TimeToLive Attribute . . . . . . . . . . . . . . . . . . . 12 - 6.7. Validation Element . . . . . . . . . . . . . . . . . . . . 12 - 6.8. Response Message Examples . . . . . . . . . . . . . . . . 12 - 7. List Services Query and Response . . . . . . . . . . . . . . . 15 - 7.1. List Service Query . . . . . . . . . . . . . . . . . . . . 15 - 7.2. List Service Response . . . . . . . . . . . . . . . . . . 15 - 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17 - 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 17 - 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 17 - 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 17 - 8.2.2. 201 Service Substitution . . . . . . . . . . . . . . . 17 - 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 17 - 8.3.1. 301 Move Permanently . . . . . . . . . . . . . . . . . 17 - 8.3.2. 302 Moved Temporarily . . . . . . . . . . . . . . . . 18 - 8.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 18 - 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 18 - 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 18 - 8.4.2. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 18 - 8.4.3. 404 Not Found . . . . . . . . . . . . . . . . . . . . 18 - 8.4.4. 414 Location Error . . . . . . . . . . . . . . . . . . 18 - 8.4.5. Example . . . . . . . . . . . . . . . . . . . . . . . 18 - 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 20 - 8.5.1. 500 Server Internal Error . . . . . . . . . . . . . . 20 - 8.5.2. 501 Service Not Implemented . . . . . . . . . . . . . 20 - 8.5.3. 504 Server Time-Out . . . . . . . . . . . . . . . . . 21 - 8.5.4. Example . . . . . . . . . . . . . . . . . . . . . . . 21 - 9. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 22 - 10. LoST Uniform Resource Locators . . . . . . . . . . . . . . . . 23 - 11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 12. Deployment Methods . . . . . . . . . . . . . . . . . . . . . . 26 - 13. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 28 - 14. Internationalization Considerations . . . . . . . . . . . . . 33 - 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 - 15.1. Content-type registration for 'application/lost+xml' . . . 34 - 15.2. LoST Relax NG Schema Registration . . . . . . . . . . . . 35 - 15.3. LoST Namespace Registration . . . . . . . . . . . . . . . 36 - 15.4. Registration Template . . . . . . . . . . . . . . . . . . 36 - 16. Security Considerations . . . . . . . . . . . . . . . . . . . 38 - 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 - 18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 - 19.1. Normative References . . . . . . . . . . . . . . . . . . . 41 - 19.2. Informative References . . . . . . . . . . . . . . . . . . 42 - Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 43 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 - Intellectual Property and Copyright Statements . . . . . . . . . . 52 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 8 + 5. LoST Uniform Resource Locators and Their Resolution . . . . . 9 + 6. Mapping a Location and Service to URLs: . . . . 10 + 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 10 + 6.2.2. Civic Address Mapping Example . . . . . . . . . . . . 11 + 6.3. Components of Request . . . . . . . . . . . 13 + 6.3.1. The Element . . . . . . . . . . . . . . . . 13 + 6.3.2. The Element . . . . . . . . . . . . . . . . 13 + 6.3.3. Recursion or Redirection . . . . . . . . . . . . . . . 13 + 6.3.4. Configuring the Response . . . . . . . . . . . . . . . 14 + 6.4. Components of the Mapping Response + . . . . . . . . . . . . . . . . . . 16 + 6.4.1. Source of Response: Element . . . . . . . . . . 16 + 6.4.2. Service URLs: the Element . . . . . . . . . . . 16 + 6.4.3. Describing the Service with the + Element . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.4.4. Approximating Services: the Element . . . . 17 + 6.4.5. Defining the Service Region with the + Element . . . . . . . . . . . . . . 17 + 6.4.6. Service Boundaries by Reference: the + Element . . . . . . . . . . 17 + 6.4.7. The Service Number . . . . . . . . . . . . . . . . . . 18 + 6.4.8. Civic Address Validation . . . . . . . . . . . . . . . 18 + 6.4.9. Validity: The 'timeToLive' Attribute . . . . . . . . . 18 + 7. Retrieving the Service Boundary via . . . 19 + 8. List Services: . . . . . . . . . . . . . . . . 21 + 9. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 23 + 9.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 23 + 9.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 26 + 9.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 26 + 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 27 + 10.1. Basic Errors . . . . . . . . . . . . . . . . . . . . . . . 27 + 10.2. Response Errors . . . . . . . . . . . . . . . . . . . . . 27 + 10.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 28 + 11. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 29 + 12. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 30 + 13. Internationalization Considerations . . . . . . . . . . . . . 37 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 + 14.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 38 + 14.2. Content-type registration for 'application/lost+xml' . . . 38 + 14.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 40 + 14.4. LoST Namespace Registration . . . . . . . . . . . . . . . 40 + 14.5. Registration Template . . . . . . . . . . . . . . . . . . 41 + 14.6. LoST Location Profile Registry . . . . . . . . . . . . . . 42 + 15. Security Considerations . . . . . . . . . . . . . . . . . . . 43 + 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 + 17. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45 + 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 + 18.1. Normative References . . . . . . . . . . . . . . . . . . . 46 + 18.2. Informative References . . . . . . . . . . . . . . . . . . 47 + Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 48 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 + Intellectual Property and Copyright Statements . . . . . . . . . . 62 1. Introduction This document describes a protocol for mapping a service identifier - [6] and location information compatible with PIDF-LO [11] to one or - more service contact URIs. Example contact URI schemes include sip, - xmpp, and tel. While the initial focus is on providing mapping - functions for emergency services, it is likely that the protocol is - applicable to any service URN. For example, in the United States, - the "2-1-1" and "3-1-1" services follow a similar location-to-service - behavior as emergency services. - - This document names this protocol usage "LoST" for Location-to- - Service Translation Protocol. The features of LoST are: - - o Supports queries using civic as well as geospatial location - information. - - o Support for recursive and iterative resolution. - - o Support for address validation. - - o A hierarchical deployment of mapping servers is independent of - civic location labels. - - o Indication of errors in the location data to facilitate debugging - and proper user feedback while simultaneously providing best- - effort answers. - - o Mapping can be based on either civic or geospatial location - information, with uniform protocol treatment of both. - - o Support for overlapping service regions. + [10] and location information compatible with PIDF-LO [8] to one or + more service contact URIs. Example contact 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 any service URN. For example, in the + United States, the "2-1-1" and "3-1-1" services follow a similar + location-to-service behavior as emergency services. - o Satisfies the requirements [5] for mapping protocols. + 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 URIs 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. LoST indicates errors in + the location data to facilitate debugging and proper user feedback, + but also provides best-effort answers. - o Minimizes round trips by caching individual mappings and by - supporting return of coverage regions ("hinting"). + LoST queries can be resolved recursively or iteratively. To minimize + round trips, LoST caches individual mappings and indicates the region + for which the same answer would be returned ("service region"). - o Facilitates reuse of Transport Layer Security (TLS). + As currently defined, LoST messages are carried in HTTP and HTTPS + protocol exchanges, facilitating use of TLS for protecting the + integrity and confidentiality of requests and responses. This document focuses on the description of the protocol between the mapping client (seeker or resolver) and the mapping server (resolver or other servers). The relationship between other functions, such as discovery of mapping servers, data replication and the overall - mapping server architecture in general, will be described in a - separate document. [20] is a first attempt to describe such a mapping - server architecture. - - The high-level protocol operation can be described as follows: - - Location - Info +----------+ - --------> | | - Service | LoST | - URN | Server | - --------> | | - +----------+ - - Query - - URI +----------+ - <------- | | - Optional | LoST | - Info (hints)| Server | - <------- | | - +----------+ - - Response - - Figure 1: Overview + mapping server architecture are described in a separate document + [19]. The query message carries location information and a service - identifier encoded as a Uniform Resource Name (URN) (see [6]) from + identifier encoded as a Uniform Resource Name (URN) (see [10]) from the LoST client to the LoST server. The LoST server uses its - database to map the input values to a Uniform Resource Identifiers - (URI) and returns it including optional information such as hints - about the service boundary in a response message back to the LoST - client. + database to map the input values to one or more Uniform Resource + Identifiers (URI) and returns those URIs along with optional + information such as hints about the service boundary in a response + message to the LoST client. If the server cannot resolve the query + itself, it may in turn query another server or return the address of + another LoST server, identified by a LoST URL (Section 5). In + addition to the mapping function described in Section 6, the protocol + also allows to retrieve the service boundary Section 7 and to list + the services available for a particular location Section 8. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [3]. + document are to be interpreted as described in [1]. -3. Usage +3. Terminology - The client queries a server, indicating the desired service and - location information. If the query succeeds, the server returns a - result that includes one or more URIs for reaching the appropriate - service for the location indicated. Depending on the query, the - result may contain a service boundary where the same mapping would - apply, a reference to another server to which the client should send - a query, or an error messages indicating problems. The combination - of these components are left to the needs and policy of the - jurisdiction where the server is being operated. + This document furthermore uses the terminology defined in [18]. + + In examples, the XML sent by the client is prepended with "C:" and + the XML sent by the server is prepended with "S:". + +4. Overview of Protocol Usage The client may perform the mapping at any time. Among the common - triggers for mapping are: + triggers for mapping requests are: - 1. When the client starts up and/or attaches to a new network - location. + 1. When the client initially starts up or attaches to a network. 2. When the client detects that its location has changed - sufficiently that it is outside the bounds of the region returned - in an earlier query. + sufficiently that it is outside the bounds of the service region + returned in an earlier LoST query. 3. When cached mapping information has expired. - 4. When calling for a particular service. During such calls, a - client may want to request a short response that contains only - the mapping data, omitting service boundary information. + 4. When invoking a particular service. At that time, a client may + omit requests for service boundaries or other auxiliary + information. - Cached answers are expected to be used by clients only after failing - to accomplish a location-to-URI mapping at call time. Cache entries - may expire according to their time-to-live value, or they may become - invalid if the location of the caller's device moves outside the - boundary limits of the cache entry. Boundaries for cache entries may - be set in both geospatial and civic terms. + A service-specific BCP such as [20] governs whether a client is + expected to invoke the mapping service just before needing the + service or whether to rely on cached answers. Cache entries expire + according to their time-to-live value (see Section 6.4.9, or they + become invalid if the caller's device moves beyond the boundaries of + the service region. -4. Resolving Service URNs Using LoST +5. LoST Uniform Resource Locators and Their Resolution + + LoST servers are identified by LoST Uniform Resource Locators (URLs), + which follow the format of URLs defined in RFC 3986 [7], with the + following ABNF: + + LoST-URI = "lost:" host + + 'host' is defined in Section 3.2.2 of RFC 3986 [7]. + + An example is 'lost:lostserver.example.com' If a LoST URL contains a host name rather than an IP address, clients - need to perform an U-NAPTR [17] lookup to obtain a DNS A record and - IP address. These records map the 'host' part of the LoST URL to one - or more URLs indicating the protocol to carry the LoST request. In - this document, only the HTTP and HTTPS URL schemes are defined. Note - that the HTTP URL can be any valid HTTP URL, including those - containing path elements. + need to use U-NAPTR [12] using the U-NAPTR specification described + below to obtain a URI (indicating host and protocol) for the + applicable LoST service. In this document, only the HTTP and HTTPS + URL schemes are defined. Note that the HTTP URL can be any valid + HTTP URL, including those containing path elements. - Here is an example: + The following two DNS entries resolve the LoST URL "lost:example.com" + to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL + http://lostserver.example.com, with the former being preferred. example.com. IN NAPTR 100 10 "u" "LoST:https" "!*.!https://lostserver.example.com/secure!" "" IN NAPTR 200 10 "u" "LoST:http" "!*.!http://lostserver.example.com!" "" -5. Query - - LoST provides the ability to use civic or geospatial location - information in the query message. In addition to location - information the query also contains a service identifier. An - optional parameter might furthermore request the LoST server to - validate location information. - -5.1. Location Information Element - - LoST supports a query using geospatial and civic location information - using the query. Geospatial location - information uses GML format [10] and civic location information - utilizes the format defined in [16]. This document does not define - location formats. - -5.2. Service Element - - The type of service desired is specified by the element. - The (emergency) service identifiers listed in the registry - established with [6] will be used in this document. - - The element is a mandatory element. In case the database - at the LoST server does not provided service for the specific - geographical region the LoST server has various choices with regard - to the response: +6. Mapping a Location and Service to URLs: - o It can send an error response. +6.1. Overview - o It can map one service to another one, if appropriate, and return - a different service identifier as described in Section 6.3. + 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. - o It can populate the URIs of one service to another service. +6.2. Examples - The operation of the LoST server is largely a policy issue. No - behavior is mandated in this document. Guidelines for operating a - LoST server for emergency services is provided in [21]. +6.2.1. Example Using Geodetic Coordinates -5.3. Validate Attribute + The following is an example of mapping a service to a location using + geodetic coordinates, for the service associated with the police + (urn:service:sos.police). - The 'validate' attribute implements the validation behavior described - in [5]. + + + + + 40.8089897 -73.9612492 + + + urn:service:sos.police + -5.4. Query Message Examples + Figure 2: A Geodetic Query - This section shows an example of a query message providing geospatial - and civic location information. + Given the query above, a server would respond with a service, and + information related to that service. In the example below, the + server has mapped the location given by the client for a police + service to the New York City Police Deparment, instructing the client + that it may contact them via the URIs sip:nypd@example.com and + xmpp:nypd@example.com. The server has also given the client a + geodetic, two-dimensional boundary for this service and time-to-live + value of 3,600 seconds. This instructs the client that if its + location changes beyond the give service boundary or if 3,600 seconds + has elapsed, it would need to requery for this information. - - - - 37:46:30N 122:25:10W - - + + + New York City Police Department + urn:service:sos.police - + + + + + 37.775 -122.4194 + 37.555 -122.4194 + 37.555 -122.4264 + 37.775 -122.4264 + 37.775 -122.4194 + + + + + sip:nypd@example.com + xmpp:nypd@example.com + 911 + - Figure 3: Query Message Example using Geospatial Location Information + Figure 3: A Geodetic Answer - The example above shows a query using geospatial location information - with no validation required and asking for the - 'urn:service:sos.police' service. +6.2.2. Civic Address Mapping Example + + The following is an example of mapping a service to a location much + like the example in Section 6.2.1, but using civic address location + information. In this example, the client requests the service + associated with police (urn:service:sos.police) along with a specific + civic address (house number 96 on a street named Neu Perlach in + Munich, Germany). - - - + + + Germany Bavaria Munich Neu Perlach 96 81675 - - + + urn:service:sos.police - - - Figure 4: Query Message Example using Civic Location Information - - The example above shows a query using a civic location in Munich - asking for the 'urn:service:sos.police' service. The query indicates - that validation is not desired and the query has to be executed - recursively. - -6. Response - - A response message might either contain civic or geospatial location - information depending on the type of the query. If the - findServiceByLocation query message contained civic location - information then the element of the response - message will also contain civic information. If the - findServiceByLocation query message contained geospatial location - information then the element of the response - message will contain a GML polygon. More information about the - element can be found at Section 6.4. - -6.1. Uniform Resource Identifiers (URI) Element - - Each element contains an appropriate contact URI for the - service for which mapping was requested. elements are of type - xs:anyURI. In the emergency service context operators are strongly - discouraged from using relative URIs, even though these are permitted - by the type. + -6.2. Display Name Element + Figure 4: A Civic Address Query - Each element contains a string that is suitable for - display. elements are of type "text" that is suitable - for internationalized human-readable text. + Given the query above, a server would respond with a service, and + information related to that service. In the example below, the + server has mapped the location given by the client for a police + service to the Mȭnchen Polizei-Abteilung, instructing the client + that it may contact them via the URIs sip:munich-police@example.com + and xmpp:munich-police@example.com. The server has also given the + client a civic address boundary (the city of Munich) for this service + and time-to-live value of 3,600 seconds. This instructs the client + that if its location changes beyond the give service boundary (i.e. + beyond the city of Munich) or if 3,600 seconds has elapsed, it would + need to requery for this information. -6.3. Service Element + + + + Mȭnchen Polizei-Abteilung + + urn:service:sos.police + + + Germany + Bavaria + Munich + 81675 + + + sip:munich-police@example.com + xmpp:munich-police@example.com + 110 + - The element is an optional element in the response message. - The (emergency) service identifiers listed in the registry - established with [6] will be used in this document. If the service - that was requested by the LoST client is not available for a - particular location then the server MAY return an alternate service. - If it does so, it MUST indicate the actual service returned (i.e., - its service URN). Alternatively, the LoST server MAY return an error - response indicating that the requested service is not available. + Figure 5: A Civic Address Answer - The following example illustrates the main idea. If there is a - region that only understands the 'urn:service:sos' service and not - 'urn:service:sos.fire', 'urn:service:sos.ambulance', and - 'urn:service:sos.police'. If a LoST client asks for the - 'urn:service:sos.fire' service then the LoST server could, depending - on the local policy at the LoST server, return: +6.3. Components of Request - 1. 'urn:service:sos', or +6.3.1. The Element - 2. 'urn:service:sos.fire' with the values of 'urn:service:sos' being - populated to 'urn:service:sos.fire', or - 3. an error message + The query communicates location using one or more + elements, which MUST conform to a location profile + (Section 9). - In case of (1) the element carries the value of - 'urn:service:sos'. +6.3.2. The Element -6.4. ServiceBoundary Element + The type of service desired is specified by the element. + It contains service URNs from the registry established in [10]. - Each element contains either one or more civic - location elements derived from the GeoPriv civic address schema or a - GML-based polygon. +6.3.3. Recursion or Redirection - The element indicates where the same query would - yield to the same response, i.e., it provides information about the - service boundary. + LoST queries can be recursive or iterative, as + indicated by the 'recursive' attribute. A value of "true" indicates + a recursive query, a value of "false" an iterative query, with + iterative being the default. When the LoST server cannot answer the + query and the query requested iterative resolution, it will return an + (Section 10.3) error message with the LoST + URI pointing to a different LoST server that the LoST client should + contact. In recursive mode, the LoST server initiates a query and + returns the result to the original querier, inserting a element + to track the response chain. -6.5. ServiceNumber Element +6.3.4. Configuring the Response - TBD: This element contains the (emergency) service number, which is a - string of digits used to reach the (emergency) service. + The 'include' attribute enumerates all the XML elements that the + client wants the LoST server to provide in the mapping response. The + server ignores any element names that it does not understand. The + ordering of the tokens is immaterial. -6.6. TimeToLive Attribute + Among other features, it determines whether service boundaries are + returned and whether they are returned by value or reference + Section 7, and whether to validate civic locations. - Each timeToLive attribute is a positive integer, expressing the - validity period of the response in seconds. The LoST client MUST NOT - consider the returned location current after the expiration of the - validity period. + Address validation is requested by including the XML element names + that provide address validation in the 'include' attribute, namely + 'valid', 'invalid' and 'unchecked'. The following example + demonstrates address validation. -6.7. Validation Element + C: + C: + C: + C: + C: Germany + C: Bavaria + C: Munich + C: Neu Perlach + C: 96 + C: 81675 + C: + C: + C: urn:service:sos.police + C: - The element contains a string that is composed of - concatenated tokens separated by a whitespace. These tokens refer to - the civic location labels used in child elements of the - element from the request that have been recognized as - valid by the server. + S: + S: + S: + S: Mȭnchen Polizei-Abteilung + S: + S: urn:service:sos.police + S: + S: + S: Germany + S: Bavaria + S: Munich + S: 81675 + S: + S: + S: sip:munich-police@example.com + S: xmpp:munich-police@example.com + S: 110 + S: country A1 A3 A6 + S: PC + S: - The following code snippet indicates that the civic address labels - 'country', 'A1', 'A3', 'A6, 'PC' have been valided by the LoST - server. + Figure 6: Address Validation Exchange - country A1 A3 A6 PC +6.4. Components of the Mapping Response -6.8. Response Message Examples +6.4.1. Source of Response: Element - This section shows an example of a query message providing geospatial - and civic location information. + A indicates the source of the response by + including a element with a LoST URL as the first element. + Thus, each server "initials" its own response. Thus, responses to + iterative queries contain one element, while responses to + recursive queries may reach the original querier with multiple + elements, one for each server that was used in the resolution. The + following example illustrates the use of : - - - - New York City Police Department + + lost:esgw.uber-110.de.example + lost:polizei.munchen.de.example + + Mȭnchen Polizei-Abteilung urn:service:sos.police - - - - - 37.775 -122.4194 - 37.555 -122.4194 - 37.555 -122.4264 - 37.775 -122.4264 - 37.775 -122.4194 - - - - - sip:nypd@example.com - xmpp:nypd@example.com - 911 - - - - Figure 6: Response Message Example using Geospatial Location Service - Boundary Hints - - This example shows a response with two URIs for the previously - queried service URN. Information about the service boundary is - provided by a GML polygon. The element indicates the - valid service number for the expressed location and service URN. - - - - - Munich Police Department - urn:service:sos.police - - + + Germany Bavaria Munich 81675 - + sip:munich-police@example.com xmpp:munich-police@example.com - 110 - - + 110 + - Figure 7: Response Message Example providing Civic Location Service - Boundary Hints + Figure 7: An Example of a Response Using - This example shows a response that returns two URIs (one for SIP and - another one for XMPP), a distring that indicates the valid distring - for the location provided in the query, a hint about the service - boundary in the element and information about the - validated civic address fields. The timeToLive attribute indicates - that the returned information can be cached for 10000 seconds and - provides a * element with additional, textual - information about the returned information. + The example above indicates that the this answer was given to the + responding server by the LoST server at esgw.uber-110.de.example, + which got the answer from the LoST server at + polizei.munchen.de.example. -7. List Services Query and Response +6.4.2. Service URLs: the Element -7.1. List Service Query + The response returns the service URLs in one or more elements. + The URLs MUST be absolute URLs. - This subsection describes a mechanism that offers the LoST client to - query for available service identifiers supported by the LoST server. - The listServices query MUST carry the and the - element. The LoST server MUST return only immediate child - elements of the service identifier specified in the element - of the listServices query available for the provided location - information. +6.4.3. Describing the Service with the Element - - + The element describes the service with a string that is + suitable for display to human users, annotated with the 'xml:lang' + attribute that contains a language tag to aid in the rendering of + text. - - - 37:46:30N 122:25:10W - - - urn:service:sos - +6.4.4. Approximating Services: the Element - Figure 8: Example for a List Service Query + If the requested service, identified by the service URN [10] in the + element in the request, does not exist for the location + indicated, the server can either return an + (Section 10.2) error or can provide an alternate service that + approximates the desired service for that location. In the latter + case, the server MUST include a element with the + alternative service URN. The choice of service URN is left to local + policy, but the alternate service should be able to satisfy the + original service request. - This listService query aims to query the immediate child elements of - the 'urn:service:sos' URN. +6.4.5. Defining the Service Region with the Element -7.2. List Service Response + A response can indicate the region for which the service URL returned + would be the same as in the actual query, the so-called service + region. The service region can be indicated by value or by reference + Section 6.4.6. If a client moves outside the service area, it MUST + send a new query with its current location to obtain valid service + data. The service region is described by value in one or more + elements, each formatted according to a different + location profile. The client only processes the first element that + it can understand according to its list of supported location + profiles. Thus, the elements are alternative descriptions of the + same service region, not additive geometries. - This subsection describes the response message that provides the LoST - client with the list of immediate child service identifiers based on - the service identifier provided by LoST client with respect to the - location information provided in the listService query. + The server returns all suitable service regions, using all available + location profiles, so that intermediate caches have this information + available for future queries. - The following example shows the response to the listServices query - example of Figure 8 listing the available services offered by the - LoST server starting with 'urn:service:sos.ambulance' and finishing - with 'urn:service:sos.suicide'. +6.4.6. Service Boundaries by Reference: the + Element - - - - urn:service:sos.ambulance - 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 - - + Since geodetic service boundaries may contain thousands of points and + thus be quite large, clients may opt to conserve bandwidth and + request a reference to the service boundary instead of the value + described in Section 6.4.5. The identifier of the service boundary + is returned in the element, along with a + LoST URL identifying the server from where it can be retrieved. The + actual value of the service boundary is then retrieved with the + getServiceBoundary (Section 7) request. - Figure 9: Example for the Response to a List Service Query + The identifier is a random token with at least 128 bits of entropy + and can be assumed to be globally unique. The identifier uniquely + references a particular boundary; if the boundary changes, a new + identifier must be chosen. Because of these properties, a client + receiving a mapping response can simply check if it already has a + copy of the boundary with that identifier. If so, it can skip + checking with the server whether the boundary has been updated. + Since service boundaries are likely to remain unchanged for extended + periods of time, possibly exceeding the normal lifetime of the + service URL, this approach avoids refreshing the boundary information + even if the cached service response has gotten stale. -8. Status Code Definitions +6.4.7. The Service Number - Each response contains a element that conveys a numeric - status code and a reason phrase indicating the success or failure of - the response. The appearance of other elements in the response - depends on the status code. Hence, different elements are used for - groups of status codes. + The service number is returned in the optional + element. It contains a string of digits, * and # that a user on a + device with a 12-key dial pad could use to reach that particular + service. - Status codes always have three digits; the list of status codes is - meant to be extensible by IANA registration and follows the general - pattern of the Session Initiation Protocol (SIP) [22] and HTTP [14]. - The first digit indicates the type of response, with '2' signaling a - successful request, '3' a redirection, '4' a request failure due to - client behavior, and '5' a server failure. +6.4.8. Civic Address Validation - If used within HTTP, LoST also utilizes the normal HTTP status codes. - However, the HTTP request can succeed, while the LoST request caused - an error. All LoST status codes appear in HTTP 200 (OK) responses. - For example, a LoST 404, 414 or 500 status would occur in an HTTP 200 - response. + A server can indicate in its response which civic address elements it + has recognized as valid, which ones it has ignored and which ones it + has checked and found to be invalid. Each element contains a list of + tokens separated by white space, enumerating the civic location + lables used in child elements of the element. The + element enumerates those civic address elements that have + been recognized as valid by the LoST server and that have been used + to determine the mapping. The elements enumerates the + civic address elements that the server did not check and that were + not used in determining the response. The element + enumerate civic address elements that the server attempted to check, + but that did not match the other civic address elements found in the + list. - Temporary unavailability of the service should be indicated by an - HTTP 505 (Service Unavailable) status code. + The example (Figure 6) indicates that the tokens 'country', 'A1', + 'A3', and 'A6' have been validated by the LoST server. The server + considered the postal code 81675 in the element as not valid for + this location. - [Editor's Note: Does this make any sense or should all or some LoST - errors occur in a non-200 HTTP response?] +6.4.9. Validity: The 'timeToLive' Attribute -8.1. Informational 1xx + The timeToLive attribute contains the number of seconds the response + is to be considered valid. The contents of this attribute is a + positive integer. See Section 4 regarding how this value is to be + utilized with a cache. [TBD: This could also be an absolute time.] - This document does not define informational status codes. +7. Retrieving the Service Boundary via -8.2. Successful 2xx + As discussed in Section 6.4.5, the response can return + a globally unique identifier that can be used to retrieve the service + boundary, rather than returning the boundary by value. This is shown + in the example in Figure 8. The client can then retrieve the + boundary using the request and obtains the + boundary in the , illustrated in the + example in Section 7. The client issues the request to the server + identified in the 'server' attribute of the + element. -8.2.1. 200 OK + C: + C: + C: + C: + C: 40.809 -73.9612 + C: + C: + C: urn:service:sos.police + C: - The query completed successfully. + S: + S: + S: + S: New York City Police Department + S: + S: urn:service:sos.police + S: + S: sip:nypd@example.com + S: xmpp:nypd@example.com + S: 911 + S: -8.2.2. 201 Service Substitution + Figure 8: findService with Service Boundary Reference + C: + C: - The service requested is not available for the location requested, - but the server is configured to provide a replacement service. + S: + S: + S: + S: + S: + S: + S: + S: 40.701 -74.020 + S: 40.876 -73.926 + S: 40.797 -73.936 + S: 40.714 -73.984 + S: 40.701 -74.020 + S: + S: + S: + S: + S: + S: -8.3. Redirection 3xx + Figure 9: Requesting a Service Boundary with getServiceBoundary -8.3.1. 301 Move Permanently + The request may also be used to retrieve service + boundaries that are expressed as civic addresses, as illustrated in + Figure 10. - The requested location is being mapped by a different server and all - future requests for that location (and locations in the service area) - should be directed to that server. + + + + + US + New York + New York + + + -8.3.2. 302 Moved Temporarily + Figure 10: Civic Address Service Boundary Response - The requested location is being mapped by a different server, but - future requests should continue to use this server. +8. List Services: -8.3.3. Example + A LoST client can ask a LoST server for the list of services it + supports. The query contains one or more + elements, each from a different location profile (Section 9), and may + contain the element. If the query contains the + element the LoST server returns only immediate child services of the + queried service that are available for the provided location. If the + element is absent, the LoST service returns all top-level + services available for the provided location that it knows about. - This is an example of an error message with a 302 status code: + A server responds to this query with a + response. This response has may contain elements + (Section 6.4.1) and must contain a element, consisting + of a whitespace-separated list of service URNs. The query and + response are illustrated in Figure 11. - - - + C: + C: + C: + C: + C: 37:46:30N 122:25:10W + C: + C: + C: urn:service:sos + C: -8.4. Client Error 4xx + S: + S: + S: + S: urn:service:sos.ambulance + S: urn:service:sos.animal-control + S: urn:service:sos.fire + S: urn:service:sos.gas + S: urn:service:sos.mountain + S: urn:service:sos.marine + S: urn:service:sos.physician + S: urn:service:sos.poison + S: urn:service:sos.police + S: urn:service:sos.suicide + S: + S: + Figure 11: ListService Query Example -8.4.1. 400 Bad Request +9. Location Profiles - The request could not be understood due to malformed syntax. + Currently, 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 + client, respectively. To achieve interoperability, LoST defines two + must-implement baseline location profiles to define the manner in + which location information is transmitted and makes it possible to + standardize other profiles in the future. The two baseline profiles + are: -8.4.2. 403 Forbidden + geodetic-2d: a simple profile for two-dimensional geodetic location + information, described in Section 9.2); - The server understood the request, but is refusing to fulfill it. - Authorization will not help, and the request SHOULD NOT be repeated. + civic: a profile consisting of civic address location information, + described in Section 9.3. -8.4.3. 404 Not Found + Requests and responses containing or + elements MUST contain location information in exactly one of the two + baseline profiles, in addition to zero or more additional profiles. + The ordering of location information indicates a preference on the + part of the sender. - The server has definitive information that there is no service - mapping for the location specified. + Standards action may create other profiles. A location profile MUST + define: -8.4.4. 414 Location Error + 1. The token identifying it in the LoST location profile registry; - The location provided does not exist or fields within the location - information are contradictory. + 2. The formal definition of the XML to be used in requests, i.e., an + enumeration and definition of the XML child elements of the + element; -8.4.5. Example + 3. The formal definition of the XML to be used in responses, i.e., + an enumeration and definition of the XML child elements of the + the element; - The first example shows an error message with a 414 status code that - is attached to the response message indicating that there was a - problem with the postal code: + 4. The declaration of whether geodetic-2d or civic is to be used as + the baseline profile. It is necessary to explicitly declare the + baseline profile as future profiles may be combinations of + geodetic and civic location information. - - - - - New York City Police Department - - unknown - - - US - New York - New York - - - sip:nypd@example.com - xmpp:nypd@example.com - 911 - - - - - +9.1. Location Profile Usage - The second example shows an error message with a 414 status code that - is attached to the response message indicating that there was a - problem with the provided geospatial location information: + A location profile is identified by a URN in the + urn:ietf:params:lost:location-profile registry. (Note that this is + not an XML schema or namespace identifier.) Clients send location + information compliant with a location profile, and servers respond + with location information compliant with that same location profile. - - - - - New York City Police Department - - urn:service:sos.police - - - - - 37.775 -122.4194 - 37.555 -122.4194 - 37.555 -122.4264 - 37.775 -122.4264 - 37.775 -122.4194 - - - - - sip:nypd@example.com - xmpp:nypd@example.com - 911 - - - - - + When a LoST client sends a request which provides location + information, it contains one or more elements. Each of + these elements contains location information compliant with a + location profile and specifies which profile has been used in the + 'profile' attribute. This allows the client to convey location + information for multiple location profiles in the same request. -8.5. Server Error 5xx + When a LoST server sends a response which contains location + information, it uses the elements much like the + client uses the elements. Each element + contains location information conformant to the location profile + specified in the 'profile' attribute. This allows the server to send + location information compliant with multiple location profiles. -8.5.1. 500 Server Internal Error + Using the location profiles defined in this document, the following + rules insure basic interoperatiblity between clients and servers: - The server encountered an unexpected condition that prevented it from - fulfilling the request. The client MAY retry the request after - several seconds. + 1. A client MUST be capable of understanding the response for the + baseline profiles it used in the request. -8.5.2. 501 Service Not Implemented + 2. If a client sends location information conformant to any location + profile other than geodetic-2d or civic, it MUST also send, in + the same request, location information conformant to one of the + baseline profiles. Otherwise, the server might not be able to + understand the request. - The server does not implement mapping for the service requested and - cannot provide an alternate service. + 3. Servers MUST implement the geodetic-2d and civic profiles. -8.5.3. 504 Server Time-Out + 4. A server ignores any location information using non-baseline + profiles it does not understand. - A server time-out occurs if the server contacted tries to recursively - resolve the query, but cannot get an answer within the time limit set - for the query. + 5. If a server receives a request that only contains location + information using profiles it does not understand, the server + responds with a (Section 10.2). -8.5.4. Example + These rules enable the use of location profiles not yet specified, + while ensuring baseline interoperability. Take, for example, this + scenario. Client X has had its firmware upgraded to support the + uber-complex-3D location profile. Client X sends location + information to Server Y, which does not understand the + uber-complex-3D location profile. If Client X also sends location + information using the geodetic-2D baseline profile, then Server Y + will still be able to understand the request and provide an + understandable response, though with location information that might + not be as precise or expressive as desired. This is possible because + both Client X and Server Y understand the baseline profile. The + following transaction, where the XML sent by the client is prepended + with 'C:' and the XML sent by the server is prepended with 'S:', + demonstrates this: - This is an example of an error message with a 500 status code: + C: + C: + C: + C: + C: 40.8089897 -73.9612492 + C: + C: + C: + C: + C: 37.775 -122.422 25 + C: + C: + C: + C: + C: 40.80 -73.96 24 + C: 40.81 -73.95 27 + C: 40.80 -73.96 24 + C: + C: + C: + C: + C: urn:service:sos.police + C: - - - Server failure - + S: + S: + S: + S: + S: New York City Police Department + S: + S: urn:service:sos.police + S: + S: + S: + S: + S: 40.701 -74.020 + S: 40.876 -73.926 + S: 40.797 -73.936 + S: 40.714 -73.984 + S: 40.701 -74.020 + S: + S: + S: + S: + S: sip:nypd@example.com + S: -9. LoST Transport + Figure 12: Example of a findServices query with baseline profile + interoperability - LoST needs an underlying protocol transport mechanisms to carry - requests and responses. This document defines the use of LoST over - HTTP and HTTP-over-TLS; other mechanisms are left to future - documents. The available transport mechanisms are indicated in the - LoST U-NAPTR DNS resource record. In protocols that support content - type indication, LoST uses the media type application/lost+xml. +9.2. Two Dimensional Geodetic Profile - When using HTTP [14] and HTTP-over-TLS [15], LoST requests use the - HTTP POST method. All HTTP responses are applicable. The HTTP URL - is derived from the LoST URL via U-NAPTR translation, as discussed in - Section 4. + The geodetic-2d location profile is identified by geodetic-2d. + Clients use this profile by placing a GML [13] element + within the element. This is defined by the 'point2D' + pattern in the LoST schema (see Section 12). -10. LoST Uniform Resource Locators + Servers use this profile by placing a GML [13] element + within the element. This is defined by the + 'polygon' pattern in the LoST schema (see Section 12). - LoST Uniform Resource Locators (URLs) follow the format of URLs - defined in RFC 3986 [9], with the following ABNF: +9.3. Basic Civic Profile - LoST-URI = "lost:" host + The basic-civic location profile is identified by the token 'civic'. + Clients use this profile by placing a element, defined + in [11], within the element. - 'host' is defined in Section 3.2.2 of RFC 3986 [9]. + Servers use this profile by placing a element, defined + in [11], within the element. - An example is 'lost:lostserver.example.com' +10. Error Handling -11. Example + Errors are indicated by error-specific elements. Depending on the + nature of the error, the error element may occur along with other + response elements, indicating that the request was only partially + satisfied and that not all information in the request was processed + correctly. Errors labeled as fatal means - After performing link layer attachment and end host performs stateful - address autoconfiguration (in our example) using DHCP. Then, DHCP - provides the end host with civic location as described in [19]. +10.1. Basic Errors - +--------+---------------+ - | CAtype | CAvalue | - +--------+---------------+ - | 0 | US | - | 1 | New York | - | 3 | New York | - | 6 | Broadway | - | 22 | Suite 75 | - | 24 | 10027-0401 | - +--------+---------------+ + LoST defines a pattern for errors, defined as "errors" in the Relax + NG schema. This pattern defines a 'message' attribute containing + human readable text and an 'xml:lang' attribute denoting the language + of the human readable text. - Figure 14: DHCP Civic Information Example + LoST defines the following elements as following this pattern: - Additionally, DHCP may provide information about the LoST server that - can be contacted. Alternatively, an additional step of indirection - is possible, for example by having DHCP return a domain name that has - to be resolved to one or more IP addresses hosting LoST servers. + badRequest The server could not parse or otherwise understand a + request. This is a top-level element, and is returned if the + server did not understand the outermost LoST XML element + identifying the request. - Both at attachment time and call time, the client places a LoST - request, including its civic location and the desired service. The - request is shown below: + serviceSubstitution The server substituted one service for another. + See Section 6.4.4. - - - - - US - New York - New York - Broadway - Suite 75 - 10027-0401 - - - urn:service:sos.police - +10.2. Response Errors - Mapping Request - Since the contacted LoST server has the requested information - available the following response is returned. The - element indicates, as a human readable display string, that the 'New - York City Police Department' is responsible for the given - geographical area. The indicated URI allows the user to start - communication using SIP or XMPP. The element indicates - which parts of the civic address were matched successfully against a - database and represent a known address. Other parts of the address, - here, the suite number, were ignored and not validated. The - element indicates that all of New York City would - result in the same response. The element indicates - that the service can be reached via the emergency service number 911. + LoST defines a pattern for errors that may generated by referrent + LoST serves queried on behalf of seekers by a resolving LoST server. + This pattern builds on the basic errors pattern (Section 10.1). It + also provides the option of specifying the source server using the + 'source' attribute, as well as specifying the query that caused the + error. - - - - - New York City Police Department - - unknown - - - US - New York - New York - - - sip:nypd@example.com - xmpp:nypd@example.com - 911 - - + LoST defines the following elements as following this pattern: - Mapping Response + forbidden The server refused to send an answer. -12. Deployment Methods + notFound The server could not find an answer to the query. - Because services for emergency contact resolution may differ - depending on local or service needs, this document only specifies the - "wire format" for LoST services and explicitly leaves open the - possibility for many different types of deployment. + serviceNotImplemented The requested service is not implemented. - For instance: + internalError The server could not satisfy a request due to + misconfiguration or other operational and non-protocol related + reasons. - During discovery, a client may be directed to issue all queries to - an LoST service completely authoritative for a given jurisdiction. + serverTimeout A time out occurred before an answer was received. - A client may be directed to issue queries to an LoST server that - acts as a reflector. In such a case, the LoST server analyzes the - query to determine the best server to which to refer the client. + serverError An answer was received but it could not be parsed or + otherwise understood. - Or the client may be directed to a server that performs further - resolution on behalf of the client. + locationProfileError A location profile in the query given is not + recognized. The element may also have an 'unsupportedProfiles' + attribute, which contains a whitespace separated list of profile + URNs. See Section 9. - A LoST service may also be represented by multiple LoST servers, - either grouped together or at multiple network locations. Using - S-NAPTR [24], clients may be given a list of multiple servers to - which queries can be sent for a single service. +10.3. Redirects - For instance, the service at emergency.example.com may advertise LoST - service at local1.emergency.example.com, - local2.emergency.example.com, and master.emergency.example.com. Each - server may given a different preference. In this case, 'local-1' and - 'local-2' may be given a lower preference (more preferred) than - 'master', which might be a busier server or located further away. + LoST defines a pattern for redirect responses. This pattern builds + on the basic error pattern (Section 10.1) and includes a 'url' + attribute indicating the LoST URL that the client should be + contacting next. - +-----------+ pref 10 +-----------+ - | |-------------------->+ | - | client |------ | local-1 | - | |--- \ | | - +-----------+ \ \ +-----------+ - \ \ - \ \ +-----------+ - \ \ pref 10 | | - \ --------->| local-2 | - \ | | - \ +-----------+ - \ - \ +-----------+ - \ pref 20 | | - ------------------------->| master | - | | - +-----------+ + Currently, LoST only defines the element along this + pattern. -13. Relax NG Schema +11. LoST Transport + + LoST needs an underlying protocol transport mechanisms to carry + requests and responses. This document defines the use of LoST over + HTTP and HTTP-over-TLS; other mechanisms are left to future + documents. The available transport mechanisms are determined through + the use of the LoST U-NAPTR application. In protocols that support + content type indication, LoST uses the media type application/ + lost+xml. + + When using HTTP [3] and HTTP-over-TLS [5], LoST requests use the HTTP + POST method. All HTTP responses are applicable. The HTTP URL is + derived from the LoST URL via U-NAPTR application, as discussed in + Section 5. + +12. 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. - default namespace = "urn:ietf:params:xml:ns:lost1" + default namespace = "http://www.opengis.net/gml" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" - namespace ns1 = "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" - namespace ns2 = "http://www.opengis.net/gml" + namespace ns1 = "urn:ietf:params:xml:ns:lost1" ## ## 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. + ## A LoST XML instance has three request types, each with + ## a cooresponding response type: find service, list services, + ## and get service boundary. ## - start = findServiceByLocation | listServices | response + start = + findService + | listServices + | getServiceBoundary + | findServiceResponse + | listServicesResponse + | getServiceBoundaryResponse ## ## The queries. ## div { - findServiceByLocation = - element findServiceByLocation { + findService = + element ns1:findService { query, - attribute validate { xsd:boolean >> a:defaultValue [ "false" ] }? + attribute include { + list { + ("uri" + | "serviceNumber" + | "displayName" + | "service" + | "valid" + | "invalid" + | "unchecked" + | "serviceBoundary" + | "serviceBoundaryReference")* + } + >> a:defaultValue [ "uri serviceNumber" ] + }? + } + listServices = element ns1:listServices { query } + getServiceBoundary = + element ns1:getServiceBoundary { + serviceBoundaryKey, extensionPoint } - listServices = element listServices { query } } ## - ## The response. + ## The responses. ## div { - response = - element response { + findServiceResponse = + element ns1:findServiceResponse { + via, + ((locationProfileError?, serviceSubstitution?, serviceResult) + | badRequest + | internalError + | forbidden + | notFound + | serviceNotImplemented + | serverTimeout + | serverError + | movedPermenantly + | movedTemporarily + | iterativeSearchExhausted), + extensionPoint + } + listServicesResponse = + element ns1:listServicesResponse { + via, + ((locationProfileError?, + element ns1:serviceList { + list { xsd:anyURI* } + })), + extensionPoint + } + getServiceBoundaryResponse = + element ns1:getServiceBoundaryResponse { + (serviceBoundary + | badRequest + | internalError + | forbidden + | notFound), + extensionPoint + } + } ## - ## 2xx responses. + ## A pattern common to some of the queries. ## - (result - | element serviceList { - list { xsd:anyURI* }, - status - })?, + div { + query = + element ns1:location { locationInformation }+, + element ns1:service { xsd:anyURI }?, + extensionPoint, + attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? + } + ## - ## 3xx, 4xx, and 4xx responses. + ## Location Information ## - ((error | redirect | failure)?), - extensionPoint + div { + locationInformation = + extensionPoint+, + attribute profile { xsd:anyURI } } + + ## + ## Service Boundary + ## + div { + serviceBoundary = element ns1:serviceBoundary + { locationInformation }+ } ## - ## Query pattern. + ## Service Boundary Key ## div { - query = - element locationInfo { anyElement* }, - element service { xsd:anyURI }, - extensionPoint, - [ a:defaultValue [ "recursive" ] ] attribute operation { text }? + serviceBoundaryKey = + attribute key { + xsd:string { pattern = "[a-zA-Z0-9/+=]+" } + } } ## - ## A result. + ## Via - list of places through which information flowed ## div { + via = element ns1:via { xsd:anyURI }* + } ## - ## 2xx response. + ## Time-to-live pattern ## - result = - element result { - element displayName { + div { + timeToLive = attribute timeToLive { xsd:positiveInteger } + } + + ## + ## A QName list + ## + div { + qnameList = list { xsd:QName* } + } + + ## + ## A location-to-service result. + ## + div { + serviceResult = + element ns1:displayName { xsd:string, attribute xml:lang { xsd:language } }?, - element service { xsd:anyURI }, - element serviceBoundary { - (civicLocation, polygon?) | (civicLocation?, polygon) - }?, - element uri { xsd:anyURI }+, - element serviceNumber { + element ns1:service { xsd:anyURI }?, + (serviceBoundary + | element ns1:serviceBoundaryReference { serviceBoundaryKey })?, + element ns1:uri { xsd:anyURI }*, + element ns1:serviceNumber { xsd:string { pattern = "[0-9]+" } }?, - element validation { - list { xsd:QName* } - }?, + element ns1:valid { qnameList }?, + element ns1:invalid { qnameList }?, + element ns1:unchecked { qnameList }?, extensionPoint, - attribute timeToLive { xsd:positiveInteger }, - status - } + timeToLive, + message } ## - ## Non-result responses. + ## Basic Errors ## div { ## - ## 5xx response. + ## Error pattern. ## - error = element error { status, extensionPoint } + error = message, extensionPoint + badRequest = element ns1:badRequest { error } + internalError = element ns1:internalError { error } + serviceSubstitution = element ns1:serviceSubstitution { error } + } + ## + ## Recursion Errors. + ## + div { ## - ## 3xx response. + ## Recursion error. ## - redirect = - element redirect { - status, - attribute redirect { xsd:anyURI }, - extensionPoint + recursionError = + attribute failedReferral { xsd:anyURI }?, + (findService | listServices | getServiceBoundary)?, + error + forbidden = + element ns1:forbidden { recursionError }, + timeToLive + notFound = + element ns1:notFound { recursionError }, + timeToLive + serviceNotImplemented = + element ns1:serviceNotImplemented { recursionError }, + timeToLive + serverTimeout = + element ns1:serverTimeout { recursionError }, + timeToLive + serverError = + element ns1:serverError { recursionError }, + timeToLive + locationProfileError = + element ns1:locationProfileError { + attribute unsupportedProfiles { + list { xsd:anyURI* } + }, + recursionError + } } ## - ## 4xx response. + ## Redirects. ## - failure = - element failure { - status, - element cause { - attribute name { xsd:QName }, - attribute message { xsd:string }, - attribute xml:lang { xsd:language } - }*, - extensionPoint - } + div { + + ## + ## Redirect pattern + ## + redirect = + attribute redirect { xsd:anyURI }, + error + movedPermenantly = element ns1:movedPermanently { redirect } + movedTemporarily = + element ns1:movedTemporarily { redirect }, + timeToLive + iterativeSearchExhausted = + element ns1:iterativeSearchExhausted { redirect }, + timeToLive } ## - ## Status pattern. + ## Message pattern. ## div { - status = - attribute status { xsd:positiveInteger }, - attribute extendedStatus { xsd:positiveInteger }?, + message = (attribute message { xsd:string }, attribute xml:lang { xsd:language })? } + ## ## Patterns for inclusion of elements from schemas in ## other namespaces. ## div { ## + ## Any element not in the LoST namespace. + ## + notLost = element * - (ns1:* | ns1:*) { anyElement } + + ## ## A wildcard pattern for including any element ## from any other namespace. ## anyElement = - element * { - (attribute * { text } - | text - | anyElement)* - } + (element * { anyElement } + | attribute * { text } + | text)* ## ## A point where future extensions - ## (elements from other namesapces) + ## (elements from other namespaces) ## can be added. ## - extensionPoint = anyElement* + extensionPoint = notLost* ## - ## A pattern to include the GEOPRIV civil location elements. + ## A 2D point from GML. ## - civicAddress = - element ns1:* { - (attribute * { text } - | text - | anyElement)* + point2d = + element position { + element Point { + attribute srsName { "urn:ogc:def:crs:EPSG:4326" }, + element pos { text } + } } ## - ## A definition of civic location from GEOPRIV. + ## A Linear Ring from GML. ## - civicLocation = element civicLocation { civicAddress*, anyElement* } + linearRing = + element LinearRing { + element pos { text } + } ## - ## A pattern to include GML elements. + ## A Polygon from GML. ## - GML = - element ns2:* { - (attribute * { text } - | text - | anyElement)* - } polygon = - element ns2:Polygon { - attribute * { text }*, - GML + element Polygon { + attribute srsName { "urn:ogc:def:crs:EPSG:4979" }, + element exterior { linearRing }, + element interior { linearRing }* } } -14. Internationalization Considerations +13. Internationalization Considerations This mechanism is largely for passing protocol information from one subsystem to another; as such, most of its elements are tokens not meant for direct human consumption. If these tokens are presented to the end user, some localization may need to occur. The content of - the element may be displayed to the end user, and it is - thus a complex type designed for this purpose. + the element and the 'message' attributes may be + displayed to the end user, and they are thus a complex types designed + for this purpose. -15. IANA Considerations + LoST exchanges information using XML. All XML processors are + required to understand UTF-8 and UTF-16 encodings, and therefore all + LoST clients and servers MUST understand UTF-8 and UTF-16 encoded + XML. Additionally, LoST servers and clients MUST NOT encode XML with + encodings other than UTF-8 or UTF-16. -15.1. Content-type registration for 'application/lost+xml' +14. IANA Considerations + +14.1. U-NAPTR Registrations + + This document registers the following U-NAPTR application service + tag: + + Application Service Tag: LoST + + Defining Publication: The specification contained within this + document. + + This document registers the following U-NAPTR application protocol + tags: + + o + + Application Protocol Tag: http + + Defining Publication: RFC 2616 [3] + + o + + Application Protocol Tag: https + + Defining Publication: RFC 2818 [5] + +14.2. Content-type registration for 'application/lost+xml' This specification requests the registration of a new MIME type - according to the procedures of RFC 4288 [13] and guidelines in RFC - 3023 [12]. + according to the procedures of RFC 4288 [9] and guidelines in RFC + 3023 [6]. MIME media type name: application MIME subtype name: lost+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the - character encoding used. See RFC 3023 [12], Section 3.2. + character encoding used. See RFC 3023 [6], Section 3.2. Security considerations: This content type is designed to carry LoST protocol payloads. Interoperability considerations: None Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.] this document @@ -1160,37 +1399,37 @@ Author: This specification is a work item of the IETF ECRIT working group, with mailing list address . Change controller: The IESG -15.2. LoST Relax NG Schema Registration +14.3. 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 + in Section 12. Its first line is default namespace = "urn:ietf:params:xml:ns:lost1" and its last line is } -15.3. LoST Namespace Registration +14.4. LoST Namespace Registration URI: urn:ietf:params:xml:ns:lost Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@siemens.com). XML: BEGIN @@ -1206,545 +1445,750 @@

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 +14.5. Registration Template - This registration template is in accordance with [8]. + This registration template is in accordance with [4]. URL scheme name: lost URL scheme syntax: - See Section 10 + See Section 5 Character encoding considerations: - See Section 10 + See Section 5 + 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 + See Section 15 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 +14.6. LoST Location Profile Registry + + This document seeks to create a registry of location profile names + for the LoST protocol. Profile names are XML tokens. This registry + will operate in accordance with RFC 2434 [2], Standards Action. + + geodetic-2d: Defined in TBD + + civic: Defined in TBD + +15. 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, the - authors RECOMMEND the use of channel security, such as TLS, with - LoST. + To avoid that an attacker can modify the query or its result, the use + of channels security, such as TLS, is RECOMMENDED. A more detailed description of threats and security requirements are - provided in [4]. + provided in [17]. -17. Acknowledgments +16. Acknowledgments [Editor's Note: Names need to be added here. Forgot it...Sorry.] -18. Open Issues +17. Open Issues Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ -19. References - -19.1. Normative References - - [1] World Wide Web Consortium, "XML Schema Part 2: Datatypes", - W3C XML Schema, October 2000, - . +18. References - [2] World Wide Web Consortium, "XML Schema Part 1: Structures", - W3C XML Schema, October 2000, - . +18.1. Normative References - [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 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-03 - (work in progress), July 2006. + [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. - [5] Schulzrinne, H. and R. Marshall, "Requirements for Emergency - Context Resolution with Internet Technologies", - draft-ietf-ecrit-requirements-12 (work in progress), - August 2006. + [3] 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. - [6] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", - draft-ietf-ecrit-service-urn-05 (work in progress), - August 2006. + [4] Petke, R. and I. King, "Registration Procedures for URL Scheme + Names", BCP 35, RFC 2717, November 1999. - [7] Mealling, M., "The IETF XML Registry", - draft-mealling-iana-xmlns-registry-05 (work in progress), - June 2003. + [5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. - [8] Petke, R. and I. King, "Registration Procedures for URL Scheme - Names", BCP 35, RFC 2717, November 1999. + [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", + RFC 3023, January 2001. - [9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + [7] 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. - - [11] Peterson, J., "A Presence-based GEOPRIV Location Object + [8] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. - [12] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", - RFC 3023, January 2001. - - [13] Freed, N. and J. Klensin, "Media Type Specifications and + [9] 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. + [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", + draft-ietf-ecrit-service-urn-05 (work in progress), + August 2006. - [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. + [11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format + for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in + progress), September 2006. - [17] Daigle, L., "Domain-based Application Service Location Using + [12] 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 + [13] OpenGIS, "Open Geography Markup Language (GML) Implementation + Specification", OGC OGC 02-023r4, January 2003. - [18] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, - December 2004. +18.2. Informative References - [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. + [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. - [20] Schulzrinne, H., "Location-to-URL Mapping Architecture and - Framework", draft-ietf-ecrit-mapping-arch-00 (work in - progress), August 2006. + [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence + Protocol (XMPP): Instant Messaging and Presence", RFC 3921, + October 2004. - [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. + [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, + December 2004. - [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. + [17] Taylor, T., "Security Threats and Requirements for Emergency + Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 + (work in progress), July 2006. - [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 + [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency + Context Resolution with Internet Technologies", + draft-ietf-ecrit-requirements-12 (work in progress), + August 2006. + + [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and + Framework", draft-ietf-ecrit-mapping-arch-00 (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. + [20] Rosen, B. and J. Polk, "Best Current Practice for + Communications Services in support of Emergency Calling", + draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006. 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. + A LoST XML instance has three request types, each with + a cooresponding response type: find service, list services, + and get service boundary. - + - + + + +
The queries. - - + + - - - false + + + + + uri + serviceNumber + displayName + service + valid + invalid + unchecked + serviceBoundary + serviceBoundaryReference + + + + uri serviceNumber + + + + + + +
+
- The response. + The responses. - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - 2xx responses. - - + + + + - + - - - - 3xx, 4xx, and 4xx responses. - + + + + + + - - - + + + + + + + - -
- Query pattern. + A pattern common to some of the queries. - - - - + + + + + + - - recursive + + + true
- A result. + Location Information - + + + + + + + + +
+ +
- 2xx response. + Service Boundary - + + + + + + + +
+ +
+ + Service Boundary Key + + + + + + [a-zA-Z0-9/+=]+ + + + +
+ +
+ + Via - list of places through which information flowed + + + + + + + + + +
+ +
+ + Time-to-live pattern + + + + + + + +
+
+ + A QName list + + + + + + + + + +
+ +
+ + A location-to-service result. + + + + - - - - - - - - - - - - - - + + + + + - + - + [0-9]+ - - - - - - + + - - - - - + + + + + + + + + + + +
- Non-result responses. + Basic Errors - 5xx response. + Error pattern. - - + + + + + + - + + + + + + + + + + + + +
+ +
- 3xx response. + Recursion Errors. - - - + + + + Recursion error. + + + - + + + + + + + + + + + + + + + - - - 4xx response. - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - + + + - - + + + + +
+ +
+ + Redirects. + + + + + Redirect pattern + + + + + + + + + - - + + + + + + + + + + + + +
- Status pattern. + Message pattern. - - - - - - - - - +
Patterns for inclusion of elements from schemas in other namespaces. - + - A wildcard pattern for including any - element from any other namespace. + Any element not in the LoST namespace. - + + + + + + + + + + + + + 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 2D point from GML. - - - - - - + + + + urn:ogc:def:crs:EPSG:4326 + - - - - - - - - A definition of civic location from GEOPRIV. - - - - - - - - + - + - A pattern to include GML elements. + A Linear Ring from GML. - - - - - - - + + - - - + + + A Polygon from GML. + - - - + + urn:ogc:def:crs:EPSG:4979 + + + + + + + - -
Authors' Addresses Ted Hardie Qualcomm, Inc. Email: hardie@qualcomm.com