--- 1/draft-ietf-ecrit-lost-servicelistboundary-00.txt 2009-11-09 11:12:24.000000000 +0100 +++ 2/draft-ietf-ecrit-lost-servicelistboundary-01.txt 2009-11-09 11:12:24.000000000 +0100 @@ -1,18 +1,29 @@ ECRIT K. Wolf Internet-Draft nic.at -Expires: April 9, 2010 October 6, 2009 +Expires: May 13, 2010 November 9, 2009 Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary - draft-ietf-ecrit-lost-servicelistboundary-00 + draft-ietf-ecrit-lost-servicelistboundary-01 + +Abstract + + 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 + query to the LoST server. However, the response from the LoST server + does not provide information about the geographical region for which + the returned service list is valid. Therefore, this document + proposes a ServiceListBoundary to assist the client to not miss a + change in available services when moving. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. @@ -21,86 +32,81 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 9, 2010. + This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - 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 - query to the LoST server. However, the response from the LoST server - does not provide information about the geographical region for which - the returned service list is valid. Therefore, this document - proposes a ServiceListBoundary to assist the client to not miss a - change in available services when moving. + 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Extensions to . . . . . . . . . . . 4 + 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Extensions to . . . . . . . . . . 4 3.2. Retrieving the serviceList Boundary via getServiceListBoundary . . . . . . . . . . . . . . . . . . 6 - 3.3. Service List Boundary . . . . . . . . . . . . . . . . . . . 7 - 3.4. Implementation Considerations . . . . . . . . . . . . . . . 8 - 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . . 8 - 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Service List Boundary . . . . . . . . . . . . . . . . . . 7 + 3.4. Implementation Considerations . . . . . . . . . . . . . . 8 + 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 8 + 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 8 - 4. Security & Privacy Considerations . . . . . . . . . . . . . . . 9 + 4. Security & Privacy Considerations . . . . . . . . . . . . . . 9 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 9 + 5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 11 - 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Location based service providers as well as Public Safety Answering Points (PSAPs) only serve a specific geographic region. Therefore - the LoST protocol defines the ServiceBoundary, 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 by the query in - LoST [RFC5222]. The LoST server returns a list of services that are - available at this particular location. But the server does not - inform the client for which geographical region the returned service - list is valid. This may lead to the situation where a client - initially discovered all available services by the + the LoST protocol [RFC5222] defines the ServiceBoundary, 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 by the + query in LoST. The LoST server returns a + list of services that are available at this particular location. But + the server does not inform the client for which geographical region + the returned service list is valid. This may lead to the situation + where a client initially discoveres all available services by the query, and then moves to a different - location while refreshing the service mappings, but does not notice - the availability of another service. The following imaginary example - illustrates the problem for emergency calling: + 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 query with location A requesting urn:services:sos. The LoST server returns the following services list: urn:service:sos.police urn:service:sos.ambulance urn:service:sos.fire @@ -152,21 +158,21 @@ The query may contain an additional serviceListBoundary element to request the boundary for the service list, either by value or by reference. In the example below the value of the serviceListBoundary element ist set to "value": AT Lower Austria Wolfsthal Hauptplatz 1 2412 @@ -174,21 +180,21 @@ urn:service:sos value A possible response is shown below: - xmlns:slb="TBD" + xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" urn:service:sos.ambulance urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.poison urn:service:sos.police @@ -211,21 +217,21 @@ boundaries. Additionally, the expires attribute indicates the absolute time when this service list becomes invalid. The boundary can also be requested by reference when setting the attribute serviceListBoundary to "reference". Then the response contains a serviceListBoundaryReference element, as shown below. - xmlns:slb="TBD" + xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" urn:service:sos.ambulance urn:service:sos.fire urn:service:sos.gas urn:service:sos.mountain urn:service:sos.poison urn:service:sos.police @@ -245,70 +251,72 @@ An example is shown below: The LoST server response is shown below: - + AT Lower Austria The serviceListKey uniquely identifies a serviceListBoundary as the key does for the service boundary (see Section 5.6 in RFC 5222). Therefore the serviceListKey is a random token with at least 128 bits of entropy 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 + profile the clients understands in a + request, this document also does not define one for the + request. + 3.3. Service List Boundary The service list boundary indicates a region within which all queries with the same service identifiers result in the same serviceList. A service list boundary may consist of geometric shapes (both in civic and geodetic location format), and may be non-contiguous, like the service boundary. The mapping of the specific services within the service list boundary may be different at different locations. The server may return the boundary information in multiple profiles, but has to use at least one profile that the client used in the request in order to ensure that the client is able to process the boundary information. - TBD: For an attribute in the request could - be used to indicate which profile the client understands (e.g. - . requests are purely for diagnostic purposes and do not contain location information at all, so no boundary information is reasonable. Also note that the serviceListBoundary is optional and the LoST - server may return it based on its local policy - like it is the case - with service boundary. However, especially for emergency services, - the serviceListBoundary might be crucial to ensure that moving - clients do not miss changes in the available services. + server may return it or not based on its local policy - like it is + the case with the service boundary. However, especially for + emergency services, the serviceListBoundary might be crucial to + ensure that moving clients do not miss changes in the available + services. 3.4. Implementation Considerations The subsections below discuss implementations issues for the LoST server and client for the serviceListBoundary support. 3.4.1. Server Side The mapping architecture and framework [RFC5582] describes that each tree announces its coverage region (for one type of service, e.g. @@ -350,39 +358,190 @@ evaluated. Whenever moving outside a serviceListBoundary, the client must perform a new listServicesByLocation query with the new location information in order to determine a change in available services. 4. Security & Privacy Considerations Security considerations are discussed in [RFC5222]. 5. IANA Considerations - TODO. + This document requests two actions by IANA: a XML schema registration + and namespace registration, according to the description in the + following sections. + +5.1. Relax NG Schema Registration + + This document requests registration of the following Relax NG Schema + to the IETF XML Registry [RFC3688]: + + URI: urn:ietf:params:xml:schema:lost1:slb + + Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf + (karlheinz.wolf@nic.at) + + Relax NG Schema: + +BEGIN + + + + +
+ + ... + ... + + Allows requesting the serviceListBoundary by reference or by value + + + + + + value + reference + + + + +
+ +
+ + ... + ... + + Returns the serviceListBoundary by Reference + + + + + + + + + + +
+ +
+ + ... + ... + + Returns the serviceListBoundary by Value + + + + + + + + + + + +
+ +
+ + + Request for the serviceListBoundary + + + + + + + + + +
+ +
+ + + Response to getServiceListBoundary + + + + + + + + + + + +
+ + +END + +5.2. Namespace Registration + + This document requests registration of the following namespace (below + the LoST namespace defined in [RFC5222]) to the IETF XML Registry + [RFC3688]: + + URI: urn:ietf:params:xml:ns:lost1:slb + + Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf + (karlheinz.wolf@nic.at) + + XML: + + BEGIN + + + + + + + LoST serviceListBoundary Namespace + + +

Namespace for the LoST serviceListBoundary

+

urn:ietf:params:xml:ns:lost1:slb

+

See + RFCXXXX.

+ + + + END 6. Acknowledgement The author would like to thank Henning Schulzrinne for the discussion on the draft. 7. Normative References [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009. [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. + Author's Address Karl Heinz Wolf nic.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria Phone: +43 1 5056416 37 Email: karlheinz.wolf@nic.at