--- 1/draft-ietf-ecrit-lost-servicelistboundary-02.txt 2010-02-26 16:10:43.000000000 +0100 +++ 2/draft-ietf-ecrit-lost-servicelistboundary-03.txt 2010-02-26 16:10:43.000000000 +0100 @@ -1,18 +1,18 @@ ECRIT K. Wolf Internet-Draft nic.at -Expires: August 13, 2010 February 9, 2010 +Intended status: Experimental February 26, 2010 +Expires: August 30, 2010 - Location-to-Service Translation Protocol (LoST) Extension: - - draft-ietf-ecrit-lost-servicelistboundary-02 + LoST Service List Boundary Extension + draft-ietf-ecrit-lost-servicelistboundary-03 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 LoST server, in its response, does not provide context information, that is, it does not provide any additional information about the geographical region for which the returned list of services is considered valid within. Therefore, @@ -35,62 +35,76 @@ 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 August 13, 2010. + This Internet-Draft will expire on August 30, 2010. Copyright Notice Copyright (c) 2010 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 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. + Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Extensions to . . . . . . . . . . 4 + 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Extensions to . . . . . . . . . . 5 3.2. Retrieving the via - . . . . . . . . . . . . . . . . . 6 - 3.3. . . . . . . . . . . . . . . . . . . 7 - 3.4. Implementation Considerations . . . . . . . . . . . . . . 8 - 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 8 - 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 9 + . . . . . . . . . . . . . . . . . 8 + 3.3. . . . . . . . . . . . . . . . . . . 9 + 3.4. Implementation Considerations . . . . . . . . . . . . . . 10 + 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 10 + 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 11 - 4. Security & Privacy Considerations . . . . . . . . . . . . . . 9 + 4. Security & Privacy Considerations . . . . . . . . . . . . . . 11 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 9 - 5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 12 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 11 + 5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 13 - 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 + 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Location based service providers as well as Public Safety Answering Points (PSAPs) only serve a specific geographic region. Therefore the LoST protocol [RFC5222] 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 by the query in LoST. The LoST server returns a @@ -178,21 +192,23 @@ AT Lower Austria Bruck an der Leitha Wolfsthal Hauptplatz 1 2412 urn:service:sos - value + + value + A possible response is shown below: xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" urn:service:sos.ambulance @@ -261,22 +276,24 @@ An example is shown below: The LoST server response is shown below: - - + + AT Lower Austria @@ -367,21 +384,21 @@ the . Since the integration into LoST follows the concept of the (and also makes use of the same location profiles), just the additional has to be evaluated. Whenever moving outside a , the client must perform a new query with the new location information in order to determine a change in available services. 4. Security & Privacy Considerations - Security considerations for LoST are discussed in RFC5222. This + Security considerations for LoST are discussed in [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 provide sufficient protection for LoST messages that use the Service List Boundary extension. @@ -527,35 +545,39 @@ END 6. Acknowledgement The author would like to thank Henning Schulzrinne for the discussion on the draft and Martin Thomson, Richard Barnes and Roger Marshall for their valuable input and text suggestions during the WGLC. -7. Normative References +7. References + +7.1. 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. +7.2. Informative References + + [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and + Framework", RFC 5582, September 2009. + 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