Network Working Group T. Hardie Internet-Draft Qualcomm, Inc.Expires: December 18, 2006Intended status: Standards Track A. Newton Expires: March 8, 2007 SunRocket H. Schulzrinne Columbia U. H. Tschofenig SiemensJune 16,September 4, 2006 LoST: A Location-to-Service Translation Protocoldraft-ietf-ecrit-lost-00.txtdraft-ietf-ecrit-lost-01.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 onDecember 18, 2006.March 8, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .34 2. Requirements Notation . . . . . . . . . . . . . . . . . . . .56 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 4.Server Discovery . . . . . . . . .Resolving Service URNs Using LoST . . . . . . . . . . . . . .78 5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 5.1. Location Information Element . . . . . . . . . . . . . . .89 5.2. ServiceIdentifierElement . . . . . . . . . . . . . . . .8. . . . . 9 5.3. Validate Attribute . . . . . . . . . . . . . . . . . . . .89 5.4. Query Message Examples . . . . . . . . . . . . . . . . . .89 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . .1011 6.1. Uniform Resource Identifiers (URI) Element . . . . . . . .1011 6.2. Display Name ElementElement. . . . . . . . . . . . . . .10 6.3. Region Element. . . . 11 6.3. Service Element . . . . . . . . . . . . . . . . . .10 6.4. Dialstring Element. . . 11 6.4. ServiceBoundary Element . . . . . . . . . . . . . . . . .1012 6.5.TimeToLive Attribute .ServiceNumber Element . . . . . . . . . . . . . . . . . .1012 6.6.Validated Element .TimeToLive Attribute . . . . . . . . . . . . . . . . . . .1012 6.7.text Attribute . .Validation Element . . . . . . . . . . . . . . . . . . . .1112 6.8. Response Message Examples . . . . . . . . . . . . . . . .1112 7.Miscellaneous Functionality . .List Services Query and Response . . . . . . . . . . . . . . .1315 7.1. List Service Query . . . . . . . . . . . . . . . . . . . .1315 7.2.Response to aList ServiceQueryResponse . . . . . . . . . . . . . . . .13. . 15 8.ExampleStatus Code Definitions . . . . . . . . . . . . . . . . . . . 17 8.1. Informational 1xx . . . . . . . . . . . . . . . . . .15 9. Deployment Methods. . 17 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 1710. XML Schema8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2.2. 201 Service Substitution . .19 11. Internationalization Considerations. . . . . . . . . . . . .24 12. IANA Considerations17 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . .25 13. Security Considerations17 8.3.1. 301 Move Permanently . . . . . . . . . . . . . . . . . 17 8.3.2. 302 Moved Temporarily . .26 14. Open Issues. . . . . . . . . . . . . . 18 8.3.3. Example . . . . . . . . . . .27 15. References. . . . . . . . . . . . 18 8.4. Client Error 4xx . . . . . . . . . . . . . .28 15.1. Normative References. . . . . . . 18 8.4.1. 400 Bad Request . . . . . . . . . . . .28 15.2. Informative References. . . . . . . 18 8.4.2. 403 Forbidden . . . . . . . . . . .28 Authors' Addresses. . . . . . . . . 18 8.4.3. 404 Not Found . . . . . . . . . . . . . . .30 Intellectual Property and Copyright Statements. . . . . 18 8.4.4. 414 Location Error . . . . .31 1. Introduction This document describes a protocol for mapping a service identifier[6] and location information compatible with PIDF-LO [10] to one or more service contact URIs.. . . . . . . . . . . . . 18 8.4.5. Examplecontact URI schemes include sip, xmpp, and tel. While the initial focus is on providing mapping functions for emergency services, it is likely that the protocol is applicable to any service URN. For example, in the United States, the "2-1-1" and "3-1-1" services follow a similar location-to-service behavior as emergency services. This document names this protocol usage "LoST" for. . . . . . . . . . . . . . . . . . . . . . . 18 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 20 8.5.1. 500 Server Internal Error . . . . . . . . . . . . . . 20 8.5.2. 501 Service Not Implemented . . . . . . . . . . . . . 20 8.5.3. 504 Server Time-Out . . . . . . . . . . . . . . . . . 21 8.5.4. Example . . . . . . . . . . . . . . . . . . . . . . . 21 9. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 22 10. LoST Uniform Resource Locators . . . . . . . . . . . . . . . . 23 11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. Deployment Methods . . . . . . . . . . . . . . . . . . . . . . 26 13. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 28 14. Internationalization Considerations . . . . . . . . . . . . . 33 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 15.1. Content-type registration for 'application/lost+xml' . . . 34 15.2. LoST Relax NG Schema Registration . . . . . . . . . . . . 35 15.3. LoST Namespace Registration . . . . . . . . . . . . . . . 36 15.4. Registration Template . . . . . . . . . . . . . . . . . . 36 16. Security Considerations . . . . . . . . . . . . . . . . . . . 38 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 40 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 19.1. Normative References . . . . . . . . . . . . . . . . . . . 41 19.2. Informative References . . . . . . . . . . . . . . . . . . 42 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . . . . . 52 1. Introduction This document describes a protocol for mapping a service identifier [6] and location information compatible with PIDF-LO [11] to one or more service contact URIs. Example contact URI schemes include sip, xmpp, and tel. While the initial focus is on providing mapping functions for emergency services, it is likely that the protocol is applicable to any service URN. For example, in the United States, the "2-1-1" and "3-1-1" services follow a similar location-to-service behavior as emergency services. This document names this protocol usage "LoST" for Location-to- ServiceTranslation Protocol.Translation Protocol. The features of LoST are: o Supports queries using civic as well as geospatial location information. o Support for recursive and iterative resolution. o Support for address validation. o A hierarchical deployment of mapping servers is independent of civic location labels. o Indication of errors in the location data to facilitate debugging and proper user feedback while simultaneously providing best- effort answers. o Mapping can be based on either civic or geospatial location information, with uniform protocol treatment of both. o Support for overlapping service regions. o Satisfies the requirements [5] for mapping protocols. o Minimizes round trips by caching individual mappings and by supporting return of coverage regions ("hinting"). o Facilitates reuse of Transport Layer Security (TLS). This document focuses on the description of the protocol between the mapping client (seeker or resolver) and the mapping server (resolver or other servers). The relationship between other functions, such as discovery of mapping servers, data replication and the overall mapping server architecture in general, will be described in a separate document. [20] is a first attempt to describe such a mapping server architecture. The high-level protocol operation can be described as follows: Location Info +----------+ --------> | | Service | LoST | URN | Server | --------> | | +----------+ Query URI +----------+ <------- | | Optional | LoST | Info (hints)| Server | <------- | | +----------+ Response Figure 1: Overview The query message carries location information and a service identifier encoded as a Uniform Resource Name (URN) (see [6]) from the LoST client to the LoST server. The LoST server uses its database to map the input values to a Uniform Resource Identifiers (URI) and returns it including optional information such as hints about the service boundary in a response message back to the LoST client. 2. Requirements Notation Thefeatureskey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3]. 3. Usage The client queries a server, indicating the desired service and location information. If the query succeeds, the server returns a result that includes one or more URIs for reaching the appropriate service for the location indicated. Depending on the query, the result may contain a service boundary where the same mapping would apply, a reference to another server to which the client should send a query, or an error messages indicating problems. The combination ofLoSTthese components are left to the needs and policy of the jurisdiction where the server is being operated. The client may perform the mapping at any time. Among the common triggers for mapping are:o Supports queries using civic as well as geospatial1. When the client starts up and/or attaches to a new network location. 2. When the client detects that its location has changed sufficiently that it is outside the bounds of the region returned in an earlier query. 3. When cached mapping information has expired. 4. When calling for a particular service. During such calls, a client may want to request a short response that contains only the mapping data, omitting service boundary information. Cached answers are expected to be used by clients only after failing to accomplish a location-to-URI mapping at call time. Cache entries may expire according to their time-to-live value, or they may become invalid if the locationinformation. o Canof the caller's device moves outside the boundary limits of the cache entry. Boundaries for cache entries may beusedset in bothrecursivegeospatial anditerative resolution. o Can be used forcivicaddress validation. oterms. 4. Resolving Service URNs Using LoST If a LoST URL contains a host name rather than an IP address, clients need to perform an U-NAPTR [17] lookup to obtain a DNS Ahierarchical deploymentrecord and IP address. These records map the 'host' part ofmapping serversthe LoST URL to one or more URLs indicating the protocol to carry the LoST request. In this document, only the HTTP and HTTPS URL schemes are defined. Note that the HTTP URL can be any valid HTTP URL, including those containing path elements. Here isindependent ofan 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 provides the ability to use civic or geospatial locationlabels. o Can indicate errorsinformation in the query message. In addition to locationdatainformation the query also contains a service identifier. An optional parameter might furthermore request the LoST server tofacilitate debuggingvalidate location information. 5.1. Location Information Element LoST supports a query using geospatial andproper user feedback while simultaneously providing best- effort answers. o Mapping can be based on eithercivicor geospatiallocationinformation,information using the <findServiceByLocation> query. Geospatial location information uses GML format [10] and civic location information utilizes the format defined in [16]. This document does not define location formats. 5.2. Service Element The type of service desired is specified by the <service> element. The (emergency) service identifiers listed in the registry established withno performance penalty[6] will be used in this document. The <service> element is a mandatory element. In case the database at the LoST server does not provided service foreither.the specific geographical region the LoST server has various choices with regard to the response: oService regionsIt canoverlap. o Satisfies the requirements [5] for mapping protocols.send an error response. oMinimizes round trips by caching individual mappingsIt can map one service to another one, if appropriate, andby supportingreturnof coverage regions ("hinting").a different service identifier as described in Section 6.3. oFacilitates reuse of TLS. This document focuses onIt can populate thedescriptionURIs ofthe protocol between the mapping client (seeker or resolver) and the mapping server (resolver or other servers).one service to another service. Therelationship between other functions, such as discoveryoperation ofmapping servers, data replication andtheoverall mappingLoST serverarchitecture in general, will be described in a separate document. [12]is largely afirst attempt to describe suchpolicy issue. No behavior is mandated in this document. Guidelines for operating amappingLoST serverarchitecture.for emergency services is provided in [21]. 5.3. Validate Attribute Thehigh-level protocol operation can be'validate' attribute implements the validation behavior describedas follows: Location Info +----------+ --------> | | Service | LoST | URN | Server | --------> | | +----------+in [5]. 5.4. QueryURI +----------+ <------- | | Optional | LoST | Info (hints)| Server | <------- | | +----------+ ResponseMessage Examples This section shows an example of a query message providing geospatial and civic 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 The example above shows a query using geospatial location information with no validation required and asking for the 'urn:service:sos.police' service. <?xml version="1.0" encoding="UTF-8"?> <findServiceByLocation xmlns="urn:ietf:params:xml:ns:lost1" validate="false" operation="recursive"> <locationInfo> <civicLocation> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <A6>Neu Perlach</A6> <HNO>96</HNO> <PC>81675</PC> </civicLocation> </locationInfo> <service>urn:service:sos.police</service> </findServiceByLocation> Figure1: Overview4: Query Message Example using Civic Location Information The example above shows a querymessage carriesusing a civic locationinformationin Munich asking for the 'urn:service:sos.police' service. The query indicates that validation is not desired anda service identifier enconded as a Uniform Resource Name (URN) (see [6]) fromtheLoST clientquery has to be executed recursively. 6. Response A response message might either contain civic or geospatial location information depending on theLoST server. The LoST server uses its database to maptype of theinput values toquery. If the findServiceByLocation query message contained civic location information then the <serviceBoundary> element of the response message will also contain civic information. If the findServiceByLocation query message contained geospatial location information then the <serviceBoundary> element of the response message will contain a GML polygon. More information about the <serviceBoundary> element can be found at Section 6.4. 6.1. Uniform Resource Identifiers (URI)and returns it including optional information such as hints aboutElement Each <uri> element contains an appropriate contact URI for the serviceboundary infor which mapping was requested. <uri> elements are of type xs:anyURI. In the emergency service context operators are strongly discouraged from using relative URIs, even though these are permitted by the type. 6.2. Display Name Element Each <displayName> element contains aresponse message back tostring that is suitable for display. <displayName> elements are of type "text" that is suitable for internationalized human-readable text. 6.3. Service Element The <service> element is an optional element in theLoST client. 2. Requirements Notationresponse message. Thekey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"(emergency) service identifiers listed inthis document are tothe registry established with [6] will beinterpreted as describedused in[3]. 3. Usage The client queries a server, indicatingthis document. If thedesiredserviceandthat was requested by the LoST client is not available for a particular locationobject.then the server MAY return an alternate service. If it does so, it MUST indicate thequery succeeds,actual service returned (i.e., its service URN). Alternatively, the LoST serverreturns a resultMAY return an error response indicating thatincludes one or more URIs for reachingtheappropriaterequested servicefor the location indicated. Depending on the query,is not available. The following example illustrates theresult may containmain idea. If there is a regionwherethat only understands thesame mapping would apply,'urn:service:sos' service and not 'urn:service:sos.fire', 'urn:service:sos.ambulance', and 'urn:service:sos.police'. If areference to anotherLoST client asks for the 'urn:service:sos.fire' service then the LoST serverto whichcould, depending on theclient should send a query, and error messages indicating problemslocal policy at the LoST server, return: 1. 'urn:service:sos', or 2. 'urn:service:sos.fire' withinterpretation of location information. The combinationthe values ofthese components are left'urn:service:sos' being populated to 'urn:service:sos.fire', or 3. an error message In case of (1) theneeds and policy<service> element carries the value of 'urn:service:sos'. 6.4. ServiceBoundary Element Each <serviceBoundary> element contains either one or more civic location elements derived from thejurisdictionGeoPriv civic address schema or a GML-based polygon. The <serviceBoundary> element indicates where theserver is being operated. The client may performsame query would yield to themapping at any time. Amongsame response, i.e., it provides information about thecommon triggers for mapping are: 1. Whenservice boundary. 6.5. ServiceNumber Element TBD: This element contains theclient starts up and/or attaches to(emergency) service number, which is anew network location. 2. Whenstring of digits used to reach theclient detects that its location has changed sufficiently that it(emergency) service. 6.6. TimeToLive Attribute Each timeToLive attribute isoutsidea positive integer, expressing theboundsvalidity period of theregion returnedresponse inan earlier query. 3. When cached mapping information has expired. 4. When calling for a particular service. During such calls, aseconds. The LoST clientMAY request a short response that contains onlyMUST NOT consider themapping data, omitting region information. In some operational environmentsreturned location current after the expiration of the validity period. 6.7. Validation Element The <validation> element contains aUDP-based transport may be available and MAY be used to confirm or update data already available. Cached answers are expected to be usedstring that is composed of concatenated tokens separated byclients only after failing to accomplishalocation-to-URI mapping at call time. Cache entries may expire accordingwhitespace. These tokens refer totheir time-to-live value, or they may become invalid ifthe civic location labels used in child elements of thecaller's device moves outside<civicAddress> element from theboundary limits ofrequest that have been recognized as valid by thecache entry. Boundaries for cache entries may be set in bothserver. The following code snippet indicates that the civic address labels 'country', 'A1', 'A3', 'A6, 'PC' have been valided by the LoST server. <validation>country A1 A3 A6 PC</validation> 6.8. Response Message Examples This section shows an example of a query message providing geospatial andcivic terms. 4. Server Discovery There are likely to becivic 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 for the previously queried service URN. Information about the service boundary is provided by a GML polygon. The <serviceNumber> element indicates the valid service number for the expressed location and service 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 avariety of waysresponse thatclients can discover appropriate LoST servers, including DHCP,returns two URIs (one for SIPdevice configuration, or DNS recordsand another one fortheir signaling protocol domain, e.g.,XMPP), a distring that indicates theAOR domainvalid distring forSIP. The appropriate server depends on, among other considerations, who operates LoST services, including the Internet Service Provider (ISP), Voice Service Provider (VSP), or the user's home domain. A DNS based approach utilizing the S-NAPTR mechanism is specified in [6]. 5. Query LoST providestheability to use civic or geospatiallocationinformationprovided in thequery message message. In addition to location information the query also containsquery, a hint about the serviceidentifier. An optional parameter might furthermore requestboundary in theLoST server to validate location information. 5.1. Location Information Element LoST supports a query using geospatial<serviceBoundary> element andcivic locationinformationusingabout thefindLoSTByCivic andvalidated civic address fields. The timeToLive attribute indicates that thefindLoSTByGeo query. Geospatial locationreturned informationuses GML format [9]can be cached for 10000 seconds andcivic locationprovides a *<displayName> element with additional, textual informationutilizesabout theformat defined in [10]. Hence,returned information. 7. List Services Query and Response 7.1. List Service Query This subsection describes a mechanism that offers thelocation format is not defined in this document but references alreadyLoST client to query for availablestandards. 5.2. Service Identifier Element The type ofservicedesired is specified by the <service> element. The emergencyidentifierslisted in the registry established with [6] will be used in this document. 5.3. Validate Attributesupported by the LoST server. The'validate' attribute implementslistServices query MUST carry thevalidation behavior described<locationInfo> and the <service> element. The LoST server MUST return only immediate child elements of the service identifier specified in[5]. 5.4. Query Message Examples This section shows an examplethe <service> element ofathe listServices querymessage providing geospatial and civicavailable for the provided location information. <?xmlversion="1.0"?> <findLoSTByGeo validate="false" xmlns:p2="http://www.opengis.net/gml"version="1.0" encoding="UTF-8"?> <listServices xmlns="urn:ietf:params:xml:ns:lost1"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <p2:location>xmlns:p2="http://www.opengis.net/gml" operation="false"> <locationInfo> <p2:Pointp2:id="point1"id="point1" srsName="epsg:4326"> <p2:coordinates>37:46:30N 122:25:10W</p2:coordinates> </p2:Point></p2:location></locationInfo> <service>urn:service:sos</service></findLoSTByGeo></listServices> Figure2: Query Message8: Exampleusing Geospatial Location Information The example above showsfor a List Service Query This listService queryusing geospatialaims to query the immediate child elements of the 'urn:service:sos' URN. 7.2. List Service Response This subsection describes the response message that provides the LoST client with the list of immediate child service identifiers based on the service identifier provided by LoST client with respect to the location informationwith no validation required and asking forprovided in the'urn:service:sos' service. <?xml version="1.0"?> <findLoSTByCivic validate="true" xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <civicLocation> <p2:country>Germany</p2:country> <p2:A1>Bavaria</p2:A1> <p2:A3>Munich</p2:A3> <p2:A6>Neu Perlach</p2:A6> <p2:HNO>96</p2:HNO> <p2:PC>81675</p2:PC> </civicLocation> <service>urn:service:sos.police</service> </findLoSTByCivic> Figure 3: Query Message Example using Civic Location InformationlistService query. The following exampleaboveshowsa query using a civic location in Munich asking forthe'urn:service:sos' service. The query also indicates that validation is desired. 6. Response Aresponsemessage might either be a responseGeo or a responseCivic depending onto thetype oflistServices querymessage. Ifexample of Figure 8 listing thequery message was a findLoSTByCivic thenavailable services offered by the LoST server starting with 'urn:service:sos.ambulance' and finishing with 'urn:service:sos.suicide'. <?xml version="1.0" encoding="UTF-8"?> <response xmlns="urn:ietf:params:xml:ns:lost1"> <serviceList status="200" message="OK" 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> Figure 9: Example for the Response to a List Service Query 8. Status Code Definitions Each responsewill becontains aresponseCivic. If<status> element that conveys afindLoSTByGeo message was sent asnumeric status code and aquery thenreason phrase indicating theresponse will be a findLoSTByGeo. The location information that is provided bysuccess or failure of the response. The appearance of other elements in the responsemessagedepends on thequery and refers to the service boundary as described in Section 6.3. 6.1. Uniform Resource Identifiers (URI) Element Each uri element contains an appropriate contact URI for the service for which mapping was requested. uristatus code. Hence, different elements are used for groups oftype xs:anyURI. Instatus codes. Status codes always have three digits; theemergency service context operators are strongly discouraged from using relative URIs, even though these are permittedlist of status codes is meant to be extensible by IANA registration and follows thetype. 6.2. Display Name Element Element Each displayName element contains a string that is suitable for display. displayName elements aregeneral pattern oftype "text" as described in Section 6.7. 6.3. Region Element Each region element contains either one or more civic location elements derived fromtheGeoPriv civic address schema or feature.xsd expression from GML. 6.4. Dialstring Element Each dialstring element contains from oneSession Initiation Protocol (SIP) [22] and HTTP [14]. The first digit indicates the type of response, with '2' signaling a successful request, '3' a redirection, '4' a request failure due tosixteen digits. Note thatclient behavior, and '5' aTel URI mayserver failure. If used within HTTP, LoST alsocontainutilizes thesame target, expressed in a different format; see RFC 3966 [11]. 6.5. TimeToLive Attribute Each timeToLive attribute is a positive integer, expressingnormal HTTP status codes. However, thevalidity periodHTTP request can succeed, while the LoST request caused an error. All LoST status codes appear in HTTP 200 (OK) responses. For example, a LoST 404, 414 or 500 status would occur in an HTTP 200 response. Temporary unavailability of theresponseservice should 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 inseconds. 6.6. Validated Element Each validated element containsastring whichnon-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 iscomposed by by concatenatingnot available for theelements fromlocation requested, but therequest which have been recognized as validserver is configured to provide a replacement service. 8.3. Redirection 3xx 8.3.1. 301 Move Permanently The requested location is being mapped by a different server and all future requests for that location (and locations in the service area) should be directed to that server.6.7. text Attribute This8.3.2. 302 Moved Temporarily The requested location is being mapped by atext type suitable for internationalized human readable text. 6.8. Response Message Examplesdifferent server, but future requests should continue to use this server. 8.3.3. Example Thissection showsis an example ofa queryan error messageproviding geospatial and civic location information.with a 302 status code: <?xml version="1.0" encoding="UTF-8"?><responseGeo timeToLive="10000" xmlns="urn:ietf:params:xml:ns:lost1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p2="http://www.opengis.net/gml"> <displayName>New York City Police Department</displayName> <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> <uri>sip:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri> <dialstring>911</dialstring> </responseGeo> Figure 4: Response Message Example using Geospatial Location Service Boundary Hints This example shows a reponse with two URIs for the previously queried service URN. Information about<response 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 The request could not be understood due to malformed syntax. 8.4.2. 403 Forbidden The server understood theservice boundaryrequest, but isprovided inrefusing to fulfill it. Authorization will not help, and thePolyon.request SHOULD NOT be repeated. 8.4.3. 404 Not Found The<dialstring> element indicates the valid dialstringserver has definitive information that there is no service mapping for theexpressedlocationand service URN. <?xml version="1.0" encoding="UTF-8"?> <responseCivic timeToLive="10000" xmlns="urn:ietf:params:xml:ns:lost1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"> <displayName>Munich Police Department</displayName> <region> <p2:country>Germany</p2:country> <p2:A1>Bavaria</p2:A1> <p2:A3>Munich</p2:A3> </region> <validated>country A1 A3 A6 PC</validated> <uri>sip:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri> <dialstring>110</dialstring> </responseCivic> Figure 5: Response Message Example providing Civicspecified. 8.4.4. 414 LocationService Boundary Hints ThisError The location provided does not exist or fields within the location information are contradictory. 8.4.5. Example The first example shows an error message with aresponse that returns two URIs (one for SIP and another one for XMPP), a distring414 status code thatindicates the valid distring for the location provided inis attached to thequery,response message indicating that there was ahint aboutproblem 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 outside of serviceboundary in the <region> element and information about the validated civic address fields.boundary" xml:lang="en" /> </failure> </response> ThetimeToLive indicatessecond example shows an error message with a 414 status code that is attached to thereturned information can be cached for 10000 seconds and providesresponse message indicating that there was adisplayNameproblem withadditional, textual information aboutthereturned information. 7. Miscellaneous Functionality 7.1. List Service Query This subsection describes a queryprovided geospatial 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="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 Error The server encountered an unexpected condition thatoffersprevented it from fulfilling theLoSTrequest. The clientto queryMAY retry the request after several seconds. 8.5.2. 501 Service Not Implemented The server does not implement mapping foravailablethe serviceidentifiers supported byrequested and cannot provide an alternate service. 8.5.3. 504 Server Time-Out A server time-out occurs if theLoST server.server contacted tries to recursively resolve the query, but cannot get an answer within the time limit set for the query. 8.5.4. Example This is an example of an error message with a 500 status code: <?xml version="1.0" encoding="UTF-8"?><listServices xmlns="urn:ietf:params:xml:ns:lost1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <service>urn:service:sos</service> </listServices> Figure 6: Example for a List Service Query This listService query aims<response xmlns="urn:ietf:params:xml:ns:lost1"> <status code="500">Server failure</status> </response> 9. LoST Transport LoST needs an underlying protocol transport mechanisms toquerycarry requests and responses. This document defines theimmediate child elementsuse ofthe 'urn:service:sos' URN. 7.2. ResponseLoST over HTTP and HTTP-over-TLS; other mechanisms are left toa List Service Query This subsection describesfuture documents. The available transport mechanisms are indicated in theresponse messageLoST U-NAPTR DNS resource record. In protocols thatprovidessupport content type indication, LoST uses the media type application/lost+xml. When using HTTP [14] and HTTP-over-TLS [15], LoSTclient withrequests use thelist of immediate child service identifiers based onHTTP POST method. All HTTP responses are applicable. The HTTP URL is derived from theservice identifier provided byLoSTclientURL via U-NAPTR translation, as discussed in Section 4. 10. LoST Uniform Resource Locators LoST Uniform Resource Locators (URLs) follow thequery. <?xml version="1.0" encoding="UTF-8"?> <returnServices timeToLive="10000" xmlns="urn:ietf:params:xml:ns:lost1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <service>urn:service:sos.ambulance</service> <service>urn:service:sos.animal-control</service> <service>urn:service:sos.fire</service> <service>urn:service:sos.gas</service> <service>urn:service:sos.mountain</service> <service>urn:service:sos.marine</service> <service>urn:service:sos.physician</service> <service>urn:service:sos.poison</service> <service>urn:service:sos.police</service> <service>urn:service:sos.suicide</service> </returnServices> Figure 7: Example for the Response to a List Service Query This response corresponds toformat of URLs defined in RFC 3986 [9], with thequeryfollowing ABNF: LoST-URI = "lost:" host 'host' is defined in Section 3.2.2 ofFigure 6. 8.RFC 3986 [9]. An example is 'lost:lostserver.example.com' 11. Example After performing link layer attachment and end host performs stateful address autoconfiguration (in our example) using DHCP. Then, DHCP provides the end host with civic location as describedin[7].in [19]. +--------+---------------+ | CAtype | CAvalue | +--------+---------------+ | 0 | US | | 1 | New York | | 3 | New York | | 6 | Broadway | | 22 | Suite 75 | | 24 | 10027-0401 | +--------+---------------+ Figure8:14: DHCP Civic Information Example Additionally, DHCP may provide information about the LoST server that can be contacted. Alternatively, an additional step of indirection is possible, for example by having DHCP return a domain name that has to be resolved to one or more IP addresses hosting LoST servers. Both at attachment time and call time, the client places a LoST request, including its civic location and the desired service. The request is shown below: <?xmlversion="1.0"?> <findLoSTByCivic validate="true"version="1.0" encoding="UTF-8"?> <findServiceByLocation xmlns="urn:ietf:params:xml:ns:lost1"xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">validate="false" operation="recursive"> <locationInfo> <civicLocation><p2:country>US</p2:country> <p2:A1>New York</p2:A1> <p2:A3>New York</p2:A3> <p2:A6>Broadway</p2:A6> <p2:LOC>Suite 75</p2:LOC> <p2:PC>10027-0401</p2:PC><country>US</country> <A1>New York</A1> <A3>New York</A3> <A6>Broadway</A6> <LOC>Suite 75</LOC> <PC>10027-0401</PC> </civicLocation> </locationInfo> <service>urn:service:sos.police</service></findLoSTByCivic></findServiceByLocation> Mapping Request Since the contacted LoST server has the requested information available the following response is returned. Theresponse<displayName> element indicates, as a human readable displaystringstring, that the 'New York City Police Department' is responsible for the given geographical area. The indicated URI allows the user to start communication using SIP or XMPP. The'validated'<validation> element indicates which parts of the civic address were matched successfully against a database and represent a known address. Other parts of the address, here, the suite number, were ignored and not validated. Thereturned service boundary<serviceBoundary> element indicates that all of New York City would result in the same response. Thedialstring<serviceNumber> element indicates that the service can be reached via thedial string 9-1-1.emergency service number 911. <?xml version="1.0" encoding="UTF-8"?><responseCivic timeToLive="10000" xmlns="urn:ietf:params:xml:ns:lost1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"> <displayName>New<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 PoliceDepartment</displayName> <region> <p2:country>US</p2:country> <p2:A1>New York</p2:A1> <p2:A3>New York</p2:A3> </region> <validated>country A1 A3 A6 PC</validated>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><dialstring>911</dialstring> </responseCivic> 9.<service-number>911</service-number> </result> </response> Mapping Response 12. Deployment Methods Because services for emergency contact resolution may differ depending on local or service needs, this document only specifies the "wire format" for LoST services and explicitly leaves open the possibility for many different types of deployment. For instance: During discovery, a client may be directed to issue all queries to an LoST service completely authoritative for a givenjursidiction.jurisdiction. A client may be directed to issue queries to an LoST server that acts as a reflector. In such a case, the LoST server analyzes the query to determine the best server towichwhich to refer the client. Or the client may be directed to a server that performs further resolution on behalf of the client. A LoST service may also be represented by multiple LoST servers, either grouped together or at multiple network locations. Using S-NAPTR[13],[24], clients may be given a list of multiple servers to which queries can be sent for a single service. For instance, the service at emergency.example.com may advertise LoST service at local1.emergency.example.com, local2.emergency.example.com, and master.emergency.example.com. Each server may given a different preference. In this case, 'local-1' and 'local-2' may be given a lower preference (more preferred) than 'master', which might be a busier server or located further away. +-----------+ pref 10 +-----------+ | |-------------------->+ | | client |------ | local-1 | | |--- \ | | +-----------+ \ \ +-----------+ \ \ \ \ +-----------+ \ \ pref 10 | | \ --------->| local-2 | \ | | \ +-----------+ \ \ +-----------+ \ pref 20 | | ------------------------->| master | | | +-----------+10. XML13. Relax NG Schema This section provides theXMLRelax NG schema used byLoST. <?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:ietf:params:xml:ns:lost1" xmlns:lost="urn:ietf:params:xml:ns:lost1" xmlns:civilLoc="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" xmlns:gml="http://www.opengis.net/gml" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" elementFormDefault="qualified" attributeFormDefault="unqualified"> <annotation> <documentation> A schema forLoST protocol in the compact form. The verbose form is included in Appendix A. default namespace = "urn:ietf:params:xml:ns:lost1" namespace aLocation to Service= "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" ## ## Location-to-Service Translation Protocol</documentation> </annotation> <!-- --> <!-- Query types --> <!-- --> <!-- Abstract Query --> <complexType name="queryType"/> <element name="query" type="lost:queryType" abstract="true"/> <!-- findLoSTByCivic --> <element name="findLoSTByCivic" type="lost:findLoSTByCivicType" substitutionGroup="lost:query"/> <complexType name="findLoSTByCivicType"> <complexContent> <extension base="lost:queryType"> <sequence> <element name="civilAddress" type="civilLoc:civilAddress" minOccurs="0" maxOccurs="1"/> <element name="service" type="anyURI" minOccurs="1" maxOccurs="1"/> </sequence> <attribute name="validate" type="boolean" default="false"/> </extension> </complexContent> </complexType> <!-- findLoSTByGeo --> <element name="findLoSTByGeo" type="lost:findLoSTByGeoType" substitutionGroup="lost:query"/> <complexType name="findLoSTByGeoType"> <complexContent> <extension base="lost:queryType"> <sequence> <element ref="gml:location" minOccurs="0" maxOccurs="1"/> <element name="service" type="anyURI" minOccurs="1" maxOccurs="1"/> </sequence> <attribute name="validate" type="boolean" default="false"/> </extension> </complexContent> </complexType> <!--(LoST) ## ## A LoST XML instance has three "root" types: ## the findServiceByLocation query, the listServices--> <element name="listServices" type="lost:listServicesType" substitutionGroup="lost:query"/> <complexType name="listServicesType"> <complexContent> <extension base="lost:queryType"> <sequence> <element name="service" type="anyURI" minOccurs="1" maxOccurs="1"/> </sequence> </extension> </complexContent> </complexType> <!-- --> <!-- Responses --> <!-- --> <!-- Abstract Response --> <element name="result" type="lost:resultType" abstract="true"/> <complexType name="resultType"> <attribute name="timeToLive" type="positiveInteger" use="required" /> </complexType> <!-- emergencyContact Response --> <element name="responseCivic" type="lost:responseCivicType" substitutionGroup="lost:result"/> <complexType name="responseCivicType"> <complexContent> <extension base="lost:resultType"> <sequence> <element name="displayName" type="normalizedString" minOccurs="0" maxOccurs="1"/> <element name="civilAddress" type="civilLoc:civilAddress" minOccurs="0" maxOccurs="1" /> <element name="uri" type="anyURI" minOccurs="0" maxOccurs="unbounded" /> <element name="dialstring" type="normalizedString" minOccurs="0" maxOccurs="1" /> </sequence> </extension> </complexContent> </complexType> <element name="responseGeo" type="lost:responseGeoType" substitutionGroup="lost:result"/> <complexType name="responseGeoType"> <complexContent> <extension base="lost:resultType"> <sequence> <element name="displayName" type="normalizedString" minOccurs="0" maxOccurs="1"/> <element ref="gml:Polygon" minOccurs="0" maxOccurs="1"/> <element name="uri" type="anyURI" minOccurs="0" maxOccurs="unbounded"/> <element name="dialstring" type="normalizedString" minOccurs="0" maxOccurs="1" /> </sequence> </extension> </complexContent> </complexType> <element name="returnServices" type="lost:returnServicesType" substitutionGroup="lost:result"/> <complexType name="returnServicesType"> <complexContent> <extension base="lost:resultType"> <sequence> <element name="service" type="anyURI" minOccurs="1" maxOccurs="unbounded"/> </sequence> </extension> </complexContent> </complexType> <!-- --> <!-- Error responses --> <!-- --> <element name="genericCode" type="lost:codeType" abstract="true"/> <element name="invalidCivicData" type="lost:codeType" substitutionGroup="lost:genericCode"/> <element name="invalidGeoData" type="lost:codeType" substitutionGroup="lost:genericCode"/> <element name="invalidService" type="lost:codeType" substitutionGroup="lost:genericCode"/> <complexType name="codeType"> <sequence minOccurs="0" maxOccurs="unbounded"> <element name="explanation"> <complexType> <simpleContent> <extension base="string"> <attribute name="language" type="language" use="required"/> </extension> </simpleContent> </complexType> </element> </sequence> </complexType> </schema> 11.query, ## and the response to these queries. ## start = findServiceByLocation | listServices | response ## ## The queries. ## div { findServiceByLocation = element findServiceByLocation { query, attribute validate { xsd:boolean >> a:defaultValue [ "false" ] }? } listServices = element listServices { query } } ## ## The response. ## div { response = element response { ## ## 2xx responses. ## (result | element serviceList { list { xsd:anyURI* }, status })?, ## ## 3xx, 4xx, and 4xx responses. ## ((error | redirect | failure)?), extensionPoint } } ## ## Query pattern. ## div { query = element locationInfo { anyElement* }, element service { xsd:anyURI }, extensionPoint, [ a:defaultValue [ "recursive" ] ] attribute operation { text }? } ## ## A result. ## div { ## ## 2xx response. ## result = element result { element displayName { xsd:string, attribute xml:lang { xsd:language } }?, element service { xsd:anyURI }, element serviceBoundary { (civicLocation, polygon?) | (civicLocation?, polygon) }?, element uri { xsd:anyURI }+, element serviceNumber { xsd:string { pattern = "[0-9]+" } }?, element validation { list { xsd:QName* } }?, extensionPoint, attribute timeToLive { xsd:positiveInteger }, status } } ## ## Non-result responses. ## div { ## ## 5xx response. ## error = element error { status, extensionPoint } ## ## 3xx response. ## redirect = element redirect { status, attribute redirect { xsd:anyURI }, extensionPoint } ## ## 4xx response. ## failure = element failure { status, element cause { attribute name { xsd:QName }, attribute message { xsd:string }, attribute xml:lang { xsd:language } }*, extensionPoint } } ## ## Status pattern. ## div { status = 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 { ## ## A wildcard pattern for including any element ## from any other namespace. ## anyElement = element * { (attribute * { text } | text | anyElement)* } ## ## A point where future extensions ## (elements from other namesapces) ## can be added. ## extensionPoint = anyElement* ## ## A pattern to include the GEOPRIV civil location elements. ## civicAddress = element ns1:* { (attribute * { text } | text | anyElement)* } ## ## A definition of civic location from GEOPRIV. ## civicLocation = element civicLocation { civicAddress*, anyElement* } ## ## A pattern to include GML elements. ## GML = element ns2:* { (attribute * { text } | text | anyElement)* } polygon = element ns2:Polygon { attribute * { text }*, GML } } 14. 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 thedisplayName<displayName> element may be displayed to the end user, and it is thus a complex type designed for this purpose.12.15. IANA ConsiderationsTBD, such as namespace registrations.15.1. Content-type registration for 'application/lost+xml' This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [13] and guidelines in RFC 3023 [12]. MIME media type name: application MIME subtype name: lost+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [12], Section 3.2. 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. LoST Relax NG Schema Registration URI: urn:ietf:params:xml:ns:lost Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@siemens.com). Relax NG Schema: The Relax NG schema to be registered is contained in Section 13. Its first line is default namespace = "urn:ietf:params:xml:ns:lost1" and its last line is } 15.3. LoST Namespace Registration URI: urn:ietf:params:xml:ns:lost Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@siemens.com). XML: BEGIN <?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> END 15.4. Registration Template This registration template is in accordance with [8]. URL scheme name: lost URL scheme syntax: See Section 10 Character encoding considerations: See Section 10 Intended Use: The intended usage is described in this document. Application and protocols which use this scheme: The usage of the LoST URL scheme is targeted for this document and hence for location-based services that make use of the mapping protocol specified in this document. Interoperability considerations: None Security considerations: See Section 16 Relevant publications: This document provides the relevant context for this URL scheme. Contact: Hannes Tschofenig, Hannes.Tschofenig@siemens.com Author/Change controller: The IESG <iesg@ietf.org> 16. Security Considerations There are multiple threats to the overall system of which service mapping forms a part. An attacker that can obtain service contact URIs can use those URIs to attempt to disrupt those services. An attacker that can prevent the lookup of contact URIs can impair the reachability of such services. An attacker that can eavesdrop on the communication requesting this lookup can surmise the existence of an emergency and possibly its nature, and may be able to use this to launch a physical attack on the caller. To avoid that an attacker can modify the query or its result,LoST RECOMMENDSthe authors RECOMMEND the use of channel security, such asTLS.TLS, with LoST. A more detailed description of threats and security requirements are provided in [4]. 17. Acknowledgments [Editor's Note:A future version of this document will describe the countermeasures based on the security requirements outlined in[4].] 14.Names need to be added here. Forgot it...Sorry.] 18. Open Issues Please find open issues at: http://www.ietf-ecrit.org:8080/lost/15.19. References15.1.19.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",RFC 2119,BCP 14, RFC 2119, March 1997. [4] Taylor, T., "Security Threats and Requirements for Emergency Call Marking and Mapping",draft-ietf-ecrit-security-threats-01draft-ietf-ecrit-security-threats-03 (work in progress),AprilJuly 2006. [5] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies",draft-ietf-ecrit-requirements-10draft-ietf-ecrit-requirements-12 (work in progress),JuneAugust 2006. [6] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",draft-ietf-ecrit-service-urn-03draft-ietf-ecrit-service-urn-05 (work in progress),MayAugust 2006. [7]Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", draft-ietf-geopriv-dhcp-civil-09 (work in progress), January 2006. [8]Mealling, M., "The IETF XML Registry",draft-mealling-iana-xmlns-registry-03draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003. [8] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November2001.1999. [9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [10] OpenGIS, "Open Geography Markup Language (GML) Implementation Specification", OGC OGC 02-023r4, January 2003.[10][11] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.15.2.[12] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [13] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [14] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [16] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-02 (work in progress), April 2006. [17] Daigle, L., "Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", draft-daigle-unaptr-00 (work in progress), June 2006. 19.2. Informative References[11][18] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.[12][19] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", draft-ietf-geopriv-dhcp-civil-09 (work in progress), January 2006. [20] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework",draft-schulzrinne-ecrit-mapping-arch-00draft-ietf-ecrit-mapping-arch-00 (work in progress),October 2005. [13]August 2006. [21] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", draft-rosen-sos-phonebcp-01 (work in progress), June 2006. [22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [23] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in progress), August 2006. [24] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and theDynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.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 the response to these queries. </a:documentation> <choice> <ref name="findServiceByLocation" /> <ref name="listServices" /> <ref name="response" /> </choice> </start> <div> <a:documentation> The queries. </a:documentation> <define name="findServiceByLocation"> <element name="findServiceByLocation"> <ref name="query" /> <optional> <attribute name="validate"> <data type="boolean" /> <a:defaultValue>false</a:defaultValue> </attribute> </optional> </element> </define> <define name="listServices"> <element name="listServices"> <ref name="query" /> </element> </define> </div> <div> <a:documentation> The response. </a:documentation> <define name="response"> <element name="response"> <optional> <choice> <a:documentation> 2xx responses. </a:documentation> <ref name="result" /> <element name="serviceList"> <list> <zeroOrMore> <data type="anyURI" /> </zeroOrMore> </list> <ref name="status" /> </element> </choice> </optional> <optional> <a:documentation> 3xx, 4xx, and 4xx responses. </a:documentation> <choice> <ref name="error" /> <ref name="redirect" /> <ref name="failure" /> </choice> </optional> <ref name="extensionPoint" /> </element> </define> </div> <div> <a:documentation> Query pattern. </a:documentation> <define name="query"> <element name="locationInfo"> <zeroOrMore> <ref name="anyElement"/> </zeroOrMore> </element> <element name="service"> <data type="anyURI"/> </element> <ref name="extensionPoint" /> <optional> <attribute name="operation"> <a:defaultValue>recursive</a:defaultValue> </attribute> </optional> </define> </div> <div> <a:documentation> A result. </a:documentation> <define name="result"> <a:documentation> 2xx response. </a:documentation> <element name="result"> <optional> <element name="displayName"> <data type="string"/> <attribute name="xml:lang"> <data type="language" /> </attribute> </element> </optional> <element name="service"> <data type="anyURI"/> </element> <optional> <element name="serviceBoundary"> <choice> <group> <ref name="civicLocation" /> <optional> <ref name="polygon" /> </optional> </group> <group> <optional> <ref name="civicLocation" /> </optional> <ref name="polygon" /> </group> </choice> </element> </optional> <oneOrMore> <element name="uri"> <data type="anyURI"/> </element> </oneOrMore> <optional> <element name="serviceNumber"> <data type="string"> <param name="pattern">[0-9]+</param> </data> </element> </optional> <optional> <element name="validation"> <list> <zeroOrMore> <data type="QName"/> </zeroOrMore> </list> </element> </optional> <ref name="extensionPoint" /> <attribute name="timeToLive"> <data type="positiveInteger"/> </attribute> <ref name="status" /> </element> </define> </div> <div> <a:documentation> Non-result responses. </a:documentation> <define name="error"> <a:documentation> 5xx response. </a:documentation> <element name="error"> <ref name="status"/> <ref name="extensionPoint" /> </element> </define> <define name="redirect"> <a:documentation> 3xx response. </a:documentation> <element name="redirect"> <ref name="status"/> <attribute name="redirect"> <data type="anyURI"/> </attribute> <ref name="extensionPoint" /> </element> </define> <define name="failure"> <a:documentation> 4xx response. </a:documentation> <element name="failure"> <ref name="status"/> <zeroOrMore> <element name="cause"> <attribute name="name"> <data type="QName"/> </attribute> <attribute name="message"> <data type="string"/> </attribute> <attribute name="xml:lang"> <data type="language"/> </attribute> </element> </zeroOrMore> <ref name="extensionPoint" /> </element> </define> </div> <div> <a:documentation> Status pattern. </a:documentation> <define name="status"> <attribute name="status"> <data type="positiveInteger"/> </attribute> <optional> <attribute name="extendedStatus"> <data type="positiveInteger"/> </attribute> </optional> <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="anyElement"> <a:documentation> A wildcard pattern for including any element from any other namespace. </a:documentation> <element> <anyName/> <zeroOrMore> <choice> <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> <ref name="anyElement" /> </zeroOrMore> </define> <define name="civicAddress"> <a:documentation> A pattern to include the GEOPRIV civil location elements. </a:documentation> <element> <nsName ns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/> <zeroOrMore> <choice> <attribute> <anyName/> </attribute> <text/> <ref name="anyElement"/> </choice> </zeroOrMore> </element> </define> <define name="civicLocation"> <a:documentation> A definition of civic location from GEOPRIV. </a:documentation> <element name="civicLocation"> <zeroOrMore> <ref name="civicAddress"/> </zeroOrMore> <zeroOrMore> <ref name="anyElement" /> </zeroOrMore> </element> </define> <define name="GML"> <a:documentation> A pattern to include GML elements. </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> </zeroOrMore> <ref name="GML"/> </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 PropertyStatementThe 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.Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.Acknowledgment Funding for the RFC Editor function iscurrentlyprovided by theInternet Society.IETF Administrative Support Activity (IASA).