draft-ietf-ecrit-lost-servicelistboundary-00.txt   draft-ietf-ecrit-lost-servicelistboundary-01.txt 
ECRIT K. Wolf ECRIT K. Wolf
Internet-Draft nic.at 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: Location-to-Service Translation Protocol (LoST) Extension:
ServiceListBoundary 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 <listServicesByLocation>
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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 43
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 April 9, 2010. This Internet-Draft will expire on May 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
LoST maps service identifiers and location information to service described in the BSD License.
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 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . . 4 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Extensions to <ListServiceByLocation> . . . . . . . . . . . 4 3.1. Extensions to <ListServiceByLocation> . . . . . . . . . . 4
3.2. Retrieving the serviceList Boundary via 3.2. Retrieving the serviceList Boundary via
getServiceListBoundary . . . . . . . . . . . . . . . . . . 6 getServiceListBoundary . . . . . . . . . . . . . . . . . . 6
3.3. Service List Boundary . . . . . . . . . . . . . . . . . . . 7 3.3. Service List Boundary . . . . . . . . . . . . . . . . . . 7
3.4. Implementation Considerations . . . . . . . . . . . . . . . 8 3.4. Implementation Considerations . . . . . . . . . . . . . . 8
3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 8
3.4.2. Client 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 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 defines the ServiceBoundary, which indicates the the LoST protocol [RFC5222] defines the ServiceBoundary, which
service region for a specific service URL. However, not all services indicates the service region for a specific service URL. However,
are available everywhere. Clients can discover available services not all services are available everywhere. Clients can discover
for a particular location by the <listServicesByLocation> query in available services for a particular location by the
LoST [RFC5222]. The LoST server returns a list of services that are <listServicesByLocation> query in LoST. The LoST server returns a
available at this particular location. But the server does not list of services that are available at this particular location. But
inform the client for which geographical region the returned service the server does not inform the client for which geographical region
list is valid. This may lead to the situation where a client the returned service list is valid. This may lead to the situation
initially discovered all available services by the where a client initially discoveres all available services by the
<listServicesByLocation> query, and then moves to a different <listServicesByLocation> query, and then moves to a different
location while refreshing the service mappings, but does not notice location (while refreshing the service mappings), but without
the availability of another service. The following imaginary example noticing the availability of other services. The following imaginary
illustrates the problem for emergency calling: example illustrates the problem for emergency calling:
The client is powered-up, does location determination (resulting in The client is powered-up, does location determination (resulting in
location A) and performs an initial <listServicesByLocation> query location A) and performs an initial <listServicesByLocation> query
with location A requesting urn:services:sos. with location A requesting urn:services:sos.
The LoST server returns the following services list: The LoST server returns the following services list:
urn:service:sos.police urn:service:sos.police
urn:service:sos.ambulance urn:service:sos.ambulance
urn:service:sos.fire urn:service:sos.fire
skipping to change at page 5, line 9 skipping to change at page 5, line 9
The query <listServicesByLocation> may contain an additional The query <listServicesByLocation> may contain an additional
serviceListBoundary element to request the boundary for the service serviceListBoundary element to request the boundary for the service
list, either by value or by reference. In the example below the list, either by value or by reference. In the example below the
value of the serviceListBoundary element ist set to "value": value of the serviceListBoundary element ist 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="TBD" xmlns:slb="urn:ietf:params:xml:schema:lost1:slb"
recursive="true"> recursive="true">
<location id="mylocation" profile="civic"> <location id="mylocation" profile="civic">
<civicAddress <civicAddress
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>
<A3>Wolfsthal</A3> <A3>Wolfsthal</A3>
<RD>Hauptplatz</RD> <RD>Hauptplatz</RD>
<HNO>1</HNO> <HNO>1</HNO>
<PC>2412</PC> <PC>2412</PC>
skipping to change at page 5, line 31 skipping to change at page 5, line 31
</location> </location>
<service>urn:service:sos</service> <service>urn:service:sos</service>
<slb:serviceListBoundary>value</slb:serviceListBoundary> <slb:serviceListBoundary>value</slb:serviceListBoundary>
</listServicesByLocation> </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="TBD" 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
urn:service:sos.gas urn:service:sos.gas
urn:service:sos.mountain urn:service:sos.mountain
urn:service:sos.poison urn:service:sos.poison
urn:service:sos.police urn:service:sos.police
</serviceList> </serviceList>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
skipping to change at page 6, line 19 skipping to change at page 6, line 19
boundaries. Additionally, the expires attribute indicates the boundaries. Additionally, the expires attribute indicates the
absolute time when this service list becomes invalid. absolute time when this service list becomes invalid.
The boundary can also be requested by reference when setting the The boundary can also be requested by reference when setting the
attribute serviceListBoundary to "reference". Then the response attribute serviceListBoundary to "reference". Then the response
contains a serviceListBoundaryReference element, as shown below. contains a serviceListBoundaryReference element, as 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="TBD" 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
urn:service:sos.gas urn:service:sos.gas
urn:service:sos.mountain urn:service:sos.mountain
urn:service:sos.poison urn:service:sos.poison
urn:service:sos.police urn:service:sos.police
</serviceList> </serviceList>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
skipping to change at page 7, line 6 skipping to change at page 7, line 6
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="TBD"> <getServiceListBoundaryResponse xmlns="urn:ietf:params:xml:schema:lost1:slb">
<serviceListBoundary profile="civic" expires="2010-01-01T00:00:00Z"> <serviceListBoundary profile="civic" expires="2010-01-01T00:00:00Z">
<civicAddress <civicAddress
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>
</civicAddress> </civicAddress>
</serviceListBoundary> </serviceListBoundary>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
</getServiceListBoundaryResponse> </getServiceListBoundaryResponse>
The serviceListKey uniquely identifies a serviceListBoundary as the The serviceListKey uniquely identifies a serviceListBoundary as the
key does for the service boundary (see Section 5.6 in RFC 5222). 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 Therefore the serviceListKey is a random token with at least 128 bits
of entropy and can be assumed globally unique. Whenever the boundary of entropy and can be assumed globally unique. Whenever the boundary
changes, a new serviceListKey MUST be assigned. changes, a new serviceListKey MUST be assigned.
Note: since LoST does not define an attribute to indicate which
profile the clients understands in a <getServiceListBoundary>
request, this document also does not define one for the
<getServiceListBoundary> request.
3.3. Service List Boundary 3.3. Service List Boundary
The service list boundary indicates a region within which all The service list boundary indicates a region within which all
<listServicesByLocation> queries with the same service identifiers <listServicesByLocation> queries with the same service identifiers
result in the same serviceList. A service list boundary may consist result in the same serviceList. A service list boundary may consist
of geometric shapes (both in civic and geodetic location format), and of geometric shapes (both in civic and geodetic location format), and
may be non-contiguous, like the service boundary. may be non-contiguous, like the service boundary.
The mapping of the specific services within the service list boundary The mapping of the specific services within the service list boundary
may be different at different locations. may be different at different locations.
The server may return the boundary information in multiple profiles, The server may return the boundary information in multiple profiles,
but has to use at least one profile that the client used in the 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 request in order to ensure that the client is able to process the
boundary information. boundary information.
TBD: For <getServiceListBoundary> an attribute in the request could
be used to indicate which profile the client understands (e.g.
<getServiceListBoundary profile="civic"... )
There is no need to include boundary information to a There is no need to include boundary information to a
<listServicesResponse>. <ListServices> requests are purely for <listServicesResponse>. <ListServices> requests are purely for
diagnostic purposes and do not contain location information at all, diagnostic purposes and do not contain location information at all,
so no boundary information is reasonable. so no boundary information is reasonable.
Also note that the serviceListBoundary is optional and the LoST Also note that the serviceListBoundary is optional and the LoST
server may return it based on its local policy - like it is the case server may return it or not based on its local policy - like it is
with service boundary. However, especially for emergency services, the case with the service boundary. However, especially for
the serviceListBoundary might be crucial to ensure that moving emergency services, the serviceListBoundary might be crucial to
clients do not miss changes in the available services. ensure that moving clients do not miss changes in the available
services.
3.4. Implementation Considerations 3.4. Implementation Considerations
The subsections below discuss implementations issues for the LoST The subsections below discuss implementations issues for the LoST
server and client for the serviceListBoundary support. server and client for the serviceListBoundary support.
3.4.1. Server Side 3.4.1. Server Side
The mapping architecture and framework [RFC5582] describes that each The mapping architecture and framework [RFC5582] describes that each
tree announces its coverage region (for one type of service, e.g. tree announces its coverage region (for one type of service, e.g.
skipping to change at page 9, line 15 skipping to change at page 9, line 17
evaluated. Whenever moving outside a serviceListBoundary, the client evaluated. Whenever moving outside a serviceListBoundary, the client
must perform a new listServicesByLocation query with the new location must perform a new listServicesByLocation query with the new location
information in order to determine a change in available services. information in order to determine a change in available services.
4. Security & Privacy Considerations 4. Security & Privacy Considerations
Security considerations are discussed in [RFC5222]. Security considerations are discussed in [RFC5222].
5. IANA Considerations 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
<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost1:slb"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
xmlns:ls="urn:ietf:params:xml:ns:lost1"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<div xmlns:slb="urn:ietf:params:xml:schema:lost1:slb">
<ls:listServicesByLocation>
...
...
<a:documentation>
Allows requesting the serviceListBoundary by reference or by value
</a:documentation>
<define name="serviceListBoundary">
<element name="serviceListBoundary">
<ref name="slb:serviceListBoundary"/>
<choice>
<value>value</value>
<value>reference</value>
</choice>
</element>
</define>
</ls:listServicesByLocation>
</div>
<div xmlns:slb="urn:ietf:params:xml:schema:lost1:slb">
<ls:listServicesByLocationResponse>
...
...
<a:documentation>
Returns the serviceListBoundary by Reference
</a:documentation>
<define name="serviceListBoundaryReference">
<element name="serviceListBoundaryReference">
<ref name="slb:serviceListBoundaryReference"/>
<attribute name="source"/>
<attribute name="serviceListKey"/>
</element>
</define>
</ls:listServicesByLocationResponse>
</div>
<div xmlns:slb="urn:ietf:params:xml:schema:lost1:slb">
<ls:listServicesByLocationResponse>
...
...
<a:documentation>
Returns the serviceListBoundary by Value
</a:documentation>
<define name="serviceListBoundary">
<element name="serviceListBoundary">
<ref name="slb:serviceListBoundary"/>
<attribute name="profile"/>
<ref name="ls:locationInformation"/>
</element>
</define>
</ls:listServicesByLocationResponse>
</div>
<div xmlns:slb="urn:ietf:params:xml:schema:lost1:slb">
<a:documentation>
Request for the serviceListBoundary
</a:documentation>
<define name="getServiceListBoundary">
<element name="getServiceListBoundary">
<ref name="slb:getServiceListBoundary"/>
<attribute name="serviceListKey"/>
</element>
</define>
</div>
<div xmlns:slb="urn:ietf:params:xml:schema:lost1:slb">
<a:documentation>
Response to getServiceListBoundary
</a:documentation>
<define name="getServiceListBoundaryResponse">
<element name="getServiceListBoundaryResponse">
<ref name="slb:getServiceListBoundaryResponse"/>
<attribute name="serviceListKey"/>
<ref name="slb:serviceListBoundary"/>
<ref name="ls:path"/>
</element>
</define>
</div>
</grammar>
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
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>LoST serviceListBoundary Namespace</title>
</head>
<body>
<h1>Namespace for the LoST serviceListBoundary</h1>
<h2>urn:ietf:params:xml:ns:lost1:slb</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p>
</body>
</html>
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. on the draft.
7. Normative References 7. 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 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009. 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,
January 2004.
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. 24 change blocks. 
57 lines changed or deleted 216 lines changed or added

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