< draft-ietf-ecrit-lost-servicelistboundary-02.txt   draft-ietf-ecrit-lost-servicelistboundary-03.txt >
ECRIT K. Wolf ECRIT K. Wolf
Internet-Draft nic.at 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: LoST Service List Boundary Extension
<serviceListBoundary> draft-ietf-ecrit-lost-servicelistboundary-03
draft-ietf-ecrit-lost-servicelistboundary-02
Abstract Abstract
LoST maps service identifiers and location information to service LoST maps service identifiers and location information to service
contact URIs. If a LoST client wants to discover available services contact URIs. If a LoST client wants to discover available services
for a particular location, it will perform a <listServicesByLocation> for a particular location, it will perform a <listServicesByLocation>
query to the LoST server. However, the LoST server, in its response, query to the LoST server. However, the LoST server, in its response,
does not provide context information, that is, it does not provide does not provide context information, that is, it does not provide
any additional information about the geographical region for which any additional information about the geographical region for which
the returned list of services is considered valid within. Therefore, the returned list of services is considered valid within. Therefore,
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Extensions to <listServicesByLocation> . . . . . . . . . . 4 3.1. Extensions to <listServicesByLocation> . . . . . . . . . . 5
3.2. Retrieving the <serviceListBoundary> via 3.2. Retrieving the <serviceListBoundary> via
<getServiceListBoundary> . . . . . . . . . . . . . . . . . 6 <getServiceListBoundary> . . . . . . . . . . . . . . . . . 8
3.3. <serviceListBoundary> . . . . . . . . . . . . . . . . . . 7 3.3. <serviceListBoundary> . . . . . . . . . . . . . . . . . . 9
3.4. Implementation Considerations . . . . . . . . . . . . . . 8 3.4. Implementation Considerations . . . . . . . . . . . . . . 10
3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 9 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 11
4. Security & Privacy Considerations . . . . . . . . . . . . . . 9 4. Security & Privacy Considerations . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 9 5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 11
5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 12 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 1. Introduction
Location based service providers as well as Public Safety Answering Location based service providers as well as Public Safety Answering
Points (PSAPs) only serve a specific geographic region. Therefore Points (PSAPs) only serve a specific geographic region. Therefore
the LoST protocol [RFC5222] defines the Service Boundary, which the LoST protocol [RFC5222] defines the Service Boundary, which
indicates the service region for a specific service URL. However, indicates the service region for a specific service URL. However,
not all services are available everywhere. Clients can discover not all services are available everywhere. Clients can discover
available services for a particular location by the available services for a particular location by the
<listServicesByLocation> query in LoST. The LoST server returns a <listServicesByLocation> query in LoST. The LoST server returns a
skipping to change at page 5, line 5 skipping to change at page 6, line 5
3.1. Extensions to <listServicesByLocation> 3.1. Extensions to <listServicesByLocation>
The query <listServicesByLocation> may contain an additional The query <listServicesByLocation> may contain an additional
<serviceListBoundaryRequest> element to additionally request the <serviceListBoundaryRequest> element to additionally request the
boundary for the service list based on the location provided, with boundary for the service list based on the location provided, with
the resulting location for the list to be presented either in a by the resulting location for the list to be presented either in a by
value or by reference form. In the example below the value of the value or by reference form. In the example below the value of the
<serviceListBoundaryRequest> element is set to "value": <serviceListBoundaryRequest> element is set to "value":
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation <listServicesByLocation
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" xmlns:slb="urn:ietf:params:xml:schema:lost1:slb"
recursive="true"> recursive="true">
<location id="5415203asdf548" profile="civic"> <location id="5415203asdf548" profile="civic">
<civicAddress xml:lang="en" <civicAddress xml:lang="en"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AT</country> <country>AT</country>
<A1>Lower Austria</A1> <A1>Lower Austria</A1>
<A2>Bruck an der Leitha</A2> <A2>Bruck an der Leitha</A2>
<A3>Wolfsthal</A3> <A3>Wolfsthal</A3>
<RD>Hauptplatz</RD> <RD>Hauptplatz</RD>
<HNO>1</HNO> <HNO>1</HNO>
<PC>2412</PC> <PC>2412</PC>
</civicAddress> </civicAddress>
</location> </location>
<service>urn:service:sos</service> <service>urn:service:sos</service>
<slb:serviceListBoundaryRequest>value</slb:serviceListBoundaryRequest> <slb:serviceListBoundaryRequest>
</listServicesByLocation> value
</slb:serviceListBoundaryRequest>
</listServicesByLocation>
A possible response is shown below: A possible response is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse <listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1"> xmlns="urn:ietf:params:xml:ns:lost1">
xmlns:slb="urn:ietf:params:xml:schema:lost1:slb" xmlns:slb="urn:ietf:params:xml:schema:lost1:slb"
<serviceList expires="2010-01-01T00:00:00Z"> <serviceList expires="2010-01-01T00:00:00Z">
urn:service:sos.ambulance urn:service:sos.ambulance
urn:service:sos.fire urn:service:sos.fire
skipping to change at page 7, line 11 skipping to change at page 9, line 5
<getServiceBoundary> request. <getServiceBoundary> request.
An example is shown below: An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<getServiceListBoundary xmlns="urn:ietf:params:xml:ns:lost1" <getServiceListBoundary xmlns="urn:ietf:params:xml:ns:lost1"
serviceListKey="123567890123567890123567890"/> serviceListKey="123567890123567890123567890"/>
The LoST server response is shown below: The LoST server response is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<getServiceListBoundaryResponse xmlns="urn:ietf:params:xml:schema:lost1:slb"> <getServiceListBoundaryResponse
<serviceListBoundary profile="civic" expires="2010-01-01T00:00:00Z"> xmlns="urn:ietf:params:xml:schema:lost1:slb">
<civicAddress xml:lang="en" <serviceListBoundary profile="civic"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> expires="2010-01-01T00:00:00Z">
<country>AT</country> <civicAddress xml:lang="en"
<A1>Lower Austria</A1> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
</civicAddress> <country>AT</country>
</serviceListBoundary> <A1>Lower Austria</A1>
<path> </civicAddress>
<via source="resolver.example"/> </serviceListBoundary>
<via source="authoritative.example"/> <path>
</path> <via source="resolver.example"/>
</getServiceListBoundaryResponse> <via source="authoritative.example"/>
</path>
</getServiceListBoundaryResponse>
The 'serviceListKey' uniquely identifies a Service List Boundary as The 'serviceListKey' uniquely identifies a Service List Boundary as
the 'key' does for the service boundary (see Section 5.6 in RFC the 'key' does for the service boundary (see Section 5.6 in RFC
5222). Therefore the 'serviceListKey' is a random token with at 5222). Therefore the 'serviceListKey' is a random token with at
least 128 bits of entropy and can be assumed globally unique. least 128 bits of entropy and can be assumed globally unique.
Whenever the boundary changes, a new 'serviceListKey' MUST be Whenever the boundary changes, a new 'serviceListKey' MUST be
assigned. assigned.
Note: since LoST does not define an attribute to indicate which Note: since LoST does not define an attribute to indicate which
profile the clients understands in a <getServiceListBoundary> profile the clients understands in a <getServiceListBoundary>
skipping to change at page 9, line 24 skipping to change at page 11, line 19
the <serviceListBoundary>. Since the integration into LoST follows the <serviceListBoundary>. Since the integration into LoST follows
the concept of the <serviceBoundary> (and also makes use of the same the concept of the <serviceBoundary> (and also makes use of the same
location profiles), just the additional <serviceListBoundary> has to location profiles), just the additional <serviceListBoundary> has to
be evaluated. Whenever moving outside a <serviceListBoundary>, the be evaluated. Whenever moving outside a <serviceListBoundary>, the
client must perform a new <listServicesByLocation> query with the new client must perform a new <listServicesByLocation> query with the new
location information in order to determine a change in available location information in order to determine a change in available
services. services.
4. Security & Privacy Considerations 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 document extends LoST to also carry Service List Boundaries (and
requests for them). These Service List Boundaries are calculated by requests for them). These Service List Boundaries are calculated by
the server based on the individual Service Boundaries and sent to the server based on the individual Service Boundaries and sent to
clients in case the local policy allows this. Therefore it is clients in case the local policy allows this. Therefore it is
generally considered to have the same level of sensitivity as for the generally considered to have the same level of sensitivity as for the
Service Boundary and thus the same access control and confidentiality Service Boundary and thus the same access control and confidentiality
requirements as the base LoST protocol. As a result, the security requirements as the base LoST protocol. As a result, the security
measures incorporated in the base LoST specification provide measures incorporated in the base LoST specification provide
sufficient protection for LoST messages that use the Service List sufficient protection for LoST messages that use the Service List
Boundary extension. Boundary extension.
skipping to change at page 12, line 45 skipping to change at page 14, line 39
</html> </html>
END END
6. Acknowledgement 6. Acknowledgement
The author would like to thank Henning Schulzrinne for the discussion The author would like to thank Henning Schulzrinne for the discussion
on the draft and Martin Thomson, Richard Barnes and Roger Marshall on the draft and Martin Thomson, Richard Barnes and Roger Marshall
for their valuable input and text suggestions during the WGLC. 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. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
7.2. Informative References
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009.
Author's Address Author's Address
Karl Heinz Wolf Karl Heinz Wolf
nic.at GmbH nic.at GmbH
Karlsplatz 1/2/9 Karlsplatz 1/2/9
Wien A-1010 Wien A-1010
Austria Austria
Phone: +43 1 5056416 37 Phone: +43 1 5056416 37
Email: karlheinz.wolf@nic.at Email: karlheinz.wolf@nic.at
 End of changes. 19 change blocks. 
61 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/