draft-ietf-ecrit-lost-servicelistboundary-03.txt   draft-ietf-ecrit-lost-servicelistboundary-04.txt 
ECRIT K. Wolf ECRIT K. Wolf
Internet-Draft nic.at Internet-Draft nic.at
Intended status: Experimental February 26, 2010 Intended status: Experimental August 6, 2010
Expires: August 30, 2010 Expires: February 7, 2011
LoST Service List Boundary Extension LoST Service List Boundary Extension
draft-ietf-ecrit-lost-servicelistboundary-03 draft-ietf-ecrit-lost-servicelistboundary-04
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,
this document proposes a <serviceListBoundary> element that returns a this document proposes a Service List Boundary that returns a local
local context along with the list of services returned, in order to context along with the list of services returned, in order to assist
assist the client to not miss a change in available services when the client to not miss a change in available services when moving.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on February 7, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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
skipping to change at page 2, line 15 skipping to change at page 2, line 8
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 Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
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
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Extensions to <listServicesByLocation> . . . . . . . . . . 5 3.1. Extensions to <listServicesByLocation> . . . . . . . . . . 5
3.2. Retrieving the <serviceListBoundary> via 3.2. Retrieving the <serviceListBoundary> via
<getServiceListBoundary> . . . . . . . . . . . . . . . . . 8 <getServiceListBoundary> . . . . . . . . . . . . . . . . . 8
3.3. <serviceListBoundary> . . . . . . . . . . . . . . . . . . 9 3.3. <serviceListBoundary> . . . . . . . . . . . . . . . . . . 9
3.4. Implementation Considerations . . . . . . . . . . . . . . 10 3.4. Implementation Considerations . . . . . . . . . . . . . . 10
3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. Server Side . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 11 3.4.2. Client Side . . . . . . . . . . . . . . . . . . . . . 10
4. Security & Privacy Considerations . . . . . . . . . . . . . . 11 4. Security & Privacy Considerations . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 11 5.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 11
5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 13 5.2. Namespace Registration . . . . . . . . . . . . . . . . . . 14
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
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 6 skipping to change at page 5, line 6
emergency call may fail altogether. 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 a
specific Service List is valid for. The Service List may even change specific Service List is valid for. The Service List may even change
within the Service Boundary of another service. For example, the within the Service Boundary of another service. For example, the
ambulance mapping is valid for a whole state, but for a part of the ambulance mapping is valid for a whole state, but for a part of the
state there is an additional mountain rescue service. 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 ask for the Service List, although it may not o clients continuously poll for the Service List, although it may
have changed not have changed
o a boundary information (telling the client that the Service List o a boundary information (telling the client that the Service List
does not change inside this area) does not change inside this area)
Since the LoST protocol employs the Service Boundary concept in order Since the LoST protocol employs the Service Boundary concept in order
to avoid having clients continuously trying to refresh the mapping of to avoid having clients continuously trying to refresh the mapping of
a specific service, a Service List Boundary mechanism would provide a specific service, a Service List Boundary mechanism would provide
similar advantages for Service Lists. similar advantages for Service Lists.
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 modifications to the LoST This chapter describes the necessary extensions to the LoST protocol
protocol in order to support the proposed <serviceListBoundary> in a in order to support the proposed Service List Boundary in a similar
similar way as the <serviceBoundary>. way as the <serviceBoundary>. Extensions defined in this document
are declared in the new XML namespace
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 to be presented either in a by the resulting location for the list presented either by value or by
value or by reference form. In the example below the value of the reference. In the example below the value of 'type' attribute 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: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">
<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> <slb:serviceListBoundaryRequest type="value"/>
value
</slb:serviceListBoundaryRequest>
</listServicesByLocation> </listServicesByLocation>
A possible response is shown below: A <listServicesByLocationResponse> with the addition of one
<serviceListBoundary> elemenents 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:ns:lost1:slb">
<serviceList expires="2010-01-01T00:00:00Z"> <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
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"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="5415203asdf548"/> <locationUsed id="5415203asdf548"/>
<slb:serviceListBoundary profile="civic"> <slb:serviceListBoundary profile="civic"
<civicAddress xml:lang="en" expires="2012-01-01T00:00:00Z">
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <civicAddress xml:lang="en"
<country>AT</country> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<A1>Lower Austria</A1> <country>AT</country>
</civicAddress> <A1>Lower Austria</A1>
</slb:serviceListBoundary> </civicAddress>
</slb:serviceListBoundary>
</listServicesByLocationResponse> </listServicesByLocationResponse>
This response above indicates that the Service List is valid for This response above indicates that the Service List is valid for
Lower Austria. The <listServicesByLocation> request has to be Lower Austria. The <listServicesByLocation> request needs to be
repeated by the client only when moving out of Lower Austria. repeated by the client only when moving out of Lower Austria.
However, the mappings of the services itself may have other service However, the mappings of the services itself 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
alternative representation, each representing the boundary in a
specific location profile. However, multiple locations inside a
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 <serviceListBoundaryRequest> element to "reference". value of the 'type' attribute of the <serviceListBoundaryRequest>
Then the response contains a <serviceListBoundaryReference> element, element to "reference" (which is the default in case the attribute is
as shown below. omitted). Then the response contains a
<serviceListBoundaryReference> element with a 'serviceListKey'
attribute (described in Section 3.2), 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:schema:lost1:slb" xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">
<serviceList expires="2010-01-01T00:00:00Z"> <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
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"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="5415203asdf548"/> <locationUsed id="5415203asdf548"/>
<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 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 xmlns="urn:ietf:params:xml:ns:lost1" <getServiceListBoundary
serviceListKey="123567890123567890123567890"/> xmlns="urn:ietf:params:xml:ns:lost1:slb"
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:schema:lost1:slb"> xmlns="urn:ietf:params:xml:ns:lost1:slb">
<serviceListBoundary profile="civic" <serviceListBoundary profile="civic" expires="2012-01-01T00:00:00Z">
expires="2010-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> <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 '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> location profile the clients understands in a
request, this document also does not define one for the <getServiceListBoundary> request, this document also does not define
<getServiceListBoundary> request. one for the <getServiceListBoundary> request.
3.3. <serviceListBoundary> 3.3. <serviceListBoundary>
The <serviceListBoundary> information that gets returned, indicates The Service List Boundary information that gets returned indicates
the geographic region in which all the service identifiers returned the geographic region in which all the service identifiers returned
from a <serviceList> element are the same, within a from a <serviceList> element are the same, within a
<listServicesByLocation> query. A <serviceListBoundary> may consist <listServicesByLocation> query. 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 location
but has to use at least one profile that the client used in the profiles, but MUST use at least one profile that the client used in
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 to a
<listServicesResponse>. <ListServices> requests are purely for <listServicesResponse>. The <listServices> request is purely for
diagnostic purposes and do not contain location information at all, diagnostic purposes and does 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 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 - like it is
the case with the Service Boundary. However, especially for the case with the Service Boundary. However, especially for
emergency services, the <serviceListBoundary> might be crucial to emergency services, the Service List Boundary might be crucial to
ensure that moving clients do not miss changes in the available ensure that 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 serviceListBoundary support. server and client for the 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] 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.
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 additionally
add the <serviceListBoundary> as well. add the <serviceListBoundary> or <serviceListBoundaryReference> as
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 unneeded queries to the LoST server are the consequence, but
still the main purpose of the <serviceListBoundary> is achieved: still the main purpose of the Service List Boundary is achieved:
Never miss a change of available services. So a reasonable trade-off Never miss a change of available services. Thus, the server operator
between the effort to generate the boundary information and the saved may specify a reasonable trade-off between the effort to generate the
queries to the LoST server has to be considered. boundary information and the saved queries to the LoST server.
Probably for some countries the county (or disrict, canton, state, For example, in some countries the offered services may differ in
...) borders would be suitable as <serviceListBoundary>. Some adjacent counties (or districts, cantons, states, ...). Their
neighbouring counties may have implemented different services while a borders may be suitable as Service List Boundary as well, even though
<listServicesByLocation> query in other neighbouring counties still some adjacent counties offer the same services.
results in the same Service List. So when moving across a county
border, it is at least ensured, that every device fetches a new
Service List from the LoST server.
Other countries might have different structures and the generation of Other countries might have different structures and the generation of
the <serviceListBoundary> might follow other rules as long as it is the Service List Boundary might follow other rules as long as it is
ensured that a client is able to notice any change in the Service 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 <serviceListBoundary>. 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> has to location profiles), just the additional <serviceListBoundary> needs
be evaluated. Whenever moving outside a <serviceListBoundary>, the to be evaluated. Whenever moving outside a Service List Boundary,
client must perform 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 & 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.
5. IANA Considerations 5. IANA Considerations
This document requests two actions by IANA: a XML schema registration This document requests two actions by IANA: an XML schema
and namespace registration, according to the description in the registration and namespace registration, according to the description
following sections. in the following sections.
5.1. Relax NG Schema Registration 5.1. Relax NG Schema Registration
This document requests registration of the following Relax NG Schema This document requests registration of the following Relax NG Schema
to the IETF XML Registry [RFC3688]: to the IETF XML 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)
skipping to change at page 12, line 4 skipping to change at page 11, line 45
to the IETF XML Registry [RFC3688]: to the IETF XML 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
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="urn:ietf:params:xml:ns:lost1" <grammar
xmlns:slb="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:slb="urn:ietf:params:xml:ns:lost1:slb"
ns="urn:ietf:params:xml:ns:lost1"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<include href="lost.rng"> <include href="lost.rng">
<!-- redefinition of LoST elements --> <!-- redefinition of LoST elements -->
<start> <start>
<choice> <choice>
<ref name="findService"/> <ref name="findService"/>
<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"/>
skipping to change at page 12, line 23 skipping to change at page 12, line 22
<ref name="findService"/> <ref name="findService"/>
<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"/>
<ref name="slb:getServiceListBoundary"/>
<ref name="slb:getServiceListBoundaryResponse"/> <!-- New in RFCXXX -->
<ref name="getServiceListBoundary"/>
<ref name="getServiceListBoundaryResponse"/>
</choice> </choice>
</start> </start>
<define name="listServicesByLocation"> <define name="listServicesByLocation">
<element name="listServicesByLocation"> <element name="listServicesByLocation">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/> <ref name="commonRequestPattern"/>
<ref name="slb:serviceListBoundaryRequest"/> <optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
<!-- New in RFCXXXX -->
<optional>
<ref name="serviceListBoundaryRequest"/>
</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"/>
<choice> <!-- New in RFCXXXX -->
<ref name="slb:serviceListBoundaryResponse"/> <optional>
<ref name="slb:serviceListBoundaryReference"/> <choice>
</choice> <ref name="serviceListBoundary"/>
<ref name="serviceListBoundaryReference"/>
</choice>
</optional>
</element> </element>
</define> </define>
</include> </include>
<define name="serviceListBoundaryRequest"> <define name="serviceListBoundaryRequest">
<element name="serviceListBoundary"> <element name="slb:serviceListBoundaryRequest">
<ref name="slb:serviceListBoundary"/> <optional>
<choice> <attribute name="type">
<value>value</value> <choice>
<value>reference</value> <value>value</value>
</choice> <value>reference</value>
</element> </choice>
</define> <a:defaultValue>reference</a:defaultValue>
</attribute>
<define name="serviceListBoundaryResponse"> </optional>
<element name="serviceListBoundary"> </element>
<ref name="slb:serviceListBoundary"/> </define>
<attribute name="profile"/>
<ref name="locationInformation"/>
</element>
</define>
<define name="serviceListBoundaryReference">
<element name="serviceListBoundaryReference">
<ref name="slb:serviceListBoundaryReference"/>
<attribute name="source"/>
<attribute name="serviceListKey"/>
</element>
</define>
<define name="getServiceListBoundary"> <define name="serviceListBoundary">
<element name="getServiceListBoundary"> <oneOrMore>
<ref name="slb:getServiceListBoundary"/> <element name="slb:serviceListBoundary">
<attribute name="serviceListKey"/> <optional>
</element> <ref name="expires"/>
</define> </optional>
<ref name="locationInformation"/>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</define>
<define name="getServiceListBoundaryResponse"> <define name="serviceListBoundaryReference">
<element name="getServiceListBoundaryResponse"> <element name="slb:serviceListBoundaryReference">
<ref name="slb:getServiceListBoundaryResponse"/> <ref name="source"/>
<attribute name="serviceListKey"/> <attribute name="serviceListKey">
<ref name="slb:serviceListBoundary"/> <data type="token"/>
<ref name="path"/> </attribute>
</element> <ref name="extensionPoint"/>
</define> </element>
</define>
<define name="getServiceListBoundary">
<element name="slb:getServiceListBoundary">
<attribute name="serviceListKey">
<data type="token"/>
</attribute>
<ref name="extensionPoint"/>
</element>
</define>
<define name="getServiceListBoundaryResponse">
<element name="slb:getServiceListBoundaryResponse">
<ref name="serviceListBoundary"/>
<ref name="path"/>
<ref name="extensionPoint"/>
</element>
</define>
</grammar> </grammar>
END END
5.2. Namespace Registration 5.2. Namespace Registration
This document requests registration of the following namespace (below This document requests registration of the following namespace (below
the LoST namespace defined in [RFC5222]) to the IETF XML Registry the LoST namespace defined in [RFC5222]) to the IETF XML Registry
[RFC3688]: [RFC3688]:
URI: urn:ietf:params:xml:ns:lost1:slb URI: urn:ietf:params:xml:ns:lost1:slb
skipping to change at page 14, line 21 skipping to change at page 15, line 14
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"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>LoST serviceListBoundary 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/rfcXXXX.txt">
RFCXXXX</a>.</p> RFCXXXX</a>.</p>
</body> </body>
</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.
Further thanks go to Joshua Bell from the 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
 End of changes. 60 change blocks. 
177 lines changed or deleted 210 lines changed or added

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