< draft-ietf-ecrit-similar-location-16.txt   draft-ietf-ecrit-similar-location-17.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: 16 July 2022 Comtech TCS Expires: 29 July 2022 Comtech TCS
12 January 2022 25 January 2022
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-16 draft-ietf-ecrit-similar-location-17
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
completed civic address element set for a valid location response, completed civic address element set for a valid location response,
and one or more suggested sets of similar location information for an and one or more suggested sets of similar location information for an
invalid location. These two types of civic addresses are referred to invalid location. These two types of civic addresses are referred to
as either "complete location" or "similar location", and are included as either "complete location" or "similar location", and are included
as a compilation of CAtype xml elements within the existing LoST as a compilation of CAtype XML elements within the existing LoST
<findServiceResponse> message structure. <findServiceResponse> message structure.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 16 July 2022. This Internet-Draft will expire on 29 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The LoST protocol [RFC5222] supports the validation of civic location The LoST protocol [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
civic address elements that the LoST server contains, or of providing civic address elements that the LoST server contains, or of providing
alternate suggestions (hints) as to which civic address is intended alternate suggestions (hints) as to which civic address is intended
for use. for use.
Whether the queried civic location is valid but missing information, Whether the queried civic location is valid but missing information,
or invalid due to missing or wrong information, this document or invalid due to missing or wrong information, this document
provides a mechanism to return a complete set of civic address provides a mechanism to return a complete set of civic address
skipping to change at page 3, line 24 skipping to change at page 3, line 24
The structure of this document includes terminology, Section 2, The structure of this document includes terminology, Section 2,
followed by a discussion of the basic elements involved in location followed by a discussion of the basic elements involved in location
validation. The use of these elements, by way of example, is validation. The use of these elements, by way of example, is
discussed in an overview section, Section 3, with accompanying discussed in an overview section, Section 3, with accompanying
rationale, and a brief discussion of the impacts to LoST, and its rationale, and a brief discussion of the impacts to LoST, and its
current schema. current schema.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. .
The following terms are defined in this document: The following terms are defined in this document:
Location: The term Location is in general used to refer to either a Location: The term Location is in general used to refer to either a
civic location or a geodetic location. In the context of this civic location or a geodetic location. In the context of this
document, location is restricted to civic locations. document, location is restricted to civic locations.
Geodetic Location: a geographic coordinate set of values that Geodetic Location: a geographic coordinate set of values that
describes a point within a defined geographic datum. For example, describes a point within a defined geographic datum. For example,
a WGS84 referenced latitude, longitude coordinate pair (2D), or a referenced latitude/longitude coordinate pair (2D), or latitude,
latitude, longitude, and altitude (3D). Note: geodetic location longitude, and altitude (3D). Note: geodetic location is defined
is defined here for context, but is not used elsewhere within this here for context, but is not used elsewhere within this document.
document.
Civic Location: The term Civic Location applies to a set of one or Civic Location: The term Civic Location applies to a set of one or
more Civic Address Elements that are used in conjunction with each more Civic Address Elements that are used in conjunction with each
other, and in accordance with a known ruleset to designate a other, and in accordance with a known ruleset to designate a
specific place within a region of geography, or a region of specific place within a region of geography, or a region of
geography by itself as defined in [RFC5139]. geography by itself as defined in [RFC5139].
Civic Address: The term Civic Address is used interchangeably with Civic Address: The term Civic Address is used interchangeably with
the term Civic Location within this document. the term Civic Location within this document.
skipping to change at page 4, line 43 skipping to change at page 4, line 45
returned when the input location is invalid returned when the input location is invalid
Returned Location Information: A set of civic locations returned in Returned Location Information: A set of civic locations returned in
a LoST response. a LoST response.
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 has two different use cases: First, when the input location
is incomplete but the LoST server can identify the intended unique
address, and second, when the input location is invalid and the LoST
server can identify one or more likely intended locations. 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's publication, no such additional location profiles have document's publication, no such additional location profiles have
been defined, so this document describes the returned location been defined, so this document describes the returned location
extension using the Basic Civic profile. In addition, the following extension using the Basic Civic profile. In addition, the following
restriction is imposed: A server MUST NOT include Returned Location restriction is imposed: A server MUST NOT include Returned Location
Information using a location profile that differs from the profile of Information using a location profile that differs from the profile of
the location used to answer the query and, by extension, MUST NOT the location used to answer the query and, by extension, MUST NOT
include Returned Location Information using a location profile that include Returned Location Information using a location profile that
was not used by the client in the request. This extension has two was not used by the client in the request.
different use cases: First, when the input location is incomplete but
the LoST server can identify the intended unique address, and second,
when the input location is invalid and the LoST server can identify
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 9, line 37 skipping to change at page 9, line 37
location information (if the server could send any) and 'any' means location information (if the server could send any) and 'any' means
to include Similar and/or Complete Location (if the server could send to include Similar and/or Complete Location (if the server could send
any). If the request includes this attribute, the server MUST NOT any). If the request includes this attribute, the server MUST NOT
send location information contravening the client's request. send location information contravening the client's request.
Omitting this attribute in the request is equivalent to including it Omitting this attribute in the request is equivalent to including it
with the value 'none'. with the value 'none'.
The server may determine that there are many possible Similar The server may determine that there are many possible Similar
Locations and decide not to send them all. The number of Similar Locations and decide not to send them all. The number of Similar
Locations sent is entirely up to the server. The server MAY include Locations sent is entirely up to the server. The server MAY include
a 'similarLocationsLimited' attribute which contains a non-zero a 'similarLocationsOmitted' attribute which contains a non-zero
integer indicating the minimum number of Similar Locations not integer indicating the minimum number of Similar Locations not
included in the response. There may be more than the indicated included in the response. There may be more than the indicated
similar locations available in the data held by the server. similar locations available in the data held by the server, but no
mechanism to request more Similar Locations is provided.
Clients MAY ignore the location information this extension defines. Clients MAY ignore the location information this extension defines.
The information is optional to send, and optional to use. In the The information is optional to send, and optional to use. In the
case where the location information in the request was valid, this case where the location information in the request was valid, this
extension does not change the validity. In the case where the extension does not change the validity. In the case where the
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.
skipping to change at page 13, line 17 skipping to change at page 13, line 17
source="authoritative.example" source="authoritative.example"
sourceId="8799e346000098aa3e"> sourceId="8799e346000098aa3e">
<displayName xml:lang="en">Leets 911</displayName> <displayName xml:lang="en">Leets 911</displayName>
<service>urn:service:sos</service> <service>urn:service:sos</service>
<uri>sip:leets-911@example.com</uri> <uri>sip:leets-911@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
<locationValidation similarLocationsLimited="5"> <locationValidation similarLocationsOmitted="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>SHOWAK COUNTY</ca:A2> <ca:A2>SHOWAK COUNTY</ca:A2>
skipping to change at page 15, line 39 skipping to change at page 15, line 39
<xs:choice minOccurs="0"> <xs:choice minOccurs="0">
<xs:element name="similarLocation" <xs:element name="similarLocation"
type="lost1:locationInformation" type="lost1:locationInformation"
minOccurs="1" maxOccurs="unbounded" /> minOccurs="1" maxOccurs="unbounded" />
<xs:element name="completeLocation" <xs:element name="completeLocation"
type="lost1:locationInformation"/> type="lost1:locationInformation"/>
</xs:choice> </xs:choice>
</xs:group> </xs:group>
<!-- and also at the locationValidation extensionPoint --> <!-- and also at the locationValidation extensionPoint -->
<xs:attribute name="similarLocationsLimited" use="optional"> <xs:attribute name="similarLocationsOmitted" use="optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:integer"> <xs:restriction base="xs:integer">
<xs:minInclusive value="1"/> <xs:minInclusive value="1"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:schema> </xs:schema>
7. Security Considerations 7. Security Considerations
skipping to change at page 16, line 37 skipping to change at page 16, line 37
LoST server implementations SHOULD evaluate the particular use cases LoST server implementations SHOULD evaluate the particular use cases
where this extension is supported, and weigh the risks around its where this extension is supported, and weigh the risks around its
use. Many services available today via the Internet offer similar use. Many services available today via the Internet offer similar
features, such as "did you mean" or address completion, so this features, such as "did you mean" or address completion, so this
capability is not introducing any fundamentally new threat. capability is not introducing any fundamentally new threat.
8. IANA Considerations 8. IANA Considerations
8.1. XML Schema Registration 8.1. XML Schema Registration
IANA is requested to register the following in the "schema" sub-
registry of the IETF XML Registry per [RFC3688].
URI: urn:ietf:params:xml:schema:lost-rli1 URI: urn:ietf:params:xml:schema:lost-rli1
Registrant Contact: IETF ECRIT Working Group, Brian Rosen Registrant Contact: IETF ECRIT Working Group, Brian Rosen
(br@brianrosen.net). (br@brianrosen.net).
XML Schema: The XML schema to be registered is contained XML Schema: The XML schema to be registered is contained
in Section 6. in Section 6.
8.2. LoST-RLI Namespace Registration 8.2. LoST-RLI Namespace Registration
IANA is requested to register the following in the "ns" sub-registry
of the IETF XML registry per [RFC3553].
URI: urn:ietf:params:xml:ns:lost-rli1 URI: urn:ietf:params:xml:ns:lost-rli1
Registrant Contact: IETF ECRIT Working Group, Brian Rosen Registrant Contact: IETF ECRIT Working Group, Brian Rosen
(br@brianrosen.net). (br@brianrosen.net).
XML: XML:
BEGIN BEGIN
<?xml version="2.0"?> <?xml version="2.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
skipping to change at page 17, line 46 skipping to change at page 17, line 47
Change", Work in Progress, Internet-Draft, draft-ietf- Change", Work in Progress, Internet-Draft, draft-ietf-
ecrit-lost-planned-changes-05, 11 October 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-05.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>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139,
February 2008, <https://www.rfc-editor.org/info/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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[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
 End of changes. 17 change blocks. 
21 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/