The IESG has approved the following document: - 'LoST Service List Boundary Extension' (draft-ietf-ecrit-lost-servicelistboundary-05.txt) as an Experimental RFC This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-servicelistboundary/ Technical Summary 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 for which the returned list of services is considered valid within. Therefore, this document proposes a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client to not miss a change in available services when moving. Working Group Summary There is consensus in the working group that this document adds useful functionality to the LoST protocol. Document Quality The document has been reviewed by key participants from the ECRIT working group and from the APP area XML-DIR. Personnel Richard Barnes is the document shepherd. Robert Sparks is the responsible AD. RFC Editor Note (Applies to -05) 1. In the abstract the document starts with LoST, Please expand to Location-to-Service Translation 2. At the end of section 3.2 - Replace the first instance of getServiceListBoundary with getServiceBoundary as follows: OLD: Note: since LoST does not define an attribute to indicate which location profile the clients understands in a <getServiceListBoundary> request, this document also does not define one for the <getServiceListBoundary> request. NEW: Note: since LoST does not define an attribute to indicate which location profile the clients understands in a <getServiceBoundary> request, this document also does not define one for the <getServiceListBoundary> request. 3. In the second to last paragraph of section 3.2 - OLD: Therefore the 'serviceListKey' is a random token with at least 128 bits of entropy and can be assumed globally unique. NEW: Therefore the 'serviceListKey' is a random token with at least 128 bits of entropy [RFC4086] and can be assumed globally unique. 4. Add as a normative reference: [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
