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.