draft-ietf-ecrit-lost-04.txt		draft-ietf-ecrit-lost-05.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: August 15, 2007 SunRocket		Expires: September 5, 2007 SunRocket
	H. Schulzrinne		H. Schulzrinne
	Columbia U.		Columbia U.
	H. Tschofenig		H. Tschofenig
	Siemens Networks GmbH & Co KG		Siemens Networks GmbH & Co KG
	February 11, 2007		March 4, 2007
	LoST: A Location-to-Service Translation Protocol		LoST: A Location-to-Service Translation Protocol
	draft-ietf-ecrit-lost-04.txt		draft-ietf-ecrit-lost-05.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 August 15, 2007.		This Internet-Draft will expire on September 5, 2007.
	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 . . . . . . . . . . . . . . 8		4. LoST servers and Their Resolution . . . . . . . . . . . . . . 9
	5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 9		5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 10
	5.1. Data source and version: The 'source', 'sourceId' and		5.1. The Data Source: 'source', 'sourceId' and
	'version' Attributes . . . . . . . . . . . . . . . . . . . 9		'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10
	5.2. Time of Last Update: The 'lastUpdated' Attribute . . . . . 9		5.2. Validity: The 'expires' Attribute . . . . . . . . . . . . 10
	5.3. Validity: The 'expires' Attribute . . . . . . . . . . . . 9		5.3. Describing the Service with the <displayName> Element . . 11
	5.4. Describing the Service with the <displayName> Element . . 10		5.4. The Mapped Service: the <service> Element . . . . . . . . 11
	5.5. The Mapped Service: the <service> Element . . . . . . . . 10		5.5. Defining the Service Region with the <serviceBoundary>
	5.6. Defining the Service Region with the <serviceBoundary>		Element . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Element . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.6. Service Boundaries by Reference: the
	5.7. Service Boundaries by Reference: the		<serviceBoundaryReference> Element . . . . . . . . . . . . 12
	<serviceBoundaryReference> Element . . . . . . . . . . . . 11		5.7. The Service Number Element . . . . . . . . . . . . . . . . 13
	5.8. The Service Number Element . . . . . . . . . . . . . . . . 11		5.8. Service URLs: the <uri> Element . . . . . . . . . . . . . 13
	5.9. Service URLs: the <uri> Element . . . . . . . . . . . . . 12		6. Path of a Request: <path> Element . . . . . . . . . . . . . . 14
	6. Path of Request: <path> Element . . . . . . . . . . . . . . . 13		7. Mapping a Location and Service to URLs: <findService> . . . . 15
	7. Mapping a Location and Service to URLs: <findService> . . . . 14		7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14		7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14		7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 15
	7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 14		7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 16
	7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 15		7.3. Components of the <findService> Request . . . . . . . . . 18
	7.3. Components of the <findService> Request . . . . . . . . . 17		7.3.1. The <location> Element . . . . . . . . . . . . . . . . 18
	7.3.1. The <location> Element . . . . . . . . . . . . . . . . 17		7.3.2. Identifying the Service: The <service> Element . . . 19
	7.3.2. Identifying the Service: The <service> Element . . . 18		7.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 19
	7.3.3. Recursion . . . . . . . . . . . . . . . . . . . . . . 18		7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 19
	7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 18		7.3.5. Requesting Civic Location Validation . . . . . . . . . 19
	7.3.5. Requesting Civic Location Validation . . . . . . . . . 18
	7.4. Components of the Mapping Response		7.4. Components of the Mapping Response
	<findServiceResponse> . . . . . . . . . . . . . . . . . . 20		<findServiceResponse> . . . . . . . . . . . . . . . . . . 21
	7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 20		7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21
	7.4.2. Civic Address Validation: the		7.4.2. Civic Address Validation: the
	<locationValidation> Element . . . . . . . . . . . . . 21		<locationValidation> Element . . . . . . . . . . . . . 22
	8. Retrieving the Service Boundary via <getServiceBoundary> . . . 22		8. Retrieving the Service Boundary via <getServiceBoundary> . . . 23
	9. List Services: <listServices> . . . . . . . . . . . . . . . . 25		9. List Services: <listServices> . . . . . . . . . . . . . . . . 26
	10. List Services By Location: <listServicesByLocation> . . . . . 26		10. List Services By Location: <listServicesByLocation> . . . . . 27
	11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 28		11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 29
	11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 29		11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 30
	11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 32		11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 33
	11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 33		11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 34
	12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 34		12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 35
	12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 34		12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 35		12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 36
	12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 36		12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 37
	13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 37		13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 38
	14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 38		14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 39
	15. Internationalization Considerations . . . . . . . . . . . . . 45		15. Internationalization Considerations . . . . . . . . . . . . . 46
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
	16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 46		16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 47
	16.2. Content-type registration for 'application/lost+xml' . . . 46		16.2. Content-type registration for 'application/lost+xml' . . . 47
	16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 48		16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 49
	16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 48		16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 49
	16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 49		16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 50
	17. Security Considerations . . . . . . . . . . . . . . . . . . . 50		17. Security Considerations . . . . . . . . . . . . . . . . . . . 51
	18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51		18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
	19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 53		19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 54
	20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54		20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
	20.1. Normative References . . . . . . . . . . . . . . . . . . . 54		20.1. Normative References . . . . . . . . . . . . . . . . . . . 55
	20.2. Informative References . . . . . . . . . . . . . . . . . . 55		20.2. Informative References . . . . . . . . . . . . . . . . . . 56
	Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 56		Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 57
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
	Intellectual Property and Copyright Statements . . . . . . . . . . 71		Intellectual Property and Copyright Statements . . . . . . . . . . 71
	1. Introduction		1. Introduction
			Numerous techniques have been specified for the discovery of servers
			for a particular service, including NAPTR records, SVRLOC and similar
			protocols. However, there are an important class of services where
			the specific service instance that is to be connected to depends on
			the identity of the service and the location of the entity that needs
			to reach it. An example of this is emergency telecommunications
			services, where the service instance is a Public Safety Answering
			Point (PSAP) that has jurisdiction over the location of the user
			making the call. Here, the desired PSAP isn't necessarily the one
			that is topologically or even line-of-sight closest to the caller;
			rather, it is the one that serves the callers location based on
			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
	[10] and location information compatible with PIDF-LO [7], namely		[9] and location information compatible with PIDF-LO [6], namely
	revised civic location information [11] and GML [13]) to one or more		revised civic location information [10] and GML [12]) to one or more
	service URL. Example service URL schemes include sip [14], xmpp		service URL. Example service URL schemes include sip [14], xmpp
	[15], and tel [16]. While the initial focus is on providing mapping		[15], and tel [16]. While the initial focus is on providing mapping
	functions for emergency services, it is likely that the protocol is		functions for emergency services, it is likely that the protocol is
	applicable to any service URN. For example, in the United States,		applicable to any service URN. For example, in the United States,
	the "2-1-1" and "3-1-1" service numbers follow a similar location-to-		the "2-1-1" and "3-1-1" service numbers follow a similar location-to-
	service behavior as emergency services.		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
	skipping to change at page 4, line 31		skipping to change at page 4, line 45
	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 (see Section 3.5 of [18]
	for a description of validation). LoST indicates errors in the		for a description of validation). LoST indicates errors in the
	location data to facilitate debugging and proper user feedback, but		location data to facilitate debugging and proper user feedback, but
	also provides best-effort answers.		also provides 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
	caches individual mappings and indicates the region for which the		supports caching of individual mappings and indicates the region for
	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. Later		integrity and confidentiality of requests and responses.
	documents may describe how LoST messages could be carried over other
	transports.
	This document focuses on the description of the protocol between the		This document focuses on the description of the protocol between the
	mapping client and the mapping server. The relationship between		mapping client and the mapping server. Other functions, such as
	other functions, such as discovery of mapping servers, data		discovery of mapping servers, data replication and the overall
	replication and the overall mapping server architecture are described		mapping server architecture are described in a separate document
	in a separate document [19].		[19].
	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 [10]) 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 7, the protocol also
	allows to retrieve the service boundary (see Section 8) and to list		allows to retrieve the service boundary (see Section 8) and to list
	the services available for a particular location (see Section 10) or		the services available for a particular location (see Section 10) or
	supported by a particular server (see Section 9).		supported by a particular server (see Section 9).
	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 furthermore uses the terminology defined in [18].		This document uses the following terms:
			Mapping:
			Mapping is a process that takes a location and a service
			identifier as inputs and returns one or more URIs that point to a
			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
			of the potential for LoST to be used for non-emergency services.
			LoST Client and Server:
			"LoST client" is the role played by an entity that sends LoST
			query messages and receives LoST response messages. "LoST server"
			is the role played by an entity that receives LoST query messages
			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:
			A service boundary is the boundary or set of boundaries of a
			geographic region, respectively set of geographic regions, within
			which all locations will map to the same URI or set of URIs for a
			given service.
			Validation:
			The term "validation" as used in this document is a concrete
			realization of the term "location validation" as defined in
			Section 3.5 of [18].
			Additional emergency service terminology can be found in [18].
	3. Overview of Protocol Usage		3. Overview of Protocol Usage
	The client may perform the mapping at any time. Among the common		The LoST protocol supports the following type of queries and
	triggers for mapping requests are:		responses:
			<findService> and <findServiceResponse>
			This message pattern allows to perform retrieve contact URIs based
			on location information together with a service identifier. The
			same query type may also ask for location validation and for
			service numbers, either integrated into mapping request or
			separately. The details can be found in Section 7 and
			Section 7.4.
			<getServiceBoundary> and <getServiceBoundaryResponse>
			This message pattern allows query for a service boundary. The
			details can be found in Section 8.
			<listServices> and <listServicesResponse>
			This message pattern enables a LoST client to ask a LoST server
			for the services it supports. The details can be found in
			Section 9.
			<listServicesByLocation> and <listServicesByLocationResponse>
			This message pattern provides the LoST client with the services
			that are available for a specific location region. The details
			can be found in Section 10.
			LoST clients may initiate any of the above queries at any time.
			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.
	returned in an earlier LoST query.
	3. When cached mapping information has expired.		3. An incoming message at a SIP proxy in a location-based routing
			scenario that requires a routing decision to be made.
	4. When invoking a particular service. At that time, a client may		4. When cached mapping information has expired.
			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.3), 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
	A LoST server may be discovered using a U-NAPTR/DDDS [12] application		LoST servers are identified by U-NAPTR/DDDS [11] application unique
	unique string (AUS), in the form of a DNS name.		strings, in the form of a DNS name.
	An example is 'lostserver.example.com'		An example is 'lostserver.example.com'
	Clients need to use the U-NAPTR [12] specification described below to		Clients need to use the U-NAPTR [11] 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 AUS		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.
	example.com.		example.com.
	IN NAPTR 100 10 "u" "LoST:https"		IN NAPTR 100 10 "u" "LoST:https"
	"!*.!https://lostserver.example.com/secure!" ""		"!.*!https://lostserver.example.com/secure!" ""
	IN NAPTR 200 10 "u" "LoST:http"		IN NAPTR 200 10 "u" "LoST:http"
	"!*.!http://lostserver.example.com!" ""		"!.*!http://lostserver.example.com!" ""
	Clients learn the LoST server's AUS by means beyond the scope of this		Clients learn the LoST server's host name by means beyond the scope
	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. Data source and version: The 'source', 'sourceId' and 'version'		5.1. The Data Source: 'source', 'sourceId' and 'lastUpdated' Attributes
	Attributes
	The 'source', 'sourceId' and 'version' attributes uniquely identify a		The 'source', the 'sourceId' and the 'lastUpdated' attributes
	particular mapping record. They are created by the authoritative		uniquely identify a particular mapping record. They are created by
	source for a mapping and never modified when a mapping is served from		the authoritative source for a mapping and never modified when a
	a cache. All three attributes are REQUIRED for all <mapping>		mapping is served from a cache. All three attributes are REQUIRED
	elements. A receiver can replace a mapping with another one having		for all <mapping> elements. A receiver can replace a mapping with
	the same 'source' and 'sourceId' and a higher version number.		another one having the same 'source' and 'sourceId' and a more recent
			datum 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. See
	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 'version' attribute is a positive integer that is incremented for		The 'lastUpdated' attribute describes when a specific instance of
	each change in the mapping. The XML data type does not specify an		mapping, identified by the combination of 'source' and 'sourceId',
	upper bound for this attribute and thus, the value MUST NOT wrap		was last changed. The contents of this attribute has the XML data
	around. Thus, a higher version number refers to a more recent		type dateTime in its timezoned form, using canonical UTC
	mapping. A mapping maintains its sourceId value as long as it		representation with the letter 'Z' as the timezone indicator.
	remains logically the same, e.g., represents the same service
	boundary or replaces an earlier service boundary.
	5.2. Time of Last Update: The 'lastUpdated' Attribute
	The 'lastUpdated' attribute describes when the mapping was last
	changed. The contents of this attribute has the XML data type
	dateTime in its timezoned form, using canonical UTC representation
	with the letter 'Z' as the timezone indicator. The attribute is
	REQUIRED.
	5.3. Validity: The 'expires' Attribute		5.2. 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
			'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is
			an indication that the mapping should not be cached. The value of
			'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.		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
			responsibility of the client to check the 'expires' attribute
			associated with mapping data returned in a LoST response to detemine
			whether the mapping is fresh.
	5.4. 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.5. 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 <service> element identifies the service for which this mapping
	applies. Two cases need to be distinguished when the LoST server		applies. Two cases need to be distinguished when the LoST server
	sets the <service> element in the response message:		sets the <service> element in the response message:
	1. If the requested service, identified by the service URN [10] 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 puts 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
	[10] 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 12.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		The <service> element is optional but may also be required if the
	mapping is to be digitally signed.		mapping is to be digitally signed.
	5.6. 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.7). 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 different location profile, identified by the 'profile' atribute
	(see Section 11). The response MUST contain at least one service		(see Section 11). If included in a response, the <serviceBoundary>
	boundary using the same profile as the request. The client only		element MUST contain at least one service boundary that uses the same
	processes the first element that it can understand according to its		profile as the request. The client only processes the first element
	list of supported location profiles. Thus, elements with geospatial		that it can understand according to its list of supported location
	coordinates are alternative descriptions of the same service region,		profiles. Thus, elements with geospatial coordinates are alternative
	not additive geometries.		descriptions of the same service region, not additive geometries.
			A service boundary is requested by the client (using the
			'serviceBoundary' attribute in the request with the value set to
			"value").
	A response MAY contain more than one <serviceBoundary> element with		A response MAY contain more than one <serviceBoundary> element with
	profile 'civic'. Each <serviceBoundary> element describes a set of		profile 'civic'. Each <serviceBoundary> element describes a set of
	civic addresses that fall within the service boundary, namely all		civic addresses that fall within the service boundary, namely all
	addresses that textually match the civic address elements provided,		addresses that textually match the civic address elements provided,
	regardless of the value of other address elements. A location falls		regardless of the value of other address elements. A location falls
	within the mapping's service boundary if it matches any of the		within the mapping's service boundary if it matches any of the
	<serviceBoundary> elements.		<serviceBoundary> elements.
	5.7. 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		thus be quite large, clients may opt to conserve bandwidth and
	request a reference to the service boundary instead of the value		request a reference to the service boundary instead of the value
	described in Section 5.6. 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 8) request.
			A reference to a service boundary is requested by the client (using
			the 'serviceBoundary' attribute in the request with the value set to
			"reference"). A LoST server may decide, based on local policy, to
			return the service boundary per value or to omit the
			<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 the remainder of the mapping has become invalid.
	5.8. The Service Number Element		5.7. The Service Number 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.9. 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 Request: <path> Element		6. Path of a Request: <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 first		i.e., the first <via> element identifies the server that initially
	received the request from the client. The authoritative server		received the request from the client issuing the request. The <via>
	copies the <path> element verbatim into the response.		element is inserted logically on receipt of the request, so that
			every server in a recursive query operation is included in the <path>
			element.
			The server that answers the request instead of forwarding it, such as
			the authoritative server, copies the <path> element verbatim into the
			response. The <path> element is not modified in responses as the
			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.
	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
	responding server by the LoST server at esgw.ueber-110.de.example,		client by the LoST server at esgw.ueber-110.de.example, which got the
	which got the answer from the 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. Mapping a Location and Service to URLs: <findService>
	7.1. Overview		7.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.
	skipping to change at page 14, line 44		skipping to change at page 15, line 44
	<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 Deparment, instructing the client
	that it may contact them via the URIs "sip:sfpd@example.com" and		that it may contact them via the URIs "sip:nypd@example.com" and
	"xmpp:sfpd@example.com". The server has also given the client a		"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" version="1">
	<displayName xml:lang="en">		<displayName xml:lang="en">
	San Francisco 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:sfpd@example.com</uri>		<uri>sip:nypd@example.com</uri>
	<uri>xmpp:sfpd@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="authoritative.example"/>
	<via source="resolver.example"/>		<via source="resolver.example"/>
	</path>		</path>
	</findServiceResponse>		</findServiceResponse>
	Figure 3: A <findServiceResponse> geodetic answer		Figure 3: A <findServiceResponse> geodetic answer
	skipping to change at page 17, line 42		skipping to change at page 18, line 42
	<via source="polizei.muenchen.de.example"/>		<via source="polizei.muenchen.de.example"/>
	</path>		</path>
	</findServiceResponse>		</findServiceResponse>
	Figure 5: A <findServiceResponse> civic address answer		Figure 5: A <findServiceResponse> civic address answer
	7.3. Components of the <findService> Request		7.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 must be contained in the		validation is performed and which elements may be contained in the
	response.		response.
	7.3.1. The <location> Element		7.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 11). 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 objects is
	significant; the server uses the first location object where it		significant; the server uses the first location object where it
	understands the location profile.		understands the location profile.
	7.3.2. Identifying the Service: The <service> Element		7.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 [10].		It contains service URNs from the registry established in [9].
	7.3.3. Recursion		7.3.3. Recursion and Iteration
	LoST <findService> and <listServicesByLocation> queries can be		LoST can operate in either recursive or iterative mode, on a request-
	recursive, as indicated by the 'recursive' attribute. A value of		by-request basis. In recursive mode, the LoST server initiates
	"true" indicates a recursive query, with the default being "false"		queries on behalf of the requester and returns the result to the
	when the attribute is omitted. Regardless of the attribute, a server		requester.
	MAY always answer a query by providing a LoST application unique
	string (see Section 4), i.e., indirection, however, it MUST NOT
	recurse if the attribute is "false".
	In recursive mode, the LoST server initiates queries on behalf of the		In iterative mode, the server contacted returns a redirection
	requester and returns the result to the requester, inserting a <via>		response indicating the next server to be queried.
	element to track the response chain. The <via> elements are appended
	in responses in order of visit, i.e., the first <via> element		For the queries defined in this document, only LoST <findService> and
	contains the authoritative server and <via> elements below indicate		<listServicesByLocation> queries can be recursive, as indicated by
	servers that the response traversed on its way back to the original		the 'recursive' attribute. A value of "true" indicates a recursive
	querier.		query, with the default being "false" when the attribute is omitted.
			Regardless of the attribute, a server MAY always answer a query by
			providing a LoST application unique string (see Section 4), i.e.,
			indirection, however, it MUST NOT recurse if the attribute is
			"false".
	7.3.4. Service Boundary		7.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. Servers SHOULD NOT		to whether to return a reference or a value.
	return a by-value service boundaries if the querier requested a
	reference.
	7.3.5. Requesting Civic Location Validation		7.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 7.4.2. The example in Figure 6 demonstrates address
	validation, omitting the standard response elements.		validation, omitting the standard response elements.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	skipping to change at page 21, line 9		skipping to change at page 22, line 9
	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 12.2), location validation information (Section 7.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		7.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 MUST 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. Each element contains a list of tokens separated by white		true but local policy at the server may allow this information to be
			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 lables 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.
	skipping to change at page 22, line 7		skipping to change at page 23, line 7
	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 (Figure 6) indicates that the tokens 'country', 'A1',
	'A3', and 'A6' have been validated by the LoST server. The server		'A3', and 'A6' have been validated by the LoST server. The server
	considered the postal code 81675 in the <PC> element as not valid for		considered the postal code 81675 in the <PC> element as not valid for
	this location.		this location.
	8. Retrieving the Service Boundary via <getServiceBoundary>		8. Retrieving the Service Boundary via <getServiceBoundary>
	As discussed in Section 5.6, 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.
	The client can then retrieve the boundary using the		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 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">		version="1">
	<displayName xml:lang="en">		<displayName xml:lang="en">
	San Francisco 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:sfpd@example.com</uri>		<uri>sip:nypd@example.com</uri>
	<uri>xmpp:sfpd@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="authoritative.example"/>
	<via source="resolver.example"/>		<via source="resolver.example"/>
	</path>		</path>
	</findServiceResponse>		</findServiceResponse>
	Figure 9: <findServiceResponse> message with service boundary		Figure 9: <findServiceResponse> message with service boundary
	reference		reference
	skipping to change at page 26, line 39		skipping to change at page 27, line 39
	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 profile="geodetic-2d">
	<p2:Point id="point1" srsName="epsg:4326">		<p2:Point srsName="urn:ogc:def:crs:EPSG::4326">
	<p2:coordinates>37:46:30N 122:25:10W</p2:coordinates>		<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
	xmlns="urn:ietf:params:xml:ns:lost1">		xmlns="urn:ietf:params:xml:ns:lost1">
	<serviceList>		<serviceList>
	skipping to change at page 29, line 41		skipping to change at page 30, line 41
	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 geodetic-2d or civic, it MUST also send, in
	the same request, location information conformant to one of the		the same request, location information conformant to one of the
	baseline profiles. Otherwise, the server might not be able to		baseline profiles. Otherwise, the server might not be able to
	understand the request.		understand the request.
	3. There can only be one instance of each location profile in a		3. A client SHOULD NOT send multiple <location> profiles of derived
			from different baseline profiles. Or said another way, a client
			should only send location profiles from the same baseline profile
			in the same query. If a client has location information
			primarily of geodetic nature and location information primarily
			of a civic nature, it should send separate requests containing
			each type of location information.
			4. There can only be one instance of each location profile in a
	query.		query.
	4. Servers MUST implement the geodetic-2d and civic profiles.		5. Servers MUST implement the geodetic-2d and civic profiles.
	5. A server uses the first-listed location profile that it		6. A server uses the first-listed location profile that it
	understands and ignores the others.		understands and ignores the others.
	6. If a server receives a request that only contains location		7. 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 12.1).
	7. The <serviceBoundary> element MUST use the same location profile		8. 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		uber-complex-3D location profile. Client X sends location
	information to Server Y, which does not understand the		information to Server Y, which does not understand the
	uber-complex-3D location profile. If Client X also sends location		uber-complex-3D location profile. If Client X also sends location
	information using the geodetic-2D baseline profile, then Server Y		information using the geodetic-2D baseline profile, then Server Y
	skipping to change at page 31, line 12		skipping to change at page 32, line 12
	not be as precise or expressive as desired. This is possible because		not be as precise or expressive as desired. This is possible because
	both Client X and Server Y understand the baseline profile.		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:p2="http://www.opengis.net/gml"
	recursive="true"		recursive="true"
	serviceBoundary="value">		serviceBoundary="value">
	<location profile="uber-complex-3d">		<location profile="uber-complex-3d">
	<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>
	<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>
	<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">		<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
	<p2:pos>-122.422 37.775</p2:pos>		<p2:pos>-122.422 37.775</p2:pos>
	</p2:Point>		</p2:Point>
	</location>		</location>
	<location profile="geodetic-2d">		<location 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 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">		version="1">
	<displayName xml:lang="en">		<displayName xml:lang="en">
	San Francisco 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>
	skipping to change at page 32, line 45		skipping to change at page 33, line 45
	<via source="resolver.example"/>		<via source="resolver.example"/>
	</path>		</path>
	</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		11.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 GML [13] <position> element		Clients use this profile by placing a <Point> element, as described
	within the <location> element. This is defined by the 'point2D'		in Section 7.2.1 of [13], within the <location> element. Section
	pattern in the LoST schema (see Section 14).		7.2.1 of [13] describes the specification of a <Point> with either a
			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 GML [13] <Polygon> element		Servers use this profile by placing a <Polygon> element, as described
	within the <serviceBoundary> element. This is defined by the		in Section 7.2.2 of [13], within the <serviceBoundary> element. This
	'polygon' pattern in the LoST schema (see Section 14).		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
			restriction to 16 points for a polygon is not applicable to this
			document. With this profile servers MUST use WGS 84 (latitude,
			longitude), i.e., the srsName set to 'urn:ogc:def:crs:EPSG::4326'
			where altitude information is omitted. The orientation of the points
			in the polygon is upward normal as described in Section 7.2.2 of
			[13].
	11.3. Basic Civic Profile		11.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 [11], 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 [11], within the <serviceBoundary> element.		in [10], within the <serviceBoundary> element.
	12. Errors, Warnings, and Redirects		12. 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. For both		response may not be quite what the client had desired. This document
	elements, the 'source' attribute names the server that originally		does not define warnings. For both elements, the 'source' attribute
	generated the error or warning, such as the authoritative server.		names the server that originally generated the error or warning, such
	Unless otherwise noted, all elements below can be either an error or		as the authoritative server. Unless otherwise noted, all elements
	a warning, depending on whether a default response, such as a		below can be either an error or a warning, depending on whether a
	mapping, is included.		default response, such as a mapping, is included.
	12.1. Errors		12.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:
	skipping to change at page 38, line 10		skipping to change at page 39, line 10
	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. All HTTP responses are applicable. The HTTP URL is
	derived from the LoST server name via U-NAPTR application, as		derived from the LoST server name via U-NAPTR application, as
	discussed above		discussed above
	14. Relax NG Schema		14. 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.
	default namespace = "http://www.opengis.net/gml"
	namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"		namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
	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)
	##		##
	## 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.
	##		##
	start =		start =
	findService		findService
	skipping to change at page 38, line 38		skipping to change at page 39, line 37
	| listServicesByLocationResponse		| listServicesByLocationResponse
	| getServiceBoundaryResponse		| getServiceBoundaryResponse
	| errors		| errors
	| redirect		| redirect
	##		##
	## The queries.		## The queries.
	##		##
	div {		div {
	findService =		findService =
	element ns1:findService {		element findService {
	element ns1:location { locationInformation }+,		element location { locationInformation }+,
	commonRequestPattern,		commonRequestPattern,
	attribute validateLocation {		attribute validateLocation {
	xsd:boolean >> a:defaultValue [ "false" ]		xsd:boolean >> a:defaultValue [ "false" ]
	}?,		}?,
	attribute serviceBoundary {		attribute serviceBoundary {
	("reference" | "value") >> a:defaultValue [ "reference" ]		("reference" | "value") >> a:defaultValue [ "reference" ]
	}?,		}?,
	attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?		attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }?
	}		}
	listServices = element ns1:listServices { commonRequestPattern }		listServices = element listServices { commonRequestPattern }
	listServicesByLocation =		listServicesByLocation =
	element ns1:listServicesByLocation {		element listServicesByLocation {
	element ns1:location { locationInformation }*,		element location { locationInformation }*,
	commonRequestPattern,		commonRequestPattern,
	attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?		attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
	}		}
	getServiceBoundary =		getServiceBoundary =
	element ns1:getServiceBoundary {		element getServiceBoundary { serviceBoundaryKey, extensionPoint }
	serviceBoundaryKey, extensionPoint
	}
	}		}
	##		##
	## The responses.		## The responses.
	##		##
	div {		div {
	findServiceResponse =		findServiceResponse =
	element ns1:findServiceResponse {		element findServiceResponse {
	mapping+, locationValidation?, commonResponsePattern		mapping+, locationValidation?, commonResponsePattern
	}		}
	listServicesResponse =		listServicesResponse =
	element ns1:listServicesResponse {		element listServicesResponse { serviceList, commonResponsePattern }
	serviceList, commonResponsePattern
	}
	listServicesByLocationResponse =		listServicesByLocationResponse =
	element ns1:listServicesByLocationResponse {		element listServicesByLocationResponse {
	serviceList, commonResponsePattern		serviceList, commonResponsePattern
	}		}
	getServiceBoundaryResponse =		getServiceBoundaryResponse =
	element ns1:getServiceBoundaryResponse {		element getServiceBoundaryResponse {
	serviceBoundary, commonResponsePattern		serviceBoundary, commonResponsePattern
	}		}
	}		}
	##		##
	## A pattern common to some of the queries.		## A pattern common to some of the queries.
	##		##
	div {		div {
	commonRequestPattern = service, extensionPoint		commonRequestPattern = service, path?, extensionPoint
	}		}
	##		##
	## A pattern common to responses.		## A pattern common to responses.
	##		##
	div {		div {
	commonResponsePattern = warnings*, path, extensionPoint		commonResponsePattern = warnings*, path, extensionPoint
	}		}
	##		##
	skipping to change at page 40, line 18		skipping to change at page 41, line 12
	div {		div {
	locationInformation =		locationInformation =
	extensionPoint+,		extensionPoint+,
	attribute profile { xsd:NMTOKEN }		attribute profile { xsd:NMTOKEN }
	}		}
	##		##
	## Service Boundary		## Service Boundary
	##		##
	div {		div {
	serviceBoundary = element ns1:serviceBoundary { locationInformation }+		serviceBoundary = element serviceBoundary { locationInformation }+
	}		}
	##		##
	## Service Boundary Reference		## Service Boundary Reference
	##		##
	div {		div {
	serviceBoundaryReference =		serviceBoundaryReference =
	element ns1:serviceBoundaryReference {		element serviceBoundaryReference {
	source, serviceBoundaryKey, extensionPoint		source, serviceBoundaryKey, extensionPoint
	}		}
	serviceBoundaryKey = attribute key { xsd:token }		serviceBoundaryKey = attribute key { xsd:token }
	}		}
	##		##
	## Path -		## Path -
	## Contains a list of via elements -		## Contains a list of via elements -
	## places through which information flowed		## places through which information flowed
	##		##
	div {		div {
	path =		path =
	element ns1:path {		element path {
	element ns1:via { source, extensionPoint }*		element via { source, extensionPoint }+
	}		}
	}		}
	##		##
	## Expires pattern		## Expires pattern
	##		##
	div {		div {
	expires = attribute expires { xsd:dateTime }		expires =
			attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
	}		}
	##		##
	## A QName list		## A QName list
	##		##
	div {		div {
	qnameList = list { xsd:QName* }		qnameList = list { xsd:QName* }
	}		}
	##		##
	## A location-to-service mapping.		## A location-to-service mapping.
	##		##
	div {		div {
	mapping =		mapping =
	skipping to change at page 41, line 15		skipping to change at page 42, line 10
	##		##
	div {		div {
	qnameList = list { xsd:QName* }		qnameList = list { xsd:QName* }
	}		}
	##		##
	## A location-to-service mapping.		## A location-to-service mapping.
	##		##
	div {		div {
	mapping =		mapping =
	element ns1:mapping {		element mapping {
	element ns1:displayName {		element displayName {
	xsd:string,		xsd:string,
	attribute xml:lang { xsd:language }		attribute xml:lang { xsd:language }
	}*,		}*,
	service,		service,
	(serviceBoundary | serviceBoundaryReference)?,		(serviceBoundary | serviceBoundaryReference)?,
	element ns1:uri { xsd:anyURI }*,		element uri { xsd:anyURI }*,
	element ns1:serviceNumber {		element serviceNumber {
	xsd:string { pattern = "[0-9*#]+" }		xsd:string { pattern = "[0-9*#]+" }
	}?,		}?,
	extensionPoint,		extensionPoint,
	expires,		expires,
	attribute lastUpdated { xsd:dateTime },		attribute lastUpdated { xsd:dateTime },
	source,		source,
	attribute sourceId { xsd:token },		attribute sourceId { xsd:token },
	attribute version { xsd:positiveInteger },
	message		message
	}		}
	}		}
	##		##
	## Location validation		## Location validation
	##		##
	div {		div {
	locationValidation =		locationValidation =
	element ns1:locationValidation {		element locationValidation {
	element ns1:valid { qnameList }?,		element valid { qnameList }?,
	element ns1:invalid { qnameList }?,		element invalid { qnameList }?,
	element ns1:unchecked { qnameList }?,		element unchecked { qnameList }?,
	extensionPoint		extensionPoint
	}		}
	}		}
	##		##
	## Errors and Warnings Container.		## Errors and Warnings Container.
	##		##
	div {		div {
	errorContainer =		errorContainer =
	(badRequest?		(badRequest?
	skipping to change at page 42, line 17		skipping to change at page 43, line 11
	& serviceSubstitution?		& serviceSubstitution?
	& forbidden?		& forbidden?
	& notFound?		& notFound?
	& loop?		& loop?
	& serviceNotImplemented?		& serviceNotImplemented?
	& serverTimeout?		& serverTimeout?
	& serverError?		& serverError?
	& locationProfileUnrecognized?),		& locationProfileUnrecognized?),
	extensionPoint,		extensionPoint,
	source		source
	errors = element ns1:errors { errorContainer }		errors = element errors { errorContainer }
	warnings = element ns1:warnings { errorContainer }		warnings = element warnings { errorContainer }
	}		}
	##		##
	## Basic Errors		## Basic Errors
	##		##
	div {		div {
	##		##
	## Error pattern.		## Error pattern.
	##		##
	basicError = message, extensionPoint		basicError = message, extensionPoint
	badRequest = element ns1:badRequest { basicError }		badRequest = element badRequest { basicError }
	internalError = element ns1:internalError { basicError }		internalError = element internalError { basicError }
	serviceSubstitution = element ns1:serviceSubstitution { basicError }		serviceSubstitution = element serviceSubstitution { basicError }
	forbidden = element ns1:forbidden { basicError }		forbidden = element forbidden { basicError }
	notFound = element ns1:notFound { basicError }		notFound = element notFound { basicError }
	loop = element ns1:loop { basicError }		loop = element loop { basicError }
	serviceNotImplemented =		serviceNotImplemented = element serviceNotImplemented { basicError }
	element ns1:serviceNotImplemented { basicError }		serverTimeout = element serverTimeout { basicError }
	serverTimeout = element ns1:serverTimeout { basicError }		serverError = element serverError { basicError }
	serverError = element ns1:serverError { basicError }
	locationProfileUnrecognized =		locationProfileUnrecognized =
	element ns1:locationProfileUnrecognized {		element locationProfileUnrecognized {
	attribute unsupportedProfiles { xsd:NMTOKENS },		attribute unsupportedProfiles { xsd:NMTOKENS },
	basicError		basicError
	}		}
	}		}
	##		##
	## Redirect.		## Redirect.
	##		##
	div {		div {
	##		##
	## Redirect pattern		## Redirect pattern
	##		##
	redirect =		redirect =
	element ns1:redirect {		element redirect {
	attribute target { appUniqueString },		attribute target { appUniqueString },
	source,		source,
	message,		message,
	extensionPoint		extensionPoint
	}		}
	}		}
	##		##
	## Some common patterns.		## Some common patterns.
	##		##
	div {		div {
	message =		message =
	(attribute message { xsd:string },		(attribute message { xsd:string },
	attribute xml:lang { xsd:language })?		attribute xml:lang { xsd:language })?
	service = element ns1:service { xsd:anyURI }?		service = element service { xsd:anyURI }?
	appUniqueString =		appUniqueString =
	xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }		xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }
	source = attribute source { appUniqueString }		source = attribute source { appUniqueString }
	serviceList =		serviceList =
	element ns1:serviceList {		element serviceList {
	list { xsd:anyURI* }		list { xsd:anyURI* }
	}		}
	}		}
	##		##
	## Patterns for inclusion of elements from schemas in		## Patterns for inclusion of elements from schemas in
	## other namespaces.		## other namespaces.
	##		##
	div {		div {
	skipping to change at page 44, line 4		skipping to change at page 44, line 45
	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*
	##
	## A 2D point from GML.
	##
	point2d =
	element Point {
	attribute srsName { "urn:ogc:def:crs:EPSG::4326" },
	pos
	}
	##
	## A GML position
	##
	pos =
	element pos {
	list { xsd:double }
	}
	##
	## A Linear Ring from GML.
	##
	linearRing = element LinearRing { pos, pos, pos, pos+ }
	##
	## A Polygon from GML.
	##
	polygon =
	element Polygon {
	attribute srsName { "urn:ogc:def:crs:EPSG::4326" },
	element exterior { linearRing },
	element interior { linearRing }*
	}
	}		}
	Figure 20: RelaxNG schema		Figure 20: RelaxNG schema
	15. Internationalization Considerations		15. Internationalization Considerations
	This mechanism is largely for passing protocol information from one		This mechanism is largely for passing protocol information from one
	subsystem to another; as such, most of its elements are tokens not		subsystem to another; as such, most of its elements are tokens not
	meant for direct human consumption. If these tokens are presented to		meant for direct human consumption. If these tokens are presented to
	the end user, some localization may need to occur. The content of		the end user, some localization may need to occur. The content of
	skipping to change at page 46, line 35		skipping to change at page 47, line 35
	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'		16.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 [8] 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
	skipping to change at page 48, line 7		skipping to change at page 49, line 7
	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> delegated to the IETF ECRIT working		The IESG <iesg@ietf.org>
	group, if it is still active.
	16.3. LoST Relax NG Schema Registration		16.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@siemens.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 14. Its first line is
	skipping to change at page 51, line 27		skipping to change at page 52, line 27
	o Martin Thomson (Review December 2006)		o Martin Thomson (Review December 2006)
	o Barbara Stark (Review January 2007)		o Barbara Stark (Review January 2007)
	o Patrik Faeltstroem (Review January 2007		o Patrik Faeltstroem (Review January 2007
	o Shida Schubert (Review January 2007 as a designated expert		o Shida Schubert (Review January 2007 as a designated expert
	reviewer)		reviewer)
			o Jonathan Rosenberg (Review February 2007)
			o Tom Taylor (Review February 2007)
			o Theresa Reese (Review February 2007)
			o Shida Schubert (Review February 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 52, line 22		skipping to change at page 53, line 30
	Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage,		Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage,
	Keith (List Services functionality)		Keith (List Services functionality)
	o Thomson, Martin, Michael Hammer (Mapping of Services)		o Thomson, Martin, Michael Hammer (Mapping of Services)
	o Shida Schubert, James Winterbottom, Keith Drage (default service		o Shida Schubert, James Winterbottom, Keith Drage (default service
	URN)		URN)
	o Otmar Lendl (LoST aggregation)		o Otmar Lendl (LoST aggregation)
			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		19. Open Issues
	Please find open issues at: http://www.ietf-ecrit.org:8080/lost/		Please find open issues at: http://www.ietf-ecrit.org:8080/lost/
	20. References		20. References
	skipping to change at page 54, line 25		skipping to change at page 55, line 25
	[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,		[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
	Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --		Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
	HTTP/1.1", RFC 2616, June 1999.		HTTP/1.1", RFC 2616, June 1999.
	[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[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] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[6] Peterson, J., "A Presence-based GEOPRIV Location Object
	Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
	January 2005.
	[7] Peterson, J., "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005.		Format", RFC 4119, December 2005.
	[8] 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.
	[9] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and		[8] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
	Registration Procedures for New URI Schemes", BCP 115,		Registration Procedures for New URI Schemes", BCP 115,
	RFC 4395, February 2006.		RFC 4395, February 2006.
	[10] 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-05 (work in progress),
	August 2006.		August 2006.
	[11] 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-04 (work in		for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
	progress), September 2006.		progress), February 2007.
	[12] Daigle, L., "Domain-based Application Service Location Using		[11] Daigle, L., "Domain-based Application Service Location Using
	URIs and the Dynamic Delegation Discovery Service (DDDS)",		URIs and the Dynamic Delegation Discovery Service (DDDS)",
	draft-daigle-unaptr-01 (work in progress), October 2006.		draft-daigle-unaptr-02 (work in progress), February 2007.
	[13] OpenGIS, "Open Geography Markup Language (GML) Implementation		[12] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
	Specification", OGC OGC 02-023r4, January 2003.		"Geographic information - Geography Markup Language (GML)", OGC
			Standard OpenGIS 03-105r1, April 2004.
			[13] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application
			Schema for use by the Internet Engineering Task Force (IETF)",
			Candidate OpenGIS Implementation Specification , December 2006.
	20.2. Informative References		20.2. Informative References
	[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.
	skipping to change at page 57, line 18		skipping to change at page 58, line 15
	<choice>		<choice>
	<value>reference</value>		<value>reference</value>
	<value>value</value>		<value>value</value>
	</choice>		</choice>
	<a:defaultValue>reference</a:defaultValue>		<a:defaultValue>reference</a:defaultValue>
	</attribute>		</attribute>
	</optional>		</optional>
	<optional>		<optional>
	<attribute name="recursive">		<attribute name="recursive">
	<data type="boolean" />		<data type="boolean" />
	<a:defaultValue>true</a:defaultValue>		<a:defaultValue>false</a:defaultValue>
	</attribute>		</attribute>
	</optional>		</optional>
	</element>		</element>
	</define>		</define>
	<define name="listServices">		<define name="listServices">
	<element name="listServices">		<element name="listServices">
	<ref name="commonRequestPattern" />		<ref name="commonRequestPattern" />
	</element>		</element>
	</define>		</define>
	skipping to change at page 59, line 7		skipping to change at page 60, line 4
	<ref name="commonResponsePattern" />		<ref name="commonResponsePattern" />
	</element>		</element>
	</define>		</define>
	</div>		</div>
	<div>		<div>
	<a:documentation>		<a:documentation>
	A pattern common to some of the queries.		A pattern common to some of the queries.
	</a:documentation>		</a:documentation>
	<define name="commonRequestPattern">		<define name="commonRequestPattern">
	<ref name="service" />		<ref name="service" />
			<optional>
			<ref name="path" />
			</optional>
	<ref name="extensionPoint" />		<ref name="extensionPoint" />
	</define>		</define>
	</div>		</div>
	<div>		<div>
	<a:documentation>		<a:documentation>
	A pattern common to responses.		A pattern common to responses.
	</a:documentation>		</a:documentation>
	<define name="commonResponsePattern">		<define name="commonResponsePattern">
	skipping to change at page 60, line 40		skipping to change at page 61, line 39
	<div>		<div>
	<a:documentation>		<a:documentation>
	Path -		Path -
	Contains a list of via elements -		Contains a list of via elements -
	places through which information flowed		places through which information flowed
	</a:documentation>		</a:documentation>
	<define name="path">		<define name="path">
	<element name="path">		<element name="path">
	<zeroOrMore>		<oneOrMore>
	<element name="via">		<element name="via">
	<ref name="source" />		<ref name="source" />
	<ref name="extensionPoint" />		<ref name="extensionPoint" />
	</element>		</element>
	</zeroOrMore>		</oneOrMore>
	</element>		</element>
	</define>		</define>
	</div>		</div>
	<div>		<div>
	<a:documentation>		<a:documentation>
	Expires pattern		Expires pattern
	</a:documentation>		</a:documentation>
	<define name="expires">		<define name="expires">
	<attribute name="expires">		<attribute name="expires">
			<choice>
	<data type="dateTime"/>		<data type="dateTime"/>
			<value>NO-CACHE</value>
			<value>NO-EXPIRATION</value>
			</choice>
	</attribute>		</attribute>
	</define>		</define>
	</div>		</div>
	<div>		<div>
	<a:documentation>		<a:documentation>
	A QName list		A QName list
	</a:documentation>		</a:documentation>
	<define name="qnameList">		<define name="qnameList">
	skipping to change at page 62, line 23		skipping to change at page 63, line 26
	</optional>		</optional>
	<ref name="extensionPoint"/>		<ref name="extensionPoint"/>
	<ref name="expires"/>		<ref name="expires"/>
	<attribute name="lastUpdated">		<attribute name="lastUpdated">
	<data type="dateTime"/>		<data type="dateTime"/>
	</attribute>		</attribute>
	<ref name="source" />		<ref name="source" />
	<attribute name="sourceId">		<attribute name="sourceId">
	<data type="token" />		<data type="token" />
	</attribute>		</attribute>
	<attribute name="version">
	<data type="positiveInteger" />
	</attribute>
	<ref name="message"/>		<ref name="message"/>
	</element>		</element>
	</define>		</define>
	</div>		</div>
	<div>		<div>
	<a:documentation>		<a:documentation>
	Location validation		Location validation
	</a:documentation>		</a:documentation>
	skipping to change at page 68, line 26		skipping to change at page 69, line 26
	<a:documentation>		<a:documentation>
	A point where future extensions		A point where future extensions
	(elements from other namespaces)		(elements from other namespaces)
	can be added.		can be added.
	</a:documentation>		</a:documentation>
	<zeroOrMore>		<zeroOrMore>
	<ref name="notLost" />		<ref name="notLost" />
	</zeroOrMore>		</zeroOrMore>
	</define>		</define>
	<define name="point2d">
	<a:documentation>
	A 2D point from GML.
	</a:documentation>
	<element name="Point" ns="http://www.opengis.net/gml">
	<attribute name="srsName">
	<value>urn:ogc:def:crs:EPSG::4326</value>
	</attribute>
	<ref name="pos"/>
	</element>
	</define>
	<define name="pos">
	<a:documentation>
	A GML position
	</a:documentation>
	<element name="pos" ns="http://www.opengis.net/gml">
	<list>
	<data type="double"/>
	</list>
	</element>
	</define>
	<define name="linearRing">
	<a:documentation>
	A Linear Ring from GML.
	</a:documentation>
	<element name="LinearRing"
	ns="http://www.opengis.net/gml">
	<ref name="pos"/>
	<ref name="pos"/>
	<ref name="pos"/>
	<oneOrMore>
	<ref name="pos"/>
	</oneOrMore>
	</element>
	</define>
	<define name="polygon">
	<a:documentation>
	A Polygon from GML.
	</a:documentation>
	<element name="Polygon"
	ns="http://www.opengis.net/gml">
	<attribute name="srsName">
	<value>urn:ogc:def:crs:EPSG::4326</value>
	</attribute>
	<element name="exterior">
	<ref name="linearRing"/>
	</element>
	<zeroOrMore>
	<element name="interior">
	<ref name="linearRing"/>
	</element>
	</zeroOrMore>
	</element>
	</define>
	</div>		</div>
	</grammar>		</grammar>
	Figure 24		Figure 24
	Authors' Addresses		Authors' Addresses
	Ted Hardie		Ted Hardie
	Qualcomm, Inc.		Qualcomm, Inc.
End of changes. 128 change blocks.
	357 lines changed or deleted		389 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/