Skip to main content

A LoST extension to return complete and similar location info
draft-ietf-ecrit-similar-location-11

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Brian Rosen , Roger Marshall , Jeff Martin
Last updated 2021-09-29 (Latest revision 2021-09-02)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Waiting for WG Chair Go-Ahead
Revised I-D Needed - Issue raised by WG
Associated WG milestone
Aug 2017
Submit ‘A LoST extension to return complete and similar location info‘ to the IESG for consideration as an Informational RFC
Document shepherd Henning Schulzrinne
IESG IESG state AD is watching
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Murray Kucherawy
Send notices to (None)
draft-ietf-ecrit-similar-location-11
ECRIT                                                           B. Rosen
Internet-Draft                                                          
Updates: 5222 (if approved)                                  R. Marshall
Intended status: Standards Track                               J. Martin
Expires: 2 April 2022                                        Comtech TCS
                                                       29 September 2021

     A LoST extension to return complete and similar location info
                  draft-ietf-ecrit-similar-location-11

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 a 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 2 April 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Rosen, et al.             Expires 2 April 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.  They each provide an indication of validity
   for any one location element as a part of the whole civic address,
   but this 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 queried 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.

Rosen, et al.             Expires 2 April 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 2 April 2022                  [Page 3]
Internet-Draft    Returned Location Extensions to LoST    September 2021

   Invalid Location:  A Civic Location that was included in a LoST
      request with 'validateLocation' set and subsequently returned with
      one or more Civic Address Elements marked as invalid.  Note that
      location information may be submitted in the <findService> request
      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> error.  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 query
      with 'validateLocation' set 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
   <findService> request 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

Rosen, et al.             Expires 2 April 2022                  [Page 4]
Internet-Draft    Returned Location Extensions to LoST    September 2021

   LoST service prefer to have.  As an example, there are LoST Civic
   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 2 April 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 2 April 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 'validateLocaton' request.  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

   A LoST server implementing this extension MAY include
   <completeLocation> or <similarLocation> elements within the
   <locationValidation> portion of the <findServiceResponse>.  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 <findService> request, 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 response MAY include elements in the
   unchecked list.

Rosen, et al.             Expires 2 April 2022                  [Page 7]
Internet-Draft    Returned Location Extensions to LoST    September 2021

   Clients can control the return of additional location information by
   including the 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 minimum number of Similar Locations not
   included in the response.  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 2 April 2022                  [Page 8]
Internet-Draft    Returned Location Extensions to LoST    September 2021

      <!-- =====Request=================================== -->

      <findService xmlns="urn:ietf:params:xml:ns:lost1"
        xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"
        validateLocation="true" rli:returnAdditionalLocation="any">

        <location id="587cd3880" profile="civic">
          <civicAddress
            xmlns="urn:ietf:params:mxl:ns:pidf:geopriv10:civicAddr">

            <country>US</country>
            <A1>WA</A1>
            <A3>Seattle</A3>
            <RD>15th</RD>
            <STS>Avenue</STS>
            <POD>Northwest</POD>
            <HNO>6000</HNO>

          </civicAddress>
        </location>

        <service>urn:service:sos</service>

      </findService>

      <!-- =====Response================================== -->

      <findServiceResponse >
        xmlns="urn:ietf:params:xml:ns:lost1"
        xmlns:rli="urn:ietf:params:xml:ns:lost-rli1">
        xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">

        <mapping
          expires="NO-CACHE"
          lastUpdated="2006-11-01T01:00:00Z"
          source="authoritative.example"
          sourceId="8799e346000098aa3e">

          <displayName xml:lang="en">Seattle 911</displayName>
          <service>urn:service:sos</service>
          <uri>sip:seattle-911@example.com</uri>
          <serviceNumber>911</serviceNumber>

        </mapping>

Rosen, et al.             Expires 2 April 2022                  [Page 9]
Internet-Draft    Returned Location Extensions to LoST    September 2021

        <locationValidation>

          <valid>ca:country ca:A1 ca:A3 ca:RD ca:STS ca:POD ca:HNO
          </valid>
          <invalid></invalid>
          <unchecked></unchecked>

          <rli:completeLocation profile="civic"><!--completed address-->
            <ca:civicAddress>
              <ca:country>US</ca:country>
              <ca:A1>WA</ca:A1>
              <ca:A2>KING COUNTY</ca:A2>
              <ca:A3>SEATTLE</ca:A3>
              <ca:RD>15TH</ca:RD>
              <ca:STS>AVENUE</ca:STS>
              <ca:POD>NORTHWEST</ca:POD>
              <ca:HNO>6000</ca:HNO>
              <ca:PC>98106</ca:PC>
              <ca:PCN>SEATTLE</ca:PCN>
            </ca:civicAddress>

        </rli:completeLocation>

      </locationValidation>

        <path>
          <via source="authoritative.example"/>
        </path>

        <locationUsed id="587cd3880"/>

      </findServiceResponse>

      <!-- =============================================== -->

5.2.  Similar Location returned for Invalid Location response

   The following example shows two returned Similar Locations in a
   <findServiceResponse> message when the original input address is
   considered invalid, in this example because the LoST server needed
   the omitted POD data to match a unique address.

Rosen, et al.             Expires 2 April 2022                 [Page 10]
Internet-Draft    Returned Location Extensions to LoST    September 2021

<!-- =====Request=================================== -->

   <findService xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"
     validateLocation="true"
     rli:returnAdditionalLocation="any">

     <location id="587cd3880" profile="civic">
        <civicAddress
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">

           <country>US</country>
           <A1>WA</A1>
           <A2>KING COUNTY</A2>
           <A3>SEATTLE</A3>
           <RD>15TH</RD>
           <STS>AVENUE</STS>
           <HNO>6000</HNO>
           <PC>98106</PC>
           <PCN>SEATTLE</PCN>

       </civicAddress>
     </location>

     <service>urn:service:sos</service>

   </findService>

   <!-- =====Response=================================== -->

   <findServiceResponse>
     xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:rli="urn:ietf:params:xml:ns:lost-rli1">
     xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">

     <mapping
       expires="NO-CACHE"
       lastUpdated="2006-11-01T01:00:00Z"
       source="authoritative.example"
       sourceId="8799e346000098aa3e">

       <displayName xml:lang="en">Seattle 911</displayName>
       <service>urn:service:sos</service>
       <uri>sip:seattle-911@example.com</uri>
       <serviceNumber>911</serviceNumber>

Rosen, et al.             Expires 2 April 2022                 [Page 11]
Internet-Draft    Returned Location Extensions to LoST    September 2021

     </mapping>

     <locationValidation>

       <valid>ca:country ca:A1 ca:A3 ca:STS ca:RD</valid>
       <invalid>ca:POD</invalid>
       <unchecked>ca:HNO</unchecked>

       <rli:similarLocation profile="civic"><!--similar location-->
         <ca:civicAddress>  <!-- similar address #1 -->
           <ca:country>US</ca:country>
           <ca:A1>WA</ca:A1>
           <ca:A2>KING COUNTY</ca:A2>
           <ca:A3>SEATTLE</ca:A3>
           <ca:RD>15TH</ca:RD>
           <ca:STS>AVENUE</ca:STS>
           <ca:POD>NORTHWEST</ca:POD>
           <ca:HNO>6000</ca:HNO>
           <ca:PC>98106</ca:PC>
           <ca:PCN>SEATTLE</ca:PCN>
         </ca:civicAddress>
       </rli:similarLocation>
       <rli:similarLocation profile="civic" similarLocationsLimited="5">
         <ca:civicAddress>  <!-- similar address #2 -->
           <ca:country>US</ca:country>
           <ca:A1>WA</ca:A1>
           <ca:A2>KING COUNTY</ca:A2>
           <ca:A3>SEATTLE</ca:A3>
           <ca:RD>15TH</ca:RD>
           <ca:STS>AVENUE</ca:STS>
           <ca:POD>NORTHEAST</ca:POD>
           <ca:HNO>6000</ca:HNO>
           <ca:PC>98105</ca:PC>
           <ca:PCN>SEATTLE</ca:PCN>
         </ca:civicAddress>
     </rli:similarLocation>

   </locationValidation>

     <path>
       <via source="authoritative.example"/>
     </path>

     <locationUsed id="587cd3880"/>

   </findServiceResponse>

Rosen, et al.             Expires 2 April 2022                 [Page 12]
Internet-Draft    Returned Location Extensions to LoST    September 2021

   <!-- =============================================== -->

6.  XML Schema

   This section provides the schema of the LoST extensions, based on the
   schema in [I-D.ietf-ecrit-lost-planned-changes]

Rosen, et al.             Expires 2 April 2022                 [Page 13]
Internet-Draft    Returned Location Extensions to LoST    September 2021

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns:lost1="urn:ietf:params:xml:ns:lost1"
              xmlns="urn:ietf:params:xml:ns:lost-rli1"
              targetNamespace="urn:ietf:params:xml:ns:lost-rli1"
              elementFormDefault="qualified">
        <!-- Import base Lost -->
        <xs:import namespace="urn:ietf:params:xml:ns:lost1"/>
   <!-- extend findService by placing the following
       at the extensionPoint
       in the included commonRequestPattern: -->
         <xs:attribute name="returnAdditionalLocation" use="optional">
          <xs:simpleType>
             <xs:restriction base="xs:token">
               <xs:enumeration value="none"/>
               <xs:enumeration value="similar"/>
               <xs:enumeration value="complete"/>
               <xs:enumeration value="any"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>

         <!-- extend locationValidation by placing the following
                  at the extensionPoint -->
         <group>
           <xs:choice minOccurs="0">
             <xs:element name="similarLocation"
                       type="lost1:locationInformation"
                       minOccurs="1" maxOccurs="unbounded" />
             <xs:element name="completeLocation"
                       type="lost1:locationInformation"/>
           </xs:choice>
         </group>

         <!-- and also at the locationValidation extensionPoint -->
         <xs:attribute name="similarLocationsLimited" use="optional">
           <xs:simpleType>
             <xs:restriction base="xs:integer">
                 <xs:minInclusive value="1">
                 </xs:restriction>
           </xs:simpleType>
         </xs:attribute>

   </xs:schema>

Rosen, et al.             Expires 2 April 2022                 [Page 14]
Internet-Draft    Returned Location Extensions to LoST    September 2021

7.  Security Considerations

   Whether the input to the LoST server is a Valid or Invalid Location,
   the LoST server ultimately determines what it considers to be a Valid
   Location.  Even in the case where the input location is valid, the
   requester still might not actually understand where that location is.
   For this kind of Valid Location use case, this extension will
   typically return more location information than what the requester
   started with, which might reveal to the requester additional
   information (additional CAtypes) about the location.  While this is
   very desirable in some scenarios such as supporting an emergency
   call, it might not be as desirable for other services.  Individual
   LoST server implementations SHOULD consider the risk of releasing
   more detail versus the value in doing so.  Generally, supplying more
   information (CAtypes) is not considered to be a significant problem
   because the requester has to already have enough information for the
   location to be considered valid, which in most cases is enough to
   uniquely locate the address.  Providing more CAtypes generally
   doesn't actually reveal anything more.  When Invalid Locations are
   submitted, this extension allows the LoST response to include
   locations that are similar to what was input, again resulting in more
   information provided in the response than was sent in the request.
   LoST server implementations SHOULD evaluate the particular use cases
   where this extension is supported, and weigh the risks around its
   use.  Many services available today via the Internet offer similar
   features, such as "did you mean" or address completion, so this
   capability is not introducing any fundamentally new threat.

8.  IANA Considerations

8.1.  XML Schema Registration

      URI:  urn:ietf:params:xml:schema:lost-rli1

      Registrant Contact:  IETF ECRIT Working Group, Brian Rosen
         (br@brianrosen.net).

      XML Schema: The XML schema to be registered is contained
         in Section 7.

8.2.  LoST-RLI Namespace Registration

Rosen, et al.             Expires 2 April 2022                 [Page 15]
Internet-Draft    Returned Location Extensions to LoST    September 2021

      URI:  urn:ietf:params:xml:ns:lost-rli1

      Registrant Contact:  IETF ECRIT Working Group, Brian Rosen
         (br@brianrosen.net).

      XML:

   BEGIN
   <?xml version="2.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
     <meta http-equiv="content-type"
           content="text/html;charset=iso-8859-1"/>
     <title>LoST Returned Location Information Namespace</title>
   </head>
   <body>
     <h1>Namespace for LoST Returned Location Information extension</h1>
     <h2>urn:ietf:params:xml:ns:lost-rli1</h2>
   <p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
      RFC????</a>.</p>
   </body>
   </html>
   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,
              <https://www.ietf.org/archive/id/draft-ietf-ecrit-lost-
              planned-changes-04.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
              <https://www.rfc-editor.org/info/rfc5222>.

9.2.  Informative References

Rosen, et al.             Expires 2 April 2022                 [Page 16]
Internet-Draft    Returned Location Extensions to LoST    September 2021

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4776,
              DOI 10.17487/RFC4776, November 2006,
              <https://www.rfc-editor.org/info/rfc4776>.

   [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>.

   [RFC5774]  Wolf, K. and A. Mayrhofer, "Considerations for Civic
              Addresses in the Presence Information Data Format Location
              Object (PIDF-LO): Guidelines and IANA Registry
              Definition", BCP 154, RFC 5774, DOI 10.17487/RFC5774,
              March 2010, <https://www.rfc-editor.org/info/rfc5774>.

   [RFC6848]  Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and
              R. George, "Specifying Civic Address Extensions in the
              Presence Information Data Format Location Object (PIDF-
              LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013,
              <https://www.rfc-editor.org/info/rfc6848>.

Authors' Addresses

   Brian Rosen
   470 Conrad Dr
   Mars, PA 16046
   United States of America

   Email: br@brianrosen.net

   Roger Marshall
   Comtech TCS
   2401 Elliott Avenue
   2nd Floor
   Seattle, WA 98121
   United States of America

   Email: roger.marshall@comtechtel.com

Rosen, et al.             Expires 2 April 2022                 [Page 17]
Internet-Draft    Returned Location Extensions to LoST    September 2021

   Jeff Martin
   Comtech TCS
   2401 Elliott Avenue
   2nd Floor
   Seattle, WA 98121
   United States of America

   Email: jeff.martin@comtechtel.com

Rosen, et al.             Expires 2 April 2022                 [Page 18]