Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. Intended status: Standards Track A. Newton Expires:March 8,April 25, 2007 SunRocket H. Schulzrinne Columbia U. H. Tschofenig SiemensSeptember 4,October 22, 2006 LoST: A Location-to-Service Translation Protocoldraft-ietf-ecrit-lost-01.txtdraft-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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 onMarch 8,April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes an XML-based protocol for mapping service identifiers andgeospatialgeodetic 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 . . .Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.Resolving Service URNs Using LoST .Overview of Protocol Usage . . . . . . . . . . . . .8 5. Query. . . . . 8 5. LoST Uniform Resource Locators and Their Resolution . . . . . 9 6. Mapping a Location and Service to URLs: <findService> . . . . 10 6.1. Overview . . . . . . . . . . . . . .9 5.1. Location Information Element. . . . . . . . . . . 10 6.2. Examples . . . .9 5.2. Service Element. . . . . . . . . . . . . . . . . . . . .9 5.3. Validate Attribute10 6.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 10 6.2.2. Civic Address Mapping Example . . . . . . . . . .9 5.4. Query Message Examples. . 11 6.3. Components of <findService> Request . . . . . . . . . . . 13 6.3.1. The <location> Element . . . . .9 6. Response. . . . . . . . . . . 13 6.3.2. The <service> Element . . . . . . . . . . . . . . . .11 6.1. Uniform Resource Identifiers (URI) Element13 6.3.3. Recursion or Redirection . . . . . . . .11 6.2. Display Name Element. . . . . . . 13 6.3.4. Configuring the Response . . . . . . . . . . . .11 6.3. Service Element. . . 14 6.4. Components of the Mapping Response <findServiceResponse> . . . . . . . . . . . . . . . . . .11 6.4. ServiceBoundary16 6.4.1. Source of Response: <via> Element . . . . . . . . . . 16 6.4.2. Service URLs: the <uri> Element . . . . . . .12 6.5. ServiceNumber Element .. . . . 16 6.4.3. Describing the Service with the <displayName> Element . . . . . . . . . . . . .12 6.6. TimeToLive Attribute. . . . . . . . . . 17 6.4.4. Approximating Services: the <service> Element . . . . 17 6.4.5. Defining the Service Region with the <serviceBoundary> Element . . . . .12 6.7. Validation Element. . . . . . . . . 17 6.4.6. Service Boundaries by Reference: the <serviceBoundaryReference> Element . . . . . . . . . . 17 6.4.7. The Service Number .12 6.8. Response Message Examples. . . . . . . . . . . . . . . .12 7. List Services Query and Response. 18 6.4.8. Civic Address Validation . . . . . . . . . . . . . .15 7.1. List Service Query. 18 6.4.9. Validity: The 'timeToLive' Attribute . . . . . . . . . 18 7. Retrieving the Service Boundary via <getServiceBoundary> . . . 19 8. List Services: <listServices> . . . . . . .15 7.2. List Service Response. . . . . . . . . 21 9. Location Profiles . . . . . . . . .15 8. Status Code Definitions. . . . . . . . . . . . . 23 9.1. Location Profile Usage . . . . . .17 8.1. Informational 1xx. . . . . . . . . . . . 23 9.2. Two Dimensional Geodetic Profile . . . . . . . .17 8.2. Successful 2xx. . . . . 26 9.3. Basic Civic Profile . . . . . . . . . . . . . . . . .17 8.2.1. 200 OK. . 26 10. Error Handling . . . . . . . . . . . . . . . . . . . . . .17 8.2.2. 201 Service Substitution. . 27 10.1. Basic Errors . . . . . . . . . . . . .17 8.3. Redirection 3xx. . . . . . . . . . 27 10.2. Response Errors . . . . . . . . . . .17 8.3.1. 301 Move Permanently. . . . . . . . . . 27 10.3. Redirects . . . . . . .17 8.3.2. 302 Moved Temporarily. . . . . . . . . . . . . . . .18 8.3.3. Example. 28 11. LoST Transport . . . . . . . . . . . . . . . . . . . . . .18 8.4. Client Error 4xx. . 29 12. Relax NG Schema . . . . . . . . . . . . . . . . . . .18 8.4.1. 400 Bad Request. . . . 30 13. Internationalization Considerations . . . . . . . . . . . . . 37 14. IANA Considerations . .18 8.4.2. 403 Forbidden. . . . . . . . . . . . . . . . . . . 38 14.1. U-NAPTR Registrations .18 8.4.3. 404 Not Found. . . . . . . . . . . . . . . . . 38 14.2. Content-type registration for 'application/lost+xml' . . .18 8.4.4. 414 Location Error38 14.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 40 14.4. LoST Namespace Registration . . . . . .18 8.4.5. Example. . . . . . . . . 40 14.5. Registration Template . . . . . . . . . . . . . .18 8.5. Server Error 5xx. . . . 41 14.6. LoST Location Profile Registry . . . . . . . . . . . . . . 42 15. Security Considerations . . .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. 43 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .21 9. LoST Transport. 44 17. Open Issues . . . . . . . . . . . . . . . . . . . . . . .22 10. LoST Uniform Resource Locators. . 45 18. References . . . . . . . . . . . . . .23 11. Example. . . . . . . . . . . . 46 18.1. Normative References . . . . . . . . . . . . . . .24 12. Deployment Methods. . . . 46 18.2. Informative References . . . . . . . . . . . . . . . . . .26 13. Relax47 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . .28 14. Internationalization Considerations . . . . . . . . . . . . . 33 15. IANA Considerations . . . . .. . . . . . 61 Intellectual Property and Copyright Statements . . . . . . . . . .34 15.1. Content-type registration62 1. Introduction This document describes a protocol for'application/lost+xml' . . . 34 15.2.mapping a service identifier [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. This document names this protocol "LoST", for Location-to-Service Translation. LoSTRelax NG Schema Registration . . . . . . . . . . . . 35 15.3.Satisfies the requirements [18] for mapping protocols. LoSTNamespace 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 Schemaprovides 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 inXML Syntax . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Intellectual Propertythe location data to facilitate debugging and proper user feedback, but also provides best-effort answers. 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"). 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 andCopyright Statements . . . . . . . . . . 52 1. Introduction This document describes a protocol forthe overall mapping server architecture are described in aservice identifier [6] andseparate document [19]. The query message carries location informationcompatible with PIDF-LO [11]and a service 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 one or more Uniform Resource Identifiers (URI) and returns those URIs along with optional information such as hints about the servicecontact URIs. Example contact URI schemes include sip, xmpp,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 andtel. Whileto list theinitial focusservices 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 [1]. 3. Terminology This document furthermore uses the terminology defined in [18]. In examples, the XML sent by the client ison providingprepended with "C:" and the XML sent by the server is prepended with "S:". 4. Overview of Protocol Usage The client may perform the mappingfunctionsat any time. Among the common triggers foremergency services,mapping requests are: 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 islikely thatoutside the bounds of theprotocol is applicable to anyserviceURN. For example,region returned inthe United States, the "2-1-1" and "3-1-1" services followan earlier LoST query. 3. When cached mapping information has expired. 4. When invoking asimilar location-to-service behavior as emergency services. This document names this protocol usage "LoST"particular service. At that time, a client may omit requests forLocation-to- Service Translation Protocol. The features of LoST are: o Supports queries using civic as well as geospatial locationservice boundaries or other auxiliary information.o Support for recursive and iterative resolution. o Support for address validation. oAhierarchical deployment of mapping serversservice-specific BCP such as [20] governs whether a client isindependent of civic location labels. o Indication of errors inexpected to invoke thelocation datamapping service just before needing the service or whether tofacilitate debugging and proper user feedback while simultaneously providing best- effort answers. o Mapping can be basedrely oneither civiccached answers. Cache entries expire according to their time-to-live value (see Section 6.4.9, orgeospatial location information, with uniform protocol treatmentthey become invalid if the caller's device moves beyond the boundaries ofboth. o Support for overlapping service regions. o Satisfiestherequirements [5] for mapping protocols. o Minimizes round trips by caching individual mappingsservice region. 5. LoST Uniform Resource Locators and Their Resolution LoST servers are identified bysupporting returnLoST Uniform Resource Locators (URLs), which follow the format ofcoverage regions ("hinting"). o Facilitates reuseURLs defined in RFC 3986 [7], with the following ABNF: LoST-URI = "lost:" host 'host' is defined in Section 3.2.2 ofTransport Layer Security (TLS). This document focuses onRFC 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 use U-NAPTR [12] using thedescription ofU-NAPTR specification described below to obtain a URI (indicating host and protocol) for theprotocol betweenapplicable LoST service. In this document, only themapping client (seeker or resolver)HTTP and HTTPS URL schemes are defined. Note that themapping server (resolver or other servers).HTTP URL can be any valid HTTP URL, including those containing path elements. Therelationship between other functions, such as discovery of mapping servers, data replication andfollowing two DNS entries resolve theoverall mapping server architecture in general, will be described in a separate document. [20] is a first attemptLoST URL "lost:example.com" todescribe suchthe 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!" "" 6. Mapping amapping server architecture. The high-level protocol operation can be described as follows:LocationInfo +----------+ --------> | |and Service| LoST | URN | Server | --------> | | +----------+ Query URI +----------+ <------- | | Optional | LoST | Info (hints)| Server | <------- | | +----------+ Response Figure 1:to URLs: <findService> 6.1. Overview The <findService> querymessage carries location information and a service identifier encoded as a Uniform Resource Name (URN) (see [6]) fromconstitutes theLoST client tocore of the LoSTserver. The LoST server uses its database to map the input valuesfunctionality, mapping civic or geodetic locations toa Uniform Resource Identifiers (URI)URLs andreturns it including optional information such as hints aboutassociated data. After giving an example, we enumerate theservice boundary in a response message back toelements of theLoST client. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",query and"OPTIONAL" in this document are to be interpreted as described in [3]. 3. Usageresponse. 6.2. Examples 6.2.1. Example Using Geodetic Coordinates Theclient queriesfollowing is an example of mapping aserver, indicating the desiredserviceand location information. If the query succeeds, the server returnsto aresult that includes one or more URIslocation using geodetic coordinates, forreachingtheappropriateservicefor the location indicated. Depending on the query,associated with theresult may contain apolice (urn:service:sos.police). <?xml version="1.0" encoding="UTF-8"?> <findService xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" recursive="true" include="uri serviceboundary whereserviceNumber displayName serviceBoundary"> <location profile="urn:ietf:params:lost:location-profile:geodetic-2d"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <p2:pos>40.8089897 -73.9612492</p2:pos> </p2:Point> </location> <service>urn:service:sos.police</service> </findService> Figure 2: A <findService> Geodetic Query Given thesame mappingquery above, a server wouldapply,respond with areferenceservice, and information related toanotherthat service. In the example below, the serverto whichhas mapped the location given by the clientshould sendfor aquery, or an error messages indicating problems. The combination of these components are leftpolice service to theneeds and policy of the jurisdiction whereNew York City Police Deparment, instructing theserver is being operated. Theclient that it mayperform the mapping at any time. Amongcontact them via thecommon triggers for mapping are: 1. WhenURIs sip:nypd@example.com and xmpp:nypd@example.com. The server has also given the clientstarts up and/or attaches toanew network location. 2. Whengeodetic, two-dimensional boundary for this service and time-to-live value of 3,600 seconds. This instructs the clientdetectsthat if its locationhas changed sufficiently that it is outside the bounds ofchanges beyond theregion returned in an earlier query. 3. When cached mapping informationgive service boundary or if 3,600 seconds hasexpired. 4. When calling for a particular service. During such calls, a client may wantelapsed, it would need torequest a short response that contains only therequery for this information. <?xml version="1.0" encoding="UTF-8"?> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" timeToLive="3600"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="urn:ietf:params:lost:location-profile:geodetic-2d"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:exterior> <p2:LinearRing> <p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4194</p2:pos> </p2:LinearRing> </p2:exterior> </p2:Polygon> </serviceBoundary> <uri>sip:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri> <serviceNumber>911</serviceNumber> </findServiceResponse> Figure 3: A <findServiceResponse> Geodetic Answer 6.2.2. Civic Address Mapping Example The following is an example of mappingdata, omittinga serviceboundary information. Cached answers are expected to be used by clients only after failingtoaccomplishalocation-to-URI mapping at call time. Cache entries may expire according to their time-to-live value, or they may become invalid if thelocationofmuch like thecaller's device moves outsideexample in Section 6.2.1, but using civic address location information. In this example, theboundary limits ofclient requests thecache entry. Boundaries for cache entries may be set in both geospatial andservice associated with police (urn:service:sos.police) along with a specific civicterms. 4. Resolving Service URNs Using LoST Ifaddress (house number 96 on aLoST URL containsstreet named Neu Perlach in Munich, Germany). <?xml version="1.0" encoding="UTF-8"?> <findService xmlns="urn:ietf:params:xml:ns:lost1" recursive="true" include="uri serviceNumber displayName serviceBoundary" > <location profile="urn:ietf:params:lost:location-profile:basic-civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <A6>Neu Perlach</A6> <HNO>96</HNO> <PC>81675</PC> </civicAddress> </location> <service>urn:service:sos.police</service> </findService> Figure 4: A <findService> Civic Address Query Given the query above, ahost name rather than an IP address, clients need to perform an U-NAPTR [17] lookup to obtainserver would respond with aDNS A recordservice, andIP address. These records mapinformation related to that service. In the'host' part ofexample below, theLoST URL to one or more URLs indicatingserver has mapped theprotocollocation given by the client for a police service tocarrytheLoST request. In this document, onlyMȭnchen Polizei-Abteilung, instructing theHTTP and HTTPS URL schemes are defined. Noteclient that it may contact them via theHTTP URL can be any valid HTTP URL, including those containing path elements. Here is an example: 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 providesURIs sip:munich-police@example.com and xmpp:munich-police@example.com. The server has also given theability to useclient a civicor geospatial location information inaddress boundary (the city of Munich) for this service and time-to-live value of 3,600 seconds. This instructs thequery message. In addition toclient that if its locationinformationchanges beyond thequery also contains agive serviceidentifier. An optional parameter might furthermore requestboundary (i.e. beyond theLoST servercity of Munich) or if 3,600 seconds has elapsed, it would need tovalidate locationrequery for this information.5.1. Location Information<?xml version="1.0" encoding="UTF-8"?> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600"> <displayName xml:lang="de"> Mȭnchen Polizei-Abteilung </displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="urn:ietf:params:lost:location-profile:basic-civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <PC>81675</PC> </civicAddress> </serviceBoundary> <uri>sip:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri> <serviceNumber>110</serviceNumber> </findServiceResponse> Figure 5: A <findServiceResponse> Civic Address Answer 6.3. Components of <findService> Request 6.3.1. The <location> ElementLoST supports aThe <findService> queryusing geospatial and civiccommunicates locationinformationusingthe <findServiceByLocation> query. Geospatial location information uses GML format [10] and civic location information utilizes the format defined in [16]. This document does not defineone or more <location> elements, which MUST conform to a locationformats. 5.2. Serviceprofile (Section 9). 6.3.2. The <service> Element The type of service desired is specified by the <service> element.The (emergency)It contains serviceidentifiers listed inURNs from the registry establishedwith [6] will be usedinthis document. The <service> element is[10]. 6.3.3. Recursion or Redirection LoST <findService> queries can be recursive or iterative, as indicated by the 'recursive' attribute. A value of "true" indicates amandatory element. In caserecursive query, a value of "false" an iterative query, with iterative being thedatabase atdefault. When the LoST serverdoes not provided service for the specific geographical regioncannot answer theLoST server has various choices with regard toquery and theresponse: o It can sendquery requested iterative resolution, it will return an <iterativeSearchExhausted> (Section 10.3) errorresponse. o It can map one servicemessage with the LoST URI pointing toanother one, if appropriate, and returna differentservice identifier as described in Section 6.3. o It can populateLoST server that theURIs of one service to another service. The operation ofLoST client should contact. In recursive mode, the LoST serveris largelyinitiates apolicy issue. No behavior is mandated in this document. Guidelines for operatingquery and returns the result to the original querier, inserting a <via> element to track the response chain. 6.3.4. Configuring the Response The 'include' attribute enumerates all the XML elements that the client wants the LoST serverfor emergency services is providedto provide in[21]. 5.3. Validate Attributethe mapping response. The server ignores any element names that it does not understand. The'validate' attribute implementsordering of the tokens is immaterial. 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. Address validation is requested by including the XML element names that provide address validationbehavior describedin[5]. 5.4. Query Message Examples This section shows an example of a query message providing geospatialthe 'include' attribute, namely 'valid', 'invalid' andcivic location information. <?xml version="1.0" encoding="UTF-8"?> <findServiceByLocation xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" validate="false" operation="recursive"> <locationInfo> <p2:Point id="point1" srsName="epsg:4326"> <p2:coordinates>37:46:30N 122:25:10W</p2:coordinates> </p2:Point> </locationInfo> <service>urn:service:sos.police</service> </findServiceByLocation> Figure 3: Query Message Example using Geospatial Location Information'unchecked'. The following exampleabove shows a query using geospatial location information with no validation required and asking for the 'urn:service:sos.police' service.demonstrates address validation. C: <?xml version="1.0" encoding="UTF-8"?><findServiceByLocationC: <findService C: xmlns="urn:ietf:params:xml:ns:lost1"validate="false" operation="recursive"> <locationInfo> <civicLocation>C: recursive="true" C: include="uri serviceNumber invalid valid unchecked"> C: <location C: profile="urn:ietf:params:lost:location-profile:basic-civic"> C: <civicAddress C: xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> C: <country>Germany</country> C: <A1>Bavaria</A1> C: <A3>Munich</A3> C: <A6>Neu Perlach</A6> C: <HNO>96</HNO> C: <PC>81675</PC></civicLocation> </locationInfo>C: </civicAddress> C: </location> C: <service>urn:service:sos.police</service> C: </findService> S: <?xml version="1.0" encoding="UTF-8"?> S: <findServiceResponse S: xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600"> S: <displayName xml:lang="de"> S: Mȭnchen Polizei-Abteilung S: </displayName> S: <service>urn:service:sos.police</service></findServiceByLocation>S: <serviceBoundary S: profile="urn:ietf:params:lost:location-profile:basic-civic"> S: <civicAddress S: xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> S: <country>Germany</country> S: <A1>Bavaria</A1> S: <A3>Munich</A3> S: <PC>81675</PC> S: </civicAddress> S: </serviceBoundary> S: <uri>sip:munich-police@example.com</uri> S: <uri>xmpp:munich-police@example.com</uri> S: <serviceNumber>110</serviceNumber> S: <valid>country A1 A3 A6</valid> S: <invalid>PC</invalid> S: </findServiceResponse> Figure4: 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 and6: Address Validation Exchange 6.4. Components of thequery has to be executed recursively. 6.Mapping Response <findServiceResponse> 6.4.1. Source of Response: <via> Element Aresponse message might either contain civic or geospatial location information depending on<findServiceResponse> indicates thetypesource of thequery. If the findServiceByLocation query message contained civic location information then the <serviceBoundary>response by including a <via> elementofwith a LoST URL as theresponse message will alsofirst <via> element. Thus, each server "initials" its own response. Thus, responses to iterative queries containcivic information. Ifone <via> element, while responses to recursive queries may reach the original querier with multiple <via> elements, one for each server that was used in the resolution. The following <findServiceResponse> example illustrates the use of <via>: <?xml version="1.0" encoding="UTF-8"?> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600"> <via>lost:esgw.uber-110.de.example</via> <via>lost:polizei.munchen.de.example</via> <displayName xml:lang="de"> Mȭnchen Polizei-Abteilung </displayName> <service>urn:service:sos.police</service> <serviceBoundary profile="urn:ietf:params:lost:location-profile:basic-civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <PC>81675</PC> </civicAddress> </serviceBoundary> <uri>sip:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri> <serviceNumber>110</serviceNumber> </findServiceResponse> Figure 7: An Example of a Response Using <via> The example above indicates that thefindServiceByLocation query message contained geospatial location information thenthis answer was given to the<serviceBoundary> element ofresponding server by theresponse message will contain a GML polygon. More information aboutLoST server at esgw.uber-110.de.example, which got the<serviceBoundary> element can be foundanswer from the LoST server atSection 6.4. 6.1. Uniform Resource Identifiers (URI) Element Eachpolizei.munchen.de.example. 6.4.2. Service URLs: the <uri>element contains an appropriate contact URI forElement The response returns the servicefor which mapping was requested.URLs in one or more <uri>elements are of type xs:anyURI. Inelements. The URLs MUST be absolute URLs. 6.4.3. Describing theemergency service context operators are strongly discouraged from using relative URIs, even though these are permitted byService with thetype. 6.2. Display Name<displayName> ElementEachThe <displayName> elementcontainsdescribes the service with a string that is suitable fordisplay. <displayName> elements are of type "text"display to human users, annotated with the 'xml:lang' attribute thatis suitable for internationalized human-readable text. 6.3. Service Element The <service> element is an optional elementcontains a language tag to aid in theresponse message. The (emergency) service identifiers listed inrendering of text. 6.4.4. Approximating Services: theregistry established with [6] will be used in this document.<service> Element If theservice that wasrequested service, identified by theLoST client isservice URN [10] in the <service> element in the request, does notavailableexist fora particularthe locationthenindicated, the serverMAYcan either return an <serviceNotImplemented> (Section 10.2) error or can provide an alternateservice. If it does so, itservice that approximates the desired service for that location. In the latter case, the server MUSTindicateinclude a <service> element with theactualalternative servicereturned (i.e., itsURN. The choice of serviceURN). Alternatively,URN is left to local policy, but theLoST server MAY return an erroralternate service should be able to satisfy the original service request. 6.4.5. Defining the Service Region with the <serviceBoundary> Element A responseindicating thatcan indicate the region for which the service URL returned would be the same as in therequestedactual query, the so-called serviceis not available.region. Thefollowing example illustrates the main idea. If there is a region that only understands the 'urn:service:sos'serviceand not 'urn:service:sos.fire', 'urn:service:sos.ambulance', and 'urn:service:sos.police'.region can be indicated by value or by reference Section 6.4.6. If aLoSTclientasks formoves outside the'urn:service:sos.fire'servicethen the LoST server could, depending on the local policy at the LoST server, return: 1. 'urn:service:sos', or 2. 'urn:service:sos.fire'area, it MUST send a new query withthe values of 'urn:service:sos' being populatedits current location to'urn:service:sos.fire', or 3. an error message In case of (1) the <service> element carries theobtain valid service data. The service region is described by valueof 'urn:service:sos'. 6.4. ServiceBoundary Element Each <serviceBoundary> element contains eitherin one or morecivic location elements derived from the GeoPriv civic address schema or<serviceBoundary> elements, each formatted according to aGML-based polygon.different location profile. The<serviceBoundary> element indicates whereclient only processes thesame query would yieldfirst element that it can understand according to its list of supported location profiles. Thus, the elements are alternative descriptions of the sameresponse, i.e., it providesservice region, not additive geometries. The server returns all suitable service regions, using all available location profiles, so that intermediate caches have this informationaboutavailable for future queries. 6.4.6. Service Boundaries by Reference: theservice boundary. 6.5. ServiceNumber<serviceBoundaryReference> ElementTBD: This element contains the (emergency)Since geodetic servicenumber, which is a stringboundaries may contain thousands ofdigits usedpoints and thus be quite large, clients may opt toreach the (emergency) service. 6.6. TimeToLive Attribute Each timeToLive attribute isconserve bandwidth and request apositive integer, expressingreference to thevalidity periodservice boundary instead of theresponsevalue described inseconds.Section 6.4.5. TheLoST client MUST NOT consideridentifier of the service boundary is returnedlocation current afterin the <serviceBoundaryReference> element, along with a LoST URL identifying theexpirationserver from where it can be retrieved. The actual value of thevalidity period. 6.7. Validation Elementservice boundary is then retrieved with the getServiceBoundary (Section 7) request. The<validation> element containsidentifier 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, astring that is composednew identifier must be chosen. Because ofconcatenated tokens separated bythese properties, awhitespace. These tokens refer to the civic location labels used in child elementsclient receiving a mapping response can simply check if it already has a copy of the<civicAddress> element from the requestboundary with thathave been recognized as valid byidentifier. If so, it can skip checking with theserver. The following code snippet indicates thatserver whether thecivic address labels 'country', 'A1', 'A3', 'A6, 'PC' haveboundary has beenvalided byupdated. Since service boundaries are likely to remain unchanged for extended periods of time, possibly exceeding theLoST server. <validation>country A1 A3 A6 PC</validation> 6.8. Response Message Examples This section shows an examplenormal lifetime ofa query message providing geospatial and civic location information. <?xml version="1.0" encoding="UTF-8"?> <response xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" > <result status="200" message="OK" xml:lang="en" timeToLive="1000"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>urn:service:sos.police</service> <serviceBoundary> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:exterior> <p2:LinearRing> <p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4194</p2:pos> </p2:LinearRing> </p2:exterior> </p2:Polygon> </serviceBoundary> <uri>sip:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri> <serviceNumber>911</serviceNumber> </result> </response> Figure 6: Response Message Example using Geospatial Location Service Boundary Hints This example shows a response with two URIs forthepreviously queriedserviceURN. Information aboutURL, this approach avoids refreshing theserviceboundaryis provided by a GML polygon. The <serviceNumber> element indicatesinformation even if thevalidcached service response has gotten stale. 6.4.7. The Service Number The service numberforis returned in theexpressed locationoptional <serviceNumber> element. It contains a string of digits, * andservice URN. <?xml version="1.0" encoding="UTF-8"?> <response xmlns="urn:ietf:params:xml:ns:lost1"> <result status="200" timeToLive="10000"> <displayName xml:lang="de">Munich Police Department</displayName> <service>urn:service:sos.police</service> <serviceBoundary> <civicLocation> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <PC>81675</PC> </civicLocation> </serviceBoundary> <uri>sip:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri> <service-number>110</service-number> </result> </response> Figure 7: Response Message Example providing Civic Location Service Boundary Hints This example shows# that aresponseuser on a device with a 12-key dial pad could use to reach thatreturns two URIs (one for SIPparticular service. 6.4.8. Civic Address Validation A server can indicate in its response which civic address elements it has recognized as valid, which ones it has ignored andanother one for XMPP),which ones it has checked and found to be invalid. Each element contains adistring that indicates the valid distring forlist of tokens separated by white space, enumerating the civic locationprovided in the query, a hint about the service boundarylables used in child elements of the<serviceBoundary><civicAddress> element. The <valid> element enumerates those civic address elements that have been recognized as valid by the LoST server andinformation aboutthat have been used to determine the mapping. The <unchecked> elements enumerates thevalidatedcivic addressfields. The timeToLive attribute indicateselements that thereturned information can be cached for 10000 secondsserver did not check andprovides a *<displayName> element with additional, textual information aboutthat were not used in determining thereturned information. 7. List Services Query and Response 7.1. List Service Query This subsection describes a mechanismresponse. The <invalid> element enumerate civic address elements thatofferstheLoST clientserver attempted toquery for available service identifiers supported bycheck, but that did not match theLoST server.other civic address elements found in the <valid> list. ThelistServices query MUST carryexample (Figure 6) indicates that the<locationInfo>tokens 'country', 'A1', 'A3', and 'A6' have been validated by the<service> element. TheLoST server. The serverMUST return only immediate child elements ofconsidered theservice identifier specifiedpostal code 81675 in the<service><PC> elementof the listServices query availableas not valid for this location. 6.4.9. Validity: The 'timeToLive' Attribute The timeToLive attribute contains theprovided location information. <?xml version="1.0" encoding="UTF-8"?> <listServices xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" operation="false"> <locationInfo> <p2:Point id="point1" srsName="epsg:4326"> <p2:coordinates>37:46:30N 122:25:10W</p2:coordinates> </p2:Point> </locationInfo> <service>urn:service:sos</service> </listServices> Figure 8: Example for a List Service Query This listService query aims to querynumber of seconds theimmediate child elementsresponse 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.] 7. Retrieving the'urn:service:sos' URN. 7.2. ListServiceResponse This subsection describesBoundary via <getServiceBoundary> As discussed in Section 6.4.5, the <findService> responsemessagecan return a globally unique identifier thatprovides the LoST client withcan be used to retrieve thelist of immediate childserviceidentifiers based onboundary, rather than returning theservice identifier providedboundary byLoSTvalue. This is shown in the example in Figure 8. The clientwith respect tocan then retrieve thelocation information providedboundary using the <getServiceBoundary> request and obtains the boundary in the <getServiceBoundaryResponse>, illustrated in thelistService query. The followingexampleshowsin Section 7. The client issues theresponserequest to thelistServices query example of Figure 8 listingserver identified in theavailable services offered by'server' attribute of theLoST server starting with 'urn:service:sos.ambulance' and finishing with 'urn:service:sos.suicide'.<serviceBoundaryReference> element. C: <?xml version="1.0" encoding="UTF-8"?><response xmlns="urn:ietf:params:xml:ns:lost1"> <serviceList status="200" message="OK"C: <findService xmlns="urn:ietf:params:xml:ns:lost1" C: xmlns:p2="http://www.opengis.net/gml" recursive="true" C: include="uri service serviceNumber displayName C: serviceBoundaryReference"> C: <location C: profile="urn:ietf:params:lost:location-profile:geodetic-2d"> C: <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> C: <p2:pos>40.809 -73.9612</p2:pos> C: </p2:Point> C: </location> C: <service>urn:service:sos.police</service> C: </findService> S: <?xml version="1.0" encoding="UTF-8"?> S: <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" S: timeToLive="3600"> S: <displayName xml:lang="en">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 </serviceList> </response>S: New York City Police Department S: </displayName> S: <service>urn:service:sos.police</service> S: <serviceBoundaryReference server="lost:nypd.example.com" S: key="7214148E0433AFE2FA2D48003D31172E"/> S: <uri>sip:nypd@example.com</uri> S: <uri>xmpp:nypd@example.com</uri> S: <serviceNumber>911</serviceNumber> S: </findServiceResponse> Figure 8: findService with Service Boundary Reference C: <?xml version="1.0" encoding="UTF-8"?> C: <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1" C: key="7214148E0433AFE2FA2D48003D31172E"/> S: <?xml version="1.0" encoding="UTF-8"?> S: <getServiceBoundaryResponse S: xmlns="urn:ietf:params:xml:ns:lost1" S: xmlns:p2="http://www.opengis.net/gml"> S: S: <serviceBoundary S: profile="urn:ietf:params:lost:location-profile:geodetic-2d"> S: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> S: <p2:exterior> S: <p2:LinearRing> S: <p2:pos>40.701 -74.020</p2:pos> S: <p2:pos>40.876 -73.926</p2:pos> S: <p2:pos>40.797 -73.936</p2:pos> S: <p2:pos>40.714 -73.984</p2:pos> S: <p2:pos>40.701 -74.020</p2:pos> S: </p2:LinearRing> S: </p2:exterior> S: </p2:Polygon> S: </serviceBoundary> S: S: </getServiceBoundaryResponse> Figure 9:Example for the Response toRequesting aListServiceQuery 8. Status Code Definitions Each response contains a <status> 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. 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,Boundary with'2' signaling a successful request, '3' a redirection, '4' agetServiceBoundary The <getServiceBoundary> requestfailure duemay also be used to retrieve service boundaries that are expressed as civic addresses, as illustrated in Figure 10. <?xml version="1.0" encoding="UTF-8"?> <getServiceBoundaryResponse xmlns="urn:ietf:params:xml:ns:lost1"> <serviceBoundary profile="urn:ietf:params:lost:location-profile:basic-civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>US</country> <A1>New York</A1> <A3>New York</A3> </civicAddress> </serviceBoundary> </getServiceBoundaryResponse> Figure 10: Civic Address Service Boundary Response 8. List Services: <listServices> A LoST clientbehavior, and '5'can ask a LoST serverfailure.for the list of services it supports. The <listServices> query contains one or more <location> elements, each from a different location profile (Section 9), and may contain the <service> element. Ifused within HTTP, LoST also utilizesthenormal HTTP status codes. However,query contains theHTTP request can succeed, while<service> element the LoSTrequest 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. Temporary unavailabilityserver returns only immediate child services of the queried serviceshould be indicated by an HTTP 505 (Service Unavailable) status code. [Editor's Note: Does this make any sense or should all or some LoST errors occur in a non-200 HTTP response?] 8.1. Informational 1xx This document does not define informational status codes. 8.2. Successful 2xx 8.2.1. 200 OK The query completed successfully. 8.2.2. 201 Service Substitution The service requested is notthat are available for thelocation requested, butprovided location. If theserver is configured to provide a replacement service. 8.3. Redirection 3xx 8.3.1. 301 Move Permanently The requested location<service> element isbeing mapped by a different server andabsent, the LoST service returns allfuture requeststop-level services available forthat location (and locations intheservice area) should be directed to that server. 8.3.2. 302 Moved Temporarily The requestedprovided locationis being mapped by a different server, but future requests should continuethat it knows about. A server responds tousethisserver. 8.3.3. Examplequery with a <listServicesResponse> response. Thisis an exampleresponse has may contain <via> elements (Section 6.4.1) and must contain a <serviceList> element, consisting ofan error message witha302 status code:whitespace-separated list of service URNs. The query and response are illustrated in Figure 11. C: <?xml version="1.0" encoding="UTF-8"?> C: <listServices C: xmlns="urn:ietf:params:xml:ns:lost1" C: xmlns:p2="http://www.opengis.net/gml" C: recursive="false"> C: <location C: profile="urn:ietf:params:lost:location-profile:basic-civic"> C: <p2:Point id="point1" srsName="epsg:4326"> C: <p2:coordinates>37:46:30N 122:25:10W</p2:coordinates> C: </p2:Point> C: </location> C: <service>urn:service:sos</service> C: </listServices> S: <?xml version="1.0" encoding="UTF-8"?><responseS: <listServicesResponse xmlns="urn:ietf:params:xml:ns:lost1"><redirect status="302" message="County-level routing" xml:lang="en" redirect="lost:co.lancaster.pa.us" </response> 8.4. Client Error 4xx 8.4.1. 400 Bad Request TheS: <serviceList> 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: </serviceList> S: </listServicesResponse> Figure 11: ListService Query Example 9. Location Profiles Currently, LoST uses location information in <location> elements in requests and <serviceBoundary> elements in responses. Such location information may be expressed in a variety of ways. This variety can cause interoperability problems where a requestcouldor response contains location information in a format notbeunderstooddue to malformed syntax. 8.4.2. 403 Forbidden Theby the serverunderstoodor client, respectively. To achieve interoperability, LoST defines two must-implement baseline location profiles to define therequest, butmanner in which location information isrefusing to fulfill it. Authorization will not help,transmitted and makes it possible to standardize other profiles in therequest SHOULD NOT be repeated. 8.4.3. 404 Not Foundfuture. Theserver has definitive information that there is no service mappingtwo baseline profiles are: geodetic-2d: a simple profile forthetwo-dimensional geodetic locationspecified. 8.4.4. 414 Location Error Theinformation, described in Section 9.2); civic: a profile consisting of civic address locationprovided does not existinformation, described in Section 9.3. Requests and responses containing <location> orfields within the<serviceBoundary> elements MUST contain location informationare contradictory. 8.4.5. Example 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: <?xml version="1.0" encoding="UTF-8"?> <response xmlns="urn:ietf:params:xml:ns:lost1"> <result status="250" message="Default Route" xml:lang="en" timeToLive="10000"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>unknown</service> <serviceBoundary> <civicLocation> <country>US</country> <A1>New York</A1> <A3>New York</A3> </civicLocation> </serviceBoundary> <uri>sip:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri> <service-number>911</service-number> </result> <failure status="414" message="Address error" xml:lang="en"> <cause name="PC" message="postal code is outsidein exactly one ofservice boundary" xml:lang="en" /> </failure> </response>the two baseline profiles, in addition to zero or more additional profiles. Thesecond example shows an error message withordering of location information indicates a414 status code that is attached topreference on theresponse message indicating that there was a problem withpart of theprovided geospatialsender. Standards action may create other profiles. A locationinformation: <?xml version="1.0" encoding="UTF-8"?> <response xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" > <result status="250" message="Default PSAP" xml:lang="en" timeToLive="1000"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>urn:service:sos.police</service> <serviceBoundary> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:exterior> <p2:LinearRing> <p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4194</p2:pos> </p2:LinearRing> </p2:exterior> </p2:Polygon> </serviceBoundary> <uri>sip:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri> <serviceNumber>911</serviceNumber> </result> <failure status="414" message="Invalide Goegraphic Location" xml:lang="en"> <cause name="p2:coordinates" message="invalid latitude" xml:lang="en" /> </failure> </response> 8.5. Server Error 5xx 8.5.1. 500 Server Internal Errorprofile MUST define: 1. Theserver encountered an unexpected condition that preventedtoken identifying itfrom fulfillingin therequest.LoST location profile registry; 2. Theclient MAY retryformal definition of therequest after several seconds. 8.5.2. 501 Service Not ImplementedXML to be used in requests, i.e., an enumeration and definition of the XML child elements of the <location> element; 3. Theserver does not implement mapping forformal definition of theservice requested and cannot provideXML to be used in responses, i.e., analternate service. 8.5.3. 504 Server Time-Out A server time-out occurs ifenumeration and definition of theserver contacted tries to recursively resolveXML child elements of thequery, but cannot get an answer withinthetime limit set for<serviceBoundary> element; 4. The declaration of whether geodetic-2d or civic is to be used as thequery. 8.5.4. Example Thisbaseline profile. It isan examplenecessary to explicitly declare the baseline profile as future profiles may be combinations of geodetic and civic location information. 9.1. Location Profile Usage A location profile is identified by a URN in the urn:ietf:params:lost:location-profile registry. (Note that this is not anerror messageXML schema or namespace identifier.) Clients send location information compliant with a500 status code: <?xml version="1.0" encoding="UTF-8"?> <response xmlns="urn:ietf:params:xml:ns:lost1"> <status code="500">Server failure</status> </response> 9. LoST Transportlocation profile, and servers respond with location information compliant with that same location profile. When a LoSTneeds an underlying protocol transport mechanisms to carry requestsclient sends a request which provides location information, it contains one or more <location> elements. Each of these elements contains location information compliant with a location profile andresponses.specifies which profile has been used in the 'profile' attribute. Thisdocument definesallows theuse of LoST over HTTP and HTTP-over-TLS; other mechanisms are leftclient tofuture documents. The available transport mechanisms are indicatedconvey location information for multiple location profiles in theLoST U-NAPTR DNS resource record. In protocols that support content type indication, LoST uses the media type application/lost+xml.same request. Whenusing HTTP [14] and HTTP-over-TLS [15],a LoSTrequests use the HTTP POST method. All HTTP responses are applicable. The HTTP URL is derived fromserver sends a response which contains location information, it uses theLoST URL via U-NAPTR translation, as discussed in Section 4. 10. LoST Uniform Resource Locators LoST Uniform Resource Locators (URLs) follow<serviceBoundary> elements much like theformat of URLs definedclient uses the <location> elements. Each <serviceBoundary> element contains location information conformant to the location profile specified inRFC 3986 [9],the 'profile' attribute. This allows the server to send location information compliant with multiple location profiles. Using thefollowing ABNF: LoST-URI = "lost:" host 'host' islocation profiles defined inSection 3.2.2 of RFC 3986 [9]. An example is 'lost:lostserver.example.com' 11. Example After performing link layer attachmentthis document, the following rules insure basic interoperatiblity between clients andend host performs stateful address autoconfiguration (in our example) using DHCP. Then, DHCP providesservers: 1. A client MUST be capable of understanding theend host with civicresponse for the baseline profiles it used in the request. 2. If a client sends locationas describedinformation conformant to any location profile other than geodetic-2d or civic, it MUST also send, in[19]. +--------+---------------+ | CAtype | CAvalue | +--------+---------------+ | 0 | US | | 1 | New York | | 3 | New York | | 6 | Broadway | | 22 | Suite 75 | | 24 | 10027-0401 | +--------+---------------+ Figure 14: DHCP Civic Information Example Additionally, DHCP may providethe same request, location informationaboutconformant to one of the baseline profiles. Otherwise, theLoSTserverthat canmight not becontacted. Alternatively, an additional step of indirection is possible, for example by having DHCP returnable to understand the request. 3. Servers MUST implement the geodetic-2d and civic profiles. 4. A server ignores any location information using non-baseline profiles it does not understand. 5. If adomain nameserver receives a request that only contains location information using profiles it does not understand, the server responds with a <locationProfileError> (Section 10.2). 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 beresolvedable tooneunderstand the request and provide an understandable response, though with location information that might not be as precise ormore IP addresses hosting LoST servers. Both at attachment timeexpressive as desired. This is possible because both Client X andcall time,Server Y understand the baseline profile. The following transaction, where the XML sent by the clientplaces a LoST request, including its civic locationis prepended with 'C:' and thedesired service. The requestXML sent by the server isshown below:prepended with 'S:', demonstrates this: C: <?xml version="1.0" encoding="UTF-8"?><findServiceByLocationC: <findService xmlns="urn:ietf:params:xml:ns:lost1"validate="false" operation="recursive"> <locationInfo> <civicLocation> <country>US</country> <A1>New York</A1> <A3>New York</A3> <A6>Broadway</A6> <LOC>Suite 75</LOC> <PC>10027-0401</PC> </civicLocation> </locationInfo>C: xmlns:p2="http://www.opengis.net/gml" C: recursive="true" include="uri serviceNumber"> C: <location C: profile="urn:ietf:params:lost:location-profile:geodetic-2d"> C: <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> C: <p2:pos>40.8089897 -73.9612492</p2:pos> C: </p2:Point> C: </location> C: <location C: profile=" C: urn:ietf:params:lost:location-profile:uber-complex-3d"> C: <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> C: <p2:pos>37.775 -122.422 25</p2:pos> C: </p2:Point> C: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> C: <p2:exterior> C: <p2:LinearRing> C: <p2:pos>40.80 -73.96 24</p2:pos> C: <p2:pos>40.81 -73.95 27</p2:pos> C: <p2:pos>40.80 -73.96 24</p2:pos> C: </p2:LinearRing> C: </p2:exterior> C: </p2:Polygon> C: </location> C: <service>urn:service:sos.police</service></findServiceByLocation> Mapping Request SinceC: </findService> S: <?xml version="1.0" encoding="UTF-8"?> S: <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" S: xmlns:p2="http://www.opengis.net/" timeToLive="3600"> S: <locationProfileError S: unsupportedProfiles=" S: urn:ietf:params:lost:location-profile:uber-complex-3d" S: message="Too sophisticated for us." xml:lang="en"/> S: <displayName xml:lang="en"> S: New York City Police Department S: </displayName> S: <service>urn:service:sos.police</service> S: <serviceBoundary S: profile="urn:ietf:params:lost:location-profile:geodetic-2d"> S: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> S: <p2:exterior> S: <p2:LinearRing> S: <p2:pos>40.701 -74.020</p2:pos> S: <p2:pos>40.876 -73.926</p2:pos> S: <p2:pos>40.797 -73.936</p2:pos> S: <p2:pos>40.714 -73.984</p2:pos> S: <p2:pos>40.701 -74.020</p2:pos> S: </p2:LinearRing> S: </p2:exterior> S: </p2:Polygon> S: </serviceBoundary> S: <uri>sip:nypd@example.com</uri> S: </findServiceResponse> Figure 12: Example of a findServices query with baseline profile interoperability 9.2. Two Dimensional Geodetic Profile The geodetic-2d location profile is identified by geodetic-2d. Clients use this profile by placing a GML [13] <position> element within thecontacted LoST server has<location> element. This is defined by therequested information available'point2D' pattern in thefollowing response is returned. The <displayName> element indicates, asLoST schema (see Section 12). Servers use this profile by placing ahuman readable display string, thatGML [13] <Polygon> element within the'New York City Police Department'<serviceBoundary> element. This isresponsible fordefined by thegiven geographical area.'polygon' pattern in the LoST schema (see Section 12). 9.3. Basic Civic Profile The basic-civic location profile is identified by the token 'civic'. Clients use this profile by placing a <civicAddress> element, defined in [11], within the <location> element. Servers use this profile by placing a <civicAddress> element, defined in [11], within the <serviceBoundary> element. 10. Error Handling Errors are indicatedURI allowsby error-specific elements. Depending on theuser to start communication using SIP or XMPP. The <validation>nature of the error, the error elementindicates which partsmay 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 10.1. Basic Errors 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 thecivic address were matched successfully againsthuman readable text. LoST defines the following elements as following this pattern: badRequest The server could not parse or otherwise understand adatabase and representrequest. This is aknown address. Other parts of the address, here, the suite number, were ignoredtop-level element, and is returned if the server did notvalidated. The <serviceBoundary> element indicates that all of New York City would result inunderstand thesame response. The <serviceNumber>outermost LoST XML elementindicates that the service can be reached viaidentifying theemergency service number 911. <?xml version="1.0" encoding="UTF-8"?> <response xmlns="urn:ietf:params:xml:ns:lost1"> <result status="200" message="OK" xml:lang="en" timeToLive="10000"> <displayName xml:lang="en"> New York City Police Department </displayName> <service>unknown</service> <serviceBoundary> <civicLocation> <country>US</country> <A1>New York</A1> <A3>New York</A3> </civicLocation> </serviceBoundary> <uri>sip:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri> <service-number>911</service-number> </result> </response> Mapping Response 12. Deployment Methods Because services for emergency contact resolution may differ depending on local orrequest. serviceSubstitution The server substituted one serviceneeds, this document only specifies the "wire format"for another. See Section 6.4.4. 10.2. Response Errors LoSTservices and explicitly leaves open the possibility for many different types of deployment. For instance: During discovery,defines aclientpattern for errors that maybe directed to issue all queries to angenerated by referrent LoSTservice completely authoritative forserves queried on behalf of seekers by agiven jurisdiction. A client may be directed to issue queries to anresolving LoST server. This pattern builds on the basic errors pattern (Section 10.1). It also provides the option of specifying the source serverthat actsusing the 'source' attribute, asa reflector. In such a case,well as specifying the query that caused the error. LoSTserver analyzesdefines thequeryfollowing elements as following this pattern: forbidden The server refused to send an answer. notFound The server could not find an answer todeterminethebestquery. serviceNotImplemented The requested service is not implemented. internalError The server could not satisfy a request due to misconfiguration or other operational and non-protocol related reasons. serverTimeout A time out occurred before an answer was received. serverError An answer was received but it could not be parsed or otherwise understood. locationProfileError A location profile in the query given is not recognized. The element may also have an 'unsupportedProfiles' attribute, whichto refercontains a whitespace separated list of profile URNs. See Section 9. 10.3. Redirects LoST defines a pattern for redirect responses. This pattern builds on the basic error pattern (Section 10.1) and includes a 'url' attribute indicating theclient. OrLoST URL that the clientmayshould bedirected to a server that performs further resolution on behalf ofcontacting next. Currently, LoST only defines theclient. A<redirect> element along this pattern. 11. LoSTservice may also be represented by multipleTransport LoSTservers, either grouped together or at multiple network locations. Using S-NAPTR [24], clients may be given a list of multiple serversneeds an underlying protocol transport mechanisms towhich queries can be sent for a single service. For instance,carry requests and responses. This document defines theservice at emergency.example.com may advertiseuse of LoSTservice at local1.emergency.example.com, local2.emergency.example.com,over HTTP andmaster.emergency.example.com. Each server may given a different preference.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. Inthis case, 'local-1'protocols that support content type indication, LoST uses the media type application/ lost+xml. When using HTTP [3] and'local-2' may be given a lower preference (more preferred) than 'master', which might be a busier server or located further away. +-----------+ pref 10 +-----------+ | |-------------------->+ | | client |------ | local-1 | | |--- \ | | +-----------+ \ \ +-----------+ \ \ \ \ +-----------+ \ \ pref 10 | | \ --------->| local-2 | \ | | \ +-----------+ \ \ +-----------+ \ pref 20 | | ------------------------->| master | | | +-----------+ 13.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""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""urn:ietf:params:xml:ns:lost1" ## ## Location-to-Service Translation Protocol (LoST) ## ## A LoST XML instance has three"root" types:request types, each with ##the findServiceByLocation query, thea cooresponding response type: find service, list services, ## and get service boundary. ## start = findService | listServices | getServiceBoundary | findServiceResponse | listServicesResponse | getServiceBoundaryResponse ## ## The queries. ## div { findService = element ns1:findService { query, 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 } } ##and the response to these queries.##startThe responses. ## div { findServiceResponse =findServiceByLocationelement ns1:findServiceResponse { via, ((locationProfileError?, serviceSubstitution?, serviceResult) |listServicesbadRequest |responseinternalError | 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 } } ## ##TheA pattern common to some of the queries. ## div {findServiceByLocationquery = elementfindServiceByLocationns1:location {query,locationInformation }+, element ns1:service { xsd:anyURI }?, extensionPoint, attributevalidaterecursive { xsd:boolean >> a:defaultValue ["false""true" ] }? }listServices## ## Location Information ## div { locationInformation =element listServicesextensionPoint+, attribute profile {queryxsd:anyURI } } ## ##The response.Service Boundary ## div {responseserviceBoundary = elementresponsens1:serviceBoundary { locationInformation }+ } ## ##2xx responses.Service Boundary Key ##(result | element serviceListdiv { serviceBoundaryKey = attribute key { xsd:string { pattern = "[a-zA-Z0-9/+=]+" } } } ## ## Via - list of places through which information flowed ## div {xsd:anyURI* }, status })?,via = element ns1:via { xsd:anyURI }* } ## ##3xx, 4xx, and 4xx responses.Time-to-live pattern ##((error | redirect | failure)?), extensionPointdiv { timeToLive = attribute timeToLive { xsd:positiveInteger } } ## ##Query pattern.A QName list ## div {queryqnameList = list { xsd:QName* } } ## ## A location-to-service result. ## div { serviceResult = elementlocationInfons1:displayName {anyElement* },xsd:string, attribute xml:lang { xsd:language } }?, elementservicens1:service { xsd:anyURI}, extensionPoint, [ a:defaultValue [ "recursive" ] ] attribute operation}?, (serviceBoundary | element ns1:serviceBoundaryReference {text }?serviceBoundaryKey })?, element ns1:uri { xsd:anyURI }*, element ns1:serviceNumber { xsd:string { pattern = "[0-9]+" } }?, element ns1:valid { qnameList }?, element ns1:invalid { qnameList }?, element ns1:unchecked { qnameList }?, extensionPoint, timeToLive, message } ## ##A result.Basic Errors ## div { ## ##2xx response.Error pattern. ##resulterror = message, extensionPoint badRequest = elementresultns1:badRequest { error } internalError = elementdisplayNamens1:internalError {xsd:string, attribute xml:langerror } serviceSubstitution = element ns1:serviceSubstitution {xsd:languageerror } } ## ## Recursion Errors. ## div { ## ## Recursion error. ## recursionError = attribute failedReferral { xsd:anyURI }?, (findService | listServices | getServiceBoundary)?, error forbidden = elementservicens1:forbidden {xsd:anyURIrecursionError }, timeToLive notFound = element ns1:notFound { recursionError }, timeToLive serviceNotImplemented = elementserviceBoundaryns1:serviceNotImplemented {(civicLocation, polygon?) | (civicLocation?, polygon) }?,recursionError }, timeToLive serverTimeout = elementurins1:serverTimeout {xsd:anyURI }+,recursionError }, timeToLive serverError = elementserviceNumber { xsd:stringns1:serverError {patternrecursionError }, timeToLive locationProfileError ="[0-9]+" } }?,elementvalidationns1:locationProfileError { attribute unsupportedProfiles { list {xsd:QName*xsd:anyURI* }}?, extensionPoint, attribute timeToLive { xsd:positiveInteger},statusrecursionError } } ## ##Non-result responses.Redirects. ## div { ## ##5xx response. ## error = element error { status, extensionPoint } ## ## 3xx response.Redirect pattern ## redirect =element redirect { status,attribute redirect { xsd:anyURI },extensionPoint } ## ## 4xx response. ## failureerror movedPermenantly = elementfailurens1:movedPermanently {status,redirect } movedTemporarily = elementcausens1:movedTemporarily {attribute name { xsd:QNameredirect },attribute messagetimeToLive iterativeSearchExhausted = element ns1:iterativeSearchExhausted {xsd:stringredirect },attribute xml:lang { xsd:language } }*, extensionPoint }timeToLive } ## ##StatusMessage pattern. ## div {statusmessage =attribute status { xsd:positiveInteger }, attribute extendedStatus { xsd:positiveInteger }?,(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(element * {(attributeanyElement } | attribute * { text } |text | anyElement)* }text)* ## ## A point where future extensions ## (elements from othernamesapces)namespaces) ## can be added. ## extensionPoint =anyElement*notLost* ## ## Apattern to include the GEOPRIV civil location elements.2D point from GML. ##civicAddresspoint2d = elementns1:*position {(attribute *element Point { attribute srsName { "urn:ogc:def:crs:EPSG:4326" }, element pos { text }| text | anyElement)*} } ## ## Adefinition of civic locationLinear Ring fromGEOPRIV.GML. ##civicLocationlinearRing = elementcivicLocationLinearRing { element pos {civicAddress*, anyElement*text } } ## ## Apattern to include GML elements.Polygon from GML. ##GMLpolygon = elementns2:*Polygon {(attribute *attribute srsName {text } | text | anyElement)* } polygon ="urn:ogc:def:crs:EPSG:4979" }, elementns2:Polygonexterior {attribute *linearRing }, element interior {text }*, GMLlinearRing }* } }14.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 <displayName> element and the 'message' attributes may be displayed to the end user, andit isthey are thus a complextypetypes designed for this purpose.15.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. 14. IANA Considerations15.1.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][9] and guidelines in RFC 3023[12].[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],[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 Applications which use this media type: Emergency and Location-based Systems Additional information: Magic Number: None File Extension: .lostxml Macintosh file type code: 'TEXT' Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@siemens.com Intended usage: LIMITED USE Author: This specification is a work item of the IETF ECRIT working group, with mailing list address <ecrit@ietf.org>. Change controller: The IESG <iesg@ietf.org>15.2.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 Section13.12. Its first line is default namespace = "urn:ietf:params:xml:ns:lost1" and its last line is }15.3.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 <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>LoST Namespace</title> </head> <body> <h1>Namespace for LoST</h1> <h2>urn:ietf:params:xml:ns:lost</h2> <p>See <a href="[URL of published RFC]">RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.]</a>.</p> </body> </html> END15.4.14.5. Registration Template This registration template is in accordance with[8].[4]. URL scheme name: lost URL scheme syntax: See Section105 Character encoding considerations: See Section105 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 Section1615 Relevant publications: This document provides the relevant context for this URL scheme. Contact: Hannes Tschofenig, Hannes.Tschofenig@siemens.com Author/Change controller: The IESG <iesg@ietf.org>16.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, theauthors RECOMMEND theuse ofchannelchannels security, such as TLS,with LoST.is RECOMMENDED. A more detailed description of threats and security requirements are provided in[4]. 17.[17]. 16. Acknowledgments [Editor's Note: Names need to be added here. Forgot it...Sorry.]18.17. Open Issues Please find open issues at: http://www.ietf-ecrit.org:8080/lost/19.18. References19.1.18.1. Normative References [1]World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>. [2] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>. [3]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[2] Narten, T. andMapping", draft-ietf-ecrit-security-threats-03 (work in progress), July 2006. [5] Schulzrinne,H.and R. Marshall, "RequirementsAlvestrand, "Guidelines forEmergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-12 (workWriting an IANA Considerations Section inprogress), August 2006. [6] Schulzrinne,RFCs", BCP 26, RFC 2434, October 1998. [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,"A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-05 (work in progress), August 2006. [7] Mealling, M., "The IETF XML Registry", draft-mealling-iana-xmlns-registry-05 (work in progress),Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June2003. [8]1999. [4] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.[9][5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [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][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][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,[10] Schulzrinne, H.,Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [16]"A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-05 (work in progress), August 2006. [11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for PIDF-LO",draft-ietf-geopriv-revised-civic-lo-02draft-ietf-geopriv-revised-civic-lo-04 (work in progress),AprilSeptember 2006.[17][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.[13] OpenGIS, "Open Geography Markup Language (GML) Implementation Specification", OGC OGC 02-023r4, January 2003. 18.2. Informative References[18][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.[19][17] Taylor, T., "Security Threats and Requirements for Emergency Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 (work in progress), July 2006. [18] Schulzrinne,H., "Dynamic Host Configuration Protocol (DHCPv4H. andDHCPv6) OptionR. Marshall, "Requirements forCivic Addresses Configuration Information", draft-ietf-geopriv-dhcp-civil-09Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-12 (work in progress),JanuaryAugust 2006.[20][19] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", draft-ietf-ecrit-mapping-arch-00 (work in progress), August 2006.[21][20] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling",draft-rosen-sos-phonebcp-01 (work in progress), June 2006. [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [23] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-10draft-ietf-ecrit-phonebcp-00 (work in progress),AugustOctober 2006.[24] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.Appendix A. Non-Normative RELAX NG Schema in XML Syntax <?xml version="1.0" encoding="UTF-8"?> <grammar ns="urn:ietf:params:xml:ns:lost1" xmlns="http://relaxng.org/ns/structure/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <start> <a:documentation> Location-to-Service Translation Protocol (LoST) A LoST XML instance has three"root" types: the findServiceByLocation query, the listServices query, and therequest types, each with a cooresponding responseto thesetype: find service, list services, and get service boundary. </a:documentation> <choice> <ref name="findService" /> <ref name="listServices" /> <ref name="getServiceBoundary" /> <ref name="findServiceResponse" /> <ref name="listServicesResponse" /> <ref name="getServiceBoundaryResponse" /> </choice> </start> <div> <a:documentation> The queries. </a:documentation> <define name="findService"> <element name="findService"> <ref name="query" /> <optional> <attribute name="include"> <list> <zeroOrMore> <choice> <value>uri</value> <value>serviceNumber</value> <value>displayName</value> <value>service</value> <value>valid</value> <value>invalid</value> <value>unchecked</value> <value>serviceBoundary</value> <value>serviceBoundaryReference</value> </choice> </zeroOrMore> </list> <a:defaultValue>uri serviceNumber</a:defaultValue> </attribute> </optional> </element> </define> <define name="listServices"> <element name="listServices"> <ref name="query" /> </element> </define> <define name="getServiceBoundary"> <element name="getServiceBoundary"> <ref name="serviceBoundaryKey" /> <ref name="extensionPoint" /> </element> </define> </div> <div> <a:documentation> The responses. </a:documentation> <define name="findServiceResponse"> <element name="findServiceResponse "> <ref name="via" /> <choice> <group> <optional> <ref name="locationProfileError"/> </optional> <optional> <ref name="serviceSubstitution"/> </optional> <ref name="serviceResult" /> </group> <ref name="badRequest"/> <ref name="internalError"/> <ref name="forbidden"/> <ref name="notFound"/> <ref name="serviceNotImplemented"/> <ref name="serverTimeout"/> <ref name="serverError"/> <ref name="movedPermenantly"/> <refname="findServiceByLocation"name="movedTemporarily"/> <ref name="iterativeSearchExhausted"/> </choice> <ref name="extensionPoint" /> </element> </define> <define name="listServicesResponse"> <element name="listServicesResponse"> <refname="listServices"name="via" /> <choice> <group> <optional> <refname="response"name="locationProfileError"/> </optional> <element name="serviceList"> <list> <zeroOrMore> <data type="anyURI" /> </zeroOrMore> </list> </element> </group> </choice></start><ref name="extensionPoint" /> </element> </define> <define name="getServiceBoundaryResponse"> <element name="getServiceBoundaryResponse"> <choice> <group> <ref name="serviceBoundary"/> </group> <ref name="badRequest"/> <ref name="internalError"/> <ref name="forbidden"/> <ref name="notFound"/> </choice> <ref name="extensionPoint" /> </element> </define> </div> <div> <a:documentation>TheA pattern common to some of the queries. </a:documentation> <definename="findServiceByLocation">name="query"> <oneOrMore> <elementname="findServiceByLocation">name="location"> <refname="query"name="locationInformation" /> </element> </oneOrMore> <optional> <element name="service"> <data type="anyURI"/> </element> </optional> <ref name="extensionPoint" /> <optional> <attributename="validate">name="recursive"> <data type="boolean" /><a:defaultValue>false</a:defaultValue><a:defaultValue>true</a:defaultValue> </attribute> </optional></element></define> </div> <div> <a:documentation> Location Information </a:documentation> <definename="listServices">name="locationInformation"> <oneOrMore> <ref name="extensionPoint"/> </oneOrMore> <attribute name="profile"> <data type="anyURI" /> </attribute> </define> </div> <div> <a:documentation> Service Boundary </a:documentation> <define name="serviceBoundary"> <oneOrMore> <elementname="listServices">name="serviceBoundary"> <refname="query"name="locationInformation" /> </element> </oneOrMore> </define> </div> <div> <a:documentation>The response.Service Boundary Key </a:documentation> <definename="response"> <element name="response"> <optional> <choice>name="serviceBoundaryKey"> <attribute name="key"> <data type="string"> <param name="pattern">[a-zA-Z0-9/+=]+</param> </data> </attribute> </define> </div> <div> <a:documentation>2xx responses.Via - list of places through which information flowed </a:documentation><ref name="result" /><define name="via"> <zeroOrMore> <elementname="serviceList">name="via"> <data type="anyURI"/> </element> </zeroOrMore> </define> </div> <div> <a:documentation> Time-to-live pattern </a:documentation> <define name="timeToLive"> <attribute name="timeToLive"> <data type="positiveInteger"/> </attribute> </define> </div> <div> <a:documentation> A QName list </a:documentation> <define name="qnameList"> <list> <zeroOrMore> <datatype="anyURI" />type="QName"/> </zeroOrMore> </list><ref name="status" /></define> </div> <div> <a:documentation> A location-to-service result. </a:documentation> <define name="serviceResult"> <optional> <element name="displayName"> <data type="string"/> <attribute name="xml:lang"> <data type="language"/> </attribute> </element> </optional> <optional> <element name="service"> <data type="anyURI"/> </element></choice></optional> <optional><a:documentation> 3xx, 4xx, and 4xx responses. </a:documentation><choice> <refname="error" />name="serviceBoundary"/> <element name="serviceBoundaryReference"> <ref name="serviceBoundaryKey"/> </element> </choice> </optional> <zeroOrMore> <element name="uri"> <data type="anyURI"/> </element> </zeroOrMore> <optional> <element name="serviceNumber"> <data type="string"> <param name="pattern">[0-9]+</param> </data> </element> </optional> <optional> <element name="valid"> <refname="redirect"name="qnameList" /> </element> </optional> <optional> <element name="invalid"> <refname="failure"name="qnameList" /></choice></element> </optional> <optional> <element name="unchecked"> <refname="extensionPoint"name="qnameList" /> </element> </optional> <ref name="extensionPoint"/> <ref name="timeToLive"/> <ref name="message"/> </define> </div> <div> <a:documentation>QueryBasic Errors </a:documentation> <define name="error"> <a:documentation> Error pattern. </a:documentation> <ref name="message"/> <ref name="extensionPoint" /> </define> <definename="query">name="badRequest"> <elementname="locationInfo"> <zeroOrMore>name="badRequest"> <refname="anyElement"/> </zeroOrMore>name="error"/> </element> </define> <define name="internalError"> <elementname="service"> <data type="anyURI"/> </element>name="internalError"> <refname="extensionPoint" /> <optional> <attribute name="operation"> <a:defaultValue>recursive</a:defaultValue> </attribute> </optional>name="error"/> </element> </define> <define name="serviceSubstitution"> <element name="serviceSubstitution"> <ref name="error"/> </element> </define> </div> <div> <a:documentation>A result.Recursion Errors. </a:documentation> <definename="result">name="recursionError"> <a:documentation>2xx response.Recursion error. </a:documentation><element name="result"><optional><element name="displayName"> <data type="string"/><attributename="xml:lang">name="failedReferral"> <datatype="language" />type="anyURI"/> </attribute></element></optional><element name="service"> <data type="anyURI"/> </element><optional><element name="serviceBoundary"><choice><group><refname="civicLocation"name="findService" /><optional><refname="polygon"name="listServices" /></optional> </group> <group> <optional><refname="civicLocation"name="getServiceBoundary" /> </choice> </optional> <refname="polygon" /> </group> </choice>name="error"/> </define> <define name="forbidden"> <element name="forbidden"> <ref name="recursionError"/> </element></optional> <oneOrMore><ref name="timeToLive"/> </define> <define name="notFound"> <elementname="uri"> <data type="anyURI"/>name="notFound"> <ref name="recursionError"/> </element></oneOrMore> <optional><ref name="timeToLive"/> </define> <define name="serviceNotImplemented"> <elementname="serviceNumber"> <data type="string"> <param name="pattern">[0-9]+</param> </data>name="serviceNotImplemented"> <ref name="recursionError"/> </element></optional> <optional><ref name="timeToLive"/> </define> <define name="serverTimeout"> <elementname="validation">name="serverTimeout"> <ref name="recursionError"/> </element> <ref name="timeToLive"/> </define> <define name="serverError"> <element name="serverError"> <ref name="recursionError"/> </element> <ref name="timeToLive"/> </define> <define name="locationProfileError"> <element name="locationProfileError"> <attribute name="unsupportedProfiles"> <list> <zeroOrMore> <datatype="QName"/>type="anyURI"/> </zeroOrMore> </list></element> </optional> <ref name="extensionPoint" /> <attribute name="timeToLive"> <data type="positiveInteger"/></attribute> <refname="status" />name="recursionError"/> </element> </define> </div> <div> <a:documentation>Non-result responses. </a:documentation> <define name="error"> <a:documentation> 5xx response.Redirects. </a:documentation><element name="error"> <ref name="status"/> <ref name="extensionPoint" /> </element> </define><define name="redirect"> <a:documentation>3xx response.Redirect pattern </a:documentation><element name="redirect"> <ref name="status"/><attribute name="redirect"> <data type="anyURI"/> </attribute> <refname="extensionPoint" /> </element>name="error"/> </define> <definename="failure"> <a:documentation> 4xx response. </a:documentation>name="movedPermenantly"> <elementname="failure">name="movedPermanently"> <refname="status"/> <zeroOrMore>name="redirect"/> </element> </define> <define name="movedTemporarily"> <elementname="cause"> <attribute name="name"> <data type="QName"/> </attribute> <attribute name="message"> <data type="string"/> </attribute> <attribute name="xml:lang"> <data type="language"/> </attribute>name="movedTemporarily"> <ref name="redirect"/> </element></zeroOrMore><refname="extensionPoint"name="timeToLive" /> </define> <define name="iterativeSearchExhausted"> <element name="iterativeSearchExhausted"> <ref name="redirect"/> </element> <ref name="timeToLive" /> </define> </div> <div> <a:documentation>StatusMessage pattern. </a:documentation> <definename="status"> <attribute name="status"> <data type="positiveInteger"/> </attribute> <optional> <attribute name="extendedStatus"> <data type="positiveInteger"/> </attribute> </optional>name="message"> <optional> <group> <attribute name="message"> <data type="string"/> </attribute> <attribute name="xml:lang"> <data type="language"/> </attribute> </group> </optional> </define> </div> <div> <a:documentation> Patterns for inclusion of elements from schemas in other namespaces. </a:documentation> <define name="notLost"> <a:documentation> Any element not in the LoST namespace. </a:documentation> <element> <anyName> <except> <nsName ns="urn:ietf:params:xml:ns:lost1"/> <nsName/> </except> </anyName> <ref name="anyElement"/> </element> </define> <define name="anyElement"> <a:documentation> A wildcard pattern for including any element from any other namespace. </a:documentation><element> <anyName/><zeroOrMore> <choice> <element> <anyName/> <ref name="anyElement"/> </element> <attribute> <anyName/> </attribute> <text/><ref name="anyElement"/></choice> </zeroOrMore></element></define> <define name="extensionPoint"> <a:documentation> A point where future extensions (elements from other namespaces) can be added. </a:documentation> <zeroOrMore> <refname="anyElement"name="notLost" /> </zeroOrMore> </define> <definename="civicAddress">name="point2d"> <a:documentation> Apattern to include the GEOPRIV civil location elements.2D point from GML. </a:documentation><element> <nsName ns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/> <zeroOrMore> <choice> <attribute> <anyName/><element name="position" ns="http://www.opengis.net/gml"> <element name="Point"> <attribute name="srsName"> <value>urn:ogc:def:crs:EPSG:4326</value> </attribute> <element name="pos"> <text/><ref name="anyElement"/> </choice> </zeroOrMore></element> </element> </element> </define> <definename="civicLocation">name="linearRing"> <a:documentation> Adefinition of civic locationLinear Ring fromGEOPRIV.GML. </a:documentation> <elementname="civicLocation"> <zeroOrMore> <ref name="civicAddress"/> </zeroOrMore> <zeroOrMore> <ref name="anyElement" /> </zeroOrMore>name="LinearRing" ns="http://www.opengis.net/gml"> <element name="pos"> <text/> </element> </element> </define> <definename="GML">name="polygon"> <a:documentation> Apattern to include GML elements.Polygon from GML. </a:documentation><element> <nsName ns="http://www.opengis.net/gml" /> <zeroOrMore> <choice> <attribute> <anyName/> </attribute> <text/> <ref name="anyElement" /> </choice> </zeroOrMore> </element> </define> <define name="polygon"><element name="Polygon" ns="http://www.opengis.net/gml"><zeroOrMore> <attribute> <anyName/><attribute name="srsName"> <value>urn:ogc:def:crs:EPSG:4979</value> </attribute></zeroOrMore><element name="exterior"> <ref name="linearRing"/> </element> <zeroOrMore> <element name="interior"> <refname="GML"/>name="linearRing"/> </element> </zeroOrMore> </element> </define> </div> </grammar> Authors' Addresses Ted Hardie Qualcomm, Inc. Email: hardie@qualcomm.com Andrew Newton SunRocket 8045 Leesburg Pike, Suite 300 Vienna, VA 22182 US Phone: +1 703 636 0852 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 Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Phone: +49 89 636 40390 Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).