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/