draft-ietf-ecrit-lost-servicelistboundary-05.txt   rfc6197.txt 
ECRIT K. Wolf Internet Engineering Task Force (IETF) K. Wolf
Internet-Draft nic.at Request for Comments: 6197 nic.at
Intended status: Experimental December 16, 2010 Category: Experimental April 2011
Expires: June 19, 2011 ISSN: 2070-1721
LoST Service List Boundary Extension Location-to-Service Translation (LoST) Service List Boundary Extension
draft-ietf-ecrit-lost-servicelistboundary-05
Abstract Abstract
LoST maps service identifiers and location information to service Location-to-Service Translation (LoST) maps service identifiers and
contact URIs. If a LoST client wants to discover available services location information to service contact URIs. If a LoST client wants
for a particular location, it will perform a <listServicesByLocation> to discover available services for a particular location, it will
query to the LoST server. However, the LoST server, in its response, perform a <listServicesByLocation> query to the LoST server.
does not provide context information, that is, it does not provide However, the LoST server, in its response, does not provide context
any additional information about the geographical region for which information; that is, it does not provide any additional information
the returned list of services is considered valid within. Therefore, about the geographical region within which the returned list of
this document proposes a Service List Boundary that returns a local services is considered valid. Therefore, this document defines a
context along with the list of services returned, in order to assist Service List Boundary that returns a local context along with the
the client to not miss a change in available services when moving. list of services returned, in order to assist the client in not
missing a change in available services when moving.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for examination, experimental implementation, and
working documents as Internet-Drafts. The list of current Internet- evaluation.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on June 19, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6197.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology .....................................................4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. LoST Extensions .................................................4
3.1. Extensions to <listServicesByLocation> .....................4
3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Retrieving the <serviceListBoundary> via
3.1. Extensions to <listServicesByLocation> . . . . . . . . . . 5 <getServiceListBoundary> ...................................7
3.2. Retrieving the <serviceListBoundary> via 3.3. <serviceListBoundary> ......................................8
<getServiceListBoundary> . . . . . . . . . . . . . . . . . 8 3.4. Implementation Considerations ..............................9
3.3. <serviceListBoundary> . . . . . . . . . . . . . . . . . . 9 3.4.1. Server Side .........................................9
3.4. Implementation Considerations . . . . . . . . . . . . . . 10 3.4.2. Client Side .........................................9
3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 10 4. Security and Privacy Considerations ............................10
3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations ............................................10
5.1. Relax NG Schema Registration ..............................10
4. Security & Privacy Considerations . . . . . . . . . . . . . . 11 5.2. Namespace Registration ....................................13
6. Acknowledgements ...............................................14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References .....................................................14
5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 11 7.1. Normative References ......................................14
5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 14 7.2. Informative References ....................................15
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Since the LoST protocol employs the Service Boundary concept in order Since the LoST protocol [RFC5222] employs the Service Boundary
to avoid having clients continuously trying to refresh the mapping of concept in order to avoid having clients continuously trying to
a specific service, a Service List Boundary mechanism provides refresh the mapping of a specific service, a Service List Boundary
similar advantages for Service Lists. mechanism provides similar advantages for Service Lists.
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 defines the Service Boundary, which indicates the
indicates the service region for a specific service URL. However, service region for a specific service URL. However, not all services
not all services are available everywhere. Clients can discover are available everywhere. Clients can discover available services
available services for a particular location by the for a particular location via the <listServicesByLocation> query in
<listServicesByLocation> query in LoST. The LoST server returns a LoST. The LoST server returns a list of services that are available
list of services that are available at this particular location. But at this particular location, but the server does not provide any
the server does not inform the client as to the extent of coverage additional information about the geographical region within which the
for which geographical region the returned Service List is valid. returned Service List is considered valid. This may lead to the
This may lead to the situation where a client initially discovers all situation where a client initially discovers all available services
available services by the <listServicesByLocation> query, and then via the <listServicesByLocation> query, and then moves to a different
moves to a different location (while refreshing the service location (while refreshing the service mappings), but without
mappings), but without noticing the availability of other services. noticing the availability of other services. The following imaginary
The following imaginary example illustrates the problem for emergency example illustrates the problem for emergency calling:
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 list of services: The LoST server returns the following list of services:
urn:service:sos.police urn:service:sos.police
urn:service:sos.ambulance urn:service:sos.ambulance
urn:service:sos.fire urn:service:sos.fire
The client does the initial LoST mapping and discovers the The client does the initial LoST mapping and discovers the
dialstrings for each service. Then the client moves, refreshing the dialstrings for each service. Then the client moves, refreshing the
individual service mappings when necessary as told by the Service individual service mappings when necessary as specified by the
Boundary. However, when arriving in location B (close to a Service Boundary. However, when arriving in location B (close to a
mountain), service sos.mountainrescue is available, which was not mountain), service sos.mountainrescue, which was not available in
available in location A. Since the client is only required to refresh location A, becomes available. Since the client is only required to
the mappings for the initially discovered services, the new service refresh the mappings for the initially discovered services, the new
is not detected. Consequently, the dialstring for the mountain service is not detected. Consequently, the dialstring for the
rescue is not known by the client. Hence, the client is unable to mountain-rescue service is not known by the client. Hence, the
recognize an emergency call when the user enters the dialstring of client is unable to recognize an emergency call when the user enters
the mountain rescue and thus the emergency call may fail altogether. the dialstring of the mountain-rescue service, and the emergency call
may fail altogether.
Note that the Service Boundary (service region for an individual Note that the Service Boundary (service region for an individual
service) cannot be considered as an indicator for the region a service) cannot be considered as an indicator for the region for
specific Service List is valid for. The Service List may even change which a specific Service List is valid. The Service List may even
within the Service Boundary of another service. For example, the change within the Service Boundary of another service. For example,
ambulance mapping is valid for a whole state, but for a part of the the ambulance mapping is valid for a whole state, but for a part of
state there is an additional mountain rescue service. the state there is an additional mountain-rescue service.
Consequently, there are two ways to tackle this issue: Consequently, there are two ways to tackle this issue:
o clients continuously poll for the Service List, although it may
not have changed o Clients continuously poll for the Service List, although it may
o a boundary information (telling the client that the Service List not have changed.
does not change inside this area)
o The server sends a message containing boundary information that
tells the client that the Service List does not change inside this
area.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. LoST Extensions 3. LoST Extensions
This chapter describes the necessary extensions to the LoST protocol This section describes the necessary extensions to the LoST protocol
in order to support the proposed Service List Boundary in a similar in order to support the Service List Boundary in a similar way as the
way as the <serviceBoundary>. Extensions defined in this document Service Boundary. Extensions defined in this document are declared
are declared in the new XML namespace in the new XML namespace urn:ietf:params:xml:ns:lost1:slb.
urn:ietf:params:xml:ns:lost1:slb.
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 presented either by value or by the resulting location for the list presented either by value or by
reference. In the example below the value of 'type' attribute of the reference. In the example below, the value of the 'type' attribute
<serviceListBoundaryRequest> element is set to "value": of the <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:ns:lost1:slb" xmlns:slb="urn:ietf:params:xml:ns: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">
skipping to change at page 6, line 28 skipping to change at page 5, line 28
<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 type="value"/> <slb:serviceListBoundaryRequest type="value"/>
</listServicesByLocation> </listServicesByLocation>
A <listServicesByLocationResponse> with the addition of one A <listServicesByLocationResponse> with the addition of one
<serviceListBoundary> elemenents is shown below: <serviceListBoundary> element 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:ns:lost1:slb"> xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">
<serviceList> <serviceList>
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
skipping to change at page 7, line 32 skipping to change at page 6, line 19
<slb:serviceListBoundary profile="civic" <slb:serviceListBoundary profile="civic"
expires="2012-01-01T00:00:00Z"> expires="2012-01-01T00:00:00Z">
<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>
</civicAddress> </civicAddress>
</slb:serviceListBoundary> </slb:serviceListBoundary>
</listServicesByLocationResponse> </listServicesByLocationResponse>
This response above indicates that the Service List is valid for The response above indicates that the Service List is valid for Lower
Lower Austria. The <listServicesByLocation> request needs to be Austria. The <listServicesByLocation> request needs to be repeated
repeated by the client only when moving out of Lower Austria. by the client only when moving out of Lower Austria. However, the
However, the mappings of the services itself may have other service mappings of the services themselves may have other service
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 response MAY contain multiple <serviceListBoundary> elements for The response MAY contain multiple <serviceListBoundary> elements for
alternative representation, each representing the boundary in a alternative representation, each representing the boundary in a
specific location profile. However, multiple locations inside a specific location profile. However, multiple locations inside a
serviceListBoundary element are considered to be additive. <serviceListBoundary> element are considered to be additive.
The boundary can also be requested by reference when setting the The boundary can also be requested by reference when setting the
value of the 'type' attribute of the <serviceListBoundaryRequest> value of the 'type' attribute of the <serviceListBoundaryRequest>
element to "reference" (which is the default in case the attribute is element to "reference" (which is the default in case the attribute is
omitted). Then the response contains a omitted). The response will contain a <serviceListBoundaryReference>
<serviceListBoundaryReference> element with a 'serviceListKey' element with a 'serviceListKey' attribute (described in Section 3.2),
attribute (described in Section 3.2), as shown below. 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="urn:ietf:params:xml:ns:lost1:slb"> xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">
<serviceList> <serviceList>
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
skipping to change at page 8, line 29 skipping to change at page 7, line 16
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="5415203asdf548"/> <locationUsed id="5415203asdf548"/>
<slb:serviceListBoundaryReference <slb:serviceListBoundaryReference
source="authoritative.example" source="authoritative.example"
serviceListKey="123567890123567890123567890" /> serviceListKey="123567890123567890123567890" />
</listServicesByLocationResponse> </listServicesByLocationResponse>
3.2. Retrieving the <serviceListBoundary> via <getServiceListBoundary> 3.2. Retrieving the <serviceListBoundary> via <getServiceListBoundary>
In order to retrieve the boundary corresponding a specific In order to retrieve the boundary corresponding to a specific
'serviceListKey', the client issues a <getServiceListBoundary> 'serviceListKey', the client issues a <getServiceListBoundary>
request to the server identified in the 'source' attribute of the request to the server identified in the 'source' attribute of the
<serviceListBoundaryReference> element, similar to the <serviceListBoundaryReference> element, similar to the
<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 <getServiceListBoundary
xmlns="urn:ietf:params:xml:ns:lost1:slb" xmlns="urn:ietf:params:xml:ns:lost1:slb"
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 <getServiceListBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1:slb"> xmlns="urn:ietf:params:xml:ns:lost1:slb">
<serviceListBoundary profile="civic" expires="2012-01-01T00:00:00Z"> <serviceListBoundary profile="civic" expires="2012-01-01T00:00:00Z">
<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>
</civicAddress> </civicAddress>
</serviceListBoundary> </serviceListBoundary>
<path xmlns="urn:ietf:params:xml:ns:lost1"> <path xmlns="urn:ietf:params:xml:ns:lost1">
<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 Service List Boundary, as
the 'key' does for the Service Boundary (see Section 5.6 of
RFC 5222). Therefore, the 'serviceListKey' is a random token with at
least 128 bits of entropy [RFC4086] and can be assumed globally
unique. Whenever the boundary changes, a new 'serviceListKey' MUST
be assigned.
The 'serviceListKey' uniquely identifies a Service List Boundary as Note: Since LoST does not define an attribute to indicate which
the 'key' does for the Service Boundary (see Section 5.6 in RFC location profile the client understands in a <getServiceBoundary>
5222). Therefore the 'serviceListKey' is a random token with at request, this document also does not define one for the
least 128 bits of entropy and can be assumed globally unique. <getServiceListBoundary> request.
Whenever the boundary changes, a new 'serviceListKey' MUST be
assigned.
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.
3.3. <serviceListBoundary> 3.3. <serviceListBoundary>
The Service List Boundary information that gets returned indicates For a particular <listServicesByLocation> query, the Service List
the geographic region in which all the service identifiers returned Boundary information that gets returned indicates that all the
from a <serviceList> element are the same, within a service identifiers returned in the <serviceList> element are the
<listServicesByLocation> query. A Service List Boundary may consist same within this geographic region. A Service List Boundary may
of geometric shapes (both in civic and geodetic location format), and consist of geometric shapes (both in civic and geodetic location
may be non-contiguous, like the Service Boundary. format), and 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 location The server MAY return the boundary information in multiple location
profiles, but MUST use at least one profile that the client used in profiles, but MUST use at least one profile that the client used in
the request in order to ensure that the client is able to process the the request in order to ensure that the client is able to process the
boundary information. boundary information.
There is no need to include boundary information to a There is no need to include boundary information in a
<listServicesResponse>. The <listServices> request is purely for <listServicesResponse>. The <listServices> request is purely for
diagnostic purposes and does not contain location information at all, diagnostic purposes and does not contain location information at all,
so boundary information cannot be calculated. so boundary information cannot be calculated.
Also note that the Service List Boundary is optional and the LoST Also note that the Service List Boundary is OPTIONAL, and the LoST
server may return it or not based on its local policy - like it is server may return it or not, based on its local policy -- as is the
the case with the Service Boundary. However, especially for case with the Service Boundary. However, especially for emergency
emergency services, the Service List Boundary might be crucial to services, the Service List Boundary might be crucial to ensure that
ensure that moving clients do not miss changes in the available moving clients do not miss changes in the available services.
services.
3.4. Implementation Considerations 3.4. Implementation Considerations
The subsections below discuss implementation issues for the LoST The subsections below discuss implementation issues for the LoST
server and client for the Service List Boundary support. server and client for Service List Boundary 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] states 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.,
sos.police) to one or more forest guides. Forest guides peer with sos.police) to one or more forest guides. Forest guides peer with
each other and synchronize their data. Hence, a forest guide has each other and synchronize their data. Hence, a forest guide has
sufficient knowledge (it knows all the services and their coverage sufficient knowledge (it knows all the services and their coverage
regions) to answer a <listServicesByLocation> query and additionally regions) to answer a <listServicesByLocation> query and to add the
add the <serviceListBoundary> or <serviceListBoundaryReference> as <serviceListBoundary> or <serviceListBoundaryReference> as well.
well.
The calculation of the largest possible area for which the Service The calculation of the largest possible area for which the Service
List stays the same might be a complex task. An alternative would be List stays the same might be a complex task. An alternative would be
to return smaller areas that are easier to compute. In such a case to return smaller areas that are easier to compute. In such a case,
some unneeded queries to the LoST server are the consequence, but some unnecessary queries to the LoST server will be a consequence,
still the main purpose of the Service List Boundary is achieved: but the main purpose of the Service List Boundary is still achieved:
Never miss a change of available services. Thus, the server operator to never miss a change of available services. Thus, the server
may specify a reasonable trade-off between the effort to generate the operator may specify a reasonable trade-off between the effort to
boundary information and the saved queries to the LoST server. generate the boundary information and the saved queries to the LoST
server.
For example, in some countries the offered services may differ in For example, in some countries the offered services may differ in
adjacent counties (or districts, cantons, states, ...). Their adjacent counties (or districts, cantons, states, etc.). Their
borders may be suitable as Service List Boundary as well, even though borders may be suitable as a Service List Boundary as well, even
some adjacent counties offer the same services. though some adjacent counties offer the same services.
Other countries might have different structures and the generation of Other countries might have different structures, and the generation
the Service List Boundary might follow other rules as long as it is of the Service List Boundary might follow other rules as long as it
ensured that a client is able to notice any change in the Service is ensured that a client is able to notice any change in the Service
List when moving. List when moving.
3.4.2. Client Side 3.4.2. Client Side
A mobile client that already implements LoST and evaluates the A mobile client that already implements LoST and evaluates the
<serviceBoundary> has almost everything that is needed to make use of <serviceBoundary> has almost everything that is needed to make use of
the Service List Boundary. Since the integration into LoST follows the Service List Boundary. 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> needs location profiles), only the additional <serviceListBoundary> needs
to be evaluated. Whenever moving outside a Service List Boundary, to be evaluated. Whenever moving outside a Service List Boundary,
the client performs a new <listServicesByLocation> query with the new the client performs 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 and 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 [RFC5222]
sufficient protection for LoST messages that use the Service List provide sufficient protection for LoST messages that use the Service
Boundary extension. List Boundary extension.
5. IANA Considerations 5. IANA Considerations
This document requests two actions by IANA: an XML schema IANA has taken two actions: an XML schema registration and a
registration and namespace registration, according to the description namespace registration, according to the description in the following
in the following sections. sections.
5.1. Relax NG Schema Registration 5.1. Relax NG Schema Registration
This document requests registration of the following Relax NG Schema IANA has registered the following Relax NG Schema in the IETF XML
to the IETF XML Registry [RFC3688]: Registry [RFC3688]:
URI: urn:ietf:params:xml:schema:lost1:slb URI: urn:ietf:params:xml:schema:lost1:slb
Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf
(karlheinz.wolf@nic.at) (karlheinz.wolf@nic.at)
Relax NG Schema: Relax NG Schema:
BEGIN BEGIN
skipping to change at page 12, line 23 skipping to change at page 11, line 18
<ref name="listServices"/> <ref name="listServices"/>
<ref name="listServicesByLocation"/> <ref name="listServicesByLocation"/>
<ref name="getServiceBoundary"/> <ref name="getServiceBoundary"/>
<ref name="findServiceResponse"/> <ref name="findServiceResponse"/>
<ref name="listServicesResponse"/> <ref name="listServicesResponse"/>
<ref name="listServicesByLocationResponse"/> <ref name="listServicesByLocationResponse"/>
<ref name="getServiceBoundaryResponse"/> <ref name="getServiceBoundaryResponse"/>
<ref name="errors"/> <ref name="errors"/>
<ref name="redirect"/> <ref name="redirect"/>
<!-- New in RFCXXX --> <!-- New in RFC 6197 -->
<ref name="getServiceListBoundary"/> <ref name="getServiceListBoundary"/>
<ref name="getServiceListBoundaryResponse"/> <ref name="getServiceListBoundaryResponse"/>
</choice> </choice>
</start> </start>
<define name="listServicesByLocation"> <define name="listServicesByLocation">
<element name="listServicesByLocation"> <element name="listServicesByLocation">
<ref name="requestLocation"/> <ref name="requestLocation"/>
<ref name="commonRequestPattern"/> <ref name="commonRequestPattern"/>
<optional> <optional>
<attribute name="recursive"> <attribute name="recursive">
<data type="boolean"/> <data type="boolean"/>
<a:defaultValue>true</a:defaultValue> <a:defaultValue>true</a:defaultValue>
</attribute> </attribute>
</optional> </optional>
<!-- New in RFCXXXX --> <!-- New in RFC 6197 -->
<optional> <optional>
<ref name="serviceListBoundaryRequest"/> <ref name="serviceListBoundaryRequest"/>
</optional> </optional>
</element> </element>
</define> </define>
<define name="listServicesByLocationResponse"> <define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse"> <element name="listServicesByLocationResponse">
<ref name="serviceList"/> <ref name="serviceList"/>
<ref name="commonResponsePattern"/> <ref name="commonResponsePattern"/>
<ref name="locationUsed"/> <ref name="locationUsed"/>
<!-- New in RFCXXXX --> <!-- New in RFC 6197 -->
<optional> <optional>
<choice> <choice>
<ref name="serviceListBoundary"/> <ref name="serviceListBoundary"/>
<ref name="serviceListBoundaryReference"/> <ref name="serviceListBoundaryReference"/>
</choice> </choice>
</optional> </optional>
</element> </element>
</define> </define>
</include> </include>
<define name="serviceListBoundaryRequest"> <define name="serviceListBoundaryRequest">
<element name="slb:serviceListBoundaryRequest"> <element name="slb:serviceListBoundaryRequest">
<optional> <optional>
<attribute name="type"> <attribute name="type">
<choice> <choice>
<value>value</value> <value>value</value>
<value>reference</value> <value>reference</value>
</choice> </choice>
skipping to change at page 14, line 26 skipping to change at page 13, line 26
<ref name="path"/> <ref name="path"/>
<ref name="extensionPoint"/> <ref name="extensionPoint"/>
</element> </element>
</define> </define>
</grammar> </grammar>
END END
5.2. Namespace Registration 5.2. Namespace Registration
This document requests registration of the following namespace (below IANA has registered the following namespace (below the LoST namespace
the LoST namespace defined in [RFC5222]) to the IETF XML Registry defined in [RFC5222]) in the IETF XML Registry [RFC3688]:
[RFC3688]:
URI: urn:ietf:params:xml:ns:lost1:slb URI: urn:ietf:params:xml:ns:lost1:slb
Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf
(karlheinz.wolf@nic.at) (karlheinz.wolf@nic.at)
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
skipping to change at page 15, line 19 skipping to change at page 14, line 20
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>LoST Service List Boundary Namespace</title> <title>LoST Service List Boundary Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for the LoST Service List Boundary</h1> <h1>Namespace for the LoST Service List Boundary</h1>
<h2>urn:ietf:params:xml:ns:lost1:slb</h2> <h2>urn:ietf:params:xml:ns:lost1:slb</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt"> <p>See <a href="http://www.rfc-editor.org/rfc/rfc6197.txt">
RFCXXXX</a>.</p> RFC 6197</a>.</p>
</body> </body>
</html> </html>
END END
6. Acknowledgement 6. Acknowledgements
The author would like to thank Henning Schulzrinne for the discussion The author would like to thank Henning Schulzrinne for discussion of
on the draft and Martin Thomson, Richard Barnes and Roger Marshall the document, 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 working
Further thanks go to Joshua Bell from the Applications Area Review group Last Call. Further thanks go to Joshua Bell from the
Team for his help with Relax NG. Applications Area Review Team for his help with Relax NG.
7. References 7. References
7.1. Normative 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.
[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.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
7.2. Informative References 7.2. Informative References
[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.
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
URI: http://www.nic.at/ URI: http://www.nic.at/
 End of changes. 52 change blocks. 
186 lines changed or deleted 180 lines changed or added

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