ECRIT B. Rosen
Internet-Draft
Updates: 5222 (if approved) R. Marshall
Intended status: Standards Track J. Martin
Expires: 6 March 2022 Comtech TCS
2 September 2021
A LoST extension to return complete and similar location info
draft-ietf-ecrit-similar-location-10
Abstract
This document introduces a new way to provide returned location
information in LoST responses that is either of a completed or
similar form to the original input civic location, based on whether
valid or invalid civic address elements are returned within the
findServiceResponse message. This document defines a new extension
to the findServiceResponse message within the LoST protocol [RFC5222]
that enables the LoST protocol to return in it's response a completed
civic address element set for a valid location response, and one or
more suggested sets of similar location information for an invalid
location. These two types of civic addresses are referred to as
either "complete location" or "similar location", and are included as
a compilation of CAtype xml elements within the existing LoST
findServiceResponse message structure.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 March 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Rosen, et al. Expires 6 March 2022 [Page 1]
Internet-Draft Returned Location Extensions to LoST September 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Returned Location Information . . . . . . . . . . 4
4. Returned Location Information . . . . . . . . . . . . . . . . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Complete Location returned for Valid Location response . 8
5.2. Similar Location returned for Invalid Location
response . . . . . . . . . . . . . . . . . . . . . . . . 10
6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. XML Schema Registration . . . . . . . . . . . . . . . . . 15
8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The LoST protcol [RFC5222] supports the validation of civic location
information sent in a findService request, by providing a set of
validation result status indicators in the response. The current
usefulness of the supported xml elements, "valid", "invalid", and
"unchecked" is limited, because while they each provide an indication
of validity for any one location element as a part of the whole civic
address, the mechanism is insufficient in providing either the
complete set of civic address elements that the LoST server contains,
or of providing alternate suggestions (hints) as to which civic
address is intended for use.
Whether the input civic location is valid but missing information, or
invalid due to missing or wrong information, this document provides a
mechanism to return a complete set of civic address elements for
those valid or invalid cases.
Rosen, et al. Expires 6 March 2022 [Page 2]
Internet-Draft Returned Location Extensions to LoST September 2021
This enhancement to the validation feature within LoST is required by
systems that rely on accurate location for processing. Use of this
enhancement increases the likelihood that the correct and/or complete
form of a civic location becomes timely known in those cases where it
is incomplete or incorrect. One such use case is that of location
based emergency calling. The use of this protocol extension
facilitates the timely correction of errors, and allows location
servers to be more easily provisioned with complete address
information.
The structure of this document includes terminology, Section 2,
followed by a discussion of the basic elements involved in location
validation. The use of these elements, by way of example, is
discussed in an overview section, Section 3, with accompanying
rationale, and a brief discussion of the impacts to LoST, and its
current schema.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
The following terms are defined in this document:
Location: The term Location can be used to refer to either a civic
location or a geodetic location.
Geodetic Location: a geographic coordinate set of values that
describes a point within a defined geographic datum. For example,
a WGS84 referenced latitude, longitude coordinate pair (2D), or
latitude, longitude, and altitude (3D). Note: geodetic location
is defined here for context, but is not used elsewhere within this
document.
Civic Location: The term Civic Location applies to a set of one or
more Civic Address Elements that are used in conjunction with each
other, and in accordance with a known ruleset to designate a
specific place within a region of geography, or a region of
geography by itself as defined in [RFC5139].
Civic Address: The term Civic Address is used interchangeably with
the term Civic Location within this document.
Civic Address Element: The term Civic Address Element is used within
this document to apply to an individual CAtype data descriptor,
for example, as is described in [RFC4776], [RFC5774], and
[RFC6848].
Rosen, et al. Expires 6 March 2022 [Page 3]
Internet-Draft Returned Location Extensions to LoST September 2021
Invalid Location: A Civic Location that was included in a LoST
validateLocation request and subsequently returned with one or
more Civic Address Elements marked as invalid. Note that location
information may be submitted in the findRequest that causes the
LoST server to return Civic Address Elements in the invalid list.
It is also possible that the location information submitted is so
inaccurate that this extension can not be used, and the LoST
server may return a notFound. In this document, we use the term
Invalid Location only to refer to a case where the LoST server
returns one or more elements in the invalid list.
Valid Location: A Civic Location that was included in a LoST
validateLocation request and subsequently returned with all Civic
Address Elements in the valid or unchecked lists.
Complete Location: An expanded civic location that includes other
Civic Address Elements in addition to the existing validated Civic
Address Elements provided as input to a LoST server.
Similar Location: A suggested civic location that is similar to the
civic location which was input, but which had one or more invalid
civic address elements returned by the LoST server or was missing
Civic Adddress Elements the server has for the location.
Returned Location Information: A set of civic locations returned in
a LoST response.
3. Overview of Returned Location Information
This document describes an extension to LoST [RFC5222] to allow
additional location information to be returned in the
locationValidation element of a findServiceResponse. This extension
is applicable when the location information in the findServiceRequest
is in a civic profile as described in RFC5222 or in another profile
derived from that civic profile. 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.
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
information in the LoST request, and find a unique location in its
database that matches the information in the request. Uniqueness
might not require values for all possible elements in the Civic
Address that the database might hold. Further, the input location
information might not represent the form of location the users of the
LoST service prefer to have. As an example, there are LoST Civic
Rosen, et al. Expires 6 March 2022 [Page 4]
Internet-Draft Returned Location Extensions to LoST September 2021
Address Elements that could be used to define a postal location,
suitable for delivery of mail as well as a municipal location
suitable for responding to an emergency call. While the LoST server
might be able to determine the location from the postal elements
provided, the emergency services would prefer that the municipal
location be used for any subsequent emergency call. Since validation
is often performed well in advance of an end-user placing an
emergency call, if the LoST server could return the preferred form of
location (or more properly in this example, the municipal elements in
addition to the postal elements), those elements could be stored in a
LIS or client application and used in a later emergency call.
In addition, this document describes the reuse of the same mechanism,
but for a different purpose: to supply similar location information
in the case where a LoST server response includes one or more Civic
Address Elements marked as invalid, constituting an Invalid Location
response. In this case, the response contains one or more suggested
alternative Valid Locations.
In a LoST findServiceResponse indicating a Valid Location -- i.e.,
containing a locationValidation element with no elements listed as
invalid -- the LoST server can use this extension to include
additional location information in a locationValidation element. As
an example, the query might contain a HNO (house number), RD (road
name) A3 (city), A1 (state/province) and a few more CAtype elements,
but might not contain A2 (county) or PC (Postal Code) CAtypes. The
civic location in the request might contain HNO, RD, STS, POD, A3 and
A1 Civic Address Elements that are sufficient enough for the LoST
server to uniquely locate the address specified in the request and
thus be considered Valid. Yet, other entities involved in a
subsequent emergency call might find it helpful to have additional
Civic Address Elements such as A2 (county), PC, (Postal Code) be
included as part of a complete civic location. 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:
Input address: 6000 15th Ave NW Seattle
Complete Location: 6000 15th Ave NW Seattle, WA 98105 US
Rosen, et al. Expires 6 March 2022 [Page 5]
Internet-Draft Returned Location Extensions to LoST September 2021
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
intended by the user. The completeLocation information may alert the
user to a mismatch between the provided location information and the
unique location the server interpreted that information to identify.
The other use case for this extension is when Invalid Location is
received from the LoST server. When a LoST server returns a response
to a findService request that contains a set of Civic Address
Elements with one or more labeled as invalid, the location
information in the findServiceResponse can be extended to include one
or more locations that might be the location desired.
In the example cited above, policy at the LoST server might deem a
missing A3 element as invalid, even if the location information in
the request was sufficient to identify a unique address. In that
case, the missing element would be listed in the invalid list, and a
similarLocation element could be returned in the response showing a
complete civic location that includes the missing A3 element, just as
in the above example.
As another example of the use of similarLocation, consider the
results based on a similar data set as used above, where the HNO, RD,
STS, A1, and A3 Civic Address Elements are not sufficient to locate a
unique address, which leads to an invalid location result. Because
the LoST server typically contains additional civic address elements
which could have resulted in a uniquely identifiable location if
these additional elements had been included in the location sent in
the query. Since [RFC5222] currently does not have a way for this
additional location information to be returned in the
findServiceResponse, this document extends [RFC5222] so that the LoST
locationValidation element of the findServiceResponse message can
include one or more similarLocation elements representing similar
civic locations.
To show this, suppose that a slightly modified version of the above
address is sent within a Lost findService request:
Input address: 6000 15th Ave N Seattle, WA.
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 N"
within the LoST server's data for the city of Seattle. However, 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
address are taken as a whole. These similar addresses that could be
returned to the client are as follows:
Rosen, et al. Expires 6 March 2022 [Page 6]
Internet-Draft Returned Location Extensions to LoST September 2021
Similar address #1: 6000 15th Ave NW Seattle, WA 98107
Similar address #2: 6000 15th Ave NE Seattle, WA 98105
This extension allows the LoST server to include the above similar
addresses in the response to locationValidation. The next section
shows examples of the LoST request and response XML message fragments
for the above valid and invalid scenarios, returning the complete or
similar addresses respectively.
4. Returned Location Information
The LoST server implementing this extension MAY include
completeLocation or similarLocation elements within the
locationValidation portion of the findService response. The
completeLocation and similarLocation elements contain a list of Civic
Address Elements identical to the elements used in the location
element with the "civic profile" in [RFC5222] or another profile
derived from the civic profile.
The LoST server MAY include more than one similarLocation element in
the response. If there are too many possible locations, the 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 server.
The server is unable to know what the intended location information
was suppose to be; it is guessing. Therefore the correct location
may or may not be one of the similarLocation elements the server
provides, and the client cannot assume that any of them are the
correct location.
Where a LoST server contains additional location information relating
to the Civic Address used in a findServiceRequest, the
findServiceResponse message MAY include a completeLocation element
containing additional location information along with the original
validated Civic Address Elements; the additional Civic Address
Elements may be deemed by local policy as necessary to form a
Complete Location. The completeLocation element MUST NOT be returned
in response messages where any Civic Address Elements occur in the
invalid list of the response, or where the set of Civic Address
Elements in the request do not identify a unique location. The
Complete Location MUST NOT contain any elements that would be marked
as invalid, or cause an error, if a recipient of that location
performs a subsequent findService request using the Complete
Location. However, if a subsequent request includes the Complete
Location, the corresponding request MAY include elements in the
unchecked list.
Rosen, et al. Expires 6 March 2022 [Page 7]
Internet-Draft Returned Location Extensions to LoST September 2021
Clients can control the return of additional location information by
including an optional returnAdditionalLocation attribute with
possible values "none", "similar", "complete" or "any". The value
"none" means to not return additional location information, "similar"
and "complete" mean to only return the respective type of additional
location information (if the server could send any) and "any" means
to include Similar and/or Complete Location (if the server could send
any). If the request includes this attribute, the server MUST NOT
send location information contravening the client's request.
Omitting this attribute in the request is equivalent to including it
with the value "none".
The server may determine that there are many possible 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
a similarLocationsLimited attribute which contains a non-zero integer
indicating the number of Similar Locations not included in the
response. The server is NOT obligated to make this number accurate,
in that there may be more than the indicated similar locations
available in the data held by the server.
Clients MAY ignore the location information this extension defines.
The information is optional to send, and optional to use. In the
case where the location information in the request was valid, this
extension does not change the validity. In the case where the
location information in the request is invalid, but alternate
location information is returned, the original location remains
invalid, and the LoST server does not change the mapping response
other than optionally including the information defined by this
extension.
The completeLocation and similarLocation elements use the
locationInformation element from [RFC5222] updated by
[I-D.ietf-ecrit-lost-planned-changes], including the profile
attribute, which is useful if the request contains location
information in a profile derived from the civic profile. The profile
attribute MUST be included in both the request and the response and
MUST be the same profile in both.
5. Examples
5.1. Complete Location returned for Valid Location response
Based on the example input request above, Returned Location
Information is provided in a findServiceResponse message since the
original input address is considered valid but is missing some
additional data that the LoST server has.
Rosen, et al. Expires 6 March 2022 [Page 8]
Internet-Draft Returned Location Extensions to LoST September 2021
See RFC????.
END 9. References 9.1. Normative References [I-D.ietf-ecrit-lost-planned-changes] Rosen, B., "Validation of Locations Around a Planned Change", Work in Progress, Internet-Draft, draft-ietf- ecrit-lost-planned-changes-04, 19 August 2021,