< draft-ietf-ecrit-similar-location-12.txt   draft-ietf-ecrit-similar-location-13.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: 14 April 2022 Comtech TCS Expires: 27 May 2022 Comtech TCS
11 October 2021 23 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-12 draft-ietf-ecrit-similar-location-13
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 14 April 2022. This Internet-Draft will expire on 27 May 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 Simplified BSD License text extracted from this document must include Revised BSD License text as
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 Simplified 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 . . . . . . . . . . . . . . . . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Complete Location returned for Valid Location response . 9 5.1. Complete Location returned for Valid Location . . . . . . 9
5.2. Similar Location returned for Invalid Location 5.2. Similar Location returned for Invalid Location . . . . . 11
response . . . . . . . . . . . . . . . . . . . . . . . . 11
6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. XML Schema Registration . . . . . . . . . . . . . . . . . 15 8.1. XML Schema Registration . . . . . . . . . . . . . . . . . 15
8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 15 8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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,
skipping to change at page 4, line 12 skipping to change at page 4, line 12
the <civicAddress> type defined in [RFC5139], including elements the <civicAddress> type defined in [RFC5139], including elements
used at the extension point therein such as those defined in used at the extension point therein such as those defined in
[RFC6848] and elsewhere. This term also includes the reference to [RFC6848] and elsewhere. This term also includes the reference to
such elements by qualified name as defined within the such elements by qualified name as defined within the
<locationValidation> element in [RFC5222]. <locationValidation> element in [RFC5222].
Invalid Location: A Civic Location that, when included in a LoST Invalid Location: A Civic Location that, when included in a LoST
query with 'validateLocation' set, will receive a response having query with 'validateLocation' set, will receive a response having
one or more Civic Address Elements in the <invalid> list. Note one or more Civic Address Elements in the <invalid> list. Note
that It is also possible that the location information submitted that it is also possible that the location information submitted
is so inaccurate that location validation cannot be performed, and is so inaccurate that location validation cannot be performed, and
the LoST server may return a <notFound> or <locationInvalid> the LoST server may return a <notFound> or <locationInvalid>
error. In this document, the term Invalid Location only refers to error. In this document, the term Invalid Location only refers to
a case where the LoST server returns one or more elements in the a case where the LoST server returns one or more elements in the
<invalid> list; the error conditions are not considered. <invalid> list; the error conditions are not considered.
Valid Location: A Civic Location, when included in a LoST query with Valid Location: A Civic Location that, when included in a LoST query
'validateLocation' set, will receive a response having all Civic with 'validateLocation' set, will receive a response having all
Address Elements in the <valid> or <unchecked> lists. Civic Address Elements in the <valid> or <unchecked> lists.
Complete Location: An expanded civic location that includes other Complete Location: An expanded civic location that includes other
Civic Address Elements in addition to the existing validated Civic Civic Address Elements in addition to the existing validated Civic
Address Elements provided as input to a LoST server. Complete Address Elements provided as input to a LoST server. Complete
Location may be returned when the input location is valid but Location may be returned when the input location is valid but
incomplete incomplete
Similar Location: A suggested civic location that is similar to an Similar Location: A suggested civic location that is similar to an
Invalid Location which was used in a LoST query, but which has one Invalid Location which was used in a LoST query, but which has one
or more elements added, modified, or removed such that the or more elements added, modified, or removed such that the
skipping to change at page 4, line 47 skipping to change at page 4, line 47
3. Overview of Returned Location Information 3. Overview of Returned Location Information
This document describes an extension to LoST [RFC5222] that allows This document describes an extension to LoST [RFC5222] that allows
additional location information to be returned in the additional location information to be returned in the
<locationValidation> element of a <findServiceResponse>. This <locationValidation> element of a <findServiceResponse>. This
extension is applicable when the location information in the extension is applicable when the location information in the
<findService> request is in the Basic Civic profile as described in <findService> request is in the Basic Civic profile as described in
[RFC5222] or in another profile whose definition provides [RFC5222] or in another profile whose definition provides
instructions concerning its use with this extension. As of this instructions concerning its use with this extension. As of this
document, no such additional location profiles have been defined, so document's publication, no such additional location profiles have
this document describes the returned location extension primarily in been defined, so this document describes the returned location
terms of how it is used with the Basic Civic profile. In addition, extension using the Basic Civic profile. In addition, the following
the following restriction is imposed: A server MUST NOT include restriction is imposed: A server MUST NOT include Returned Location
Returned Location Information using a location profile that differs Information using a location profile that differs from the profile of
from the profile of the location used to answer the query and, by the location used to answer the query and, by extension, MUST NOT
extension, MUST NOT include Returned Location Information using a include Returned Location Information using a location profile that
location profile that was not used by the client in the request. was not used by the client in the request. This extension has two
This extension has two different use cases: First, when the input different use cases: First, when the input location is incomplete but
location is incomplete but the LoST server can identify the intended the LoST server can identify the intended unique address, and second,
unique address, and second, when the input location is invalid and when the input location is invalid and the LoST server can identify
the LoST server can identify one or more likely intended locations. one or more likely intended locations.
When a LoST server is asked to validate a civic location, its goal is When a LoST server is asked to validate a civic location, its goal is
to take the set of Civic Address Elements provided as the location to take the set of Civic Address Elements provided as the location
information in the LoST request, and find a unique location in its information in the LoST request, and find a unique location in its
database that matches the information in the request. Uniqueness database that matches the information in the request. Uniqueness
might not require values for all possible elements in the Civic might not require values for all possible elements in the Civic
Address that the database might hold. Further, the input location Address that the database might hold. Further, the input location
information might not represent the form of location the users of the information might not represent the form of location the users of the
LoST service prefer to have. As an example, there are LoST Civic LoST service prefer to have. As an example, there are LoST Civic
Address Elements that could be used to define a postal location, Address Elements that could be used to define a postal location,
skipping to change at page 5, line 39 skipping to change at page 5, line 39
client application such as a Location Information Server (LIS) and client application such as a Location Information Server (LIS) and
used in a later emergency call. used in a later emergency call.
In addition, this document describes the reuse of the same mechanism, In addition, this document describes the reuse of the same mechanism,
but for a different purpose: to supply similar location information but for a different purpose: to supply similar location information
in the case where a LoST server response includes one or more Civic in the case where a LoST server response includes one or more Civic
Address Elements marked as invalid, indicating an Invalid Location Address Elements marked as invalid, indicating an Invalid Location
used in the query. In this case, the response contains one or more used in the query. In this case, the response contains one or more
suggested alternative Valid Locations. suggested alternative Valid Locations.
In a LoST findServiceResponse indicating a Valid Location i.e., In a LoST <findServiceResponse> indicating a Valid Location i.e.,
containing a <locationValidation> element with no elements listed as containing the <locationValidation> element with no elements listed
invalid, the LoST server can use this extension to include additional as invalid, the LoST server can use this extension to include
location information in a <locationValidation> element. As an additional location information in a <locationValidation> element.
example, the query might contain <HNO> (house number), <RD> (road As an example, a query contains <HNO> (house number), <RD> (road
name) <A3> (city), <A1> (state/province) and a few more CAtype name) <A3> (city), <A1> (state/province) but not <POD> (Post-
elements, but might not contain <POD> (Post-Directional) or <PC> Directional). In this example, there is no street with just the
(Postal Code) CAtype elements. In this example, there is no street street name, all streets have a post-directional. However, the LoST
with just the streetname, all streets have a post-directional. The server is able to uniquely locate the intended address and thus
civic location in the request might contain <HNO>, <RD>, <STS>, <A3> consider the queried location Valid, as there is only one street with
and <A1> Civic Address Elements that are sufficient enough for the the street name and house number in the city that it could be. As
LoST server to uniquely locate the address specified in the request the queried location is missing the post-directional element, a more
and thus be considered Valid, meaning there was only one street with strict entity might consider it Invalid (e.g., during a subsequent
the house street name and house number in the city that it could be. query) or worse, the lack of a Post-Directional element might cause
Yet, other entities involved in a subsequent emergency call might confusion and delay an emergency response. The server can use this
find it helpful to have additional Civic Address Elements such as extension to supply the missing post-directional element <POD> in a
<A2> (county) and <PC> (Postal Code) included as part of a complete <completeLocation> element within the <locationValidation> element.
civic location. Since [RFC5222] currently does not have a way for
this additional location information to be returned in the In another example, the civic location in a request might lack <A2>
<findServiceResponse>, this document extends the LoST protocol so (county) and <PC> (Postal Code) Civic Address Elements. In this
that it can include a <completeLocation> element within the example, too, the LoST server is able uniquely locate the intended
<locationValidation> element of the <findServiceResponse> message, address and consider the location <Valid>, but other entities
allowing for the representation of complete location information. involved in a subsequent emergency call might find it helpful to have
the additional Civic Address Elements. The LoST server can use this
extension to supply the missing <A2> and <PC> Civic Address Elements.
Since [RFC5222] currently does not have a way for this additional
location information to be returned in the <findServiceResponse>,
this document extends the LoST protocol so that it can include a
<completeLocation> element within the <locationValidation> element of
the <findServiceResponse> message, allowing for the representation of
complete location information.
An example showing complete location information supplied: An example showing complete location information supplied:
Input address: 6000 15th Avenue Seattle, WA US Input address: 6000 15th Avenue Leets, WA US
Complete Location: 6000 15th Avenue Northwest Seattle, WA 98105 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 Invalid Location. When a LoST server returns a request contains an Invalid Location. When a LoST server returns a
response to a <findService> request that contains a set of Civic response to a <findService> request that contains a set of Civic
Address Elements with one or more listed as invalid, this extension Address Elements with one or more listed as invalid, this extension
allows the server to include in the <locationValidation> element one allows the server to include in the <locationValidation> element one
or more locations that might be the intended location. or more locations that might be the intended location.
In the example cited above, policy at the LoST server might deem a In the example cited above, policy at the LoST server might deem a
missing <A3> element as being invalid, even if the location missing <A3> element as being invalid, even if the location
information in the request was sufficient to identify a unique information in the request is sufficient to identify a unique
address. In that case, the missing element would be listed in the address. In this case, the missing element is listed in the
<invalid> list, and a <similarLocation> element could be returned in <invalid> list, and a <similarLocation> element could be returned in
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. missing <A3> element, just as in the above example the missing <A3>
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, where the <HNO>, results based on a similar data set as used above, but where the
<RD>, <STS>, <A1>, and <A3> Civic Address Elements are not sufficient <HNO>, <RD>, <STS>, <A1>, and <A3> Civic Address Elements are not
to locate a unique address, which leads to an invalid location result sufficient to locate a unique address, resulting in an invalid
because the LoST server contains additional civic address elements location response. Because the LoST server contains additional civic
which would have resulted in a uniquely identifiable location if address elements which, had they been included in the query, would
these additional elements had been included in the location sent in have resulted in a uniquely identifiable location,the server can
the query. Since [RFC5222] currently does not have a way for this include one or more <similarLocation> elements containing the
additional location information to be returned in the supplied Civic Address Elements plus the omitted ones. Since
<findServiceResponse>, this document extends [RFC5222] so that the [RFC5222] currently does not have a way for this additional location
LoST <locationValidation> element of the <findServiceResponse> information to be returned in the <findServiceResponse>, this
message can include one or more <similarLocation> elements document extends [RFC5222] so that the LoST <locationValidation>
representing similar civic locations. element of the <findServiceResponse> can include one or more
<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 Seattle, 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 Ave North by the LoST server because there is no such thing as "15th Avenue
within the LoST server's data for the city of Seattle. However, we North" within the LoST server's data for the city of Leets. However,
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 Seattle, WA 98107 US Similar address #1: 6000 15th Avenue Northwest Leets, WA 98107 US
Similar address #2: 6000 15th Avenue Northeast Seattle, WA 98105 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. The next section shows examples of 'validateLocaton' set to true. Section 5 shows examples of the LoST
the LoST request and response XML message fragments for the above request and response XML message fragments for the above valid and
valid and invalid scenarios, returning the complete or similar invalid scenarios, returning the complete or similar addresses
addresses respectively. respectively.
4. Returned Location Information 4. Returned Location Information
A LoST server implementing this extension MAY include A LoST server implementing this extension MAY include
<completeLocation> or <similarLocation> elements within the <completeLocation> or <similarLocation> elements within the
<locationValidation> portion of the <findServiceResponse>. The <locationValidation> portion of the <findServiceResponse>. The
<completeLocation> and <similarLocation> elements are of type <completeLocation> and <similarLocation> elements are of type
"locationInformation" as defined by the LoST schema in [RFC5222], and "locationInformation" as defined by the LoST schema in [RFC5222].
contain location information in the same profile of the location used These elements MAY contain location information either in the Basic
to answer the query. These elements MAY contain location information Civic profile defined in RFC5222 or in another profile whose
either in the Basic Civic profile defined in RFC5222 or in another definition provides instructions concerning its use with this
profile derived from the Basic Civic profile whose definition extension but this MUST be the same profile as the location in the
provides instructions concerning its use with this extension. When query. When used with the Basic Civic profile, these elements
used with the Basic Civic profile, these elements contain a contain a <civicAddress> element as defined in [RFC5139].
<civicAddressgt; element as defined in [RFC5139].
The LoST server MAY include more than one <similarLocation> element The LoST server MAY include more than one <similarLocation> element
in the response. If there are too many possible locations, the in the response. If there are too many possible locations, the
server MAY return none, or it MAY return a subset considered most server MAY return none, or it MAY return a subset considered most
likely. How many to return is left to the implementation of the LoST likely. How many to return is left to the implementation of the LoST
server. The server is unable to know what the intended location server. The server is unable to know what the intended location
information was supposed to be; it is guessing. Therefore the information was supposed to be; it is guessing. Therefore the
correct location may or may not be one of the <similarLocation> correct location may or may not be one of the <similarLocation>
elements the server provides, and the client cannot assume that any elements the server provides, and the client cannot assume that any
one of them is the correct location. one of them is the correct location.
skipping to change at page 9, line 13 skipping to change at page 9, line 22
location information in the request is invalid, but alternate location information in the request is invalid, but alternate
location information is returned, the original location remains location information is returned, the original location remains
invalid, and the LoST server does not change the mapping response invalid, and the LoST server does not change the mapping response
other than optionally including the information defined by this other than optionally including the information defined by this
extension. extension.
The <completeLocation> and <similarLocation> elements use the The <completeLocation> and <similarLocation> elements use the
<locationInformation> element from [RFC5222] updated by <locationInformation> element from [RFC5222] updated by
[I-D.ietf-ecrit-lost-planned-changes], including the 'profile' [I-D.ietf-ecrit-lost-planned-changes], including the 'profile'
attribute, which is useful if the request contains location attribute, which is useful if the request contains location
information in a profile derived from the 'civic' profile. The information in a profile other than the 'civic' profile. The
'profile' attribute MUST be included in both the request and the 'profile' attribute MUST be included in both the request and the
response and MUST be the same profile in both. response and MUST be the same profile in both.
5. Examples 5. Examples
5.1. Complete Location returned for Valid Location response 5.1. Complete Location returned for Valid Location
Based on the example input request above, Returned Location This example is based on the example request above; the LoST server
Information is provided in a <findServiceResponse> message since the considered the location in the query to be valid but missing some
original input address is considered valid but is missing some Civic Address elements, so in the Returned Location Information in
additional data that the LoST server has. the <findServiceResponse>, the server includes a <completeLocation>
element supplying the omitted Civic Address elements <A2>, <PC>, and
<PCN>.
<!-- =====Request=================================== --> <!-- =====Request=================================== -->
<findService xmlns="urn:ietf:params:xml:ns:lost1" <findService xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:rli="urn:ietf:params:xml:ns:lost-rli1" xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"
validateLocation="true" rli:returnAdditionalLocation="any"> validateLocation="true" rli:returnAdditionalLocation="any">
<location id="587cd3880" profile="civic"> <location id="587cd3880" profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:mxl:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:mxl:ns:pidf:geopriv10:civicAddr">
<country>US</country> <country>US</country>
<A1>WA</A1> <A1>WA</A1>
<A3>Seattle</A3> <A3>Leets</A3>
<RD>15th</RD> <RD>15th</RD>
<STS>Avenue</STS> <STS>Avenue</STS>
<POD>Northwest</POD> <POD>Northwest</POD>
<HNO>6000</HNO> <HNO>6000</HNO>
</civicAddress> </civicAddress>
</location> </location>
<service>urn:service:sos</service> <service>urn:service:sos</service>
skipping to change at page 10, line 4 skipping to change at page 10, line 14
<STS>Avenue</STS> <STS>Avenue</STS>
<POD>Northwest</POD> <POD>Northwest</POD>
<HNO>6000</HNO> <HNO>6000</HNO>
</civicAddress> </civicAddress>
</location> </location>
<service>urn:service:sos</service> <service>urn:service:sos</service>
</findService> </findService>
<!-- =====Response================================== --> <!-- =====Response================================== -->
<findServiceResponse > <findServiceResponse >
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> xmlns:rli="urn:ietf:params:xml:ns:lost-rli1">
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<mapping <mapping
expires="NO-CACHE" expires="NO-CACHE"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example" source="authoritative.example"
sourceId="8799e346000098aa3e"> sourceId="8799e346000098aa3e">
<displayName xml:lang="en">Seattle 911</displayName> <displayName xml:lang="en">Leets 911</displayName>
<service>urn:service:sos</service> <service>urn:service:sos</service>
<uri>sip:seattle-911@example.com</uri> <uri>sip:leets-911@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
<locationValidation> <locationValidation>
<valid>ca:country ca:A1 ca:A3 ca:RD ca:STS ca:POD ca:HNO <valid>ca:country ca:A1 ca:A3 ca:RD ca:STS ca:POD ca:HNO
</valid> </valid>
<invalid></invalid> <invalid></invalid>
<unchecked></unchecked> <unchecked></unchecked>
<rli:completeLocation profile="civic"><!--completed address--> <rli:completeLocation profile="civic"><!--completed address-->
<ca:civicAddress> <ca:civicAddress>
<ca:country>US</ca:country> <ca:country>US</ca:country>
<ca:A1>WA</ca:A1> <ca:A1>WA</ca:A1>
<ca:A2>KING COUNTY</ca:A2> <ca:A2>SHOWAK COUNTY</ca:A2>
<ca:A3>SEATTLE</ca:A3> <ca:A3>LEETS</ca:A3>
<ca:RD>15TH</ca:RD> <ca:RD>15TH</ca:RD>
<ca:STS>AVENUE</ca:STS> <ca:STS>AVENUE</ca:STS>
<ca:POD>NORTHWEST</ca:POD> <ca:POD>NORTHWEST</ca:POD>
<ca:HNO>6000</ca:HNO> <ca:HNO>6000</ca:HNO>
<ca:PC>98106</ca:PC> <ca:PC>98106</ca:PC>
<ca:PCN>SEATTLE</ca:PCN> <ca:PCN>LEETS</ca:PCN>
</ca:civicAddress> </ca:civicAddress>
</rli:completeLocation> </rli:completeLocation>
</locationValidation> </locationValidation>
<path> <path>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="587cd3880"/> <locationUsed id="587cd3880"/>
</findServiceResponse> </findServiceResponse>
<!-- =============================================== --> <!-- =============================================== -->
5.2. Similar Location returned for Invalid Location response 5.2. Similar Location returned for Invalid Location
The following example shows two returned Similar Locations in a The following example shows two Similar Locations returned in a
<findServiceResponse> message when the original input address is <findServiceResponse> message when the original input address is
considered invalid, in this example because the LoST server needed considered invalid, in this example because the LoST server needed
the omitted POD data to match a unique address. the omitted POD data to match a unique address.
<!-- =====Request=================================== --> <!-- =====Request=================================== -->
<findService xmlns="urn:ietf:params:xml:ns:lost1" <findService xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:rli="urn:ietf:params:xml:ns:lost-rli1" xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"
validateLocation="true" validateLocation="true"
rli:returnAdditionalLocation="any"> rli:returnAdditionalLocation="any">
<location id="587cd3880" profile="civic"> <location id="587cd3880" 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>WA</A1> <A1>WA</A1>
<A2>KING COUNTY</A2> <A2>SHOWAK COUNTY</A2>
<A3>SEATTLE</A3> <A3>LEETS</A3>
<RD>15TH</RD> <RD>15TH</RD>
<STS>AVENUE</STS> <STS>AVENUE</STS>
<HNO>6000</HNO> <HNO>6000</HNO>
<PC>98106</PC> <PC>98106</PC>
<PCN>SEATTLE</PCN> <PCN>LEETS</PCN>
</civicAddress> </civicAddress>
</location> </location>
<service>urn:service:sos</service> <service>urn:service:sos</service>
</findService> </findService>
<!-- =====Response=================================== --> <!-- =====Response=================================== -->
<findServiceResponse> <findServiceResponse>
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> xmlns:rli="urn:ietf:params:xml:ns:lost-rli1">
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<mapping <mapping
expires="NO-CACHE" expires="NO-CACHE"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example" source="authoritative.example"
sourceId="8799e346000098aa3e"> sourceId="8799e346000098aa3e">
<displayName xml:lang="en">Seattle 911</displayName> <displayName xml:lang="en">Leets 911</displayName>
<service>urn:service:sos</service> <service>urn:service:sos</service>
<uri>sip:seattle-911@example.com</uri> <uri>sip:leets-911@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
<locationValidation similarLocationsLimited="5"> <locationValidation similarLocationsLimited="5">
<valid>ca:country ca:A1 ca:A3 ca:STS ca:RD</valid> <valid>ca:country ca:A1 ca:A3 ca:STS ca:RD</valid>
<invalid>ca:POD</invalid> <invalid>ca:POD</invalid>
<unchecked>ca:HNO</unchecked> <unchecked>ca:HNO</unchecked>
<rli:similarLocation profile="civic"><!--similar location--> <rli:similarLocation profile="civic"><!--similar location-->
<ca:civicAddress> <!-- similar address #1 --> <ca:civicAddress> <!-- similar address #1 -->
<ca:country>US</ca:country> <ca:country>US</ca:country>
<ca:A1>WA</ca:A1> <ca:A1>WA</ca:A1>
<ca:A2>KING COUNTY</ca:A2> <ca:A2>SHOWAK COUNTY</ca:A2>
<ca:A3>SEATTLE</ca:A3> <ca:A3>LEETS</ca:A3>
<ca:RD>15TH</ca:RD> <ca:RD>15TH</ca:RD>
<ca:STS>AVENUE</ca:STS> <ca:STS>AVENUE</ca:STS>
<ca:POD>NORTHWEST</ca:POD> <ca:POD>NORTHWEST</ca:POD>
<ca:HNO>6000</ca:HNO> <ca:HNO>6000</ca:HNO>
<ca:PC>98106</ca:PC> <ca:PC>98106</ca:PC>
<ca:PCN>SEATTLE</ca:PCN> <ca:PCN>LEETS</ca:PCN>
</ca:civicAddress> </ca:civicAddress>
</rli:similarLocation> </rli:similarLocation>
<rli:similarLocation profile="civic" > <rli:similarLocation profile="civic" >
<ca:civicAddress> <!-- similar address #2 --> <ca:civicAddress> <!-- similar address #2 -->
<ca:country>US</ca:country> <ca:country>US</ca:country>
<ca:A1>WA</ca:A1> <ca:A1>WA</ca:A1>
<ca:A2>KING COUNTY</ca:A2> <ca:A2>SHOWAK COUNTY</ca:A2>
<ca:A3>SEATTLE</ca:A3> <ca:A3>LEETS</ca:A3>
<ca:RD>15TH</ca:RD> <ca:RD>15TH</ca:RD>
<ca:STS>AVENUE</ca:STS> <ca:STS>AVENUE</ca:STS>
<ca:POD>NORTHEAST</ca:POD> <ca:POD>NORTHEAST</ca:POD>
<ca:HNO>6000</ca:HNO> <ca:HNO>6000</ca:HNO>
<ca:PC>98105</ca:PC> <ca:PC>98105</ca:PC>
<ca:PCN>SEATTLE</ca:PCN> <ca:PCN>LEETS</ca:PCN>
</ca:civicAddress> </ca:civicAddress>
</rli:similarLocation> </rli:similarLocation>
</locationValidation> </locationValidation>
<path> <path>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="587cd3880"/> <locationUsed id="587cd3880"/>
skipping to change at page 16, line 37 skipping to change at page 16, line 37
</html> </html>
END END
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-ecrit-lost-planned-changes] [I-D.ietf-ecrit-lost-planned-changes]
Rosen, B., "Validation of Locations Around a Planned Rosen, B., "Validation of Locations Around a Planned
Change", Work in Progress, Internet-Draft, draft-ietf- Change", Work in Progress, Internet-Draft, draft-ietf-
ecrit-lost-planned-changes-04, 19 August 2021, ecrit-lost-planned-changes-05, 11 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-ecrit-lost- <https://www.ietf.org/archive/id/draft-ietf-ecrit-lost-
planned-changes-04.txt>. planned-changes-05.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139,
February 2008, <https://www.rfc-editor.org/info/rfc5139>.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
<https://www.rfc-editor.org/info/rfc5222>. <https://www.rfc-editor.org/info/rfc5222>.
9.2. Informative References 9.2. Informative References
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139,
February 2008, <https://www.rfc-editor.org/info/rfc5139>.
[RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and
R. George, "Specifying Civic Address Extensions in the R. George, "Specifying Civic Address Extensions in the
Presence Information Data Format Location Object (PIDF- Presence Information Data Format Location Object (PIDF-
LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013, LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013,
<https://www.rfc-editor.org/info/rfc6848>. <https://www.rfc-editor.org/info/rfc6848>.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
470 Conrad Dr 470 Conrad Dr
 End of changes. 48 change blocks. 
120 lines changed or deleted 133 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/