< draft-ietf-ecrit-similar-location-13.txt		draft-ietf-ecrit-similar-location-14.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft		Internet-Draft
	Updates: 5222 (if approved) R. Marshall		Updates: 5222 (if approved) R. Marshall
	Intended status: Standards Track J. Martin		Intended status: Standards Track J. Martin
	Expires: 27 May 2022 Comtech TCS		Expires: 2 June 2022 Comtech TCS
	23 November 2021		29 November 2021
	A LoST extension to return complete and similar location info		A LoST extension to return complete and similar location info
	draft-ietf-ecrit-similar-location-13		draft-ietf-ecrit-similar-location-14
	Abstract		Abstract
	This document introduces a new way to provide returned location		This document introduces a new way to provide returned location
	information in LoST responses that is either of a completed or		information in LoST responses that is either of a completed or
	similar form to the original input civic location, based on whether		similar form to the original input civic location, based on whether
	valid or invalid civic address elements are returned within the		valid or invalid civic address elements are returned within the
	<findServiceResponse> message. This document defines a new extension		<findServiceResponse> message. This document defines a new extension
	to the <findServiceResponse> message within the LoST protocol		to the <findServiceResponse> message within the LoST protocol
	[RFC5222] that enables the LoST protocol to return in a response a		[RFC5222] that enables the LoST protocol to return in a response a
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 27 May 2022.		This Internet-Draft will expire on 2 June 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview of Returned Location Information . . . . . . . . . . 4		3. Overview of Returned Location Information . . . . . . . . . . 4
	4. Returned Location Information . . . . . . . . . . . . . . . . 7		4. Returned Location Information . . . . . . . . . . . . . . . . 8
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Complete Location returned for Valid Location . . . . . . 9		5.1. Complete Location returned for Valid Location . . . . . . 10
	5.2. Similar Location returned for Invalid Location . . . . . 11		5.2. Similar Location returned for Invalid Location . . . . . 12
	6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 13		6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8.1. XML Schema Registration . . . . . . . . . . . . . . . . . 15		8.1. XML Schema Registration . . . . . . . . . . . . . . . . . 16
	8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 15		8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 16
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . 17
	9.2. Informative References . . . . . . . . . . . . . . . . . 17		9.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The LoST protcol [RFC5222] supports the validation of civic location		The LoST protcol [RFC5222] supports the validation of civic location
	information sent in a <findService> request, by providing a set of		information sent in a <findService> request, by providing a set of
	validation result status indicators in the response. The current		validation result status indicators in the response. The current
	usefulness of the supported xml elements <valid>, <invalid>, and		usefulness of the supported xml elements <valid>, <invalid>, and
	<unchecked> is limited. They each provide an indication of validity		<unchecked> is limited. They each provide an indication of validity
	for any one location element as a part of the whole civic address,		for any one location element as a part of the whole civic address,
	but this is insufficient in providing either the complete set of		but this is insufficient in providing either the complete set of
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	<completeLocation> element within the <locationValidation> element.		<completeLocation> element within the <locationValidation> element.
	In another example, the civic location in a request might lack <A2>		In another example, the civic location in a request might lack <A2>
	(county) and <PC> (Postal Code) Civic Address Elements. In this		(county) and <PC> (Postal Code) Civic Address Elements. In this
	example, too, the LoST server is able uniquely locate the intended		example, too, the LoST server is able uniquely locate the intended
	address and consider the location <Valid>, but other entities		address and consider the location <Valid>, but other entities
	involved in a subsequent emergency call might find it helpful to have		involved in a subsequent emergency call might find it helpful to have
	the additional Civic Address Elements. The LoST server can use this		the additional Civic Address Elements. The LoST server can use this
	extension to supply the missing <A2> and <PC> Civic Address Elements.		extension to supply the missing <A2> and <PC> Civic Address Elements.
	Since [RFC5222] currently does not have a way for this additional		Since [RFC5222] does not have a way for this additional location
	location information to be returned in the <findServiceResponse>,		information to be returned in the <findServiceResponse>, this
	this document extends the LoST protocol so that it can include a		document extends the LoST protocol so that it can include a
	<completeLocation> element within the <locationValidation> element of		<completeLocation> element within the <locationValidation> element of
	the <findServiceResponse> message, allowing for the representation of		the <findServiceResponse> message, allowing for the representation of
	complete location information.		complete location information.
	An example showing complete location information supplied:		An example showing complete location information supplied:
	Input address: 6000 15th Avenue Leets, WA US		Input address:
	Complete Location: 6000 15th Avenue Northwest Leets, WA 98105 US		6000 15th Avenue
			Leets, WA US
			Complete Location:
			6000 15th Avenue Northwest
			Leets, WA 98105 US
	The information provided in the request may be enough to identify a		The information provided in the request may be enough to identify a
	unique location in the LoST server, but that may not be the location		unique location in the LoST server, but that may not be the location
	intended by the user. The <completeLocation> information may alert		intended by the user. The <completeLocation> information may alert
	the user to a mismatch between the provided location information and		the user to a mismatch between the provided location information and
	the unique location the server interpreted that information to		the unique location the server interpreted that information to
	identify.		identify.
	The other use case for this extension is when the <findService>		The other use case for this extension is when the <findService>
	request contains an Invalid Location. When a LoST server returns a		request contains an Invalid Location. When a LoST server returns a
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 20 ¶
	the response showing a complete civic location that includes the		the response showing a complete civic location that includes the
	missing <A3> element, just as in the above example the missing <A3>		missing <A3> element, just as in the above example the missing <A3>
	element is included in a <completeLocation> element.		element is included in a <completeLocation> element.
	As another example of the use of <similarLocation>, consider the		As another example of the use of <similarLocation>, consider the
	results based on a similar data set as used above, but where the		results based on a similar data set as used above, but where the
	<HNO>, <RD>, <STS>, <A1>, and <A3> Civic Address Elements are not		<HNO>, <RD>, <STS>, <A1>, and <A3> Civic Address Elements are not
	sufficient to locate a unique address, resulting in an invalid		sufficient to locate a unique address, resulting in an invalid
	location response. Because the LoST server contains additional civic		location response. Because the LoST server contains additional civic
	address elements which, had they been included in the query, would		address elements which, had they been included in the query, would
	have resulted in a uniquely identifiable location,the server can		have resulted in a uniquely identifiable location, the server can
	include one or more <similarLocation> elements containing the		include one or more <similarLocation> elements containing the
	supplied Civic Address Elements plus the omitted ones. Since		supplied Civic Address Elements plus the omitted ones. Since
	[RFC5222] currently does not have a way for this additional location		[RFC5222] does not have a way for this additional location
	information to be returned in the <findServiceResponse>, this		information to be returned in the <findServiceResponse>, this
	document extends [RFC5222] so that the LoST <locationValidation>		document extends [RFC5222] so that the LoST <locationValidation>
	element of the <findServiceResponse> can include one or more		element of the <findServiceResponse> can include one or more
	<similarLocation> elements representing similar civic locations.		<similarLocation> elements representing similar civic locations.
	To show this, suppose that a slightly modified version of the above		To show this, suppose that a slightly modified version of the above
	address is sent within a Lost <findService request>:		address is sent within a Lost <findService> request:
	Input address: 6000 15th Avenue North Leets, WA US		Input address:
			6000 15th Avenue North
			Leets, WA US
	This time we make the assumption that the address is deemed invalid		This time we make the assumption that the address is deemed invalid
	by the LoST server because there is no such thing as "15th Avenue		by the LoST server because there is no such thing as "15th Avenue
	North" within the LoST server's data for the city of Leets. However,		North" within the LoST server's data for the city of Leets. However,
	we also happen to know for this example that there are two addresses		we also happen to know for this example that there are two addresses
	within the address dataset that are "similar", when all parts of the		within the address dataset that are "similar", when all parts of the
	address are taken as a whole. These similar addresses that could be		address are taken as a whole. These similar addresses that could be
	returned to the client are as follows:		returned to the client are as follows:
	Similar address #1: 6000 15th Avenue Northwest Leets, WA 98107 US		Similar address #1:
	Similar address #2: 6000 15th Avenue Northeast Leets, WA 98105 US		6000 15th Avenue Northwest
			Leets, WA 98107 US
			Similar address #2:
			6000 15th Avenue Northeast
			Leets, WA 98105 US
	This extension allows the LoST server to include the above similar		This extension allows the LoST server to include the above similar
	addresses in the response to a <findService> request with		addresses in the response to a <findService> request with
	'validateLocaton' set to true. Section 5 shows examples of the LoST		'validateLocaton' set to true. Section 5 shows examples of the LoST
	request and response XML message fragments for the above valid and		request and response XML message fragments for the above valid and
	invalid scenarios, returning the complete or similar addresses		invalid scenarios, returning the complete or similar addresses
	respectively.		respectively.
	4. Returned Location Information		4. Returned Location Information
End of changes. 13 change blocks.
	28 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/