Internet Engineering Task Force (IETF) K. Wolf Request for Comments: 6197 nic.at Category: Experimental April 2011 ISSN: 2070-1721 Location-to-Service Translation (LoST) Service List Boundary Extension
AbstractLocation-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6197.
Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 1. Introduction ....................................................3 2. Terminology .....................................................4 3. LoST Extensions .................................................4 3.1. Extensions to <listServicesByLocation> .....................4 3.2. Retrieving the <serviceListBoundary> via <getServiceListBoundary> ...................................7 3.3. <serviceListBoundary> ......................................8 3.4. Implementation Considerations ..............................9 3.4.1. Server Side .........................................9 3.4.2. Client Side .........................................9 4. Security and Privacy Considerations ............................10 5. IANA Considerations ............................................10 5.1. Relax NG Schema Registration ..............................10 5.2. Namespace Registration ....................................13 6. Acknowledgements ...............................................14 7. References .....................................................14 7.1. Normative References ......................................14 7.2. Informative References ....................................15
RFC5222] employs the Service Boundary concept in order to avoid having clients continuously trying to refresh the mapping of a specific service, a Service List Boundary mechanism provides similar advantages for Service Lists. Location-based service providers, as well as Public Safety Answering Points (PSAPs), only serve a specific geographic region. Therefore, the LoST protocol defines the Service Boundary, which indicates the service region for a specific service URL. However, not all services are available everywhere. Clients can discover available services for a particular location via the <listServicesByLocation> query in LoST. The LoST server returns a list of services that are available at this particular location, but the server does not provide any additional information about the geographical region within which the returned Service List is considered valid. This may lead to the situation where a client initially discovers all available services via the <listServicesByLocation> query, and then moves to a different location (while refreshing the service mappings), but without noticing the availability of other services. The following imaginary example illustrates the problem for emergency calling: The client is powered-up, does location determination (resulting in location A), and performs an initial <listServicesByLocation> query with location A requesting urn:services:sos. The LoST server returns the following list of services: urn:service:sos.police urn:service:sos.ambulance urn:service:sos.fire The client does the initial LoST mapping and discovers the dialstrings for each service. Then the client moves, refreshing the individual service mappings when necessary as specified by the Service Boundary. However, when arriving in location B (close to a mountain), service sos.mountainrescue, which was not available in location A, becomes available. Since the client is only required to refresh the mappings for the initially discovered services, the new service is not detected. Consequently, the dialstring for the mountain-rescue service is not known by the client. Hence, the client is unable to recognize an emergency call when the user enters the dialstring of the mountain-rescue service, and the emergency call may fail altogether.
Note that the Service Boundary (service region for an individual service) cannot be considered as an indicator for the region for which a specific Service List is valid. The Service List may even change within the Service Boundary of another service. For example, the ambulance mapping is valid for a whole state, but for a part of the state there is an additional mountain-rescue service. Consequently, there are two ways to tackle this issue: o Clients continuously poll for the Service List, although it may not have changed. o The server sends a message containing boundary information that tells the client that the Service List does not change inside this area. RFC2119].
<?xml version="1.0" encoding="UTF-8"?> <listServicesByLocation xmlns="urn:ietf:params:xml:ns:lost1" xmlns:gml="http://www.opengis.net/gml" xmlns:slb="urn:ietf:params:xml:ns:lost1:slb" recursive="true"> <location id="5415203asdf548" profile="civic"> <civicAddress xml:lang="en" xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>AT</country> <A1>Lower Austria</A1> <A2>Bruck an der Leitha</A2> <A3>Wolfsthal</A3> <RD>Hauptplatz</RD> <HNO>1</HNO> <PC>2412</PC> </civicAddress> </location> <service>urn:service:sos</service> <slb:serviceListBoundaryRequest type="value"/> </listServicesByLocation> A <listServicesByLocationResponse> with the addition of one <serviceListBoundary> element is shown below: <?xml version="1.0" encoding="UTF-8"?> <listServicesByLocationResponse xmlns="urn:ietf:params:xml:ns:lost1" xmlns:slb="urn:ietf:params:xml:ns:lost1:slb"> <serviceList> urn:service:sos.ambulance urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.poison urn:service:sos.police </serviceList>
<path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> <locationUsed id="5415203asdf548"/> <slb:serviceListBoundary profile="civic" expires="2012-01-01T00:00:00Z"> <civicAddress xml:lang="en" xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>AT</country> <A1>Lower Austria</A1> </civicAddress> </slb:serviceListBoundary> </listServicesByLocationResponse> The response above indicates that the Service List is valid for Lower Austria. The <listServicesByLocation> request needs to be repeated by the client only when moving out of Lower Austria. However, the mappings of the services themselves may have other service boundaries. Additionally, the 'expires' attribute indicates the absolute time when this Service List becomes invalid. The response MAY contain multiple <serviceListBoundary> elements for alternative representation, each representing the boundary in a specific location profile. However, multiple locations inside a <serviceListBoundary> element are considered to be additive. The boundary can also be requested by reference when setting the value of the 'type' attribute of the <serviceListBoundaryRequest> element to "reference" (which is the default in case the attribute is omitted). The response will contain a <serviceListBoundaryReference> element with a 'serviceListKey' attribute (described in Section 3.2), as shown below. <?xml version="1.0" encoding="UTF-8"?> <listServicesByLocationResponse xmlns="urn:ietf:params:xml:ns:lost1" xmlns:slb="urn:ietf:params:xml:ns:lost1:slb"> <serviceList> urn:service:sos.ambulance urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.poison urn:service:sos.police </serviceList>
<path> <via source="resolver.example"/> <via source="authoritative.example"/> </path> <locationUsed id="5415203asdf548"/> <slb:serviceListBoundaryReference source="authoritative.example" serviceListKey="123567890123567890123567890" /> </listServicesByLocationResponse>
The 'serviceListKey' uniquely identifies a Service List Boundary, as the 'key' does for the Service Boundary (see Section 5.6 of RFC 5222). Therefore, the 'serviceListKey' is a random token with at least 128 bits of entropy [RFC4086] and can be assumed globally unique. Whenever the boundary changes, a new 'serviceListKey' MUST be assigned. Note: Since LoST does not define an attribute to indicate which location profile the client understands in a <getServiceBoundary> request, this document also does not define one for the <getServiceListBoundary> request.
RFC5582] states that each tree announces its coverage region (for one type of service, e.g., sos.police) to one or more forest guides. Forest guides peer with each other and synchronize their data. Hence, a forest guide has sufficient knowledge (it knows all the services and their coverage regions) to answer a <listServicesByLocation> query and to add the <serviceListBoundary> or <serviceListBoundaryReference> as well. The calculation of the largest possible area for which the Service List stays the same might be a complex task. An alternative would be to return smaller areas that are easier to compute. In such a case, some unnecessary queries to the LoST server will be a consequence, but the main purpose of the Service List Boundary is still achieved: to never miss a change of available services. Thus, the server operator may specify a reasonable trade-off between the effort to generate the boundary information and the saved queries to the LoST server. For example, in some countries the offered services may differ in adjacent counties (or districts, cantons, states, etc.). Their borders may be suitable as a Service List Boundary as well, even though some adjacent counties offer the same services. Other countries might have different structures, and the generation of the Service List Boundary might follow other rules as long as it is ensured that a client is able to notice any change in the Service List when moving.
RFC5222]. This document extends LoST to also carry Service List Boundaries (and requests for them). These Service List Boundaries are calculated by the server based on the individual Service Boundaries and sent to clients in case the local policy allows this. Therefore, it is generally considered to have the same level of sensitivity as for the Service Boundary and thus the same access control and confidentiality requirements as the base LoST protocol. As a result, the security measures incorporated in the base LoST specification [RFC5222] provide sufficient protection for LoST messages that use the Service List Boundary extension. RFC3688]: URI: urn:ietf:params:xml:schema:lost1:slb Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf (email@example.com) Relax NG Schema: BEGIN <?xml version="1.0" encoding="UTF-8"?> <grammar xmlns="http://relaxng.org/ns/structure/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns:slb="urn:ietf:params:xml:ns:lost1:slb" ns="urn:ietf:params:xml:ns:lost1" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <include href="lost.rng">
<!-- redefinition of LoST elements --> <start> <choice> <ref name="findService"/> <ref name="listServices"/> <ref name="listServicesByLocation"/> <ref name="getServiceBoundary"/> <ref name="findServiceResponse"/> <ref name="listServicesResponse"/> <ref name="listServicesByLocationResponse"/> <ref name="getServiceBoundaryResponse"/> <ref name="errors"/> <ref name="redirect"/> <!-- New in RFC 6197 --> <ref name="getServiceListBoundary"/> <ref name="getServiceListBoundaryResponse"/> </choice> </start> <define name="listServicesByLocation"> <element name="listServicesByLocation"> <ref name="requestLocation"/> <ref name="commonRequestPattern"/> <optional> <attribute name="recursive"> <data type="boolean"/> <a:defaultValue>true</a:defaultValue> </attribute> </optional> <!-- New in RFC 6197 --> <optional> <ref name="serviceListBoundaryRequest"/> </optional> </element> </define> <define name="listServicesByLocationResponse"> <element name="listServicesByLocationResponse"> <ref name="serviceList"/> <ref name="commonResponsePattern"/> <ref name="locationUsed"/>
<!-- New in RFC 6197 --> <optional> <choice> <ref name="serviceListBoundary"/> <ref name="serviceListBoundaryReference"/> </choice> </optional> </element> </define> </include> <define name="serviceListBoundaryRequest"> <element name="slb:serviceListBoundaryRequest"> <optional> <attribute name="type"> <choice> <value>value</value> <value>reference</value> </choice> <a:defaultValue>reference</a:defaultValue> </attribute> </optional> </element> </define> <define name="serviceListBoundary"> <oneOrMore> <element name="slb:serviceListBoundary"> <optional> <ref name="expires"/> </optional> <ref name="locationInformation"/> <ref name="extensionPoint"/> </element> </oneOrMore> </define> <define name="serviceListBoundaryReference"> <element name="slb:serviceListBoundaryReference"> <ref name="source"/> <attribute name="serviceListKey"> <data type="token"/> </attribute> <ref name="extensionPoint"/> </element> </define>
<define name="getServiceListBoundary"> <element name="slb:getServiceListBoundary"> <attribute name="serviceListKey"> <data type="token"/> </attribute> <ref name="extensionPoint"/> </element> </define> <define name="getServiceListBoundaryResponse"> <element name="slb:getServiceListBoundaryResponse"> <ref name="serviceListBoundary"/> <ref name="path"/> <ref name="extensionPoint"/> </element> </define> </grammar> END RFC5222]) in the IETF XML Registry [RFC3688]: URI: urn:ietf:params:xml:ns:lost1:slb Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf (firstname.lastname@example.org)
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 Service List Boundary Namespace</title> </head> <body> <h1>Namespace for the LoST Service List Boundary</h1> <h2>urn:ietf:params:xml:ns:lost1:slb</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc6197.txt"> RFC 6197</a>.</p> </body> </html> END [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.