draft-ietf-ecrit-lost-05.txt		draft-ietf-ecrit-lost-06.txt
	ECRIT T. Hardie		ECRIT T. Hardie
	Internet-Draft Qualcomm, Inc.		Internet-Draft Qualcomm, Inc.
	Intended status: Standards Track A. Newton		Intended status: Standards Track A. Newton
	Expires: September 5, 2007 SunRocket		Expires: February 11, 2008 TranTech, Inc.
	H. Schulzrinne		H. Schulzrinne
	Columbia U.		Columbia University
	H. Tschofenig		H. Tschofenig
	Siemens Networks GmbH & Co KG		Nokia Siemens Networks
	March 4, 2007		August 10, 2007
	LoST: A Location-to-Service Translation Protocol		LoST: A Location-to-Service Translation Protocol
	draft-ietf-ecrit-lost-05.txt		draft-ietf-ecrit-lost-06.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 5, 2007.		This Internet-Draft will expire on February 11, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes an XML-based protocol for mapping service		This document describes an XML-based protocol for mapping service
	identifiers and geodetic or civic location information to service		identifiers and geodetic or civic location information to service
	contact URIs. In particular, it can be used to determine the		contact URIs. In particular, it can be used to determine the
	location-appropriate PSAP for emergency services.		location-appropriate PSAP for emergency services.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology and Requirements Notation . . . . . . . . . . . . 6		2. Terminology and Requirements Notation . . . . . . . . . . . . 6
	3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7		3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7
	4. LoST servers and Their Resolution . . . . . . . . . . . . . . 9		4. LoST Servers and Their Resolution . . . . . . . . . . . . . . 9
	5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 10		5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 10
	5.1. The Data Source: 'source', 'sourceId' and		5.1. The Mapping Data Source: 'source', 'sourceId' and
	'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10		'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10
	5.2. Validity: The 'expires' Attribute . . . . . . . . . . . . 10		5.2. Mapping Validity: The 'expires' Attribute . . . . . . . . 10
	5.3. Describing the Service with the <displayName> Element . . 11		5.3. Describing the Service with the <displayName> Element . . 11
	5.4. The Mapped Service: the <service> Element . . . . . . . . 11		5.4. The Mapped Service: the <service> Element . . . . . . . . 11
	5.5. Defining the Service Region with the <serviceBoundary>		5.5. Defining the Service Region with the <serviceBoundary>
	Element . . . . . . . . . . . . . . . . . . . . . . . . . 11		Element . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.6. Service Boundaries by Reference: the		5.6. Service Boundaries by Reference: the
	<serviceBoundaryReference> Element . . . . . . . . . . . . 12		<serviceBoundaryReference> Element . . . . . . . . . . . . 12
	5.7. The Service Number Element . . . . . . . . . . . . . . . . 13		5.7. The Service Number: the <serviceNumber> Element . . . . . 13
	5.8. Service URLs: the <uri> Element . . . . . . . . . . . . . 13		5.8. Service URLs: the <uri> Element . . . . . . . . . . . . . 13
	6. Path of a Request: <path> Element . . . . . . . . . . . . . . 14		6. Path of a Request: the <path> Element . . . . . . . . . . . . 14
	7. Mapping a Location and Service to URLs: <findService> . . . . 15		7. Identifying the Location Element Used for Mapping:
	7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15		<locationUsed> . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15		8. Mapping a Location and Service to URLs: <findService> . . . . 16
	7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 15		8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 16		8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.3. Components of the <findService> Request . . . . . . . . . 18		8.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 16
	7.3.1. The <location> Element . . . . . . . . . . . . . . . . 18		8.2.2. Civic Address Mapping Example . . . . . . . . . . . . 17
	7.3.2. Identifying the Service: The <service> Element . . . 19		8.3. Components of the <findService> Request . . . . . . . . . 19
	7.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 19		8.3.1. The <location> Element . . . . . . . . . . . . . . . . 19
	7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 19		8.3.2. Identifying the Service: The <service> Element . . . 20
	7.3.5. Requesting Civic Location Validation . . . . . . . . . 19		8.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 20
	7.4. Components of the Mapping Response		8.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 20
	<findServiceResponse> . . . . . . . . . . . . . . . . . . 21		8.3.5. Requesting Civic Location Validation . . . . . . . . . 20
	7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21		8.4. Components of the Mapping Response
	7.4.2. Civic Address Validation: the		<findServiceResponse> . . . . . . . . . . . . . . . . . . 22
	<locationValidation> Element . . . . . . . . . . . . . 22		8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
	8. Retrieving the Service Boundary via <getServiceBoundary> . . . 23		8.4.2. Civic Address Validation: the
	9. List Services: <listServices> . . . . . . . . . . . . . . . . 26		<locationValidation> Element . . . . . . . . . . . . . 23
	10. List Services By Location: <listServicesByLocation> . . . . . 27		9. Retrieving the Service Boundary via <getServiceBoundary> . . . 24
	11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 29		10. List Services: <listServices> . . . . . . . . . . . . . . . . 27
	11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 30		11. List Services By Location: <listServicesByLocation> . . . . . 28
	11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 33		12. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 30
	11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 34		12.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 31
	12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 35		12.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 34
	12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 35		12.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 35
	12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 36		13. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 37
	12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 37		13.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 38		13.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 39
	14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 39		13.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 40
	15. Internationalization Considerations . . . . . . . . . . . . . 46		14. LoST Transport: HTTP . . . . . . . . . . . . . . . . . . . . . 42
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47		15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43
	16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 47		16. Internationalization Considerations . . . . . . . . . . . . . 50
	16.2. Content-type registration for 'application/lost+xml' . . . 47		17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
	16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 49		17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51
	16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 49		17.2. Content-type registration for 'application/lost+xml' . . . 51
	16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 50		17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53
	17. Security Considerations . . . . . . . . . . . . . . . . . . . 51		17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53
	18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52		17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54
	19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 54		18. Security Considerations . . . . . . . . . . . . . . . . . . . 55
	20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55		19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56
	20.1. Normative References . . . . . . . . . . . . . . . . . . . 55		20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
	20.2. Informative References . . . . . . . . . . . . . . . . . . 56		20.1. Normative References . . . . . . . . . . . . . . . . . . . 58
	Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 57		20.2. Informative References . . . . . . . . . . . . . . . . . . 59
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70		Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 60
	Intellectual Property and Copyright Statements . . . . . . . . . . 71		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74
			Intellectual Property and Copyright Statements . . . . . . . . . . 75
	1. Introduction		1. Introduction
	Numerous techniques have been specified for the discovery of servers		Protocols such as NAPTR records and the Service Location Protocol
	for a particular service, including NAPTR records, SVRLOC and similar		(SLP) can be used to discover servers offering a particular service.
	protocols. However, there are an important class of services where		However, for an important class of services the appropriate specific
	the specific service instance that is to be connected to depends on		service instance depends both on the identity of the service and the
	the identity of the service and the location of the entity that needs		geographic location of the entity that needs to reach it. Emergency
	to reach it. An example of this is emergency telecommunications		telecommunications services are an important example; here, the
	services, where the service instance is a Public Safety Answering		service instance is a Public Safety Answering Point (PSAP) that has
	Point (PSAP) that has jurisdiction over the location of the user		jurisdiction over the location of the user making the call. The
	making the call. Here, the desired PSAP isn't necessarily the one		desired PSAP isn't necessarily the one that is topologically or even
	that is topologically or even line-of-sight closest to the caller;		line-of-sight closest to the caller; rather, it is the one that
	rather, it is the one that serves the callers location based on		serves the callers location based on jurisdictional boundaries.
	geopolitical boundaries. For this reason, the selected service
	instance is a function of location and the desired service.
	This document describes a protocol for mapping a service identifier		This document describes a protocol for mapping a service identifier
	[9] and location information compatible with PIDF-LO [6], namely		(service URNs) [9] and location information compatible with PIDF-LO
	revised civic location information [10] and GML [12]) to one or more		[6], namely revised civic location information [10] and a subset of
	service URL. Example service URL schemes include sip [14], xmpp		the PIDF-LO profile [13] and consequently with the Geo-Shapes [12]
	[15], and tel [16]. While the initial focus is on providing mapping		defined for GML [11]) to one or more service URLs. Example service
	functions for emergency services, it is likely that the protocol is		URL schemes include sip [14], xmpp [15], and tel [16]. While the
	applicable to any service URN. For example, in the United States,		initial focus is on providing mapping functions for emergency
	the "2-1-1" and "3-1-1" service numbers follow a similar location-to-		services, it is likely that the protocol is applicable to other
	service behavior as emergency services.		service URNs. For example, in the United States, the "2-1-1" and
			"3-1-1" service numbers follow a similar location-to-service behavior
			as emergency services.
	This document names this protocol "LoST", for Location-to-Service		This document names this protocol "LoST", for Location-to-Service
	Translation. LoST Satisfies the requirements [18] for mapping		Translation. LoST Satisfies the requirements [18] for mapping
	protocols. LoST provides a number of operations, centered around		protocols. LoST provides a number of operations, centered around
	mapping locations and service URNs to service URLs and associated		mapping locations and service URNs to service URLs and associated
	information. LoST mapping queries can contain either civic or		information. LoST mapping queries can contain either civic or
	geodetic location information. For civic addresses, LoST can		geodetic location information. For civic addresses, LoST can
	indicate which parts of the civic address are known to be valid or		indicate which parts of the civic address are known to be valid or
	invalid, thus providing address validation (see Section 3.5 of [18]		invalid, thus providing address validation, as described in Section
	for a description of validation). LoST indicates errors in the		3.5 of [18]. LoST indicates errors in the location data to
	location data to facilitate debugging and proper user feedback, but		facilitate debugging and proper user feedback, but also provides
	also provides best-effort answers.		best-effort answers.
	LoST queries can be resolved recursively or iteratively. To minimize		LoST queries can be resolved recursively or iteratively. To minimize
	round trips and to provide robustness against network failures, LoST		round trips and to provide robustness against network failures, LoST
	supports caching of individual mappings and indicates the region for		supports caching of individual mappings and indicates the region for
	which the same answer would be returned ("service region").		which the same answer would be returned ("service region").
	As defined in this document, LoST messages are carried in HTTP and		As defined in this document, LoST messages are carried in HTTP and
	HTTPS protocol exchanges, facilitating use of TLS for protecting the		HTTPS protocol exchanges, facilitating use of TLS for protecting the
	integrity and confidentiality of requests and responses.		integrity and confidentiality of requests and responses.
	skipping to change at page 5, line 18		skipping to change at page 5, line 18
	The query message carries location information and a service		The query message carries location information and a service
	identifier encoded as a Uniform Resource Name (URN) (see [9]) from		identifier encoded as a Uniform Resource Name (URN) (see [9]) from
	the LoST client to the LoST server. The LoST server uses its		the LoST client to the LoST server. The LoST server uses its
	database to map the input values to one or more Uniform Resource		database to map the input values to one or more Uniform Resource
	Identifiers (URI) and returns those URIs along with optional		Identifiers (URI) and returns those URIs along with optional
	information, such as hints about the service boundary, in a response		information, such as hints about the service boundary, in a response
	message to the LoST client. If the server cannot resolve the query		message to the LoST client. If the server cannot resolve the query
	itself, it may in turn query another server or return the address of		itself, it may in turn query another server or return the address of
	another LoST server, identified by a LoST server name. In addition		another LoST server, identified by a LoST server name. In addition
	to the mapping function described in Section 7, the protocol also		to the mapping function described in Section 8, the protocol also
	allows to retrieve the service boundary (see Section 8) and to list		allows to retrieve the service boundary (see Section 9) and to list
	the services available for a particular location (see Section 10) or		the services available for a particular location (see Section 11) or
	supported by a particular server (see Section 9).		supported by a particular server (see Section 10).
	2. Terminology and Requirements Notation		2. Terminology and Requirements Notation
	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 [1].		document are to be interpreted as described in [1].
	This document uses the following terms:		This document uses the following terms:
	Mapping:		Mapping: Mapping is a process that takes a location and a service
			identifier as inputs and returns one or more URIs. Those URIs can
	Mapping is a process that takes a location and a service		either point to a host providing that service or to a host that in
	identifier as inputs and returns one or more URIs that point to a		turn routes the request to the final destination. This definition
	host providing that service or acting as an intermediary to
	establish communication with the serving entity. This definition
	is a generalization of the term "mapping" as used in [18], because		is a generalization of the term "mapping" as used in [18], because
	of the potential for LoST to be used for non-emergency services.		LoST can be used for non-emergency services.
	LoST Client and Server:		LoST client: A host acts as a LoST client if it sends LoST query
			messages and receives LoST response messages.
	"LoST client" is the role played by an entity that sends LoST		LoST server: A host acts as a LoST server if it receives LoST query
	query messages and receives LoST response messages. "LoST server"		messages and sends LoST response messages. In recursive
	is the role played by an entity that receives LoST query messages		operation, the same entity may be both a client and a server.
	and sends LoST response messages. In recursive operation, the
	same entity may play both roles. This document also uses the term
	"authoritative server" to designate an entity that acts in the
	LoST server role only and successfully resolves the input location
	and service identifier to a URI or set of URIs.
	Service Boundary:		Authoritative LoST server: An authoritative server acts only as a
			server and successfully resolves the input location and service
			identifier to a URI or set of URIs.
	A service boundary is the boundary or set of boundaries of a		Service boundary: A service boundary circumscribes the region within
	geographic region, respectively set of geographic regions, within		which all locations map to the same service URI or set of URIs for
	which all locations will map to the same URI or set of URIs for a		a given service. A service boundary may consist of several non-
	given service.		contiguous geometric shapes.
	Validation:		Validation:
	The term "validation" as used in this document is a concrete		The term "validation" describes the behavior defined as "location
	realization of the term "location validation" as defined in		validation" in Section 3.5 of [18].
	Section 3.5 of [18].
	Additional emergency service terminology can be found in [18].		Additional emergency service terminology can be found in [18].
	3. Overview of Protocol Usage		3. Overview of Protocol Usage
	The LoST protocol supports the following type of queries and		The LoST protocol supports the following type of queries and
	responses:		responses:
	<findService> and <findServiceResponse>		<findService> and <findServiceResponse>
	This message pattern allows to perform retrieve contact URIs based		A LoST client retrieves contact URIs based on location information
	on location information together with a service identifier. The		and a service identifier with this request and response. The same
	same query type may also ask for location validation and for		query type may also ask for location validation and for service
	service numbers, either integrated into mapping request or		numbers, either combined with a mapping request or separately.
	separately. The details can be found in Section 7 and		The details can be found in Section 8 and Section 8.4.
	Section 7.4.
	<getServiceBoundary> and <getServiceBoundaryResponse>		<getServiceBoundary> and <getServiceBoundaryResponse>
	This message pattern allows query for a service boundary. The		A LoST client obtains a service boundary with this request and
	details can be found in Section 8.		response, as described in Section 9.
	<listServices> and <listServicesResponse>		<listServices> and <listServicesResponse>
	This message pattern enables a LoST client to ask a LoST server		With this request and response, a LoST client can find out which
	for the services it supports. The details can be found in		services a LoST server supports, as described in Section 10.
	Section 9.
	<listServicesByLocation> and <listServicesByLocationResponse>		<listServicesByLocation> and <listServicesByLocationResponse>
	This message pattern provides the LoST client with the services		A LoST client can determine with this request and response which
	that are available for a specific location region. The details		services are available for a specific location region. Section 11
	can be found in Section 10.		describes the details.
	LoST clients may initiate any of the above queries at any time.		LoST clients may initiate any of the above queries at any time.
	Among the common triggers are:		Among the common triggers are:
	1. When the client initially starts up or attaches to a network.		1. When the client initially starts up or attaches to a network;
	2. When the client detects that its location has changed		2. when the client detects that its location has changed
	sufficiently that it is outside the bounds of the service region.		sufficiently that it is outside the bounds of the service region;
	3. An incoming message at a SIP proxy in a location-based routing		3. when a SIP message arrives at a SIP proxy performing location-
	scenario that requires a routing decision to be made.		based call routing;
	4. When cached mapping information has expired.		4. when cached mapping information has expired;
	5. When invoking a particular service. At that time, a client may		5. when invoking a particular service. At that time, a client may
	omit requests for service boundaries or other auxiliary		omit requests for service boundaries or other auxiliary
	information.		information.
	A service-specific Best Current Practice (BCP) document, such as		A service-specific Best Current Practice (BCP) document, such as
	[20], governs whether a client is expected to invoke the mapping		[20], governs whether a client is expected to invoke the mapping
	service just before needing the service or whether to rely on cached		service just before needing the service or whether to rely on cached
	answers. Cache entries expire at their expiration time (see		answers. Cache entries expire at their expiration time (see
	Section 5.2), or they become invalid if the caller's device moves		Section 5.2), or they become invalid if the caller's device moves
	beyond the boundaries of the service region.		beyond the boundaries of the service region.
	4. LoST servers and Their Resolution		4. LoST Servers and Their Resolution
	LoST servers are identified by U-NAPTR/DDDS [11] application unique
	strings, in the form of a DNS name.
	An example is 'lostserver.example.com'		LoST servers are identified by U-NAPTR/DDDS [8] application unique
			strings, in the form of a DNS name. An example is
			'lostserver.example.com'.
	Clients need to use the U-NAPTR [11] specification described below to		Clients need to use the U-NAPTR [8] specification described below to
	obtain a URI (indicating host and protocol) for the applicable LoST		obtain a URI (indicating host and protocol) for the applicable LoST
	service. In this document, only the HTTP and HTTPS URL schemes are		service. In this document, only the HTTP and HTTPS URL schemes are
	defined. Note that the HTTP URL can be any valid HTTP URL, including		defined. Note that the HTTP URL can be any valid HTTP URL, including
	those containing path elements.		those containing path elements.
	The following two DNS entries show the U-NAPTR resolution for		The following two DNS entries show the U-NAPTR resolution for
	"example.com" to the HTTPS URL https://lostserv.example.com/secure or		"example.com" to the HTTPS URL https://lostserv.example.com/secure or
	the HTTP URL http://lostserver.example.com, with the former being		the HTTP URL http://lostserver.example.com, with the former being
	preferred.		preferred.
	skipping to change at page 10, line 11		skipping to change at page 10, line 11
	Clients learn the LoST server's host name by means beyond the scope		Clients learn the LoST server's host name by means beyond the scope
	of this specification, such as SIP configuration and DHCP.		of this specification, such as SIP configuration and DHCP.
	5. The <mapping> Element		5. The <mapping> Element
	The <mapping> element is the core data element in LoST, describing a		The <mapping> element is the core data element in LoST, describing a
	service region and the associated service URLs. Its attributes and		service region and the associated service URLs. Its attributes and
	elements are described in subsections below.		elements are described in subsections below.
	5.1. The Data Source: 'source', 'sourceId' and 'lastUpdated' Attributes		5.1. The Mapping Data Source: 'source', 'sourceId' and 'lastUpdated'
			Attributes
	The 'source', the 'sourceId' and the 'lastUpdated' attributes		The 'source', the 'sourceId' and the 'lastUpdated' attributes
	uniquely identify a particular mapping record. They are created by		uniquely identify a particular mapping record. They are created by
	the authoritative source for a mapping and never modified when a		the authoritative source for a mapping and are never modified when a
	mapping is served from a cache. All three attributes are REQUIRED		mapping is served from a cache. All three attributes are REQUIRED
	for all <mapping> elements. A receiver can replace a mapping with		for all <mapping> elements. A receiver can replace a mapping with
	another one having the same 'source' and 'sourceId' and a more recent		another one having the same 'source' and 'sourceId' and a more recent
	datum in 'lastUpdated'.		time in 'lastUpdated'.
	The 'source' attribute contains a LoST application unique string		The 'source' attribute contains a LoST application unique string
	identifying the authoritative generator of the mapping. See		identifying the authoritative generator of the mapping (Section 4).
	Section 4.
	The 'sourceId' attribute identifies a particular mapping and contains		The 'sourceId' attribute identifies a particular mapping and contains
	an opaque token that MUST be unique among all different mappings		an opaque token that MUST be unique among all different mappings
	maintained by the authoritative source for that particular service.		maintained by the authoritative source for that particular service.
	For example, a Universally Unique Identifier (UUID) is a suitable		For example, a Universally Unique Identifier (UUID) is a suitable
	format.		format.
	The 'lastUpdated' attribute describes when a specific instance of		The 'lastUpdated' attribute describes when a specific instance of
	mapping, identified by the combination of 'source' and 'sourceId',		mapping, identified by the combination of 'source' and 'sourceId',
	was last changed. The contents of this attribute has the XML data		was last changed. The contents of this attribute has the XML data
	type dateTime in its timezoned form, using canonical UTC		type dateTime in its timezoned form, using canonical UTC
	representation with the letter 'Z' as the timezone indicator.		representation with the letter 'Z' as the timezone indicator.
	5.2. Validity: The 'expires' Attribute		5.2. Mapping Validity: The 'expires' Attribute
	The 'expires' attribute contains the absolute time at which the		The 'expires' attribute contains the absolute time at which the
	mapping becomes invalid. The contents of this attribute is a		mapping becomes invalid. The contents of this attribute is a
	timezoned XML type dateTime, in canonical representation. See		timezoned XML type dateTime, in canonical representation. See
	Section 3 regarding how this value is to be utilized with a cache.		Section 3 regarding how this value is to be utilized with a cache.
	The 'expires' attribute is REQUIRED to be included in the <mapping>		The 'expires' attribute is REQUIRED to be included in the <mapping>
	element.		element.
	Optionally, this attribute may contain the values of 'NO-CACHE' and		Optionally, this attribute may contain the values of 'NO-CACHE' and
	'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is		'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is
	skipping to change at page 11, line 10		skipping to change at page 11, line 10
	'NO-EXPIRATION' is an indication that the mapping does not expire.		'NO-EXPIRATION' is an indication that the mapping does not expire.
	On occasion, a server may be forced to return an expired mapping if		On occasion, a server may be forced to return an expired mapping if
	it cannot reach the authoritative server or the server fails to		it cannot reach the authoritative server or the server fails to
	return a usable answer. Clients and servers MAY cache the mapping so		return a usable answer. Clients and servers MAY cache the mapping so
	that they have at least some information available. Caching servers		that they have at least some information available. Caching servers
	that have such stale information SHOULD re-attempt the query each		that have such stale information SHOULD re-attempt the query each
	time a client requests a mapping. Since the expired mapping will be		time a client requests a mapping. Since the expired mapping will be
	returned to the client as a non-error/non-warning response it is the		returned to the client as a non-error/non-warning response it is the
	responsibility of the client to check the 'expires' attribute		responsibility of the client to check the 'expires' attribute
	associated with mapping data returned in a LoST response to detemine		associated with mapping data returned in a LoST response to determine
	whether the mapping is fresh.		whether the mapping is fresh.
	5.3. Describing the Service with the <displayName> Element		5.3. Describing the Service with the <displayName> Element
	Zero or more <displayName> elements describe the service with a		Zero or more <displayName> elements describe the service with a
	string that is suitable for display to human users, each annotated		string that is suitable for display to human users, each annotated
	with the 'xml:lang' attribute that contains a language tag to aid in		with the 'xml:lang' attribute that contains a language tag to aid in
	the rendering of text.		the rendering of text.
	5.4. The Mapped Service: the <service> Element		5.4. The Mapped Service: the <service> Element
	The <service> element identifies the service for which this mapping		The mandatory <service> element identifies the service for which this
	applies. Two cases need to be distinguished when the LoST server		mapping applies. Two cases need to be distinguished when the LoST
	sets the <service> element in the response message:		server sets the <service> element in the response message:
	1. If the requested service, identified by the service URN [9] in		1. If the requested service, identified by the service URN [9] in
	the <service> element of the request, exists for the location		the <service> element of the request, exists for the location
	indicated, then the LoST server puts the service URN from the		indicated, then the LoST server copies the service URN from the
	request into the <service> element.		request into the <service> element.
	2. If, however, the requested service, identified by the service URN		2. If, however, the requested service, identified by the service URN
	[9] in the <service> element in the request, does not exist for		[9] in the <service> element in the request, does not exist for
	the location indicated, the server can either return an		the location indicated, the server can either return an
	<serviceNotImplemented> (Section 12.1) error or can provide an		<serviceNotImplemented> (Section 13.1) error or can provide an
	alternate service that approximates the desired service for that		alternate service that approximates the desired service for that
	location. In the latter case, the server MUST include a		location. In the latter case, the server MUST include a
	<service> element with the alternative service URN. The choice		<service> element with the alternative service URN. The choice
	of service URN is left to local policy, but the alternate service		of service URN is left to local policy, but the alternate service
	should be able to satisfy the original service request.		should be able to satisfy the original service request.
	The <service> element is optional but may also be required if the
	mapping is to be digitally signed.
	5.5. Defining the Service Region with the <serviceBoundary> Element		5.5. Defining the Service Region with the <serviceBoundary> Element
	A response MAY indicate the region for which the service URL returned		A response MAY indicate the region for which the service URL returned
	would be the same as in the actual query, the so-called _service		would be the same as in the actual query, the so-called _service
	region_. The service region can be indicated by value or by		region_. The service region can be indicated by value or by
	reference (see Section 5.6). If a client moves outside the service		reference (see Section 5.6). If a client moves outside the service
	area and wishes to obtain current service data, it sends a new query		area and wishes to obtain current service data, it sends a new query
	with its current location. The service region is described by value		with its current location. The service region is described by value
	in one or more <serviceBoundary> elements, each formatted according		in one or more <serviceBoundary> elements, each formatted according
	to a different location profile, identified by the 'profile' atribute		to a specific location profile, identified by the 'profile' attribute
	(see Section 11). If included in a response, the <serviceBoundary>		(see Section 12). serviceBoundary elements formatted according to
	element MUST contain at least one service boundary that uses the same		different location profiles are alternative representations of the
	profile as the request. The client only processes the first element		same area, not additive to one another; this allows a client
	that it can understand according to its list of supported location		understanding only one of the profile types to be sure it has a
	profiles. Thus, elements with geospatial coordinates are alternative		complete view of the serviceBoundary. Within a serviceBoundary
	descriptions of the same service region, not additive geometries.		element there may, however, be multiple locations which _are_
			additive; this is necessary because some serviceBoundary areas could
			not be easily expressed with a single shape or civic location. If
			included in a response, the <serviceBoundary> element MUST contain at
			least one service boundary that uses the same profile as the request.
	A service boundary is requested by the client (using the		A service boundary is requested by the client, using the
	'serviceBoundary' attribute in the request with the value set to		'serviceBoundary' attribute in the request with the value set to
	"value").		"value".
	A response MAY contain more than one <serviceBoundary> element with
	profile 'civic'. Each <serviceBoundary> element describes a set of
	civic addresses that fall within the service boundary, namely all
	addresses that textually match the civic address elements provided,
	regardless of the value of other address elements. A location falls
	within the mapping's service boundary if it matches any of the
	<serviceBoundary> elements.
	5.6. Service Boundaries by Reference: the <serviceBoundaryReference>		5.6. Service Boundaries by Reference: the <serviceBoundaryReference>
	Element		Element
	Since geodetic service boundaries may contain thousands of points and		Since geodetic service boundaries may contain thousands of points and
	thus be quite large, clients may opt to conserve bandwidth and		can thus be quite large, clients may wish to conserve bandwidth by
	request a reference to the service boundary instead of the value		requesting a reference to the service boundary instead of the value
	described in Section 5.5. The identifier of the service boundary is		described in Section 5.5. The identifier of the service boundary is
	returned as an attribute of the <serviceBoundaryReference> element,		returned as an attribute of the <serviceBoundaryReference> element,
	along with a LoST application unique string (see Section 4)		along with a LoST application unique string (see Section 4)
	identifying the server from where it can be retrieved. The actual		identifying the server from where it can be retrieved. The actual
	value of the service boundary is then retrieved with the		value of the service boundary is then retrieved with the
	getServiceBoundary (Section 8) request.		getServiceBoundary (Section 9) request.
	A reference to a service boundary is requested by the client (using		A reference to a service boundary is requested by the client (using
	the 'serviceBoundary' attribute in the request with the value set to		the 'serviceBoundary' attribute in the request with the value set to
	"reference"). A LoST server may decide, based on local policy, to		"reference"). A LoST server may decide, based on local policy, to
	return the service boundary per value or to omit the		return the service boundary per value or to omit the
	<serviceBoundaryReference> element in the response.		<serviceBoundaryReference> element in the response.
	The identifier is a random token with at least 128 bits of entropy		The identifier is a random token with at least 128 bits of entropy
	and can be assumed to be globally unique. It uniquely references a		and can be assumed to be globally unique. It uniquely references a
	particular boundary. If the boundary changes, a new identifier MUST		particular boundary. If the boundary changes, a new identifier MUST
	be chosen. Because of these properties, a client receiving a mapping		be chosen. Because of these properties, a client receiving a mapping
	response can simply check if it already has a copy of the boundary		response can simply check if it already has a copy of the boundary
	with that identifier. If so, it can skip checking with the server		with that identifier. If so, it can skip checking with the server
	whether the boundary has been updated. Since service boundaries are		whether the boundary has been updated. Since service boundaries are
	likely to remain unchanged for extended periods of time, possibly		likely to remain unchanged for extended periods of time, possibly
	exceeding the normal lifetime of the service URL, this approach		exceeding the normal lifetime of the service URL, this approach
	avoids unnecessarily refreshing the boundary information just because		avoids unnecessarily refreshing the boundary information just because
	the the remainder of the mapping has become invalid.		the remainder of the mapping has become invalid.
	5.7. The Service Number Element		5.7. The Service Number: the <serviceNumber> Element
	The service number is returned in the optional <serviceNumber>		The service number is returned in the optional <serviceNumber>
	element. It contains a string of digits, * and # that a user on a		element. It contains a string of digits, * and # that a user on a
	device with a 12-key dial pad could use to reach that particular		device with a 12-key dial pad could use to reach that particular
	service.		service.
	5.8. Service URLs: the <uri> Element		5.8. Service URLs: the <uri> Element
	The response returns the service URLs in one or more <uri> elements.		The response returns the service URLs in one or more <uri> elements.
	The URLs MUST be absolute URLs. The ordering of the URLs has no		The URLs MUST be absolute URLs. The ordering of the URLs has no
	particular significance. Each URL scheme MUST only appear at most		particular significance. Each URL scheme MUST only appear at most
	once, but it is permissible to include both secured and regular		once, but it is permissible to include both secured and regular
	versions of a protocol, such as both 'http' and 'https' or 'sip' and		versions of a protocol, such as both 'http' and 'https' or 'sip' and
	'sips'.		'sips'.
	6. Path of a Request: <path> Element		6. Path of a Request: the <path> Element
	To prevent loops and to allow tracing of request and response paths,		To prevent loops and to allow tracing of request and response paths,
	all requests that allow recursion include a <path> element that		all requests that allow recursion include a <path> element that
	contains one or more <via> elements, each possessing an attribute		contains one or more <via> elements, each possessing an attribute
	containing a LoST application unique string (see Section 4). The		containing a LoST application unique string (see Section 4). The
	order of <via> elements corresponds to the order of LoST servers,		order of <via> elements corresponds to the order of LoST servers,
	i.e., the first <via> element identifies the server that initially		i.e., the first <via> element identifies the server that initially
	received the request from the client issuing the request. The <via>		received the request from the client issuing the request. The <via>
	element is inserted logically on receipt of the request, so that		element is inserted logically on receipt of the request, so that
	every server in a recursive query operation is included in the <path>		every server in a recursive query operation is included in the <path>
	element.		element.
	The server that answers the request instead of forwarding it, such as		The server that answers the request instead of forwarding it, such as
	the authoritative server, copies the <path> element verbatim into the		the authoritative server, copies the <path> element verbatim into the
	response. The <path> element is not modified in responses as the		response. The <path> element is not modified in responses as the
	responses traverses the server chain back to the querying client.		responses traverses the server chain back to the querying client.
	If a query is answered iteratively, the querier includes all servers		If a query is answered iteratively, the querier includes all servers
	that it has already contacted.		that it has already contacted.
			When a cached mapping is returned then the <path> element cached
			together with the mapping is returned.
	The example in Figure 5 indicates that the answer was given to the		The example in Figure 5 indicates that the answer was given to the
	client by the LoST server at esgw.ueber-110.de.example, which got the		client by the LoST server at esgw.ueber-110.de.example, which got the
	answer from the (authoritative) LoST server at		answer from the (authoritative) LoST server at
	polizei.muenchen.de.example.		polizei.muenchen.de.example.
	7. Mapping a Location and Service to URLs: <findService>		7. Identifying the Location Element Used for Mapping: <locationUsed>
	7.1. Overview		Several of the requests can provide one or more <location> elements,
			among which the server gets to choose. It is useful for the client
			to be able to determine which one was actually used in producing the
			result. For that purpose, the <location> tag MUST contain an 'id'
			attribute that uniquely identifies the <location> element. The
			format of the identifier is left to the client; it could, for
			example, use a hash of the location information. The server returns
			the identifier for the <location> element it used in the
			<locationUsed> tag.
			8. Mapping a Location and Service to URLs: <findService>
			8.1. Overview
	The <findService> query constitutes the core of the LoST		The <findService> query constitutes the core of the LoST
	functionality, mapping civic or geodetic locations to URLs and		functionality, mapping civic or geodetic locations to URLs and
	associated data. After giving an example, we enumerate the elements		associated data. After giving an example, we enumerate the elements
	of the query and response.		of the query and response.
	7.2. Examples		8.2. Examples
	7.2.1. Example Using Geodetic Coordinates		8.2.1. Example Using Geodetic Coordinates
	The following is an example of mapping a service to a location using		The following is an example of mapping a service to a location using
	geodetic coordinates, for the service associated with the police		geodetic coordinates, for the service associated with the police
	(urn:service:sos.police).		(urn:service:sos.police).
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findService		<findService
	xmlns="urn:ietf:params:xml:ns:lost1"		xmlns="urn:ietf:params:xml:ns:lost1"
	xmlns:p2="http://www.opengis.net/gml"		xmlns:p2="http://www.opengis.net/gml"
	serviceBoundary="value"		serviceBoundary="value"
	recursive="true">		recursive="true">
	<location profile="geodetic-2d">		<location id="6020688f1ce1896d" profile="geodetic-2d">
	<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">		<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
	<p2:pos>37.775 -122.422</p2:pos>		<p2:pos>37.775 -122.422</p2:pos>
	</p2:Point>		</p2:Point>
	</location>		</location>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	</findService>		</findService>
	Figure 2: A <findService> geodetic query		Figure 2: A <findService> geodetic query
	Given the query above, a server would respond with a service, and		Given the query above, a server would respond with a service, and
	information related to that service. In the example below, the		information related to that service. In the example below, the
	server has mapped the location given by the client for a police		server has mapped the location given by the client for a police
	service to the New York City Police Deparment, instructing the client		service to the New York City Police Department, instructing the
	that it may contact them via the URIs "sip:nypd@example.com" and		client that it may contact them via the URIs "sip:nypd@example.com"
	"xmpp:nypd@example.com". The server has also given the client a		and "xmpp:nypd@example.com". The server has also given the client a
	geodetic, two-dimensional boundary for this service. The mapping was		geodetic, two-dimensional boundary for this service. The mapping was
	last updated on November 1, 2006 and expires on January 1, 2007. If		last updated on November 1, 2006 and expires on January 1, 2007. If
	the client's location changes beyond the given service boundary or		the client's location changes beyond the given service boundary or
	the expiration time has been reached, it may want to requery for this		the expiration time has been reached, it may want to requery for this
	information, depending on the usage environment of LoST.		information, depending on the usage environment of LoST.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"		<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
	xmlns:p2="http://www.opengis.net/gml">		xmlns:p2="http://www.opengis.net/gml">
	<mapping		<mapping
	expires="2007-01-01T01:44:33Z"		expires="2007-01-01T01:44:33Z"
	lastUpdated="2006-11-01T01:00:00Z"		lastUpdated="2006-11-01T01:00:00Z"
	source="authoritative.example"		source="authoritative.example"
	sourceId="7e3f40b098c711dbb6060800200c9a66" version="1">		sourceId="7e3f40b098c711dbb6060800200c9a66">
	<displayName xml:lang="en">		<displayName xml:lang="en">
	New York City Police Department		New York City Police Department
	</displayName>		</displayName>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	<serviceBoundary profile="geodetic-2d">		<serviceBoundary profile="geodetic-2d">
	<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">		<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
	<p2:exterior>		<p2:exterior>
	<p2:LinearRing>		<p2:LinearRing>
	<p2:pos>37.775 -122.4194</p2:pos>		<p2:pos>37.775 -122.4194</p2:pos>
	<p2:pos>37.555 -122.4194</p2:pos>		<p2:pos>37.555 -122.4194</p2:pos>
	skipping to change at page 16, line 35		skipping to change at page 17, line 35
	<p2:pos>37.775 -122.4194</p2:pos>		<p2:pos>37.775 -122.4194</p2:pos>
	</p2:LinearRing>		</p2:LinearRing>
	</p2:exterior>		</p2:exterior>
	</p2:Polygon>		</p2:Polygon>
	</serviceBoundary>		</serviceBoundary>
	<uri>sip:nypd@example.com</uri>		<uri>sip:nypd@example.com</uri>
	<uri>xmpp:nypd@example.com</uri>		<uri>xmpp:nypd@example.com</uri>
	<serviceNumber>911</serviceNumber>		<serviceNumber>911</serviceNumber>
	</mapping>		</mapping>
	<path>		<path>
	<via source="authoritative.example"/>
	<via source="resolver.example"/>		<via source="resolver.example"/>
			<via source="authoritative.example"/>
	</path>		</path>
			<locationUsed id="6020688f1ce1896d"/>
	</findServiceResponse>		</findServiceResponse>
	Figure 3: A <findServiceResponse> geodetic answer		Figure 3: A <findServiceResponse> geodetic answer
	7.2.2. Civic Address Mapping Example		8.2.2. Civic Address Mapping Example
	The following is an example of mapping a service to a location much		The example below shows how to map a service to a location much like
	like the example in Section 7.2.1, but using civic address location		the example in Section 8.2.1, but using civic address location
	information. In this example, the client requests the service		information. In this example, the client requests the service
	associated with police (urn:service:sos.police) along with a specific		associated with police (urn:service:sos.police) along with a specific
	civic address (house number 6 on a street named Otto-Hahn-Ring in		civic address (house number 6 on a street named Otto-Hahn-Ring in
	Munich, Germany).		Munich, Germany).
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findService xmlns="urn:ietf:params:xml:ns:lost1"		<findService xmlns="urn:ietf:params:xml:ns:lost1"
	recursive="true" serviceBoundary="value">		recursive="true" serviceBoundary="value">
	<location		<location id="627b8bf819d0bad4d" profile="civic">
	profile="civic">
	<civicAddress		<civicAddress
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">		xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
	<country>Germany</country>		<country>Germany</country>
	<A1>Bavaria</A1>		<A1>Bavaria</A1>
	<A3>Munich</A3>		<A3>Munich</A3>
	<A6>Otto-Hahn-Ring</A6>		<A6>Otto-Hahn-Ring</A6>
	<HNO>6</HNO>		<HNO>6</HNO>
	<PC>81675</PC>		<PC>81675</PC>
	</civicAddress>		</civicAddress>
	</location>		</location>
	skipping to change at page 18, line 11		skipping to change at page 19, line 11
	January 1, 2007. This instructs the client to requery for the		January 1, 2007. This instructs the client to requery for the
	information if its location changes beyond the given service boundary		information if its location changes beyond the given service boundary
	(i.e., beyond the city of Munich) or after January 1, 2007.		(i.e., beyond the city of Munich) or after January 1, 2007.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">		<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
	<mapping		<mapping
	expires="2007-01-01T01:44:33Z"		expires="2007-01-01T01:44:33Z"
	lastUpdated="2006-11-01T01:00:00Z"		lastUpdated="2006-11-01T01:00:00Z"
	source="esgw.ueber-110.de.example"		source="esgw.ueber-110.de.example"
	sourceId="e8b05a41d8d1415b80f2cdbb96ccf109" version="1" >		sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
	<displayName xml:lang="de">		<displayName xml:lang="de">
	Muenchen Polizei-Abteilung		Muenchen Polizei-Abteilung
	</displayName>		</displayName>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	<serviceBoundary		<serviceBoundary
	profile="urn:ietf:params:lost:location-profile:basic-civic">		profile="urn:ietf:params:lost:location-profile:basic-civic">
	<civicAddress		<civicAddress
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">		xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
	<country>Germany</country>		<country>Germany</country>
	<A1>Bavaria</A1>		<A1>Bavaria</A1>
	skipping to change at page 18, line 34		skipping to change at page 19, line 34
	</civicAddress>		</civicAddress>
	</serviceBoundary>		</serviceBoundary>
	<uri>sip:munich-police@example.com</uri>		<uri>sip:munich-police@example.com</uri>
	<uri>xmpp:munich-police@example.com</uri>		<uri>xmpp:munich-police@example.com</uri>
	<serviceNumber>110</serviceNumber>		<serviceNumber>110</serviceNumber>
	</mapping>		</mapping>
	<path>		<path>
	<via source="esgw.ueber-110.de.example"/>		<via source="esgw.ueber-110.de.example"/>
	<via source="polizei.muenchen.de.example"/>		<via source="polizei.muenchen.de.example"/>
	</path>		</path>
			<locationUsed id="627b8bf819d0bad4d"/>
	</findServiceResponse>		</findServiceResponse>
	Figure 5: A <findServiceResponse> civic address answer		Figure 5: A <findServiceResponse> civic address answer
	7.3. Components of the <findService> Request		8.3. Components of the <findService> Request
	The <findService> request includes attributes that govern whether the		The <findService> request includes attributes that govern whether the
	request is handled iteratively or recursively, whether location		request is handled iteratively or recursively, whether location
	validation is performed and which elements may be contained in the		validation is performed and which elements may be contained in the
	response.		response.
	7.3.1. The <location> Element		8.3.1. The <location> Element
	The <findService> query communicates location information using one		The <findService> query communicates location information using one
	or more <location> elements, which MUST conform to a location profile		or more <location> elements, which MUST conform to a location profile
	(see Section 11). There MUST NOT be more than one location element		(see Section 12). There MUST NOT be more than one location element
	for each distinct location profile. The order of location objects is		for each distinct location profile. The order of location elements
	significant; the server uses the first location object where it		is significant; the server uses the first location element where it
	understands the location profile.		understands the location profile.
	7.3.2. Identifying the Service: The <service> Element		8.3.2. Identifying the Service: The <service> Element
	The type of service desired is specified by the <service> element.		The type of service desired is specified by the <service> element.
	It contains service URNs from the registry established in [9].		It contains service URNs from the registry established in [9].
	7.3.3. Recursion and Iteration		8.3.3. Recursion and Iteration
	LoST can operate in either recursive or iterative mode, on a request-		LoST can operate in either recursive or iterative mode, on a request-
	by-request basis. In recursive mode, the LoST server initiates		by-request basis. In recursive mode, the LoST server initiates
	queries on behalf of the requester and returns the result to the		queries on behalf of the requester and returns the result to the
	requester.		requester.
	In iterative mode, the server contacted returns a redirection		In iterative mode, the server contacted returns a redirection
	response indicating the next server to be queried.		response indicating the next server to be queried if the server
			contacted cannot provide an answer itself.
	For the queries defined in this document, only LoST <findService> and		For the queries defined in this document, only LoST <findService> and
	<listServicesByLocation> queries can be recursive, as indicated by		<listServicesByLocation> queries can be recursive, as indicated by
	the 'recursive' attribute. A value of "true" indicates a recursive		the 'recursive' attribute. A value of "true" indicates a recursive
	query, with the default being "false" when the attribute is omitted.		query, with the default being "false" when the attribute is omitted.
	Regardless of the attribute, a server MAY always answer a query by		Regardless of the attribute, a server MAY always answer a query by
	providing a LoST application unique string (see Section 4), i.e.,		providing a LoST application unique string (see Section 4), i.e.,
	indirection, however, it MUST NOT recurse if the attribute is		indirection, however, it MUST NOT recurse if the attribute is
	"false".		"false".
	7.3.4. Service Boundary		8.3.4. Service Boundary
	LoST <mapping> elements can describe the service boundary either by		LoST <mapping> elements can describe the service boundary either by
	value or by reference. Returning a service boundary reference is		value or by reference. Returning a service boundary reference is
	generally more space-efficient for geospatial (polygon) boundaries		generally more space-efficient for geospatial (polygon) boundaries
	and if the boundaries change rarely, but does incur an additional		and if the boundaries change rarely, but does incur an additional
	<getServiceBoundary> request. The querier can express a preference		<getServiceBoundary> request. The querier can express a preference
	for one or the other modality with the 'serviceBoundary' attribute in		for one or the other modality with the 'serviceBoundary' attribute in
	the <findService> request, but the server makes the final decision as		the <findService> request, but the server makes the final decision as
	to whether to return a reference or a value.		to whether to return a reference or a value.
	7.3.5. Requesting Civic Location Validation		8.3.5. Requesting Civic Location Validation
	Civic address validation is requested by setting the optional		Civic address validation is requested by setting the optional
	attribute 'validateLocation' to true. If the attribute is omitted,		attribute 'validateLocation' to true. If the attribute is omitted,
	it is assumed to be false. The response is described in		it is assumed to be false. The response is described in
	Section 7.4.2. The example in Figure 6 demonstrates address		Section 8.4.2. The example in Figure 6 demonstrates address
	validation, omitting the standard response elements.		validation. If the server chooses a geodetic location among the
			locations provided in a request, the attribute is ignored.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findService		<findService
	xmlns="urn:ietf:params:xml:ns:lost1"		xmlns="urn:ietf:params:xml:ns:lost1"
	recursive="true"		recursive="true"
	validateLocation="true"		validateLocation="true"
	serviceBoundary="value">		serviceBoundary="value">
	<location profile="civic">		<location id="627b8bf819d0bad4d" profile="civic">
	<civicAddress		<civicAddress
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">		xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
	<country>DE</country>		<country>DE</country>
	<A1>Bavaria</A1>		<A1>Bavaria</A1>
	<A3>Munich</A3>		<A3>Munich</A3>
	<A6>Otto-Hahn-Ring</A6>		<A6>Otto-Hahn-Ring</A6>
	<HNO>6</HNO>		<HNO>6</HNO>
	<PC>81675</PC>		<PC>81675</PC>
	</civicAddress>		</civicAddress>
	</location>		</location>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	</findService>		</findService>
	Figure 6: A <findService> query with address validation request		Figure 6: A <findService> query with address validation request
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">		<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
	<mapping		<mapping
	expires="2007-01-01T01:44:33Z"		expires="2007-01-01T01:44:33Z"
	lastUpdated="2006-11-01T01:00:00Z"		lastUpdated="2006-11-01T01:00:00Z"
	source="authoritative.example"		source="authoritative.example"
	sourceId="4db898df52b84edfa9b6445ea8a0328e"		sourceId="4db898df52b84edfa9b6445ea8a0328e">
	version="1" >
	<displayName xml:lang="de">		<displayName xml:lang="de">
	Muenchen Polizei-Abteilung		Muenchen Polizei-Abteilung
	</displayName>		</displayName>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	<serviceBoundary profile="civic">		<serviceBoundary profile="civic">
	<civicAddress		<civicAddress
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">		xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
	<country>Germany</country>		<country>Germany</country>
	<A1>Bavaria</A1>		<A1>Bavaria</A1>
	<A3>Munich</A3>		<A3>Munich</A3>
	<PC>81675</PC>		<PC>81675</PC>
	</civicAddress>		</civicAddress>
	</serviceBoundary>		</serviceBoundary>
	<uri>sip:munich-police@example.com</uri>		<uri>sip:munich-police@example.com</uri>
	<uri>xmpp:munich-police@example.com</uri>		<uri>xmpp:munich-police@example.com</uri>
	<serviceNumber>110</serviceNumber>		<serviceNumber>110</serviceNumber>
	</mapping>		</mapping>
	<locationValidation>		<locationValidation>
	<valid>country A1 A3 A6</valid>		<valid>country A1 A3 A6</valid>
	<invalid>PC</invalid>		<invalid>PC</invalid>
			<unchecked>HNO</unchecked>
	</locationValidation>		</locationValidation>
	<path>		<path>
	<via source="authoritative.example"/>
	<via source="resolver.example"/>		<via source="resolver.example"/>
			<via source="authoritative.example"/>
	</path>		</path>
			<locationUsed id="627b8bf819d0bad4d"/>
	</findServiceResponse>		</findServiceResponse>
	Figure 7: A <findServiceResponse> message with address validation		Figure 7: A <findServiceResponse> message with address validation
	information		information
	7.4. Components of the Mapping Response <findServiceResponse>		8.4. Components of the Mapping Response <findServiceResponse>
	7.4.1. Overview		8.4.1. Overview
	Mapping responses consist of the <mapping> element (Section 5)		Mapping responses consist of the <mapping> element (Section 5)
	describing the mapping itself, possibly followed by warnings		describing the mapping itself, possibly followed by warnings
	(Section 12.2), location validation information (Section 7.4.2), and		(Section 13.2), location validation information (Section 8.4.2), and
	an indication of the path (Section 6) the response has taken.		an indication of the path (Section 6) the response has taken.
	7.4.2. Civic Address Validation: the <locationValidation> Element		8.4.2. Civic Address Validation: the <locationValidation> Element
	A server can indicate in its response which civic address elements it		A server can indicate in its response which civic address elements it
	has recognized as valid, which ones it has ignored and which ones it		has recognized as valid, which ones it has ignored and which ones it
	has checked and found to be invalid. The server SHOULD include this		has checked and found to be invalid. The server SHOULD include this
	information if the 'validateLocation' attribute in the request was		information if the 'validateLocation' attribute in the request was
	true but local policy at the server may allow this information to be		true but local policy at the server may allow this information to be
	omitted. Each element contains a list of tokens separated by white		omitted. Each element contains a list of tokens separated by white
	space, enumerating the civic location lables used in child elements		space, enumerating the civic location labels used in child elements
	of the <civicAddress> element. The <valid> element enumerates those		of the <civicAddress> element. The <valid> element enumerates those
	civic address elements that have been recognized as valid by the LoST		civic address elements that have been recognized as valid by the LoST
	server and that have been used to determine the mapping. The		server and that have been used to determine the mapping. The
	<unchecked> elements enumerates the civic address elements that the		<unchecked> elements enumerates the civic address elements that the
	server did not check and that were not used in determining the		server did not check and that were not used in determining the
	response. The <invalid> element enumerate civic address elements		response. The <invalid> element enumerate civic address elements
	that the server attempted to check, but that did not match the other		that the server attempted to check, but that did not match the other
	civic address elements found in the <valid> list.		civic address elements found in the <valid> list. Civic location
			tokens that are neither listed in the <valid>, the <invalid> and the
			<unchecked> element belong to the class of unchecked tokens.
	Note that the same address can yield different responses if parts of		Note that the same address can yield different responses if parts of
	the civic address contradict each other. For example, if the postal		the civic address contradict each other. For example, if the postal
	code does not match the city, local server policy determines whether		code does not match the city, local server policy determines whether
	the postal code or the city is considered valid. The mapping		the postal code or the city is considered valid. The mapping
	naturally corresponds to the valid elements.		naturally corresponds to the valid elements.
	The example (Figure 6) indicates that the tokens 'country', 'A1',		The example shown in Figure 6 and in Figure 7 indicates that the
	'A3', and 'A6' have been validated by the LoST server. The server		tokens 'country', 'A1', 'A3', and 'A6' have been validated by the
	considered the postal code 81675 in the <PC> element as not valid for		LoST server. The server considered the postal code 81675 in the <PC>
	this location.		element as not valid for this location. The 'HNO' token belongs to
			the class of unchecked location tokens.
	8. Retrieving the Service Boundary via <getServiceBoundary>		9. Retrieving the Service Boundary via <getServiceBoundary>
	As discussed in Section 5.5, the <findServiceResponse> can return a		As discussed in Section 5.5, the <findServiceResponse> can return a
	globally unique identifier in the 'serviceBoundary' attribute that		globally unique identifier in the 'serviceBoundary' attribute that
	can be used to retrieve the service boundary, rather than returning		can be used to retrieve the service boundary, rather than returning
	the boundary by value. This is shown in the example in Figure 8.		the boundary by value. This is shown in the example in Figure 8 and
	The client can then retrieve the boundary using the		Figure 9. The client can then retrieve the boundary using the
	<getServiceBoundary> request and obtains the boundary in the		<getServiceBoundary> request and obtains the boundary in the
	<getServiceBoundaryResponse>, illustrated in the example in		<getServiceBoundaryResponse>, illustrated in the example in
	Figure 10. The client issues the request to the server identified in		Figure 10. The client issues the request to the server identified in
	the 'server' attribute of the <serviceBoundaryReference> element.		the 'server' attribute of the <serviceBoundaryReference> element.
	These requests are always directed to the authoritative server and do		These requests are always directed to the authoritative server and do
	not recurse.		not recurse.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findService		<findService
	xmlns="urn:ietf:params:xml:ns:lost1"		xmlns="urn:ietf:params:xml:ns:lost1"
	xmlns:p2="http://www.opengis.net/gml"		xmlns:p2="http://www.opengis.net/gml"
	recursive="true"		recursive="true"
	serviceBoundary="reference">		serviceBoundary="reference">
	<location profile="geodetic-2d">		<location id="6020688f1ce1896d" profile="geodetic-2d">
	<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">		<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
	<p2:pos>37.775 -122.422</p2:pos>		<p2:pos>37.775 -122.422</p2:pos>
	</p2:Point>		</p2:Point>
	</location>		</location>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	</findService>		</findService>
	Figure 8: <findService> request and response with service boundary		Figure 8: <findService> request and response with service boundary
	reference		reference
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"		<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
	xmlns:p2="http://www.opengis.net/gml">		xmlns:p2="http://www.opengis.net/gml">
	<mapping		<mapping
	expires="2007-01-01T01:44:33Z"		expires="2007-01-01T01:44:33Z"
	lastUpdated="2006-11-01T01:00:00Z"		lastUpdated="2006-11-01T01:00:00Z"
	source="authoritative.example"		source="authoritative.example"
	sourceId="7e3f40b098c711dbb6060800200c9a66"		sourceId="7e3f40b098c711dbb6060800200c9a66">
	version="1">
	<displayName xml:lang="en">		<displayName xml:lang="en">
	New York City Police Department		New York City Police Department
	</displayName>		</displayName>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	<serviceBoundaryReference		<serviceBoundaryReference
	source="authoritative.example"		source="authoritative.example"
	key="7214148E0433AFE2FA2D48003D31172E" />		key="7214148E0433AFE2FA2D48003D31172E" />
	<uri>sip:nypd@example.com</uri>		<uri>sip:nypd@example.com</uri>
	<uri>xmpp:nypd@example.com</uri>		<uri>xmpp:nypd@example.com</uri>
	<serviceNumber>911</serviceNumber>		<serviceNumber>911</serviceNumber>
	</mapping>		</mapping>
	<path>		<path>
	<via source="authoritative.example"/>
	<via source="resolver.example"/>		<via source="resolver.example"/>
			<via source="authoritative.example"/>
	</path>		</path>
			<locationUsed id="6020688f1ce1896d"/>
	</findServiceResponse>		</findServiceResponse>
	Figure 9: <findServiceResponse> message with service boundary		Figure 9: <findServiceResponse> message with service boundary
	reference		reference
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"		<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
	key="7214148E0433AFE2FA2D48003D31172E"/>		key="7214148E0433AFE2FA2D48003D31172E"/>
	Figure 10: Requesting a service boundary with <getServiceBoundary>		Figure 10: Requesting a service boundary with <getServiceBoundary>
	The <getServiceBoundary> request may also be used to retrieve service		The <getServiceBoundary> request may also be used to retrieve service
	boundaries that are expressed as civic addresses, as illustrated in		boundaries that are expressed as civic addresses, as illustrated in
	Figure 11.		Figure 11.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<getServiceBoundaryResponse		<getServiceBoundaryResponse
	xmlns="urn:ietf:params:xml:ns:lost1">		xmlns="urn:ietf:params:xml:ns:lost1">
	<serviceBoundary		<serviceBoundary profile="civic">
	profile="civic">
	<civicAddress		<civicAddress
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">		xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
	<country>US</country>		<country>US</country>
	<A1>New York</A1>		<A1>New York</A1>
	<A3>New York</A3>		<A3>New York</A3>
	</civicAddress>		</civicAddress>
	</serviceBoundary>		</serviceBoundary>
	<path>		<path>
	<via source="authoritative.example"/>
	<via source="resolver.example"/>		<via source="resolver.example"/>
			<via source="authoritative.example"/>
	</path>		</path>
	</getServiceBoundaryResponse>		</getServiceBoundaryResponse>
	Figure 11: Civic Address Service Boundary Response		Figure 11: Civic Address Service Boundary Response
	9. List Services: <listServices>		10. List Services: <listServices>
	A LoST client can ask a LoST server for the list of services that it		A LoST client can ask a LoST server for the list of services that it
	understands, primarily for diagnostic purposes. The query does not		understands, primarily for diagnostic purposes. The query does not
	contain location information, as it simply provides an indication of		contain location information, as it simply provides an indication of
	which services the server can look up, not whether a particular		which services the server can look up, not whether a particular
	service is offered for a particular area. Typically, only top-level		service is offered for a particular area. Typically, only top-level
	services are included in the answer, implying support for all sub-		services are included in the answer, implying support for all sub-
	services. Since the query is answered by the queried server, there		services. Since the query is answered by the queried server, there
	is no notion of recursion or indirection and no path indication. The		is no notion of recursion or indirection and no path indication. The
	<listServicesByLocation (Section 10) query below can be used to find		<listServicesByLocation> (Section 11) query below can be used to find
	out whether a particular service is offered for a specific location.		out whether a particular service is offered for a specific location.
	An example request and response are shown in Figure 12.		An example request and response are shown in Figure 12.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<listServices		<listServices
	xmlns="urn:ietf:params:xml:ns:lost1">		xmlns="urn:ietf:params:xml:ns:lost1">
	<service>urn:service:sos</service>		<service>urn:service:sos</service>
	</listServices>		</listServices>
	Figure 12: Example of <ListServices> query		Figure 12: Example of <ListServices> query
	skipping to change at page 27, line 5		skipping to change at page 28, line 5
	urn:service:sos.marine		urn:service:sos.marine
	urn:service:sos.physician		urn:service:sos.physician
	urn:service:sos.poison		urn:service:sos.poison
	urn:service:sos.police		urn:service:sos.police
	urn:service:sos.suicide		urn:service:sos.suicide
	</serviceList>		</serviceList>
	</listServicesResponse>		</listServicesResponse>
	Figure 13: Example of <ListServiceResponse>		Figure 13: Example of <ListServiceResponse>
	10. List Services By Location: <listServicesByLocation>		11. List Services By Location: <listServicesByLocation>
	A LoST client can ask a LoST server for the list of services it knows		A LoST client can ask a LoST server for the list of services it knows
	about for a particular area. The <listServicesByLocation> query		about for a particular area. The <listServicesByLocation> query
	contains one or more <location> elements, each from a different		contains one or more <location> elements, each from a different
	location profile (Section 11), and may contain the <service> element.		location profile (Section 12), and may contain the <service> element.
	As for <findService>, the server selects the first location element		As for <findService>, the server selects the first location element
	that has a profile the server understands and it can operate either		that has a profile the server understands and it can operate either
	recursively or iteratively; < via> elements track the progress of the		recursively or iteratively; < via> elements track the progress of the
	request. By its nature, the query can only indicate the services		request. The query indicates the services that the server can
	that a particular server can determine, not all possible services		enumerate from within the forest structure of which it is a part.
	that might be offered. Unlike <ListServices>, the answer describes		Because LoST does not presume a single, overarching organization of
	the services available at a specific location, not just those		all potential service types, there may be services available within a
	understood by the server.		geographic area which could be described by other LoST servers
			connected to other forest structures. As an example, the emergency
			services forest for a region may be distinct from the forests that
			locate commercial services within the same region
	If the query contains the <service> element, the LoST server returns		If the query contains the <service> element, the LoST server returns
	only immediate child services of the queried service that are		only immediate child services of the queried service that are
	available for the provided location. If the <service> element is		available for the provided location. If the <service> element is
	absent, the LoST service returns all top-level services available for		absent, the LoST service returns all top-level services available for
	the provided location that it knows about.		the provided location that it knows about.
	A server responds to this query with a		A server responds to this query with a
	<listServicesByLocationResponse> response. This response MAY contain		<listServicesByLocationResponse> response. This response MAY contain
	<via> elements (see Section 6) and MUST contain a <serviceList>		<via> elements (see Section 6) and MUST contain a <serviceList>
	element, consisting of a whitespace-separated list of service URNs.		element, consisting of a whitespace-separated list of service URNs.
	The query and response are illustrated in Figure 14 and in Figure 15,		The query and response are illustrated in Figure 14 and in Figure 15,
	respectively.		respectively.
	<?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:p2="http://www.opengis.net/gml"		xmlns:p2="http://www.opengis.net/gml"
	recursive="true">		recursive="true">
	<location profile="geodetic-2d">		<location id="3e19dfb3b9828c3" profile="geodetic-2d">
	<p2:Point srsName="urn:ogc:def:crs:EPSG::4326">		<p2:Point srsName="urn:ogc:def:crs:EPSG::4326">
	<p2:pos>-34.407 150.883</p2:pos>		<p2:pos>-34.407 150.883</p2:pos>
	</p2:Point>		</p2:Point>
	</location>		</location>
	<service>urn:service:sos</service>		<service>urn:service:sos</service>
	</listServicesByLocation>		</listServicesByLocation>
	Figure 14: Example of <ListServicesbyLocation> query		Figure 14: Example of <ListServicesbyLocation> query
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<listServicesByLocationResponse		<listServicesByLocationResponse
	skipping to change at page 28, line 20		skipping to change at page 29, line 20
	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.marine		urn:service:sos.marine
	urn:service:sos.physician		urn:service:sos.physician
	urn:service:sos.poison		urn:service:sos.poison
	urn:service:sos.police		urn:service:sos.police
	urn:service:sos.suicide		urn:service:sos.suicide
	</serviceList>		</serviceList>
	<path>		<path>
	<via source="authoritative.example"/>
	<via source="resolver.example"/>		<via source="resolver.example"/>
			<via source="authoritative.example"/>
	</path>		</path>
			<locationUsed id="3e19dfb3b9828c3"/>
	</listServicesByLocationResponse>		</listServicesByLocationResponse>
	Figure 15: Example of <ListServices> response		Figure 15: Example of <ListServices> response
	11. Location Profiles		12. Location Profiles
	LoST uses location information in <location> elements in requests and		LoST uses location information in <location> elements in requests and
	<serviceBoundary> elements in responses. Such location information		<serviceBoundary> elements in responses. Such location information
	may be expressed in a variety of ways. This variety can cause		may be expressed in a variety of ways. This variety can cause
	interoperability problems where a request or response contains		interoperability problems where a request or response contains
	location information in a format not understood by the server or the		location information in a format not understood by the server or the
	client, respectively. To achieve interoperability, this document		client, respectively. To achieve interoperability, this document
	defines two mandatory-to-implement baseline location profiles to		defines two mandatory-to-implement baseline location profiles to
	define the manner in which location information is transmitted. It		define the manner in which location information is transmitted. It
	possible to standardize other profiles in the future. The two		is possible to standardize other profiles in the future. The three
	baseline profiles are:		baseline profiles are:
	geodetic-2d:		geodetic-2d:
	a simple profile for two-dimensional geodetic location		a profile for two-dimensional geodetic location information, as
	information, as described in Section 11.2;		described in Section 12.2;
	civic:		civic:
	a profile consisting of civic address location information, as		a profile consisting of civic address location information, as
	described in Section 11.3.		described in Section 12.3.
	Requests and responses containing <location> or <serviceBoundary>		Requests and responses containing <location> or <serviceBoundary>
	elements MUST contain location information in exactly one of the two		elements MUST contain location information in exactly one of the two
	baseline profiles, in addition to zero or more additional profiles.		baseline profiles, in addition to zero or more additional profiles.
	The ordering of location information indicates a preference on the		The ordering of location information indicates a preference on the
	part of the sender.		part of the sender.
	Standards action is required for defining new profiles. A location		Standards action is required for defining new profiles. A location
	profile MUST define:		profile MUST define:
	skipping to change at page 30, line 5		skipping to change at page 31, line 5
	3. The formal definition of the XML to be used in responses, i.e.,		3. The formal definition of the XML to be used in responses, i.e.,
	an enumeration and definition of the XML child elements of the		an enumeration and definition of the XML child elements of the
	<serviceBoundary> element;		<serviceBoundary> element;
	4. The declaration of whether geodetic-2d or civic is to be used as		4. The declaration of whether geodetic-2d or civic is to be used as
	the baseline profile. It is necessary to explicitly declare the		the baseline profile. It is necessary to explicitly declare the
	baseline profile as future profiles may be combinations of		baseline profile as future profiles may be combinations of
	geodetic and civic location information.		geodetic and civic location information.
	11.1. Location Profile Usage		12.1. Location Profile Usage
	A location profile is identified by a token in an IANA-maintained		A location profile is identified by a token in an IANA-maintained
	registry (Section 16.5). Clients send location information compliant		registry (Section 17.5). Clients send location information compliant
	with a location profile, and servers respond with location		with a location profile, and servers respond with location
	information compliant with that same location profile.		information compliant with that same location profile.
	When a LoST client sends a <findService> request that provides		When a LoST client sends a <findService> request that provides
	location information, it includes one or more <location> elements. A		location information, it includes one or more <location> elements. A
	<location> element carries a mandatory 'profile' attribute that		<location> element carries an optional 'profile' attribute that
	indicates the location format of the child elements. The concept of		indicates the location format of the child elements. A client may
	location profiles are described in Section 11. With the ability to		obtain location information that does not conform to a profile it
	specify more than one <location> element the client is able to convey		recognizes or it may not have the capability to map XML to profiles.
	location information for multiple location profiles in the same		In that case, a client MAY omit the profile attribute and the server
	request.		should interpret the XML location data to the best of its ability,
			returning a "locationProfileUnrecognized" error if it is unable to do
			so.
			The concept of location profiles are described in Section 12. With
			the ability to specify more than one <location> element the client is
			able to convey location information for multiple location profiles in
			the same request.
	When a LoST server sends a response that contains location		When a LoST server sends a response that contains location
	information, it uses the <serviceBoundary> elements much like the		information, it uses the <serviceBoundary> elements much like the
	client uses the <location> elements. Each <serviceBoundary> element		client uses the <location> elements. Each <serviceBoundary> element
	contains location information conformant to the location profile		contains location information conforming to the location profile
	specified in the 'profile' attribute. When multiple <location>		specified in the 'profile' attribute. A response MAY contain
	elements are included then it enables the server to send location		multiple mappings or boundaries for the different <location>
	information compliant with multiple location profiles.		elements, subject to the restrictions below.
	Using the location profiles defined in this document, the following		Using the location profiles defined in this document, the following
	rules insure basic interoperatiblity between clients and servers:		rules ensure interoperability between clients and servers:
	1. A client MUST be capable of understanding the response for the		1. A client MUST be capable of understanding the response for the
	baseline profiles it used in the request.		baseline profiles it used in the request.
	2. If a client sends location information conformant to any location		2. If a client sends location information conformant to any location
	profile other than geodetic-2d or civic, it MUST also send, in		profile other than the ones described in this document, it MUST
	the same request, location information conformant to one of the		also send, in the same request, location information conformant
	baseline profiles. Otherwise, the server might not be able to		to one of the baseline profiles. Otherwise, the server might not
	understand the request.		be able to understand the request.
	3. A client SHOULD NOT send multiple <location> profiles of derived		3. A client MUST NOT send multiple <location> objects that are
	from different baseline profiles. Or said another way, a client		derived from different baseline profiles. In other words, a
	should only send location profiles from the same baseline profile		client MUST only send location objects according to the same
	in the same query. If a client has location information		baseline profile in a query, but it MAY contain a location
	primarily of geodetic nature and location information primarily		element following a baseline profile in addition to some other
	of a civic nature, it should send separate requests containing		profile.
	each type of location information.
	4. There can only be one instance of each location profile in a		4. If a client has both location information primarily of geodetic
			nature and location information primarily of a civic nature, it
			MUST send separate requests containing each type of location
			information.
			5. There can only be one instance of each location profile in a
	query.		query.
	5. Servers MUST implement the geodetic-2d and civic profiles.		6. Servers MUST implement all profiles described in this document.
	6. A server uses the first-listed location profile that it		7. A server uses the first-listed location profile that it
	understands and ignores the others.		understands and ignores the others.
	7. If a server receives a request that only contains location		8. If a server receives a request that only contains location
	information using profiles it does not understand, the server		information using profiles it does not understand, the server
	responds with a <locationProfileError> (Section 12.1).		responds with a <locationProfileError> (Section 13.1).
	8. The <serviceBoundary> element MUST use the same location profile		9. The <serviceBoundary> element MUST use the same location profile
	that was used to retrieve the answer and indicates which profile		that was used to retrieve the answer and indicates which profile
	has been used with the 'profile' attribute.		has been used with the 'profile' attribute.
	These rules enable the use of location profiles not yet specified,		These rules enable the use of location profiles not yet specified,
	while ensuring baseline interoperability. Take, for example, this		while ensuring baseline interoperability. Take, for example, this
	scenario. Client X has had its firmware upgraded to support the		scenario. Client X has had its firmware upgraded to support the
	uber-complex-3D location profile. Client X sends location		'not-yet-standardized-prism-profile' location profile. Client X
	information to Server Y, which does not understand the		sends location information to Server Y, which does not understand the
	uber-complex-3D location profile. If Client X also sends location		'not-yet-standardized-prism-profile' location profile. If Client X
	information using the geodetic-2D baseline profile, then Server Y		also sends location information using the geodetic-2D baseline
	will still be able to understand the request and provide an		profile, then Server Y will still be able to understand the request
	understandable response, though with location information that might		and provide an understandable response, though with location
	not be as precise or expressive as desired. This is possible because		information that might not be as precise or expressive as desired.
	both Client X and Server Y understand the baseline profile.		This is possible because both Client X and Server Y understand the
			baseline profile.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findService		<findService
	xmlns="urn:ietf:params:xml:ns:lost1"		xmlns="urn:ietf:params:xml:ns:lost1"
	xmlns:p2="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
			xmlns:gs="http://www.opengis.net/pidflo/1.0"
	recursive="true"		recursive="true"
	serviceBoundary="value">		serviceBoundary="value">
	<location profile="uber-complex-3d">		<location profile="not-yet-standardized-prism-profile">
	<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">		<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
	<p2:pos>37.775 -122.422</p2:pos>		<gs:base>
	</p2:Point>		<gml:Polygon>
	<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">		<gml:exterior>
	<p2:exterior>		<gml:LinearRing>
	<p2:LinearRing>		<gml:posList>
	<p2:pos>37.775 -122.4194</p2:pos>		42.556844 -73.248157 36.6
	<p2:pos>37.555 -122.4194</p2:pos>		42.656844 -73.248157 36.6
	<p2:pos>37.555 -122.4264</p2:pos>		42.656844 -73.348157 36.6
	<p2:pos>37.775 -122.4264</p2:pos>		42.556844 -73.348157 36.6
	<p2:pos>37.775 -122.4194</p2:pos>		42.556844 -73.248157 36.6
	</p2:LinearRing>		</gml:posList>
	</p2:exterior>		</gml:LinearRing>
	</p2:Polygon>		</gml:exterior>
	<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">		</gml:Polygon>
	<p2:pos>-122.422 37.775</p2:pos>		</gs:base>
	</p2:Point>		<gs:height uom="urn:ogc:def:uom:EPSG::9001">
			2.4
			</gs:height>
			</gs:Prism>
	</location>		</location>
	<location profile="geodetic-2d">		<location profile="geodetic-2d">
	<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">		<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
	<p2:pos>37.775 -122.422</p2:pos>		<gml:pos>42.656844 -73.348157</gml:pos>
	</p2:Point>		</gml:Point>
	</location>		</location>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	</findService>		</findService>
	Figure 16: Example of a <findServices> query with baseline profile		Figure 16: Example of a <findServices> query with baseline profile
	interoperability		interoperability
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findServiceResponse		<findServiceResponse
	xmlns="urn:ietf:params:xml:ns:lost1"		xmlns="urn:ietf:params:xml:ns:lost1"
	xmlns:p2="http://www.opengis.net/">		xmlns:p2="http://www.opengis.net/">
	<mapping		<mapping
	expires="2007-01-01T01:44:33Z"		expires="2007-01-01T01:44:33Z"
	lastUpdated="2006-11-01T01:00:00Z"		lastUpdated="2006-11-01T01:00:00Z"
	source="authoritative.example"		source="authoritative.example"
	sourceId="cf19bbb038fb4ade95852795f045387d"		sourceId="cf19bbb038fb4ade95852795f045387d">
	version="1">
	<displayName xml:lang="en">		<displayName xml:lang="en">
	New York City Police Department		New York City Police Department
	</displayName>		</displayName>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	<serviceBoundary profile="geodetic-2d">		<serviceBoundary profile="geodetic-2d">
	<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">		<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
	<p2:exterior>		<p2:exterior>
	<p2:LinearRing>		<p2:LinearRing>
	<p2:pos>37.775 -122.4194</p2:pos>		<p2:pos>37.775 -122.4194</p2:pos>
	<p2:pos>37.555 -122.4194</p2:pos>		<p2:pos>37.555 -122.4194</p2:pos>
	<p2:pos>37.555 -122.4264</p2:pos>		<p2:pos>37.555 -122.4264</p2:pos>
	<p2:pos>37.775 -122.4264</p2:pos>		<p2:pos>37.775 -122.4264</p2:pos>
	<p2:pos>37.775 -122.4194</p2:pos>		<p2:pos>37.775 -122.4194</p2:pos>
	</p2:LinearRing>		</p2:LinearRing>
	</p2:exterior>		</p2:exterior>
	</p2:Polygon>		</p2:Polygon>
	</serviceBoundary>		</serviceBoundary>
	<uri>sip:nypd@example.com</uri>		<uri>sip:nypd@example.com</uri>
	</mapping>		</mapping>
	<path>		<path>
	<via source="authoritative.example"/>
	<via source="resolver.example"/>		<via source="resolver.example"/>
			<via source="authoritative.example"/>
	</path>		</path>
			<locationUsed id="6020688f1ce1896d"/>
	</findServiceResponse>		</findServiceResponse>
	Figure 17: Example of a <findServiceResponse> message with baseline		Figure 17: Example of a <findServiceResponse> message with baseline
	profile interoperability		profile interoperability
	11.2. Two Dimensional Geodetic Profile		12.2. Two Dimensional Geodetic Profile
	The geodetic-2d location profile is identified by geodetic-2d.		The "geodetic-2d" location profile is identified by "geodetic-2d".
	Clients use this profile by placing a <Point> element, as described		Clients and servers use this profile by placing the following
	in Section 7.2.1 of [13], within the <location> element. Section		location shapes into the <serviceBoundary> or into the <location>
	7.2.1 of [13] describes the specification of a <Point> with either a		element (unless indicated otherwise):
	two dimensional position (latitude and longitude) or three
	dimensional position (latitude, longitude, and altitude). A client
	MAY use the three dimensional position, and servers MAY interpret a
	three dimensional position as a two dimensional position by ignoring
	altitude.
	Servers use this profile by placing a <Polygon> element, as described		Point:
	in Section 7.2.2 of [13], within the <serviceBoundary> element. This
	is defined by the 'polygon' pattern in the LoST schema (see
	Section 14).
	With respect to the description in Section 7.2.2 of [13] the		The <Point> element is described in Section 5.2.1 of [13].
	restriction to 16 points for a polygon is not applicable to this		Section 5.2.1 of [13] shows also the specification of a <Point>
	document. With this profile servers MUST use WGS 84 (latitude,		with either a two dimensional position (latitude and longitude) or
	longitude), i.e., the srsName set to 'urn:ogc:def:crs:EPSG::4326'		three dimensional position (latitude, longitude, and altitude). A
	where altitude information is omitted. The orientation of the points		client MAY use the three dimensional position, and servers MAY
	in the polygon is upward normal as described in Section 7.2.2 of		interpret a three dimensional position as a two dimensional
	[13].		position by ignoring the altitude value. A <Point> element is not
			placed into a <serviceBoundary> element.
	11.3. Basic Civic Profile		Polygon:
			The <Polygon> element is described in Section 5.2.2 of [13]. The
			restriction to 16 points for a polygon contained in Section 7.2.2
			of [12] is not applicable to this document.
			Circle:
			The <Circle> element is described in Section 5.2.3 of [13].
			Ellipse:
			The <Ellipse> element is described in Section 5.2.4 of [13].
			ArcBand:
			The <ArcBand> element is described in Section 5.2.5 of [13].
			When clients place a <Polygon>, <Circle>, <Ellipse> or <ArcBand>
			element within the <location> element then it indicates that the
			query is about any point contained in the given area; it is left to
			the server to select an appropriate matching algorithm, such as using
			computing the centroid. A server MAY return multiple <mapping>
			elements if the polygon extends across multiple service areas.
			When geodetic location information of this location profile is placed
			in the <serviceBoundary> element then the elements with geospatial
			coordinates are alternative descriptions of the same service region,
			not additive geometries.
			12.3. Basic Civic Profile
	The basic-civic location profile is identified by the token 'civic'.		The basic-civic location profile is identified by the token 'civic'.
	Clients use this profile by placing a <civicAddress> element, defined		Clients use this profile by placing a <civicAddress> element, defined
	in [10], within the <location> element.		in [10], within the <location> element.
	Servers use this profile by placing a <civicAddress> element, defined		Servers use this profile by placing a <civicAddress> element, defined
	in [10], within the <serviceBoundary> element.		in [10], within the <serviceBoundary> element.
	12. Errors, Warnings, and Redirects		A response MAY contain more than one <serviceBoundary> element with
			profile 'civic'. Each <serviceBoundary> element describes a set of
			civic addresses that fall within the service boundary, namely all
			addresses that textually match the civic address elements provided,
			regardless of the value of other address elements. A location falls
			within the mapping's service boundary if it matches any of the
			<serviceBoundary> elements. Hence, a response may contain multiple
			<serviceBoundary> elements with civic and/or geodetic location
			profiles.
			13. Errors, Warnings, and Redirects
	When a LoST server cannot fulfill a request completely, it can return		When a LoST server cannot fulfill a request completely, it can return
	either an error or a warning, depending on the severity of the		either an error or a warning, depending on the severity of the
	problem. It returns an error element if no useful response can be		problem. It returns an error element if no useful response can be
	returned for the query. It returns a <warnings> element as part of		returned for the query. It returns a <warnings> element as part of
	another response element if it was able to respond in part, but the		another response element if it was able to respond in part, but the
	response may not be quite what the client had desired. This document		response may not be quite what the client had desired. For both
	does not define warnings. For both elements, the 'source' attribute		elements, the 'source' attribute names the server that originally
	names the server that originally generated the error or warning, such		generated the error or warning, such as the authoritative server.
	as the authoritative server. Unless otherwise noted, all elements		Unless otherwise noted, all elements below can be either an error or
	below can be either an error or a warning, depending on whether a		a warning, depending on whether a default response, such as a
	default response, such as a mapping, is included.		mapping, is included.
	12.1. Errors		13.1. Errors
	LoST defines a pattern for errors, defined as <errors> elements in		LoST defines a pattern for errors, defined as <errors> elements in
	the Relax NG schema. This pattern defines a 'message' attribute		the Relax NG schema. This pattern defines a 'message' attribute
	containing human readable text and an 'xml:lang' attribute denoting		containing human readable text and an 'xml:lang' attribute denoting
	the language of the human readable text. One or more such error		the language of the human readable text. One or more such error
	elements are contained in the <errors> element.		elements are contained in the <errors> element.
	The following errors follow this basic pattern:		The following errors follow this basic pattern:
	badRequest		badRequest
	The server could not parse or otherwise understand a request,		The server could not parse or otherwise understand a request,
	e.g., because the XML was malformed.		e.g., because the XML was malformed.
	forbidden		forbidden
	The server refused to send an answer. This generally only occurs		The server refused to send an answer. This generally only occurs
	for recursive queries, namely if the client tried to contact the		for recursive queries, namely if the client tried to contact the
	authoritative server and was refused. (For HTTP as the underlying		authoritative server and was refused.
	protocol, an HTTP 401 error would be returned.)
	internalError		internalError
	The server could not satisfy a request due to misconfiguration or		The server could not satisfy a request due to misconfiguration or
	other operational and non-protocol related reasons.		other operational and non-protocol related reasons.
	locationProfileUnrecognized		locationProfileUnrecognized
	None of the profiles in the request were recognized by the server		None of the profiles in the request were recognized by the server
	(see Section 11).		(see Section 12).
			locationInvalid
			The geodetic or civic location in the request was invalid. For
			example, the longitude or latitude values fall outside the
			acceptable ranges.
			SRSInvalid
			The spatial reference system (SRS) contained in the location
			element was not recognized or does not match the location profile.
	loop		loop
	During a recursive query, the server was about to visit a server		During a recursive query, the server was about to visit a server
	that was already in the server list in the <path> element,		that was already in the server list in the <path> element,
	indicating a request loop.		indicating a request loop.
	notFound		notFound
	The server could not find an answer to the query.		The server could not find an answer to the query.
	skipping to change at page 36, line 40		skipping to change at page 39, line 13
	An example is below:		An example is below:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<errors xmlns="urn:ietf:params:xml:ns:lost1"		<errors xmlns="urn:ietf:params:xml:ns:lost1"
	source="resolver.example">		source="resolver.example">
	<internalError message="Software bug." xml:lang="en"/>		<internalError message="Software bug." xml:lang="en"/>
	</errors>		</errors>
	Figure 18: Example of an error resonse		Figure 18: Example of an error resonse
	12.2. Warnings		13.2. Warnings
	A response MAY contain zero or more warnings. This pattern defines a		A response MAY contain zero or more warnings. This pattern defines a
	'message' attribute containing human readable text and an 'xml:lang'		'message' attribute containing human readable text and an 'xml:lang'
	attribute denoting the language of the human readable text. One or		attribute denoting the language of the human readable text. One or
	more such warning elements are contained in the <warnings> element.		more such warning elements are contained in the <warnings> element.
			To provide human readable text in an appropriate language the HTTP
			content negotiation capabilities (see Section 14) MAY be utilized by
			a server.
	This version of the specification does not define any warning		This version of the specification defines the following warnings:
	elements.
	12.3. Redirects		locationValidationUnavailable
			The <locationValidationUnavailable> element MAY be returned when a
			server wishes to notify a client that it cannot fulfill a location
			validation request. This warning allows a server to return
			mapping information while signalling this exception state.
			serviceSubstitution
			The <serviceSubstitution> element MAY be returned when a server
			was not able to fulfill a <findService> request for a given
			service URN. For example, a <findService> request with the
			'urn:service:sos.police' service URN for a location in Uruguay may
			cause the LoST service to return a mapping for the
			'urn:service:sos' service URN since Uruguay does not make use of
			the sub-services police, fire and ambulance. If this warning is
			returned then the <service> element in the response provides
			information about the service URN that refers to the mapping.
			defaultMappingReturned
			The <defaultMappingReturned> element MAY be returned when a server
			was not able to fulfill a <findService> request for a given
			location but is able to respond with a default URI. For example,
			a nearby PSAP may be returned.
			An example of a warning is shown below:
			<?xml version="1.0" encoding="UTF-8"?>
			<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
			xmlns:p2="http://www.opengis.net/">
			<mapping
			expires="2007-01-01T01:44:33Z"
			lastUpdated="2006-11-01T01:00:00Z"
			source="authoritative.example"
			sourceId="fb8ed888433343b7b27865aeb38f3a99">
			<displayName xml:lang="en">
			New York City Police Department
			</displayName>
			<service>urn:service:sos.police</service>
			<serviceBoundary profile="geodetic-2d">
			<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
			<p2:exterior>
			<p2:LinearRing>
			<p2:pos>37.775 -122.4194</p2:pos>
			<p2:pos>37.555 -122.4194</p2:pos>
			<p2:pos>37.555 -122.4264</p2:pos>
			<p2:pos>37.775 -122.4264</p2:pos>
			<p2:pos>37.775 -122.4194</p2:pos>
			</p2:LinearRing>
			</p2:exterior>
			</p2:Polygon>
			</serviceBoundary>
			<uri>sip:nypd@example.com</uri>
			</mapping>
			<warnings source="authoritative.example">
			<defaultMappingReturned
			message="Unable to determine PSAP for the given location;
			using default PSAP"
			xml:lang="en"/>
			</warnings>
			<path>
			<via source="resolver.example"/>
			<via source="authoritative.example"/>
			</path>
			</findServiceResponse>
			Figure 19: Example of an warning resonse
			13.3. Redirects
	A LoST server can respond indicating that the querier should redirect		A LoST server can respond indicating that the querier should redirect
	the query to another server, using the <redirect> element. The		the query to another server, using the <redirect> element. The
	element includes a 'target' attribute indicating the LoST application		element includes a 'target' attribute indicating the LoST application
	unique string (see Section 4) that the client SHOULD be contacting		unique string (see Section 4) that the client SHOULD be contacting
	next, as well as the 'source' attribute indicating the server that		next, as well as the 'source' attribute indicating the server that
	generated the redirect response and a 'message' attribute explaining		generated the redirect response and a 'message' attribute explaining
	the reason for the redirect response. During a recursive query, a		the reason for the redirect response. During a recursive query, a
	server receiving a <redirect> response can decide whether it wants to		server receiving a <redirect> response can decide whether it wants to
	follow the redirection or simply return the response to its upstream		follow the redirection or simply return the response to its upstream
	querier.		querier.
	An example is below:		An example is below:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<redirect xmlns="urn:ietf:params:xml:ns:lost1"		<redirect xmlns="urn:ietf:params:xml:ns:lost1"
	target="eastpsap.example"		target="eastpsap.example"
	source="westpsap.example"		source="westpsap.example"
	message="We have temporarily failed over." xml:lang="en"/>		message="We have temporarily failed over." xml:lang="en"/>
	Figure 19: Example of a redirect resonse		Figure 20: Example of a redirect response
	13. LoST Transport		14. LoST Transport: HTTP
	LoST needs an underlying protocol transport mechanisms to carry		LoST needs an underlying protocol transport mechanisms to carry
	requests and responses. This document defines the use of LoST over		requests and responses. This document defines the use of LoST over
	HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future		HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future
	documents. The available transport mechanisms are determined through		documents. The available transport mechanisms are determined through
	the use of the LoST U-NAPTR application. In protocols that support		the use of the LoST U-NAPTR application. In protocols that support
	content type indication, LoST uses the media type application/		content type indication, LoST uses the media type application/
	lost+xml.		lost+xml.
	When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP		When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP
	POST method. All HTTP responses are applicable. The HTTP URL is		POST method. The HTTP request MUST use the Cache-Control response
	derived from the LoST server name via U-NAPTR application, as		directive "no-cache" to HTTP-level "caching even by caches that have
	discussed above		been configured to return stale responses to client requests."
	14. Relax NG Schema		All LoST responses, including those indicating a LoST warning or
			error, are carried in 2xx responses, typically 200 (OK). Other 2xx
			responses, in particular 203 (Non-authoritative information) may be
			returned by HTTP caches that disregard the caching instructions. 3xx,
			4xx and 5xx HTTP response codes indicates that the HTTP request
			itself failed or was redirected; these responses do not contain any
			LoST XML elements.
			The HTTP URL is derived from the LoST server name via U-NAPTR
			application, as discussed above.
			15. Relax NG Schema
	This section provides the Relax NG schema used by LoST protocol in		This section provides the Relax NG schema used by LoST protocol in
	the compact form. The verbose form is included in Appendix A.		the compact form. The verbose form is included in Appendix A.
	namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"		namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
	default namespace ns1 = "urn:ietf:params:xml:ns:lost1"		default namespace ns1 = "urn:ietf:params:xml:ns:lost1"
	##		##
	## Location-to-Service Translation Protocol (LoST)		## Location-to-Service Translation Protocol (LoST)
	##		##
	skipping to change at page 41, line 5		skipping to change at page 45, line 5
	div {		div {
	commonResponsePattern = warnings*, path, extensionPoint		commonResponsePattern = warnings*, path, extensionPoint
	}		}
	##		##
	## Location Information		## Location Information
	##		##
	div {		div {
	locationInformation =		locationInformation =
	extensionPoint+,		extensionPoint+,
	attribute profile { xsd:NMTOKEN }		attribute profile { xsd:NMTOKEN }?
	}		}
	##		##
	## Service Boundary		## Service Boundary
	##		##
	div {		div {
	serviceBoundary = element serviceBoundary { locationInformation }+		serviceBoundary = element serviceBoundary { locationInformation }+
	}		}
	##		##
	skipping to change at page 42, line 47		skipping to change at page 46, line 47
	element invalid { qnameList }?,		element invalid { qnameList }?,
	element unchecked { qnameList }?,		element unchecked { qnameList }?,
	extensionPoint		extensionPoint
	}		}
	}		}
	##		##
	## Errors and Warnings Container.		## Errors and Warnings Container.
	##		##
	div {		div {
	errorContainer =		exceptionContainer =
	(badRequest?		(badRequest?
	& internalError?		& internalError?
	& serviceSubstitution?		& serviceSubstitution?
			& defaultMappingReturned?
	& forbidden?		& forbidden?
	& notFound?		& notFound?
	& loop?		& loop?
	& serviceNotImplemented?		& serviceNotImplemented?
	& serverTimeout?		& serverTimeout?
	& serverError?		& serverError?
			& locationInvalid?
	& locationProfileUnrecognized?),		& locationProfileUnrecognized?),
	extensionPoint,		extensionPoint,
	source		source
	errors = element errors { errorContainer }		errors = element errors { exceptionContainer }
	warnings = element warnings { errorContainer }		warnings = element warnings { exceptionContainer }
	}		}
	##		##
	## Basic Errors		## Basic Exceptions
	##		##
	div {		div {
	##		##
	## Error pattern.		## Exception pattern.
	##		##
	basicError = message, extensionPoint		basicException = message, extensionPoint
	badRequest = element badRequest { basicError }		badRequest = element badRequest { basicException }
	internalError = element internalError { basicError }		internalError = element internalError { basicException }
	serviceSubstitution = element serviceSubstitution { basicError }		serviceSubstitution = element serviceSubstitution { basicException }
	forbidden = element forbidden { basicError }		defaultMappingReturned =
	notFound = element notFound { basicError }		element defaultMappingReturned { basicException }
	loop = element loop { basicError }		forbidden = element forbidden { basicException }
	serviceNotImplemented = element serviceNotImplemented { basicError }		notFound = element notFound { basicException }
	serverTimeout = element serverTimeout { basicError }		loop = element loop { basicException }
	serverError = element serverError { basicError }		serviceNotImplemented =
			element serviceNotImplemented { basicException }
			serverTimeout = element serverTimeout { basicException }
			serverError = element serverError { basicException }
			locationInvalid = element locationInvalid { basicException }
			locationValidationUnavailable =
			element locationValidationUnavailable { basicException }
	locationProfileUnrecognized =		locationProfileUnrecognized =
	element locationProfileUnrecognized {		element locationProfileUnrecognized {
	attribute unsupportedProfiles { xsd:NMTOKENS },		attribute unsupportedProfiles { xsd:NMTOKENS },
	basicError		basicException
	}		}
	}		}
	##		##
	## Redirect.		## Redirect.
	##		##
	div {		div {
	##		##
	## Redirect pattern		## Redirect pattern
	##		##
	redirect =		redirect =
	element redirect {		element redirect {
	attribute target { appUniqueString },		attribute target { appUniqueString },
	source,		source,
	message,		message,
	extensionPoint		extensionPoint
	}		}
	skipping to change at page 44, line 45		skipping to change at page 49, line 4
	notLost = element * - (ns1:* | ns1:*) { anyElement }		notLost = element * - (ns1:* | ns1:*) { anyElement }
	##		##
	## A wildcard pattern for including any element		## A wildcard pattern for including any element
	## from any other namespace.		## from any other namespace.
	##		##
	anyElement =		anyElement =
	(element * { anyElement }		(element * { anyElement }
	| attribute * { text }		| attribute * { text }
	| text)*		| text)*
	##		##
	## A point where future extensions		## A point where future extensions
	## (elements from other namespaces)		## (elements from other namespaces)
	## can be added.		## can be added.
	##		##
	extensionPoint = notLost*		extensionPoint = notLost*
	}		}
	Figure 20: RelaxNG schema		Figure 21: RelaxNG schema
	15. Internationalization Considerations		16. Internationalization Considerations
	This mechanism is largely for passing protocol information from one		The LoST protocol is mostly meant for machine-to-machine
	subsystem to another; as such, most of its elements are tokens not		communications; as such, most of its elements are tokens not meant
	meant for direct human consumption. If these tokens are presented to		for direct human consumption. If these tokens are presented to the
	the end user, some localization may need to occur. The content of		end user, some localization may need to occur. The content of the
	the <displayName> element and the 'message' attributes may be		<displayName> element and the 'message' attributes may be displayed
	displayed to the end user, and they are thus a complex types designed		to the end user, and they are thus complex types designed for this
	for this purpose.		purpose.
	LoST exchanges information using XML. All XML processors are		LoST exchanges information using XML. All XML processors are
	required to understand UTF-8 and UTF-16 encodings, and therefore all		required to understand UTF-8 and UTF-16 encodings, and therefore all
	LoST clients and servers MUST understand UTF-8 and UTF-16 encoded		LoST clients and servers MUST understand UTF-8 and UTF-16 encoded
	XML. Additionally, LoST servers and clients MUST NOT encode XML with		XML. Additionally, LoST servers and clients MUST NOT encode XML with
	encodings other than UTF-8 or UTF-16.		encodings other than UTF-8 or UTF-16.
	16. IANA Considerations		17. IANA Considerations
	16.1. U-NAPTR Registrations		17.1. U-NAPTR Registrations
	This document registers the following U-NAPTR application service		This document registers the following U-NAPTR application service
	tag:		tag:
	Application Service Tag: LoST		Application Service Tag: LoST
	Defining Publication: The specification contained within this		Defining Publication: The specification contained within this
	document.		document.
	This document registers the following U-NAPTR application protocol		This document registers the following U-NAPTR application protocol
	skipping to change at page 47, line 32		skipping to change at page 51, line 32
	Application Protocol Tag: http		Application Protocol Tag: http
	Defining Publication: RFC 2616 [3]		Defining Publication: RFC 2616 [3]
	o		o
	Application Protocol Tag: https		Application Protocol Tag: https
	Defining Publication: RFC 2818 [4]		Defining Publication: RFC 2818 [4]
	16.2. Content-type registration for 'application/lost+xml'		17.2. Content-type registration for 'application/lost+xml'
	This specification requests the registration of a new MIME type		This specification requests the registration of a new MIME type
	according to the procedures of RFC 4288 [7] and guidelines in RFC		according to the procedures of RFC 4288 [7] and guidelines in RFC
	3023 [5].		3023 [5].
	MIME media type name: application		MIME media type name: application
	MIME subtype name: lost+xml		MIME subtype name: lost+xml
	Mandatory parameters: none		Mandatory parameters: none
	Optional parameters: charset		Optional parameters: charset
	Indicates the character encoding of enclosed XML.		Indicates the character encoding of enclosed XML.
	Encoding considerations:		Encoding considerations: Uses XML, which can employ 8-bit
			characters, depending on the character encoding used. See RFC
	Uses XML, which can employ 8-bit characters, depending on the		3023 [5], Section 3.2.
	character encoding used. See RFC 3023 [5], Section 3.2.
	Security considerations:
	This content type is designed to carry LoST protocol payloads.		Security considerations: This content type is designed to carry LoST
			protocol payloads.
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please		Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
	replace XXXX with the RFC number of this specification.] this		replace XXXX with the RFC number of this specification.]
	document
	Applications which use this media type:
	Emergency and Location-based Systems		Applications which use this media type: Emergency and Location-based
			Systems
	Additional information:		Additional information:
	Magic Number: None		Magic Number: None
	File Extension: .lostxml		File Extension: .lostxml
	Macintosh file type code: 'TEXT'		Macintosh file type code: 'TEXT'
	Personal and email address for further information: Hannes		Personal and email address for further information: Hannes
	Tschofenig, Hannes.Tschofenig@siemens.com		Tschofenig, Hannes.Tschofenig@nsn.com
	Intended usage: LIMITED USE		Intended usage: LIMITED USE
	Author:		Author:
	This specification is a work item of the IETF ECRIT working group,		This specification is a work item of the IETF ECRIT working group,
	with mailing list address <ecrit@ietf.org>.		with mailing list address <ecrit@ietf.org>.
	Change controller:		Change controller:
	The IESG <iesg@ietf.org>		The IESG <iesg@ietf.org>
	16.3. LoST Relax NG Schema Registration		17.3. LoST Relax NG Schema Registration
	URI: urn:ietf:params:xml:ns:lost1		URI: urn:ietf:params:xml:ns:lost1
	Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig		Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
	(Hannes.Tschofenig@siemens.com).		(Hannes.Tschofenig@nsn.com).
	Relax NG Schema: The Relax NG schema to be registered is contained		Relax NG Schema: The Relax NG schema to be registered is contained
	in Section 14. Its first line is		in Section 15. Its first line is
	default namespace = "urn:ietf:params:xml:ns:lost1"		default namespace = "urn:ietf:params:xml:ns:lost1"
	and its last line is		and its last line is
	}		}
	16.4. LoST Namespace Registration		17.4. LoST Namespace Registration
	URI: urn:ietf:params:xml:ns:lost1		URI: urn:ietf:params:xml:ns:lost1
	Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig		Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
	(Hannes.Tschofenig@siemens.com).		(Hannes.Tschofenig@nsn.com).
	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 50, line 6		skipping to change at page 54, line 6
	<h1>Namespace for LoST</h1>		<h1>Namespace for LoST</h1>
	<h2>urn:ietf:params:xml:ns:lost1</h2>		<h2>urn:ietf:params:xml:ns:lost1</h2>
	<p>See <a href="[URL of published RFC]">RFCXXXX		<p>See <a href="[URL of published RFC]">RFCXXXX
	[NOTE TO IANA/RFC-EDITOR:		[NOTE TO IANA/RFC-EDITOR:
	Please replace XXXX with the RFC number of this		Please replace XXXX with the RFC number of this
	specification.]</a>.</p>		specification.]</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	16.5. LoST Location Profile Registry		17.5. LoST Location Profile Registry
	This document seeks to create a registry of location profile names		This document seeks to create a registry of location profile names
	for the LoST protocol. Profile names are XML tokens. This registry		for the LoST protocol. Profile names are XML tokens. This registry
	will operate in accordance with RFC 2434 [2], Standards Action.		will operate in accordance with RFC 2434 [2], Standards Action.
	geodetic-2d:		geodetic-2d:
	Defined in Section 11.2		Defined in Section 12.2.
	civic:		civic:
	Defined in Section 11.3		Defined in Section 12.3.
	17. Security Considerations		18. Security Considerations
	There are multiple threats to the overall system of which service		There are several threats to the overall system of which service
	mapping forms a part. An attacker that can obtain service contact		mapping forms a part. An attacker that can obtain service contact
	URIs can use those URIs to attempt to disrupt those services. An		URIs can use those URIs to attempt to disrupt those services. An
	attacker that can prevent the lookup of contact URIs can impair the		attacker that can prevent the lookup of contact URIs can impair the
	reachability of such services. An attacker that can eavesdrop on the		reachability of such services. An attacker that can eavesdrop on the
	communication requesting this lookup can surmise the existence of an		communication requesting this lookup can surmise the existence of an
	emergency and possibly its nature, and may be able to use this to		emergency and possibly its nature, and may be able to use this to
	launch a physical attack on the caller.		launch a physical attack on the caller.
	To avoid that an attacker can modify the query or its result, the use		To avoid that an attacker can modify the query or its result, the use
	of channel security, such as TLS, is RECOMMENDED.		of channel security, such as TLS, is RECOMMENDED.
	Generally, authentication and authorization is not required for		Generally, authentication and authorization is not required for
	mapping queries. If it is, authentication mechanism of the		mapping queries. If it is, authentication mechanism of the
	underlying transport mechanism, such as HTTP basic and digest		underlying transport mechanism, such as HTTP basic and digest
	authentication, MAY be used. (Basic authentication SHOULD only be		authentication, MAY be used. (Basic authentication SHOULD only be
	used in combination with TLS.)		used in combination with TLS.)
	A more detailed description of threats and security requirements are		A more detailed description of threats and security requirements are
	provided in [17].		provided in [17].
	18. Acknowledgments		19. Acknowledgments
	We would like to the thank the following working group members for		We would like to the thank the following working group members for
	the detailed review of previous LoST document versions:		the detailed review of previous LoST document versions:
	o Martin Thomson (Review July 2006)		o Martin Thomson (Review July 2006)
	o Jonathan Rosenberg (Review July 2006)		o Jonathan Rosenberg (Review July 2006)
	o Leslie Daigle (Review September 2006)		o Leslie Daigle (Review September 2006)
	skipping to change at page 52, line 35		skipping to change at page 56, line 35
	reviewer)		reviewer)
	o Jonathan Rosenberg (Review February 2007)		o Jonathan Rosenberg (Review February 2007)
	o Tom Taylor (Review February 2007)		o Tom Taylor (Review February 2007)
	o Theresa Reese (Review February 2007)		o Theresa Reese (Review February 2007)
	o Shida Schubert (Review February 2007)		o Shida Schubert (Review February 2007)
			o James Winterbottom (Review July 2007)
	We would also like to thank the following working group members for		We would also like to thank the following working group members for
	their input to selected design aspects of the LoST protocol:		their input to selected design aspects of the LoST protocol:
	o Leslie Daigle and Martin Thomson (DNS-based LoST discovery		o Leslie Daigle and Martin Thomson (DNS-based LoST discovery
	procedure)		procedure)
	o John Schnizlein (authoritive LoST answers)		o John Schnizlein (authoritive LoST answers)
	o Rohan Mahy (display names)		o Rohan Mahy (display names)
	skipping to change at page 54, line 5		skipping to change at page 57, line 36
	URN)		URN)
	o Otmar Lendl (LoST aggregation)		o Otmar Lendl (LoST aggregation)
	o Tom Taylor (Terminology)		o Tom Taylor (Terminology)
	Klaus Darilion and Marc Linsner provided miscellaneous input to the		Klaus Darilion and Marc Linsner provided miscellaneous input to the
	design of the protocol. Finally, we would like to thank Brian Rosen		design of the protocol. Finally, we would like to thank Brian Rosen
	who participated in almost every discussion thread.		who participated in almost every discussion thread.
	19. Open Issues		Early implementation efforts lead to good feedback by two open source
			implementation groups. We would like to thank the implementers for
			their work and for helping us to improve the quality of the
			specification:
	Please find open issues at: http://www.ietf-ecrit.org:8080/lost/		o Wonsang Song
			o Jong-Yul Kim
			o Anna Makarowska
			o Krzysztof Rzecki
			o Blaszczyk Piotr
	20. References		20. References
	20.1. Normative References		20.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434,		Considerations Section in RFCs", BCP 26, RFC 2434,
	skipping to change at page 55, line 31		skipping to change at page 58, line 31
	[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",		[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
	RFC 3023, January 2001.		RFC 3023, January 2001.
	[6] Peterson, J., "A Presence-based GEOPRIV Location Object		[6] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[7] Freed, N. and J. Klensin, "Media Type Specifications and		[7] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", BCP 13, RFC 4288, December 2005.		Registration Procedures", BCP 13, RFC 4288, December 2005.
	[8] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and		[8] Daigle, L., "Domain-Based Application Service Location Using
	Registration Procedures for New URI Schemes", BCP 115,		URIs and the Dynamic Delegation Discovery Service (DDDS)",
	RFC 4395, February 2006.		RFC 4848, April 2007.
	[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",		[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
	draft-ietf-ecrit-service-urn-05 (work in progress),		draft-ietf-ecrit-service-urn-06 (work in progress), March 2007.
	August 2006.
	[10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format		[10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
	for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in		for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
	progress), February 2007.		progress), February 2007.
	[11] Daigle, L., "Domain-based Application Service Location Using		[11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
	URIs and the Dynamic Delegation Discovery Service (DDDS)",
	draft-daigle-unaptr-02 (work in progress), February 2007.
	[12] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
	"Geographic information - Geography Markup Language (GML)", OGC		"Geographic information - Geography Markup Language (GML)", OGC
	Standard OpenGIS 03-105r1, April 2004.		Standard OpenGIS 03-105r1, April 2004.
	[13] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application		[12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application
	Schema for use by the Internet Engineering Task Force (IETF)",		Schema for use by the Internet Engineering Task Force (IETF)",
	Candidate OpenGIS Implementation Specification , December 2006.		Candidate OpenGIS Implementation Specification , December 2006.
	20.2. Informative References		20.2. Informative References
			[13] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
			Considerations and Recommendations",
			draft-ietf-geopriv-pdif-lo-profile-08 (work in progress),
			July 2007.
	[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence		[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence
	Protocol (XMPP): Instant Messaging and Presence", RFC 3921,		Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
	October 2004.		October 2004.
	[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,		[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
	December 2004.		December 2004.
	[17] Taylor, T., "Security Threats and Requirements for Emergency		[17] Taylor, T., "Security Threats and Requirements for Emergency
	Call Marking and Mapping", draft-ietf-ecrit-security-threats-03		Call Marking and Mapping", draft-ietf-ecrit-security-threats-04
	(work in progress), July 2006.		(work in progress), April 2007.
	[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency		[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
	Context Resolution with Internet Technologies",		Context Resolution with Internet Technologies",
	draft-ietf-ecrit-requirements-12 (work in progress),		draft-ietf-ecrit-requirements-13 (work in progress),
	August 2006.		March 2007.
	[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and		[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and
	Framework", draft-ietf-ecrit-mapping-arch-01 (work in		Framework", draft-ietf-ecrit-mapping-arch-02 (work in
	progress), December 2006.		progress), July 2007.
	[20] Rosen, B. and J. Polk, "Best Current Practice for		[20] Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in support of Emergency Calling",		Communications Services in support of Emergency Calling",
	draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006.		draft-ietf-ecrit-phonebcp-01 (work in progress), March 2007.
	Appendix A. Non-Normative RELAX NG Schema in XML Syntax		Appendix A. Non-Normative RELAX NG Schema in XML Syntax
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<grammar ns="urn:ietf:params:xml:ns:lost1"		<grammar ns="urn:ietf:params:xml:ns:lost1"
	xmlns="http://relaxng.org/ns/structure/1.0"		xmlns="http://relaxng.org/ns/structure/1.0"
	xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"		xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
	datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">		datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
	<start>		<start>
	<a:documentation>		<a:documentation>
	Location-to-Service Translation Protocol (LoST)		Location-to-Service Translation Protocol (LoST)
	A LoST XML instance has three request types, each with		A LoST XML instance has three request types, each with
	a cooresponding response type: find service, list services,		a cooresponding response type: find service, list services,
	and get service boundary.		and get service boundary.
	</a:documentation>		</a:documentation>
	<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" />
	skipping to change at page 60, line 36		skipping to change at page 63, line 40
	<div>		<div>
	<a:documentation>		<a:documentation>
	Location Information		Location Information
	</a:documentation>		</a:documentation>
	<define name="locationInformation">		<define name="locationInformation">
	<oneOrMore>		<oneOrMore>
	<ref name="extensionPoint"/>		<ref name="extensionPoint"/>
	</oneOrMore>		</oneOrMore>
			<optional>
	<attribute name="profile">		<attribute name="profile">
	<data type="NMTOKEN" />		<data type="NMTOKEN" />
	</attribute>		</attribute>
			</optional>
	</define>		</define>
	</div>		</div>
	<div>		<div>
	<a:documentation>		<a:documentation>
	Service Boundary		Service Boundary
	</a:documentation>		</a:documentation>
	<define name="serviceBoundary">		<define name="serviceBoundary">
	<oneOrMore>		<oneOrMore>
	<element name="serviceBoundary">		<element name="serviceBoundary">
	<ref name="locationInformation" />		<ref name="locationInformation" />
	</element>		</element>
	</oneOrMore>		</oneOrMore>
	</define>		</define>
	</div>		</div>
	<div>		<div>
	skipping to change at page 64, line 16		skipping to change at page 67, line 21
	<ref name="extensionPoint"/>		<ref name="extensionPoint"/>
	</element>		</element>
	</define>		</define>
	</div>		</div>
	<div>		<div>
	<a:documentation>		<a:documentation>
	Errors and Warnings Container.		Errors and Warnings Container.
	</a:documentation>		</a:documentation>
	<define name="errorContainer">		<define name="exceptionContainer">
	<interleave>		<interleave>
	<optional>		<optional>
	<ref name="badRequest" />		<ref name="badRequest" />
	</optional>		</optional>
	<optional>		<optional>
	<ref name="internalError" />		<ref name="internalError" />
	</optional>		</optional>
	<optional>		<optional>
	<ref name="serviceSubstitution" />		<ref name="serviceSubstitution" />
	</optional>		</optional>
	skipping to change at page 64, line 46		skipping to change at page 67, line 51
	<optional>		<optional>
	<ref name="serviceNotImplemented" />		<ref name="serviceNotImplemented" />
	</optional>		</optional>
	<optional>		<optional>
	<ref name="serverTimeout" />		<ref name="serverTimeout" />
	</optional>		</optional>
	<optional>		<optional>
	<ref name="serverError" />		<ref name="serverError" />
	</optional>		</optional>
	<optional>		<optional>
			<ref name="locationInvalid" />
			</optional>
			<optional>
	<ref name="locationProfileUnrecognized" />		<ref name="locationProfileUnrecognized" />
	</optional>		</optional>
	</interleave>		</interleave>
	<ref name="extensionPoint" />		<ref name="extensionPoint" />
	<ref name="source" />		<ref name="source" />
	</define>		</define>
	<define name="errors">		<define name="errors">
	<element name="errors">		<element name="errors">
	<ref name="errorContainer" />		<ref name="exceptionContainer" />
	</element>		</element>
	</define>		</define>
	<define name="warnings">		<define name="warnings">
	<element name="warnings">		<element name="warnings">
	<ref name="errorContainer" />		<ref name="exceptionContainer" />
	</element>		</element>
	</define>		</define>
	</div>		</div>
	<div>		<div>
	<a:documentation>		<a:documentation>
	Basic Errors		Basic Exceptions
	</a:documentation>		</a:documentation>
	<define name="basicError">		<define name="basicException">
	<a:documentation>		<a:documentation>
	Error pattern.		Exception pattern.
	</a:documentation>		</a:documentation>
	<ref name="message"/>		<ref name="message"/>
	<ref name="extensionPoint" />		<ref name="extensionPoint" />
	</define>		</define>
	<define name="badRequest">		<define name="badRequest">
	<element name="badRequest">		<element name="badRequest">
	<ref name="basicError"/>		<ref name="basicException"/>
	</element>		</element>
	</define>		</define>
	<define name="internalError">		<define name="internalError">
	<element name="internalError">		<element name="internalError">
	<ref name="basicError"/>		<ref name="basicException"/>
	</element>		</element>
	</define>		</define>
	<define name="serviceSubstitution">		<define name="serviceSubstitution">
	<element name="serviceSubstitution">		<element name="serviceSubstitution">
	<ref name="basicError"/>		<ref name="basicException"/>
	</element>		</element>
	</define>		</define>
	<define name="forbidden">		<define name="forbidden">
	<element name="forbidden">		<element name="forbidden">
	<ref name="basicError"/>		<ref name="basicException"/>
	</element>		</element>
	</define>		</define>
	<define name="notFound">		<define name="notFound">
	<element name="notFound">		<element name="notFound">
	<ref name="basicError"/>		<ref name="basicException"/>
	</element>		</element>
	</define>		</define>
	<define name="loop">		<define name="loop">
	<element name="loop">		<element name="loop">
	<ref name="basicError" />		<ref name="basicException" />
	</element>		</element>
	</define>		</define>
	<define name="serviceNotImplemented">		<define name="serviceNotImplemented">
	<element name="serviceNotImplemented">		<element name="serviceNotImplemented">
	<ref name="basicError"/>		<ref name="basicException"/>
	</element>		</element>
	</define>		</define>
	<define name="serverTimeout">		<define name="serverTimeout">
	<element name="serverTimeout">		<element name="serverTimeout">
	<ref name="basicError"/>		<ref name="basicException"/>
	</element>		</element>
	</define>		</define>
	<define name="serverError">		<define name="serverError">
	<element name="serverError">		<element name="serverError">
	<ref name="basicError"/>		<ref name="basicException"/>
			</element>
			</define>
			<define name="locationInvalid">
			<element name="locationInvalid">
			<ref name="basicException"/>
			</element>
			</define>
			<define name="locationValidationUnavailable">
			<element name="locationValidationUnavailable">
			<ref name="basicException" />
	</element>		</element>
	</define>		</define>
	<define name="locationProfileUnrecognized">		<define name="locationProfileUnrecognized">
	<element name="locationProfileUnrecognized">		<element name="locationProfileUnrecognized">
	<attribute name="unsupportedProfiles">		<attribute name="unsupportedProfiles">
	<data type="NMTOKENS" />		<data type="NMTOKENS" />
	</attribute>		</attribute>
	<ref name="basicError"/>		<ref name="basicException"/>
	</element>		</element>
	</define>		</define>
	</div>		</div>
	<div>		<div>
	<a:documentation>		<a:documentation>
	Redirect.		Redirect.
	</a:documentation>		</a:documentation>
	<define name="redirect">		<define name="redirect">
	<a:documentation>		<a:documentation>
	Redirect pattern		Redirect pattern
	</a:documentation>		</a:documentation>
	<element name="redirect">		<element name="redirect">
	<attribute name="target">		<attribute name="target">
	<ref name="appUniqueString" />		<ref name="appUniqueString" />
	</attribute>		</attribute>
	<ref name="source" />		<ref name="source" />
	<ref name="message" />		<ref name="message" />
	skipping to change at page 69, line 29		skipping to change at page 73, line 4
	can be added.		can be added.
	</a:documentation>		</a:documentation>
	<zeroOrMore>		<zeroOrMore>
	<ref name="notLost" />		<ref name="notLost" />
	</zeroOrMore>		</zeroOrMore>
	</define>		</define>
	</div>		</div>
	</grammar>		</grammar>
			Figure 25
	Figure 24
	Authors' Addresses		Authors' Addresses
	Ted Hardie		Ted Hardie
	Qualcomm, Inc.		Qualcomm, Inc.
	Email: hardie@qualcomm.com		Email: hardie@qualcomm.com
	Andrew Newton		Andrew Newton
	SunRocket		TranTech, Inc.
	8045 Leesburg Pike, Suite 300		4900 Seminary Road, Suite 215
	Vienna, VA 22182		Alexandria, VA 22311
	US		US
	Phone: +1 703 636 0852		Phone: +1 703 671 9873
	Email: andy@hxr.us		Email: andy@hxr.us
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	US		US
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	Email: hgs+ecrit@cs.columbia.edu		Email: hgs+ecrit@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Hannes Tschofenig		Hannes Tschofenig
	Siemens Networks GmbH & Co KG		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bavaria 81739		Munich, Bavaria 81739
	Germany		Germany
	Phone: +49 89 636 40390		Phone: +49 89 636 40390
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@nsn.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
End of changes. 227 change blocks.
	450 lines changed or deleted		633 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/