draft-ietf-ecrit-lost-07.txt		draft-ietf-ecrit-lost-08.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 10, 2008 American Registry for Internet		Expires: September 29, 2008 American Registry for Internet
	Numbers		Numbers
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	February 7, 2008		March 28, 2008
	LoST: A Location-to-Service Translation Protocol		LoST: A Location-to-Service Translation Protocol
	draft-ietf-ecrit-lost-07.txt		draft-ietf-ecrit-lost-08.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 40		skipping to change at page 1, line 40
	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 8, 2008.		This Internet-Draft will expire on September 29, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	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 Public Safety Answering Point (PSAP) for
			emergency services.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology and Requirements Notation . . . . . . . . . . . . 6		2. Terminology and Requirements Notation . . . . . . . . . . . . 6
	3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7		3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7
	4. LoST Servers and Their Resolution . . . . . . . . . . . . . . 9		4. LoST Servers and Their Resolution . . . . . . . . . . . . . . 9
	5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 10		5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 10
	5.1. The Mapping Data Source: 'source', 'sourceId' and		5.1. The Mapping Data Source: 'source', 'sourceId' and
	'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10		'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10
	skipping to change at page 3, line 7		skipping to change at page 3, line 8
	<findServiceResponse> . . . . . . . . . . . . . . . . . . 22		<findServiceResponse> . . . . . . . . . . . . . . . . . . 22
	8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22		8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
	8.4.2. Civic Address Validation: the		8.4.2. Civic Address Validation: the
	<locationValidation> Element . . . . . . . . . . . . . 23		<locationValidation> Element . . . . . . . . . . . . . 23
	9. Retrieving the Service Boundary via <getServiceBoundary> . . . 24		9. Retrieving the Service Boundary via <getServiceBoundary> . . . 24
	10. List Services: <listServices> . . . . . . . . . . . . . . . . 27		10. List Services: <listServices> . . . . . . . . . . . . . . . . 27
	11. List Services By Location: <listServicesByLocation> . . . . . 28		11. List Services By Location: <listServicesByLocation> . . . . . 28
	12. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 30		12. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 30
	12.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 31		12.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 31
	12.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 34		12.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 34
	12.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 35		12.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 36
	13. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 37		13. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 37
	13.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 37		13.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	13.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 39		13.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 39
	13.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 40		13.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 40
	14. LoST Transport: HTTP . . . . . . . . . . . . . . . . . . . . . 42		14. LoST Transport: HTTP . . . . . . . . . . . . . . . . . . . . . 42
	15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43		15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43
	16. Internationalization Considerations . . . . . . . . . . . . . 50		16. Internationalization Considerations . . . . . . . . . . . . . 50
	17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51		17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
	17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51		17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51
	17.2. Content-type registration for 'application/lost+xml' . . . 51		17.2. Content-type registration for 'application/lost+xml' . . . 51
	17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53		17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53
	17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53		17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53
	17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54		17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54
	18. Security Considerations . . . . . . . . . . . . . . . . . . . 55		18. Security Considerations . . . . . . . . . . . . . . . . . . . 55
	19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56		19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
	20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58		20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
	20.1. Normative References . . . . . . . . . . . . . . . . . . . 58		20.1. Normative References . . . . . . . . . . . . . . . . . . . 59
	20.2. Informative References . . . . . . . . . . . . . . . . . . 59		20.2. Informative References . . . . . . . . . . . . . . . . . . 60
	Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 60		Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 61
	Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 74		Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 75
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76
	Intellectual Property and Copyright Statements . . . . . . . . . . 76		Intellectual Property and Copyright Statements . . . . . . . . . . 77
	1. Introduction		1. Introduction
	Protocols such as NAPTR records and the Service Location Protocol		Protocols such as NAPTR records and the Service Location Protocol
	(SLP) can be used to discover servers offering a particular service.		(SLP) can be used to discover servers offering a particular service.
	However, for an important class of services the appropriate specific		However, for an important class of services the appropriate specific
	service instance depends both on the identity of the service and the		service instance depends both on the identity of the service and the
	geographic location of the entity that needs to reach it. Emergency		geographic location of the entity that needs to reach it. Emergency
	telecommunications services are an important example; here, the		telecommunications services are an important example; here, the
	service instance is a Public Safety Answering Point (PSAP) that has		service instance is a Public Safety Answering Point (PSAP) that has
	jurisdiction over the location of the user making the call. The		jurisdiction over the location of the user making the call. The
	desired PSAP isn't necessarily the one that is topologically or even		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		line-of-sight closest to the caller; rather, it is the one that
	serves the caller's location based on jurisdictional boundaries.		serves the caller's location based on jurisdictional boundaries.
	This document describes a protocol for mapping a service identifier		This document describes a protocol for mapping a service identifier
	and location information compatible with PIDF-LO PIDF-LO [6] to one		and location information compatible with PIDF-LO [6] to one or more
	or more service URIs. Service identifiers take the form of the		service URIs. Service identifiers take the form of the service URNs
	service URNs described in [9]. Location information here includes		described in [9]. Location information here includes revised civic
	revised civic location information [10] and a subset of the PIDL-LO		location information [10] and a subset of the PIDL-LO profile [13]
	profile [13] which consequently includes the Geo-Shapes [12] defined		which consequently includes the Geo-Shapes [12] defined for GML [11].
	for GML [11]. Example service URI schemes include sip [14], xmpp		Example service URI schemes include sip [14], xmpp [15], and tel
	[15], and tel [16]. While the initial focus is on providing mapping		[16]. While the initial focus is on providing mapping functions for
	functions for emergency services, it is likely that the protocol is		emergency services, it is likely that the protocol is applicable to
	applicable to other service URNs. For example, in the United States,		other service URNs. For example, in the United States, the "2-1-1"
	the "2-1-1" and "3-1-1" service numbers follow a similar location-to-		and "3-1-1" service numbers follow a similar location-to-service
	service behavior as emergency services.		behavior as emergency services.
	This document names this protocol "LoST", for Location-to-Service		This document names this protocol "LoST", for Location-to-Service
	Translation. LoST Satisfies the requirements [18] for mapping		Translation. LoST Satisfies the requirements [18] for mapping
	protocols. LoST provides a number of operations, centered around		protocols. LoST provides a number of operations, centered around
	mapping locations and service URNs to service URLs and associated		mapping locations and service URNs to service URLs and associated
	information. LoST mapping queries can contain either civic or		information. LoST mapping queries can contain either civic or
	geodetic location information. For civic addresses, LoST can		geodetic location information. For civic addresses, LoST can
	indicate which parts of the civic address are known to be valid or		indicate which parts of the civic address are known to be valid or
	invalid, thus providing address validation, as described in Section		invalid, thus providing address validation, as described in Section
	3.5 of [18]. LoST indicates errors in the location data to		3.5 of [18]. LoST indicates errors in the location data to
	skipping to change at page 8, line 6		skipping to change at page 8, line 6
	3. when a SIP message arrives at a SIP proxy performing location-		3. when a SIP message arrives at a SIP proxy performing location-
	based call routing;		based call routing;
	4. when cached mapping information has expired;		4. when cached mapping information has expired;
	5. when invoking a particular service. At that time, a client may		5. when invoking a particular service. At that time, a client may
	omit requests for service boundaries or other auxiliary		omit requests for service boundaries or other auxiliary
	information.		information.
	A service-specific Best Current Practice (BCP) document, such as		A service-specific Best Current Practice (BCP) document, such as
	[20], governs whether a client is expected to invoke the mapping		[21], governs whether a client is expected to invoke the mapping
	service just before needing the service or whether to rely on cached		service just before needing the service or whether to rely on cached
	answers. Cache entries expire at their expiration time (see		answers. Cache entries expire at their expiration time (see
	Section 5.2), or they become invalid if the caller's device moves		Section 5.2), or they become invalid if the caller's device moves
	beyond the boundaries of the service region.		beyond the boundaries of the service region. Service-specific Best
			Curent Practice documents may also provide guidance on the contact
			URI schemes most appropriate to the service. As a general set of
			guidelines, URI schemes that do not provide mechanisms for actually
			initiating a contact method should be avoided (examples include data,
			info, cid, and tag) as transforming those references into contact
			mechanisms requires a layer of indirection that makes the overall
			mechanism more fragile. Provisionally registered URI schemes should
			also be carefully considered before use, because they are subject to
			change in core semantics.
	4. LoST Servers and Their Resolution		4. LoST Servers and Their Resolution
	LoST servers are identified by U-NAPTR/DDDS [8] application unique		LoST servers are identified by U-NAPTR/DDDS [8] application unique
	strings, in the form of a DNS name. An example is		strings, in the form of a DNS name. An example is
	'lostserver.example.com'.		'lostserver.example.com'.
	Clients need to use the U-NAPTR [8] specification described below to		Clients need to use the U-NAPTR [8] specification described below to
	obtain a URI (indicating host and protocol) for the applicable LoST		obtain a URI (indicating host and protocol) for the applicable LoST
	service. In this document, only the HTTP and HTTPS URL schemes are		service. In this document, only the HTTP and HTTPS URL schemes are
	skipping to change at page 14, line 15		skipping to change at page 14, line 15
	6. Path of a Request: the <path> Element		6. Path of a Request: the <path> Element
	To prevent loops and to allow tracing of request and response paths,		To prevent loops and to allow tracing of request and response paths,
	all requests that allow recursion include a <path> element that		all requests that allow recursion include a <path> element that
	contains one or more <via> elements, each possessing an attribute		contains one or more <via> elements, each possessing an attribute
	containing a LoST application unique string (see Section 4). The		containing a LoST application unique string (see Section 4). The
	order of <via> elements corresponds to the order of LoST servers,		order of <via> elements corresponds to the order of LoST servers,
	i.e., the first <via> element identifies the server that initially		i.e., the first <via> element identifies the server that initially
	received the request from the client issuing the request. Every		received the request from the client issuing the request. Every
	server in a recursive query operation is included in the		server in a recursive query operation is included in the
	<path>elelment, including the first server to receive it.		<path>element, including the first server to receive it.
	The server that answers the request instead of forwarding it, such as		The server that answers the request instead of forwarding it, such as
	the authoritative server, copies the <path> element verbatim into the		the authoritative server, copies the <path> element verbatim into the
	response. The <path> element is not modified in responses as the		response. The <path> element is not modified in responses as the
	responses traverses the server chain back to the querying client.		responses traverses the server chain back to the querying client.
	If a query is answered iteratively, the querier includes all servers		If a query is answered iteratively, the querier includes all servers
	that it has already contacted.		that it has already contacted.
	When a cached mapping is returned then the <path> element cached		When a cached mapping is returned then the <path> element cached
	together with the mapping is returned.		together with the mapping is returned.
	The example in Figure 5 indicates that the answer was given to the		The example in Figure 4 indicates that the answer was given to the
	client by the LoST server at esgw.ueber-110.de.example, which got the		client by the LoST server at esgw.ueber-110.de.example, which got the
	answer from the (authoritative) LoST server at		answer from the (authoritative) LoST server at
	polizei.muenchen.de.example.		polizei.muenchen.de.example.
	7. Identifying the Location Element Used for Mapping: <locationUsed>		7. Identifying the Location Element Used for Mapping: <locationUsed>
	Several of the requests can provide one or more <location> elements,		Several of the requests can provide one or more <location> elements,
	among which the server gets to choose. It is useful for the client		among which the server gets to choose. It is useful for the client
	to be able to determine which one was actually used in producing the		to be able to determine which one was actually used in producing the
	result. For that purpose, the <location> tag MUST contain an 'id'		result. For that purpose, the <location> tag MUST contain an 'id'
	skipping to change at page 16, line 38		skipping to change at page 16, line 38
	<location id="6020688f1ce1896d" profile="geodetic-2d">		<location id="6020688f1ce1896d" profile="geodetic-2d">
	<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">		<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
	<p2:pos>37.775 -122.422</p2:pos>		<p2:pos>37.775 -122.422</p2:pos>
	</p2:Point>		</p2:Point>
	</location>		</location>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	</findService>		</findService>
	Figure 2: A <findService> geodetic query		Figure 1: 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 Department, instructing the		service to the New York City Police Department, instructing the
	client that it may contact them via the URIs "sip:nypd@example.com"		client that it may contact them via the URIs "sip:nypd@example.com"
	and "xmpp:nypd@example.com". The server has also given the client a		and "xmpp:nypd@example.com". The server has also given the client a
	geodetic, two-dimensional boundary for this service. The mapping was		geodetic, two-dimensional boundary for this service. The mapping was
	last updated on November 1, 2006 and expires on January 1, 2007. If		last updated on November 1, 2006 and expires on January 1, 2007. If
	the client's location changes beyond the given service boundary or		the client's location changes beyond the given service boundary or
	skipping to change at page 17, line 41		skipping to change at page 17, line 41
	<uri>xmpp:nypd@example.com</uri>		<uri>xmpp:nypd@example.com</uri>
	<serviceNumber>911</serviceNumber>		<serviceNumber>911</serviceNumber>
	</mapping>		</mapping>
	<path>		<path>
	<via source="resolver.example"/>		<via source="resolver.example"/>
	<via source="authoritative.example"/>		<via source="authoritative.example"/>
	</path>		</path>
	<locationUsed id="6020688f1ce1896d"/>		<locationUsed id="6020688f1ce1896d"/>
	</findServiceResponse>		</findServiceResponse>
	Figure 3: A <findServiceResponse> geodetic answer		Figure 2: A <findServiceResponse> geodetic answer
	8.2.2. Civic Address Mapping Example		8.2.2. Civic Address Mapping Example
	The example below shows how to map a service to a location much like		The example below shows how to map a service to a location much like
	the example in Section 8.2.1, but using civic address location		the example in Section 8.2.1, but using civic address location
	information. In this example, the client requests the service		information. In this example, the client requests the service
	associated with police (urn:service:sos.police) along with a specific		associated with police (urn:service:sos.police) along with a specific
	civic address (house number 6 on a street named Otto-Hahn-Ring in		civic address (house number 6 on a street named Otto-Hahn-Ring in
	Munich, Germany).		Munich, Germany).
	skipping to change at page 18, line 22		skipping to change at page 18, line 22
	<A1>Bavaria</A1>		<A1>Bavaria</A1>
	<A3>Munich</A3>		<A3>Munich</A3>
	<A6>Otto-Hahn-Ring</A6>		<A6>Otto-Hahn-Ring</A6>
	<HNO>6</HNO>		<HNO>6</HNO>
	<PC>81675</PC>		<PC>81675</PC>
	</civicAddress>		</civicAddress>
	</location>		</location>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	</findService>		</findService>
	Figure 4: A <findService> civic address query		Figure 3: A <findService> civic address 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 Muenchen Polizei-Abteilung, instructing the client		service to the Muenchen Polizei-Abteilung, instructing the client
	that it may contact them via the URIs sip:munich-police@example.com		that it may contact them via the URIs sip:munich-police@example.com
	and xmpp:munich-police@example.com. The server has also given the		and xmpp:munich-police@example.com. The server has also given the
	client a civic address boundary (the city of Munich) for this		client a civic address boundary (the city of Munich) for this
	service. The mapping was last updated on November 1, 2006 by the		service. The mapping was last updated on November 1, 2006 by the
	authoritative source "polizei.muenchen.de.example" and expires on		authoritative source "polizei.muenchen.de.example" and expires on
	skipping to change at page 19, line 37		skipping to change at page 19, line 37
	<uri>xmpp:munich-police@example.com</uri>		<uri>xmpp:munich-police@example.com</uri>
	<serviceNumber>110</serviceNumber>		<serviceNumber>110</serviceNumber>
	</mapping>		</mapping>
	<path>		<path>
	<via source="esgw.ueber-110.de.example"/>		<via source="esgw.ueber-110.de.example"/>
	<via source="polizei.muenchen.de.example"/>		<via source="polizei.muenchen.de.example"/>
	</path>		</path>
	<locationUsed id="627b8bf819d0bad4d"/>		<locationUsed id="627b8bf819d0bad4d"/>
	</findServiceResponse>		</findServiceResponse>
	Figure 5: A <findServiceResponse> civic address answer		Figure 4: A <findServiceResponse> civic address answer
	8.3. Components of the <findService> Request		8.3. Components of the <findService> Request
	The <findService> request includes attributes and elements that		The <findService> request includes attributes and elements that
	govern whether the request is handled iteratively or recursively,		govern whether the request is handled iteratively or recursively,
	whether location validation is performed and which elements may be		whether location validation is performed and which elements may be
	contained in the response.		contained in the response.
	8.3.1. The <location> Element		8.3.1. The <location> Element
	skipping to change at page 20, line 47		skipping to change at page 20, line 47
	<getServiceBoundary> request. The querier can express a preference		<getServiceBoundary> request. The querier can express a preference
	for one or the other modality with the 'serviceBoundary' attribute in		for one or the other modality with the 'serviceBoundary' attribute in
	the <findService> request, but the server makes the final decision as		the <findService> request, but the server makes the final decision as
	to whether to return a reference or a value.		to whether to return a reference or a value.
	8.3.5. Requesting Civic Location Validation		8.3.5. Requesting Civic Location Validation
	Civic address validation is requested by setting the optional		Civic address validation is requested by setting the optional
	attribute 'validateLocation' to true. If the attribute is omitted,		attribute 'validateLocation' to true. If the attribute is omitted,
	it is assumed to be false. The response is described in		it is assumed to be false. The response is described in
	Section 8.4.2. The example in Figure 6 demonstrates address		Section 8.4.2. The example in Figure 5 demonstrates address
	validation. If the server chooses a geodetic location among the		validation. If the server chooses a geodetic location among the
	locations provided in a request, the attribute is ignored.		locations provided in a request, the attribute is ignored.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findService		<findService
	xmlns="urn:ietf:params:xml:ns:lost1"		xmlns="urn:ietf:params:xml:ns:lost1"
	recursive="true"		recursive="true"
	validateLocation="true"		validateLocation="true"
	serviceBoundary="value">		serviceBoundary="value">
	<location id="627b8bf819d0bad4d" profile="civic">		<location id="627b8bf819d0bad4d" profile="civic">
	skipping to change at page 21, line 25		skipping to change at page 21, line 25
	<A1>Bavaria</A1>		<A1>Bavaria</A1>
	<A3>Munich</A3>		<A3>Munich</A3>
	<A6>Otto-Hahn-Ring</A6>		<A6>Otto-Hahn-Ring</A6>
	<HNO>6</HNO>		<HNO>6</HNO>
	<PC>81675</PC>		<PC>81675</PC>
	</civicAddress>		</civicAddress>
	</location>		</location>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	</findService>		</findService>
	Figure 6: A <findService> query with address validation request		Figure 5: A <findService> query with address validation request
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">		<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
	<mapping		<mapping
	expires="2007-01-01T01:44:33Z"		expires="2007-01-01T01:44:33Z"
	lastUpdated="2006-11-01T01:00:00Z"		lastUpdated="2006-11-01T01:00:00Z"
	source="authoritative.example"		source="authoritative.example"
	sourceId="4db898df52b84edfa9b6445ea8a0328e">		sourceId="4db898df52b84edfa9b6445ea8a0328e">
	<displayName xml:lang="de">		<displayName xml:lang="de">
	Muenchen Polizei-Abteilung		Muenchen Polizei-Abteilung
	</displayName>		</displayName>
	skipping to change at page 22, line 40		skipping to change at page 22, line 40
	<invalid>PC</invalid>		<invalid>PC</invalid>
	<unchecked>HNO</unchecked>		<unchecked>HNO</unchecked>
	</locationValidation>		</locationValidation>
	<path>		<path>
	<via source="resolver.example"/>		<via source="resolver.example"/>
	<via source="authoritative.example"/>		<via source="authoritative.example"/>
	</path>		</path>
	<locationUsed id="627b8bf819d0bad4d"/>		<locationUsed id="627b8bf819d0bad4d"/>
	</findServiceResponse>		</findServiceResponse>
	Figure 7: A <findServiceResponse> message with address validation		Figure 6: A <findServiceResponse> message with address validation
	information		information
	8.4. Components of the Mapping Response <findServiceResponse>		8.4. Components of the Mapping Response <findServiceResponse>
	8.4.1. Overview		8.4.1. Overview
	Mapping responses consist of the <mapping> element (Section 5)		Mapping responses consist of the <mapping> element (Section 5)
	describing the mapping itself, possibly followed by warnings		describing the mapping itself, possibly followed by warnings
	(Section 13.2), location validation information (Section 8.4.2), and		(Section 13.2), location validation information (Section 8.4.2), and
	an indication of the path (Section 6) the response has taken.		an indication of the path (Section 6) the response has taken.
	skipping to change at page 23, line 31		skipping to change at page 23, line 31
	civic address elements found in the <valid> list. Civic location		civic address elements found in the <valid> list. Civic location
	tokens that are neither listed in the <valid>, the <invalid> and the		tokens that are neither listed in the <valid>, the <invalid> and the
	<unchecked> element belong to the class of unchecked tokens.		<unchecked> element belong to the class of unchecked tokens.
	Note that the same address can yield different responses if parts of		Note that the same address can yield different responses if parts of
	the civic address contradict each other. For example, if the postal		the civic address contradict each other. For example, if the postal
	code does not match the city, local server policy determines whether		code does not match the city, local server policy determines whether
	the postal code or the city is considered valid. The mapping		the postal code or the city is considered valid. The mapping
	naturally corresponds to the valid elements.		naturally corresponds to the valid elements.
	The example shown in Figure 6 and in Figure 7 indicates that the		The example shown in Figure 5 and in Figure 6 indicates that the
	tokens 'country', 'A1', 'A3', and 'A6' have been validated by the		tokens 'country', 'A1', 'A3', and 'A6' have been validated by the
	LoST server. The server considered the postal code 81675 in the <PC>		LoST server. The server considered the postal code 81675 in the <PC>
	element as not valid for this location. The 'HNO' token belongs to		element as not valid for this location. The 'HNO' token belongs to
	the class of unchecked location tokens.		the class of unchecked location tokens.
	9. Retrieving the Service Boundary via <getServiceBoundary>		9. Retrieving the Service Boundary via <getServiceBoundary>
	As discussed in Section 5.5, the <findServiceResponse> can return a		As discussed in Section 5.5, the <findServiceResponse> can return a
	globally unique identifier in the 'serviceBoundary' attribute that		globally unique identifier in the 'serviceBoundary' attribute that
	can be used to retrieve the service boundary, rather than returning		can be used to retrieve the service boundary, rather than returning
	the boundary by value. This is shown in the example in Figure 8 and		the boundary by value. This is shown in the example in Figure 7 and
	Figure 9. The client can then retrieve the boundary using the		Figure 8. 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 9.
	Figure 10. The client issues the request to the server identified in		The client issues the request to the server identified in the
	the 'server' attribute of the <serviceBoundaryReference> element.		'server' attribute of the <serviceBoundaryReference> element. These
	These requests are always directed to the authoritative server and do		requests are always directed to the authoritative server and do not
	not recurse.		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 id="6020688f1ce1896d" profile="geodetic-2d">		<location id="6020688f1ce1896d" profile="geodetic-2d">
	<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">		<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
	<p2:pos>37.775 -122.422</p2:pos>		<p2:pos>37.775 -122.422</p2:pos>
	</p2:Point>		</p2:Point>
	</location>		</location>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	</findService>		</findService>
	Figure 8: <findService> request and response with service boundary		Figure 7: <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">
	<displayName xml:lang="en">		<displayName xml:lang="en">
	skipping to change at page 25, line 30		skipping to change at page 25, line 30
	<uri>xmpp:nypd@example.com</uri>		<uri>xmpp:nypd@example.com</uri>
	<serviceNumber>911</serviceNumber>		<serviceNumber>911</serviceNumber>
	</mapping>		</mapping>
	<path>		<path>
	<via source="resolver.example"/>		<via source="resolver.example"/>
	<via source="authoritative.example"/>		<via source="authoritative.example"/>
	</path>		</path>
	<locationUsed id="6020688f1ce1896d"/>		<locationUsed id="6020688f1ce1896d"/>
	</findServiceResponse>		</findServiceResponse>
	Figure 9: <findServiceResponse> message with service boundary		Figure 8: <findServiceResponse> message with service boundary
	reference		reference
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"		<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
	key="7214148E0433AFE2FA2D48003D31172E"/>		key="7214148E0433AFE2FA2D48003D31172E"/>
	Figure 10: Requesting a service boundary with <getServiceBoundary>		Figure 9: Requesting a service boundary with <getServiceBoundary>
	The <getServiceBoundary> request may also be used to retrieve service		The <getServiceBoundary> request may also be used to retrieve service
	boundaries that are expressed as civic addresses, as illustrated in		boundaries that are expressed as civic addresses, as illustrated in
	Figure 11.		Figure 10.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<getServiceBoundaryResponse		<getServiceBoundaryResponse
	xmlns="urn:ietf:params:xml:ns:lost1">		xmlns="urn:ietf:params:xml:ns:lost1">
	<serviceBoundary profile="civic">		<serviceBoundary profile="civic">
	<civicAddress		<civicAddress
	xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">		xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
	<country>US</country>		<country>US</country>
	<A1>New York</A1>		<A1>New York</A1>
	<A3>New York</A3>		<A3>New York</A3>
	</civicAddress>		</civicAddress>
	</serviceBoundary>		</serviceBoundary>
	<path>		<path>
	<via source="resolver.example"/>		<via source="resolver.example"/>
	<via source="authoritative.example"/>		<via source="authoritative.example"/>
	</path>		</path>
	</getServiceBoundaryResponse>		</getServiceBoundaryResponse>
	Figure 11: Civic Address Service Boundary Response		Figure 10: Civic Address Service Boundary Response
	10. List Services: <listServices>		10. List Services: <listServices>
	A LoST client can ask a LoST server for the list of services that it		A LoST client can ask a LoST server for the list of services that it
	understands, primarily for diagnostic purposes. The query does not		understands, primarily for diagnostic purposes. The query does not
	contain location information, as it simply provides an indication of		contain location information, as it simply provides an indication of
	which services the server can look up, not whether a particular		which services the server can look up, not whether a particular
	service is offered for a particular area. Typically, only top-level		service is offered for a particular area. Typically, only top-level
	services are included in the answer, implying support for all sub-		services are included in the answer, implying support for all sub-
	services. Since the query is answered by the queried server, there		services. Since the query is answered by the queried server, there
	is no notion of recursion or indirection and no path indication. The		is no notion of recursion or indirection and no path indication. The
	<listServicesByLocation> (Section 11) query below can be used to find		<listServicesByLocation> (Section 11) query below can be used to find
	out whether a particular service is offered for a specific location.		out whether a particular service is offered for a specific location.
	An example request and response are shown in Figure 12.		An example request and response are shown in Figure 11.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<listServices		<listServices
	xmlns="urn:ietf:params:xml:ns:lost1">		xmlns="urn:ietf:params:xml:ns:lost1">
	<service>urn:service:sos</service>		<service>urn:service:sos</service>
	</listServices>		</listServices>
	Figure 12: Example of <ListServices> query		Figure 11: Example of <ListServices> query
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<listServicesResponse		<listServicesResponse
	xmlns="urn:ietf:params:xml:ns:lost1">		xmlns="urn:ietf:params:xml:ns:lost1">
	<serviceList>		<serviceList>
	urn:service:sos.ambulance		urn:service:sos.ambulance
	urn:service:sos.animal-control		urn:service:sos.animal-control
	urn:service:sos.fire		urn:service:sos.fire
	urn:service:sos.gas		urn:service:sos.gas
	urn:service:sos.mountain		urn:service:sos.mountain
	skipping to change at page 27, line 48		skipping to change at page 27, line 48
	urn:service:sos.poison		urn:service:sos.poison
	urn:service:sos.police		urn:service:sos.police
	urn:service:sos.suicide		urn:service:sos.suicide
	</serviceList>		</serviceList>
	<path>		<path>
	<via source="resolver.example"/>		<via source="resolver.example"/>
	<via source="authoritative.example"/>		<via source="authoritative.example"/>
	</path>		</path>
	</listServicesResponse>		</listServicesResponse>
	Figure 13: Example of <ListServiceResponse>		Figure 12: Example of <ListServiceResponse>
	11. List Services By Location: <listServicesByLocation>		11. List Services By Location: <listServicesByLocation>
	A LoST client can ask a LoST server for the list of services it knows		A LoST client can ask a LoST server for the list of services it knows
	about for a particular area. The <listServicesByLocation> query		about for a particular area. The <listServicesByLocation> query
	contains one or more <location> elements, each from a different		contains one or more <location> elements, each from a different
	location profile (Section 12), and may contain the <service> element.		location profile (Section 12), and may contain the <service> element.
	As for <findService>, the server selects the first location element		As for <findService>, the server selects the first location element
	that has a profile the server understands and it can operate either		that has a profile the server understands and it can operate either
	recursively or iteratively; <via> elements track the progress of the		recursively or iteratively; <via> elements track the progress of the
	skipping to change at page 28, line 33		skipping to change at page 28, line 33
	If the query contains the <service> element, the LoST server returns		If the query contains the <service> element, the LoST server returns
	only immediate child services of the queried service that are		only immediate child services of the queried service that are
	available for the provided location. If the <service> element is		available for the provided location. If the <service> element is
	absent, the LoST service returns all top-level services available for		absent, the LoST service returns all top-level services available for
	the provided location that it knows about.		the provided location that it knows about.
	A server responds to this query with a		A server responds to this query with a
	<listServicesByLocationResponse> response. This response MAY contain		<listServicesByLocationResponse> response. This response MAY contain
	<via> elements (see Section 6) and MUST contain a <serviceList>		<via> elements (see Section 6) and MUST contain a <serviceList>
	element, consisting of a whitespace-separated list of service URNs.		element, consisting of a whitespace-separated list of service URNs.
	The query and response are illustrated in Figure 14 and in Figure 15,		The query and response are illustrated in Figure 13 and in Figure 14,
	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 id="3e19dfb3b9828c3" profile="geodetic-2d">		<location id="3e19dfb3b9828c3" profile="geodetic-2d">
	<p2:Point srsName="urn:ogc:def:crs:EPSG::4326">		<p2:Point srsName="urn:ogc:def:crs:EPSG::4326">
	<p2:pos>-34.407 150.883</p2:pos>		<p2:pos>-34.407 150.883</p2:pos>
	</p2:Point>		</p2:Point>
	</location>		</location>
	<service>urn:service:sos</service>		<service>urn:service:sos</service>
	</listServicesByLocation>		</listServicesByLocation>
	Figure 14: Example of <ListServicesbyLocation> query		Figure 13: 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>
	urn:service:sos.ambulance		urn:service:sos.ambulance
	urn:service:sos.animal-control		urn:service:sos.animal-control
	urn:service:sos.fire		urn:service:sos.fire
	urn:service:sos.gas		urn:service:sos.gas
	urn:service:sos.mountain		urn:service:sos.mountain
	urn:service:sos.marine		urn:service:sos.marine
	skipping to change at page 29, line 26		skipping to change at page 29, line 26
	urn:service:sos.police		urn:service:sos.police
	urn:service:sos.suicide		urn:service:sos.suicide
	</serviceList>		</serviceList>
	<path>		<path>
	<via source="resolver.example"/>		<via source="resolver.example"/>
	<via source="authoritative.example"/>		<via source="authoritative.example"/>
	</path>		</path>
	<locationUsed id="3e19dfb3b9828c3"/>		<locationUsed id="3e19dfb3b9828c3"/>
	</listServicesByLocationResponse>		</listServicesByLocationResponse>
	Figure 15: Example of <ListServices> response		Figure 14: Example of <ListServices> response
	12. Location Profiles		12. Location Profiles
	LoST uses location information in <location> elements in requests and		LoST uses location information in <location> elements in requests and
	<serviceBoundary> elements in responses. Such location information		<serviceBoundary> elements in responses. Such location information
	may be expressed in a variety of ways. This variety can cause		may be expressed in a variety of ways. This variety can cause
	interoperability problems where a request or response contains		interoperability problems where a request or response contains
	location information in a format not understood by the server or the		location information in a format not understood by the server or the
	client, respectively. To achieve interoperability, this document		client, respectively. To achieve interoperability, this document
	defines two mandatory-to-implement baseline location profiles to		defines two mandatory-to-implement baseline location profiles to
	skipping to change at page 33, line 43		skipping to change at page 33, line 43
	</gs:Prism>		</gs:Prism>
	</location>		</location>
	<location id="DEF 345" profile="geodetic-2d">		<location id="DEF 345" profile="geodetic-2d">
	<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">		<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
	<gml:pos>42.656844 -73.348157</gml:pos>		<gml:pos>42.656844 -73.348157</gml:pos>
	</gml:Point>		</gml:Point>
	</location>		</location>
	<service>urn:service:sos.police</service>		<service>urn:service:sos.police</service>
	</findService>		</findService>
	Figure 16: Example of a <findServices> query with baseline profile		Figure 15: 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">
	skipping to change at page 34, line 40		skipping to change at page 34, line 40
	<uri>sip:nypd@example.com</uri>		<uri>sip:nypd@example.com</uri>
	<serviceNumber>911</serviceNumber>		<serviceNumber>911</serviceNumber>
	</mapping>		</mapping>
	<path>		<path>
	<via source="resolver.example"/>		<via source="resolver.example"/>
	<via source="authoritative.example"/>		<via source="authoritative.example"/>
	</path>		</path>
	<locationUsed id="6020688f1ce1896d"/>		<locationUsed id="6020688f1ce1896d"/>
	</findServiceResponse>		</findServiceResponse>
	Figure 17: Example of a <findServiceResponse> message with baseline		Figure 16: Example of a <findServiceResponse> message with baseline
	profile interoperability		profile interoperability
	12.2. Two Dimensional Geodetic Profile		12.2. Two Dimensional Geodetic Profile
	The "geodetic-2d" location profile is identified by "geodetic-2d".		The "geodetic-2d" location profile is identified by "geodetic-2d".
	Clients and servers use this profile by placing the following		Clients and servers use this profile by placing the following
	location shapes into the <serviceBoundary> or into the <location>		location shapes into the <serviceBoundary> or into the <location>
	element (unless indicated otherwise):		element (unless indicated otherwise):
	Point:		Point:
	skipping to change at page 35, line 34		skipping to change at page 35, line 34
	The <Circle> element is described in Section 5.2.3 of [13].		The <Circle> element is described in Section 5.2.3 of [13].
	Ellipse:		Ellipse:
	The <Ellipse> element is described in Section 5.2.4 of [13].		The <Ellipse> element is described in Section 5.2.4 of [13].
	ArcBand:		ArcBand:
	The <ArcBand> element is described in Section 5.2.5 of [13].		The <ArcBand> element is described in Section 5.2.5 of [13].
	When clients place a <Polygon>, <Circle>, <Ellipse> or <ArcBand>		When a client uses a <Polygon>, <Circle>, <Ellipse> or <ArcBand>
	element within the <location> element then it indicates that the		element within the <location> element, it is indicating that it will
	query is about any point contained in the given area; it is left to		be satisfied by query results appropriate to any portion of the
	the server to select an appropriate matching algorithm, such as using		shape. It is left to the server to select an appropriate matching
	computing the centroid. A server MAY return multiple <mapping>		algorithm. A server MAY return multiple <mapping> elements if the
	elements if the polygon extends across multiple service areas.		shape extends across multiple service areas. Servers are not
			required to return all possible <mapping> elements to avoid denial of
			service attacks in which clients present queries that span a very
			large number service boundaries (e.g. presenting a shape covering all
			of the United States).
			In the case where the server does not return multiple <mapping>
			elements, but the shape extends across a service boundary, it is
			possible that the matching algorithm selected by the LoST server will
			return results that match a portion of the shape but do not match
			those specific to a particular point. A client may always select a
			point from within the shape to avoid this condition. The cases where
			it does not are generally those where it knows its own position only
			within the shape given. In emergency service use cases, that may
			result in the PSAP contacted at the URI provided by LoST being
			required to forward a call to one of its neighbors; this is an
			expected part of the overall emergency response system. In non-
			emergency service use cases, the service deployment model should take
			into account this issue as part of the provisioning model, as the
			combination of the data in the LoST server and the algorithm used for
			mapping determine which contact URIs are returned when shapes are
			used which overlap multiple service areas.
			As a general guideline, any deployed matching algorithm should ensure
			that the algorithm used does not needlessly return NULL results if
			there are valid results for any portion of the shape.
	When geodetic location information of this location profile is placed		When geodetic location information of this location profile is placed
	in the <serviceBoundary> element then the elements with geospatial		in the <serviceBoundary> element then the elements with geospatial
	coordinates are alternative descriptions of the same service region,		coordinates are alternative descriptions of the same service region,
	not additive geometries.		not additive geometries.
	12.3. Basic Civic Profile		12.3. Basic Civic Profile
	The basic-civic location profile is identified by the token 'civic'.		The basic-civic location profile is identified by the token 'civic'.
	Clients use this profile by placing a <civicAddress> element, defined		Clients use this profile by placing a <civicAddress> element, defined
	skipping to change at page 39, line 11		skipping to change at page 39, line 11
	was available.		was available.
	An example is below:		An example is below:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<errors xmlns="urn:ietf:params:xml:ns:lost1"		<errors xmlns="urn:ietf:params:xml:ns:lost1"
	source="resolver.example">		source="resolver.example">
	<internalError message="Software bug." xml:lang="en"/>		<internalError message="Software bug." xml:lang="en"/>
	</errors>		</errors>
	Figure 18: Example of an error resonse		Figure 17: Example of an error resonse
	13.2. Warnings		13.2. Warnings
	A response MAY contain zero or more warnings. This pattern defines a		A response MAY contain zero or more warnings. This pattern defines a
	'message' attribute containing human readable text and an 'xml:lang'		'message' attribute containing human readable text and an 'xml:lang'
	attribute denoting the language of the human readable text. One or		attribute denoting the language of the human readable text. One or
	more such warning elements are contained in the <warnings> element.		more such warning elements are contained in the <warnings> element.
	To provide human readable text in an appropriate language the HTTP		To provide human readable text in an appropriate language the HTTP
	content negotiation capabilities (see Section 14) MAY be utilized by		content negotiation capabilities (see Section 14) MAY be utilized by
	a server.		a server.
	skipping to change at page 40, line 44		skipping to change at page 40, line 44
	message="Unable to determine PSAP for the given location;		message="Unable to determine PSAP for the given location;
	using default PSAP"		using default PSAP"
	xml:lang="en"/>		xml:lang="en"/>
	</warnings>		</warnings>
	<path>		<path>
	<via source="resolver.example"/>		<via source="resolver.example"/>
	<via source="authoritative.example"/>		<via source="authoritative.example"/>
	</path>		</path>
	</findServiceResponse>		</findServiceResponse>
	Figure 19: Example of an warning resonse		Figure 18: Example of an warning resonse
	13.3. Redirects		13.3. Redirects
	A LoST server can respond indicating that the querier should redirect		A LoST server can respond indicating that the querier should redirect
	the query to another server, using the <redirect> element. The		the query to another server, using the <redirect> element. The
	element includes a 'target' attribute indicating the LoST application		element includes a 'target' attribute indicating the LoST application
	unique string (see Section 4) that the client SHOULD be contacting		unique string (see Section 4) that the client SHOULD be contacting
	next, as well as the 'source' attribute indicating the server that		next, as well as the 'source' attribute indicating the server that
	generated the redirect response and a 'message' attribute explaining		generated the redirect response and a 'message' attribute explaining
	the reason for the redirect response. During a recursive query, a		the reason for the redirect response. During a recursive query, a
	server receiving a <redirect> response can decide whether it wants to		server receiving a <redirect> response can decide whether it wants to
	follow the redirection or simply return the response to its upstream		follow the redirection or simply return the response to its upstream
	querier.		querier. The "expires" value in the response returned by the server
			handling the redirected query indicates the earliest time at which a
			new query might be needed (see section 5.2). The query for the same
			tuple of location and service SHOULD NOT be directed to the server
			which gave redirect prior to that time.
	An example is below:		An example is below:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<redirect xmlns="urn:ietf:params:xml:ns:lost1"		<redirect xmlns="urn:ietf:params:xml:ns:lost1"
	target="eastpsap.example"		target="eastpsap.example"
	source="westpsap.example"		source="westpsap.example"
	message="We have temporarily failed over." xml:lang="en"/>		message="We have temporarily failed over." xml:lang="en"/>
	Figure 20: Example of a redirect response		Figure 19: Example of a redirect response
	14. LoST Transport: HTTP		14. LoST Transport: HTTP
	LoST needs an underlying protocol transport mechanisms to carry		LoST needs an underlying protocol transport mechanisms to carry
	requests and responses. This document defines the use of LoST over		requests and responses. This document defines the use of LoST over
	HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future		HTTP and LoST over HTTP-over-TLS. Client and server developers are
	documents. The available transport mechanisms are determined through		reminded that full support of RFC 2616 HTTP facilities is expected.
	the use of the LoST U-NAPTR application. In protocols that support		If LoST clients or servers re-implement HTTP, rather than using
	content type indication, LoST uses the media type application/		available servers or client code as a base, careful attention must be
	lost+xml.		paid to full interoperability. Other transport mechanisms are left
			to future documents. The available transport mechanisms are
			determined through the use of the LoST U-NAPTR application. In
			protocols that support content type indication, LoST uses the media
			type application/lost+xml.
	When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP		When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP
	POST method. The HTTP request MUST use the Cache-Control response		POST method. The HTTP request MUST use the Cache-Control response
	directive "no-cache" to HTTP-level "caching even by caches that have		directive "no-cache" to HTTP-level caching even by caches that have
	been configured to return stale responses to client requests."		been configured to return stale responses to client requests.
	All LoST responses, including those indicating a LoST warning or		All LoST responses, including those indicating a LoST warning or
	error, are carried in 2xx responses, typically 200 (OK). Other 2xx		error, are carried in 2xx responses, typically 200 (OK). Other 2xx
	responses, in particular 203 (Non-authoritative information) may be		responses, in particular 203 (Non-authoritative information) may be
	returned by HTTP caches that disregard the caching instructions. 3xx,		returned by HTTP caches that disregard the caching instructions. 3xx,
	4xx and 5xx HTTP response codes indicates that the HTTP request		4xx and 5xx HTTP response codes indicates that the HTTP request
	itself failed or was redirected; these responses do not contain any		itself failed or was redirected; these responses do not contain any
	LoST XML elements. The 3xx responses are distinct from the redirects		LoST XML elements. The 3xx responses are distinct from the redirects
	which are described in Section 13.3; the 13.3 redirects occur after a		which are described in Section 13.3; the 13.3 redirects occur after a
	LoST server processes the request. Where an HTTP-layer redirect will		LoST server processes the request. Where an HTTP-layer redirect will
	skipping to change at page 49, line 36		skipping to change at page 49, line 36
	| text)*		| text)*
	##		##
	## A point where future extensions		## A point where future extensions
	## (elements from other namespaces)		## (elements from other namespaces)
	## can be added.		## can be added.
	##		##
	extensionPoint = notLost*		extensionPoint = notLost*
	}		}
	Figure 21: RelaxNG schema		Figure 20: RelaxNG schema
	16. Internationalization Considerations		16. Internationalization Considerations
	The LoST protocol is mostly meant for machine-to-machine		The LoST protocol is mostly meant for machine-to-machine
	communications; as such, most of its elements are tokens not meant		communications; as such, most of its elements are tokens not meant
	for direct human consumption. If these tokens are presented to the		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 the
	<displayName> element and the 'message' attributes may be displayed		<displayName> element and the 'message' attributes may be displayed
	to the end user, and they are thus complex types designed for this		to the end user, and they are thus complex types designed for this
	purpose.		purpose.
	skipping to change at page 55, line 16		skipping to change at page 55, line 16
	There are several threats to the overall system of which service		There are several threats to the overall system of which service
	mapping forms a part. An attacker that can obtain service contact		mapping forms a part. An attacker that can obtain service contact
	URIs can use those URIs to attempt to disrupt those services. An		URIs can use those URIs to attempt to disrupt those services. An
	attacker that can prevent the lookup of contact URIs can impair the		attacker that can prevent the lookup of contact URIs can impair the
	reachability of such services. An attacker that can eavesdrop on the		reachability of such services. An attacker that can eavesdrop on the
	communication requesting this lookup can surmise the existence of an		communication requesting this lookup can surmise the existence of an
	emergency and possibly its nature, and may be able to use this to		emergency and possibly its nature, and may be able to use this to
	launch a physical attack on the caller.		launch a physical attack on the caller.
	To avoid that an attacker can modify the query or its result, TLS		To avoid an attacker modifying the query or its result, TLS MUST be
	MUST be implemented and SHOULD be used. Use is RECOMMENDED both for		implemented and SHOULD be used. Use is RECOMMENDED both for clients'
	clients' queries to servers and for queries among servers; this		queries to servers and for queries among servers; this latter
	latter recommendation is to help avoid cache poisoning attacks by		recommendation is to help avoid LoST cache poisoning attacks by
	replacing answers given to caching servers. The use of server		replacing answers given to caching LoST servers. The use of server
	identity checks is also RECOMMENDED, as described in [4]		identity checks is also RECOMMENDED, as described in [4] .
	Generally, authentication and authorization is not required for		In emergency service use cases, it is likely that deployments will
	mapping queries. If it is, authentication mechanism of the		see a large number of inputs to the U-NAPTR algorithm resolving to a
	underlying transport mechanism, such as HTTP basic and digest		single server. This is because local organizations will likely be
	authentication, MAY be used. (Basic authentication SHOULD only be		permitted or even encouraged to use LoST servers provided by the
	used in combination with TLS.)		local emergency services authority. This makes the use of
			alternatives to server identity which would check the input to the
			U-NAPTR algorithm against the certificates provided by the LoST
			server impractical, as the list of organizations using it would be
			large, subject to rapid change, and unknown to the LoST server
			operator. The use of server identity does leave open the possibility
			of DNS cache poisoning attacks, as the NAPTR records may be altered
			by an attacker. U-NAPTR recommends DNSSEC [20] as protection. While
			DNSSEC is incompletely deployed, users should be aware of the risk,
			particularly when they are requesting NAPTR records for domains or
			from servers with which they have no previous trust relationship.
			Generally, LoST servers will not need to authenticate or authorize
			clients presenting mapping queries. If they do, an authentication of
			the underlying transport mechanism, such as HTTP basic and digest
			authentication MAY be used. Basic Authentication SHOULD only be used
			in combination with TLS.
	A more detailed description of threats and security requirements are		A more detailed description of threats and security requirements are
	provided in [17].		provided in [17]. The threats and security requirements in non-
			emergency service uses of LoST may be considerably different from
			those described here. For example, an attacker might seek monetary
			benefit by returning service mapping information which directed users
			to specific service providers. Before deploying LoST in new
			contexts, a thorough analysis of the threats and requirements
			specific to that context should be undertaken and decisions made on
			the appropriate mitigations.
	19. Acknowledgments		19. Acknowledgments
	We would like to the thank the following working group members for		We would like to the thank the following working group members for
	the detailed review of previous LoST document versions:		the detailed review of previous LoST document versions:
	o Martin Thomson (Review July 2006)		o Martin Thomson (Review July 2006)
	o Jonathan Rosenberg (Review July 2006)		o Jonathan Rosenberg (Review July 2006)
	skipping to change at page 59, line 9		skipping to change at page 60, line 9
	Standard OpenGIS 03-105r1, April 2004.		Standard OpenGIS 03-105r1, April 2004.
	[12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application		[12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application
	Schema for use by the Internet Engineering Task Force (IETF)",		Schema for use by the Internet Engineering Task Force (IETF)",
	Candidate OpenGIS Implementation Specification , December 2006.		Candidate OpenGIS Implementation Specification , December 2006.
	20.2. Informative References		20.2. Informative References
	[13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV		[13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
	PIDF-LO Usage Clarification, Considerations and		PIDF-LO Usage Clarification, Considerations and
	Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work		Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work
	in progress), October 2007.		in progress), February 2008.
	[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence		[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence
	Protocol (XMPP): Instant Messaging and Presence", RFC 3921,		Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
	October 2004.		October 2004.
	[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,		[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
	skipping to change at page 59, line 36		skipping to change at page 60, line 36
	[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency		[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
	Context Resolution with Internet Technologies",		Context Resolution with Internet Technologies",
	draft-ietf-ecrit-requirements-13 (work in progress),		draft-ietf-ecrit-requirements-13 (work in progress),
	March 2007.		March 2007.
	[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and		[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and
	Framework", draft-ietf-ecrit-mapping-arch-03 (work in		Framework", draft-ietf-ecrit-mapping-arch-03 (work in
	progress), September 2007.		progress), September 2007.
	[20] Rosen, B. and J. Polk, "Best Current Practice for		[20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
			"DNS Security Introduction and Requirements", RFC 4033,
			March 2005.
			[21] Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in support of Emergency Calling",		Communications Services in support of Emergency Calling",
	draft-ietf-ecrit-phonebcp-03 (work in progress), November 2007.		draft-ietf-ecrit-phonebcp-04 (work in progress), February 2008.
	URIs		URIs
	[21] <http://www.tschofenig.com/svn/draft-ietf-ecrit-lost/RelaxNG>		[22] <http://www.tschofenig.com/svn/draft-ietf-ecrit-lost/RelaxNG>
	Appendix A. Non-Normative RELAX NG Schema in XML Syntax		Appendix A. Non-Normative RELAX NG Schema in XML Syntax
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<grammar ns="urn:ietf:params:xml:ns:lost1"		<grammar ns="urn:ietf:params:xml:ns:lost1"
	xmlns="http://relaxng.org/ns/structure/1.0"		xmlns="http://relaxng.org/ns/structure/1.0"
	xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"		xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
	datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">		datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
	<start>		<start>
	skipping to change at page 74, line 36		skipping to change at page 75, line 36
	</a:documentation>		</a:documentation>
	<zeroOrMore>		<zeroOrMore>
	<ref name="notLost" />		<ref name="notLost" />
	</zeroOrMore>		</zeroOrMore>
	</define>		</define>
	</div>		</div>
	</grammar>		</grammar>
	Figure 25		Figure 21
	Appendix B. Examples On-line		Appendix B. Examples On-line
	The XML examples and Relax NG schemas may be found on-line [21].		The XML examples and Relax NG schemas may be found on-line [22].
	Authors' Addresses		Authors' Addresses
	Ted Hardie		Ted Hardie
	Qualcomm, Inc.		Qualcomm, Inc.
	Email: hardie@qualcomm.com		Email: hardie@qualcomm.com
	Andrew Newton		Andrew Newton
	American Registry for Internet Numbers		American Registry for Internet Numbers
	skipping to change at page 77, line 44		skipping to change at line 3014
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 53 change blocks.
	98 lines changed or deleted		164 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/