idnits 2.17.1 

draft-ietf-ecrit-similar-location-19.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC5222, but the
     abstract doesn't seem to directly say this.  It does mention RFC5222
     though, so this could be OK.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

     (Using the creation date from RFC5222, updated by this document, for
     RFC5378 checks: 2006-06-20)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (4 March 2022) is 782 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-09) exists of
     draft-ietf-ecrit-lost-planned-changes-05


     Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------


2	ECRIT                                                           B. Rosen
3	Internet-Draft
4	Updates: 5222 (if approved)                                  R. Marshall
5	Intended status: Standards Track                               J. Martin
6	Expires: 5 September 2022                                    Comtech TCS
7	                                                            4 March 2022

9	     A LoST extension to return complete and similar location info
10	                  draft-ietf-ecrit-similar-location-19

12	Abstract

14	   This document describes an extension to the LoST protocol of RFC 5222
15	   that allows additional civic location information to be returned in a
16	   <findServiceResponse>.  This extension supports two use cases: First,
17	   when the input location is valid but lacks some Civic Address
18	   elements, the LoST server can provide a completed form.  Second, when
19	   the input location is invalid, the LoST server can identify one or
20	   more feasible ("similar") locations.  This extension is applicable
21	   when the location information in the <findService> request uses the
22	   Basic Civic profile as described in RFC 5222 or another profile whose
23	   definition provides instructions concerning its use with this
24	   extension.

26	Status of This Memo

28	   This Internet-Draft is submitted in full conformance with the
29	   provisions of BCP 78 and BCP 79.

31	   Internet-Drafts are working documents of the Internet Engineering
32	   Task Force (IETF).  Note that other groups may also distribute
33	   working documents as Internet-Drafts.  The list of current Internet-
34	   Drafts is at https://datatracker.ietf.org/drafts/current/.

36	   Internet-Drafts are draft documents valid for a maximum of six months
37	   and may be updated, replaced, or obsoleted by other documents at any
38	   time.  It is inappropriate to use Internet-Drafts as reference
39	   material or to cite them other than as "work in progress."

41	   This Internet-Draft will expire on 5 September 2022.

43	Copyright Notice

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

48	   This document is subject to BCP 78 and the IETF Trust's Legal
49	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
50	   license-info) in effect on the date of publication of this document.
51	   Please review these documents carefully, as they describe your rights
52	   and restrictions with respect to this document.  Code Components
53	   extracted from this document must include Revised BSD License text as
54	   described in Section 4.e of the Trust Legal Provisions and are
55	   provided without warranty as described in the Revised BSD License.

57	Table of Contents

59	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
60	   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
61	   3.  Overview of Returned Location Information . . . . . . . . . .   4
62	   4.  Returned Location Information . . . . . . . . . . . . . . . .   8
63	   5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
64	     5.1.  Complete Location returned for Valid Location . . . . . .  10
65	     5.2.  Similar Location returned for Invalid Location  . . . . .  12
66	   6.  XML Schema  . . . . . . . . . . . . . . . . . . . . . . . . .  14
67	   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
68	   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
69	     8.1.  XML Schema Registration . . . . . . . . . . . . . . . . .  16
70	     8.2.  LoST-RLI Namespace Registration . . . . . . . . . . . . .  17
71	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
72	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
73	     9.2.  Informative References  . . . . . . . . . . . . . . . . .  18
74	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

76	1.  Introduction

78	   The LoST protocol [RFC5222] supports the validation of civic location
79	   information sent in a <findService> request, by providing a set of
80	   validation result status indicators in the response.  The current
81	   usefulness of the supported XML elements <valid>, <invalid>, and
82	   <unchecked> is limited.  They each provide an indication of validity
83	   for any one location element as a part of the whole civic address,
84	   but this is insufficient in providing either the complete set of
85	   civic address elements that the LoST server contains, or of providing
86	   alternate suggestions (hints) as to which civic address is intended
87	   for use.

89	   Whether the queried civic location is valid but missing information,
90	   or invalid due to missing or wrong information, this document
91	   provides a mechanism to return a complete set of civic address
92	   elements.

94	   This enhancement to the validation feature within LoST is required by
95	   systems that rely on accurate location for processing.  Use of this
96	   enhancement increases the likelihood that incorrect or incomplete
97	   civic location will be updated.  One such use case is that of
98	   location-based emergency calling.  The use of this protocol extension
99	   facilitates the timely correction of errors, and allows LoST clients
100	   to be more easily provisioned with complete address information.

102	2.  Terminology

104	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
105	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
106	   "OPTIONAL" in this document are to be interpreted as described in BCP
107	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
108	   capitals, as shown here.

110	   The following terms are defined in this document:

112	   Location:  The term Location is in general used to refer to either a
113	      civic location or a geodetic location.  In the context of this
114	      document, location is restricted to civic locations.

116	   Geodetic Location:  a geographic coordinate set of values that
117	      describes a point within a defined geographic datum.  For example,
118	      a referenced latitude/longitude coordinate pair (2D), or latitude,
119	      longitude, and altitude (3D).  Note: geodetic location is defined
120	      here for context, but is not used elsewhere within this document.

122	   Civic Location:  A set of Civic Address Elements as defined in
123	      [RFC5139] that are used in conjunction with each other, and in
124	      accordance with a known ruleset to designate a specific place
125	      within a country.

127	   Civic Address:  The term Civic Address is used interchangeably with
128	      the term Civic Location within this document.

130	   Civic Address Element:  The term Civic Address Element is used within
131	      this document to indicate any individual XML element used within
132	      the <civicAddress> type defined in [RFC5139], including elements
133	      used at the extension point therein such as those defined in
134	      [RFC6848] and elsewhere.  This term also includes the reference to
135	      such elements by qualified name as defined within the
136	      <locationValidation> element in [RFC5222].

138	   Invalid Location:  A Civic Location that, when included in a LoST
139	      query with 'validateLocation' set, will receive a response having
140	      one or more Civic Address Elements in the <invalid> list.  Note
141	      that it is also possible that the location information submitted
142	      is so inaccurate that location validation cannot be performed, and
143	      the LoST server may return a <notFound> or <locationInvalid>
144	      error.  In this document, the term Invalid Location only refers to
145	      a case where the LoST server returns one or more elements in the
146	      <invalid> list; the error conditions are not considered.

148	   Valid Location:  A Civic Location that, when included in a LoST query
149	      with 'validateLocation' set, will receive a response having all
150	      Civic Address Elements in the <valid> or <unchecked> lists.

152	   Incomplete Location:  "A Civic Location that the LoST server
153	      considers valid but which omits one or more Civic Address Elements
154	      that the LoST server considers necessary or helpful.

156	   Complete Location:  A Civic Location that was considered by the LoST
157	      server to be an Incomplete Location but that with the addition of
158	      one or more Civic Address Elements is considered complete by the
159	      LoST server.

161	   Similar Location:  A suggested civic location that is similar to an
162	      Invalid Location which was used in a LoST query, but which has one
163	      or more elements added, modified, or removed such that the
164	      suggested location is a Valid Location.  Similar Location may be
165	      returned when the input location is invalid.

167	   Returned Location Information:  A set of civic locations returned in
168	      a LoST response.

170	3.  Overview of Returned Location Information

172	   This document describes an extension to LoST [RFC5222] that allows
173	   additional location information to be returned in the
174	   <locationValidation> element of a <findServiceResponse>.  This
175	   extension has two different use cases: First, when the input location
176	   is incomplete but the LoST server can identify the intended unique
177	   address, and second, when the input location is invalid and the LoST
178	   server can identify one or more likely intended locations.  This
179	   extension is applicable when the location information in the
180	   <findService> request is in the Basic Civic profile as described in
181	   [RFC5222] or in another profile whose definition provides
182	   instructions concerning its use with this extension.  As of this
183	   document's publication, no such additional location profiles have
184	   been defined, so this document describes the returned location
185	   extension using the Basic Civic profile.  In addition, the following
186	   restriction is imposed: A server MUST NOT include Returned Location
187	   Information using a location profile that differs from the profile of
188	   the location used to answer the query and, by extension, MUST NOT
189	   include Returned Location Information using a location profile that
190	   was not used by the client in the request.

192	   When a LoST server is asked to validate a civic location, its goal is
193	   to take the set of Civic Address Elements provided as the location
194	   information in the LoST request, and find a unique location in its
195	   database that matches the information in the request.  Uniqueness
196	   might not require values for all possible elements in the Civic
197	   Address that the database might hold.  Further, the input location
198	   information might not represent the form of location the users of the
199	   LoST service prefer to have.  As an example, there are LoST Civic
200	   Address Elements that could be used to define a postal location,
201	   suitable for delivery of mail as well as a municipal location
202	   suitable for responding to an emergency call.  While the LoST server
203	   might be able to determine the location from the postal elements
204	   provided, the emergency services would prefer that the municipal
205	   location be used for any subsequent emergency call.  Since validation
206	   is often performed well in advance of an end user placing an
207	   emergency call, if the LoST server could return the preferred form of
208	   location (or more properly in this example, the municipal elements in
209	   addition to the postal elements), those elements could be stored in a
210	   client application such as a Location Information Server (LIS) and
211	   used in a later emergency call.

213	   In addition, this document describes the reuse of the same mechanism,
214	   but for a different purpose: to supply similar location information
215	   in the case where a LoST server response includes one or more Civic
216	   Address Elements marked as invalid, indicating an Invalid Location
217	   used in the query.  In this case, the response contains one or more
218	   suggested alternative Valid Locations.

220	   In a LoST <findServiceResponse> indicating a Valid Location
221	   (Section 2) i.e., containing the <locationValidation> element with no
222	   elements listed as invalid, the LoST server can use this extension to
223	   include additional location information in a <locationValidation>
224	   element.  As an example, a query contains <HNO> (house number), <RD>
225	   (road name) <A3> (city), <A1> (state/province) but not <POD> (Post-
226	   Directional).  In this example, there is no street with just the
227	   street name, all streets have a post-directional.  However, the LoST
228	   server is able to uniquely locate the intended address and thus
229	   consider the queried location Valid, as there is only one street with
230	   the street name and house number in the city that it could be.  As
231	   the queried location is missing the post-directional element, a more
232	   strict entity might consider it Invalid (e.g., during a subsequent
233	   query) or worse, the lack of a Post-Directional element might cause
234	   confusion and delay an emergency response.  The server can use this
235	   extension to supply the missing post-directional element <POD> in a
236	   <completeLocation> element within the <locationValidation> element.

238	   In another example, the civic location in a request might lack <A2>
239	   (county) and <PC> (Postal Code) Civic Address Elements.  In this
240	   example, too, the LoST server is able to uniquely locate the intended
241	   address and consider the location <Valid>, but other entities
242	   involved in a subsequent emergency call might find it helpful to have
243	   the additional Civic Address Elements.  The LoST server can use this
244	   extension to supply the missing <A2> and <PC> Civic Address Elements.

246	   Since [RFC5222] does not have a way for this additional location
247	   information to be returned in the <findServiceResponse>, this
248	   document extends the LoST protocol so that it can include a
249	   <completeLocation> element within the <locationValidation> element of
250	   the <findServiceResponse> message, allowing for the representation of
251	   complete location information.

253	   An example showing complete location information supplied:

255	   Input address:

257	      6000 15th Avenue
258	      Leets, WA US

260	   Complete Location:

262	      6000 15th Avenue Northwest
263	      Leets, WA 98105 US

265	   The information provided in the request may be enough to identify a
266	   unique location in the LoST server, but that may not be the location
267	   intended by the end user.  The <completeLocation> information may
268	   alert the user to a mismatch between the provided location
269	   information and the unique location the server interpreted that
270	   information to identify.

272	   The other use case for this extension is when the <findService>
273	   request contains an Invalid Location.  When a LoST server returns a
274	   response to a <findService> request that contains a set of Civic
275	   Address Elements with one or more listed as invalid, this extension
276	   allows the server to include in the <locationValidation> element one
277	   or more locations that might be the intended location.

279	   In the example cited above, policy at the LoST server might deem a
280	   missing <A3> element as being invalid, even if the location
281	   information in the request is sufficient to identify a unique
282	   address.  In this case, the missing element is listed in the
283	   <invalid> list, and a <similarLocation> element could be returned in
284	   the response showing a complete civic location that includes the
285	   missing <A3> element, just as in the above example the missing <A3>
286	   element is included in a <completeLocation> element.

288	   As another example of the use of <similarLocation>, consider the
289	   results based on a similar data set as used above, but where the
290	   <HNO>, <RD>, <STS>, <A1>, and <A3> Civic Address Elements are not
291	   sufficient to locate a unique address, resulting in an invalid
292	   location response.  Because the LoST server contains additional civic
293	   address elements which, had they been included in the query, would
294	   have resulted in a uniquely identifiable location, the server can
295	   include one or more <similarLocation> elements containing the
296	   supplied Civic Address Elements plus the omitted ones.  Since
297	   [RFC5222] does not have a way for this additional location
298	   information to be returned in the <findServiceResponse>, this
299	   document extends [RFC5222] so that the LoST <locationValidation>
300	   element of the <findServiceResponse> can include one or more
301	   <similarLocation> elements representing similar civic locations.

303	   To show this, suppose that a slightly modified version of the above
304	   address is sent within a Lost <findService> request:

306	   Input address:

308	      6000 15th Avenue North
309	      Leets, WA US

311	   This time we make the assumption that the address is deemed invalid
312	   by the LoST server because there is no such thing as "15th Avenue
313	   North" within the LoST server's data for the city of Leets.  However,
314	   we also happen to know for this example that there are two addresses
315	   within the address dataset that are "similar", when all parts of the
316	   address are taken as a whole.  These similar addresses that could be
317	   returned to the client are as follows:

319	   Similar address #1:

321	      6000 15th Avenue Northwest
322	      Leets, WA 98107 US

324	   Similar address #2:

326	      6000 15th Avenue Northeast
327	      Leets, WA 98105 US

329	   This extension allows the LoST server to include the above similar
330	   addresses in the response to a <findService> request with
331	   'validateLocaton' set to true.  Section 5 shows examples of the LoST
332	   request and response XML message fragments for the above valid and
333	   invalid scenarios, returning the complete or similar addresses
334	   respectively.

336	4.  Returned Location Information

338	   A LoST server implementing this extension MAY include
339	   <completeLocation> or <similarLocation> elements within the
340	   <locationValidation> portion of the <findServiceResponse>.  The
341	   <completeLocation> and <similarLocation> elements are of type
342	   "locationInformation" as defined by the LoST schema in [RFC5222].
343	   These elements MAY contain location information either in the Basic
344	   Civic profile defined in [RFC5222] or in another profile whose
345	   definition provides instructions concerning its use with this
346	   extension; this MUST be the same profile as the location in the
347	   query.  When used with the Basic Civic profile, these elements
348	   contain a <civicAddress> element as defined in [RFC5139].

350	   If there is at least one Civic Address Element in the <invalid> list,
351	   the LoST server MAY include one or more <similarLocation> element in
352	   the response.  If there are too many possible locations, the server
353	   MAY return none, or it MAY return a subset considered most likely.
354	   How many to return is left to the implementation of the LoST server.
355	   The server is unable to know what the intended location information
356	   was supposed to be; it is guessing.  Therefore, the correct location
357	   may or may not be one of the <similarLocation> elements the server
358	   provides, and the client cannot assume that any one of them is the
359	   correct location.

361	   Where a LoST server contains additional location information relating
362	   to the Civic Address used in a <findService> request, the
363	   <findServiceResponse> message MAY include a <completeLocation>
364	   element containing additional location information along with the
365	   original validated Civic Address Elements; the additional Civic
366	   Address Elements may be deemed by local policy as necessary to form a
367	   Complete Location.  The <completeLocation> element MUST NOT be
368	   returned in response messages where any Civic Address Elements occur
369	   in the invalid list of the response, or where the set of Civic
370	   Address Elements in the request do not identify a unique location.
371	   The Complete Location MUST NOT contain any elements that would be
372	   marked as invalid, or cause an error, if a recipient of that location
373	   performs a subsequent <findService> request using the Complete
374	   Location.  However, if a subsequent request includes the Complete
375	   Location, the corresponding response MAY include elements in the
376	   unchecked list.

378	   Clients can control the return of additional location information by
379	   including the optional 'returnAdditionalLocation' attribute with
380	   possible values 'none', 'similar', 'complete' or 'any'.  The value
381	   'none' means to not return additional location information, 'similar'
382	   and 'complete' mean to only return the respective type of additional
383	   location information (if the server could send any) and 'any' means
384	   to include Similar and/or Complete Location (if the server could send
385	   any).  If the request includes this attribute, the server MUST NOT
386	   send location information contravening the client's request.
387	   Omitting this attribute in the request is equivalent to including it
388	   with the value 'none'.

390	   The server may determine that there are many possible Similar
391	   Locations and decide not to send them all.  The number of Similar
392	   Locations sent is entirely up to the server.  The server MAY include
393	   a 'similarLocationsOmitted' attribute which contains a non-zero
394	   integer indicating the minimum number of Similar Locations not
395	   included in the response.  There may be more than the indicated
396	   similar locations available in the data held by the server, but no
397	   mechanism to request more Similar Locations is provided.

399	   Clients MAY ignore the location information this extension defines.
400	   The information is optional to send, and optional to use.  In the
401	   case where the location information in the request was valid, this
402	   extension does not change the validity.  In the case where the
403	   location information in the request is invalid, but alternate
404	   location information is returned, the original location remains
405	   invalid, and the LoST server does not change the mapping response
406	   other than optionally including the information defined by this
407	   extension.

409	   The <completeLocation> and <similarLocation> elements use the
410	   <locationInformation> element from [RFC5222] updated by
411	   [I-D.ietf-ecrit-lost-planned-changes], including the 'profile'
412	   attribute, which is useful if the request contains location
413	   information in a profile other than the 'civic' profile.  The
414	   'profile' attribute MUST be included in both the request and the
415	   response and MUST be the same profile in both.

417	5.  Examples

419	5.1.  Complete Location returned for Valid Location

421	   This example is based on the example request above; the LoST server
422	   considered the location in the query to be valid but missing some
423	   Civic Address elements, so in the Returned Location Information in
424	   the <findServiceResponse>, the server includes a <completeLocation>
425	   element supplying the omitted Civic Address elements <A2>, <PC>, and
426	   <PCN>.

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

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

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

438	            <country>US</country>
439	            <A1>WA</A1>
440	            <A3>Leets</A3>
441	            <RD>15th</RD>
442	            <STS>Avenue</STS>
443	            <POD>Northwest</POD>
444	            <HNO>6000</HNO>

446	          </civicAddress>
447	        </location>

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

451	      </findService>

453	      <!-- =====Response================================== -->
454	      <findServiceResponse
455	        xmlns="urn:ietf:params:xml:ns:lost1"
456	        xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"
457	        xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">

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

465	          <displayName xml:lang="en">Leets 911</displayName>
466	          <service>urn:service:sos</service>
467	          <uri>sip:leets-911@example.com</uri>
468	          <serviceNumber>911</serviceNumber>

470	        </mapping>

472	        <locationValidation>

474	          <valid>ca:country ca:A1 ca:A3 ca:RD ca:STS ca:POD ca:HNO
475	          </valid>
476	          <invalid></invalid>
477	          <unchecked></unchecked>

479	          <rli:completeLocation profile="civic"><!--completed address-->
480	            <ca:civicAddress>
481	              <ca:country>US</ca:country>
482	              <ca:A1>WA</ca:A1>
483	              <ca:A2>SHOWAK COUNTY</ca:A2>
484	              <ca:A3>LEETS</ca:A3>
485	              <ca:RD>15TH</ca:RD>
486	              <ca:STS>AVENUE</ca:STS>
487	              <ca:POD>NORTHWEST</ca:POD>
488	              <ca:HNO>6000</ca:HNO>
489	              <ca:PC>98106</ca:PC>
490	              <ca:PCN>LEETS</ca:PCN>
491	            </ca:civicAddress>

493	        </rli:completeLocation>

495	      </locationValidation>

497	        <path>
498	          <via source="authoritative.example"/>
499	        </path>

501	        <locationUsed id="587cd3880"/>

503	      </findServiceResponse>

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

507	5.2.  Similar Location returned for Invalid Location

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

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

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

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

525	              <country>AU</country>
526	              <A1>QLD</A1>
527	              <A3>PIMPANA</A3>
528	              <RD>SHIRLEY</RD>
529	              <STS>STREET</STS>
530	              <HNO>98</HNO>
531	              <PC>4209</PC>
532	              <PCN>PIMPANA</PCN>

534	          </civicAddress>
535	        </location>

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

539	      </findService>

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

543	      <findServiceResponse
544	        xmlns="urn:ietf:params:xml:ns:lost1"
545	        xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"
546	        xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
547	        <mapping
548	          expires="NO-CACHE"
549	          lastUpdated="2006-11-01T01:00:00Z"
550	          source="authoritative.example"
551	          sourceId="8799e346000098aa3e">

553	          <displayName xml:lang="en">Australian 000</displayName>
554	          <service>urn:service:sos</service>
555	          <uri>sip:000@example.com</uri>
556	          <serviceNumber>000</serviceNumber>

558	        </mapping>

560	        <locationValidation similarLocationsOmitted="5">

562	          <valid>ca:country ca:A1 ca:A3 ca:STS ca:RD</valid>
563	          <invalid>ca:POD</invalid>
564	          <unchecked>ca:HNO ca:PC ca:PCN</unchecked>

566	          <rli:similarLocation profile="civic"><!--similar location-->
567	            <ca:civicAddress>  <!-- similar address #1 -->
568	              <ca:country>AU</ca:country>
569	              <ca:A1>QLD</ca:A1>
570	              <ca:A3>PIMPANA</ca:A3>
571	              <ca:RD>SHIRLEY</ca:RD>
572	              <ca:STS>STREET</ca:STS>
573	              <ca:POD>NORTH</ca:POD>
574	              <ca:HNO>98</ca:HNO>
575	              <ca:PC>4209</ca:PC>
576	              <ca:PCN>PIMPANAS</ca:PCN>
577	            </ca:civicAddress>
578	          </rli:similarLocation>
579	          <rli:similarLocation profile="civic" >
580	            <ca:civicAddress>  <!-- similar address #2 -->
581	            <ca:country>AU</ca:country>
582	            <ca:A1>QLD</ca:A1>
583	            <ca:A3>PIMPANA</ca:A3>
584	            <ca:RD>SHIRLEY</ca:RD>
585	            <ca:STS>STREET</ca:STS>
586	            <ca:POD>SOUTH</ca:POD>
587	            <ca:HNO>98</ca:HNO>
588	            <ca:PC>4209</ca:PC>
589	            <ca:PCN>PIMPANAS</ca:PCN>

591	            </ca:civicAddress>
592	        </rli:similarLocation>

594	      </locationValidation>
595	        <path>
596	          <via source="authoritative.example"/>
597	        </path>

599	        <locationUsed id="587cd3880"/>

601	      </findServiceResponse>

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

605	6.  XML Schema

607	   This section provides the schema of the LoST extensions, based on the
608	   schema in [I-D.ietf-ecrit-lost-planned-changes]
609	   <?xml version="1.0" encoding="UTF-8"?>
610	   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
611	              xmlns:lost1="urn:ietf:params:xml:ns:lost1"
612	              xmlns="urn:ietf:params:xml:ns:lost-rli1"
613	              targetNamespace="urn:ietf:params:xml:ns:lost-rli1"
614	              elementFormDefault="qualified">
615	        <!-- Import base Lost -->
616	        <xs:import namespace="urn:ietf:params:xml:ns:lost1"/>
617	   <!-- extend findService by placing the following
618	       at the extensionPoint
619	       in the included commonRequestPattern: -->
620	         <xs:attribute name="returnAdditionalLocation" use="optional">
621	          <xs:simpleType>
622	             <xs:restriction base="xs:token">
623	               <xs:enumeration value="none"/>
624	               <xs:enumeration value="similar"/>
625	               <xs:enumeration value="complete"/>
626	               <xs:enumeration value="any"/>
627	             </xs:restriction>
628	           </xs:simpleType>
629	         </xs:attribute>

631	         <!-- extend locationValidation by placing the following
632	                  at the extensionPoint -->
633	         <xs:group>
634	           <xs:choice minOccurs="0">
635	             <xs:element name="similarLocation"
636	                       type="lost1:locationInformation"
637	                       minOccurs="1" maxOccurs="unbounded" />
638	             <xs:element name="completeLocation"
639	                       type="lost1:locationInformation"/>
640	           </xs:choice>
641	         </xs:group>

643	         <!-- and also at the locationValidation extensionPoint -->
644	         <xs:attribute name="similarLocationsOmitted" use="optional">
645	           <xs:simpleType>
646	             <xs:restriction base="xs:integer">
647	                 <xs:minInclusive value="1"/>
648	                 </xs:restriction>
649	           </xs:simpleType>
650	         </xs:attribute>

652	   </xs:schema>

654	7.  Security Considerations

656	   As this document defines extensions to [RFC5222], the Security
657	   Considerations of that document apply here.

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

685	   The similar location service could be misused to attempt to enumerate
686	   the entire database by running a high volume of invalid or partial
687	   queries.  The LoST server can limit the volume of similar locations
688	   it returns.  It can also authenticate queries and limit the service
689	   to known queriers

691	8.  IANA Considerations

693	8.1.  XML Schema Registration

695	   IANA is requested to register the following in the "schema" sub-
696	   registry of the IETF XML Registry per [RFC3688].

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

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

703	      XML Schema: The XML schema to be registered is contained
704	         in Section 6.

706	8.2.  LoST-RLI Namespace Registration

708	   IANA is requested to register the following in the "ns" sub-registry
709	   of the IETF XML registry per [RFC3553].

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

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

716	      XML:

718	   BEGIN
719	   <?xml version="1.0"?>
720	   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
721	     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
722	   <html xmlns="http://www.w3.org/1999/xhtml">
723	   <head>
724	     <meta http-equiv="content-type"
725	           content="text/html;charset=iso-8859-1"/>
726	     <title>LoST Returned Location Information Namespace</title>
727	   </head>
728	   <body>
729	     <h1>Namespace for LoST Returned Location Information extension</h1>
730	     <h2>urn:ietf:params:xml:ns:lost-rli1</h2>
731	   <p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
732	      RFC????</a>.</p>
733	   </body>
734	   </html>
735	   END

737	9.  References

739	9.1.  Normative References

741	   [I-D.ietf-ecrit-lost-planned-changes]
742	              Rosen, B., "Validation of Locations Around a Planned
743	              Change", Work in Progress, Internet-Draft, draft-ietf-
744	              ecrit-lost-planned-changes-05, 11 October 2021,
745	              <https://www.ietf.org/archive/id/draft-ietf-ecrit-lost-
746	              planned-changes-05.txt>.

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

753	   [RFC3553]  Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
754	              IETF URN Sub-namespace for Registered Protocol
755	              Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
756	              2003, <https://www.rfc-editor.org/info/rfc3553>.

758	   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
759	              DOI 10.17487/RFC3688, January 2004,
760	              <https://www.rfc-editor.org/info/rfc3688>.

762	   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
763	              Format for Presence Information Data Format Location
764	              Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139,
765	              February 2008, <https://www.rfc-editor.org/info/rfc5139>.

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

772	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
773	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
774	              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

776	9.2.  Informative References

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

784	Authors' Addresses
785	   Brian Rosen
786	   470 Conrad Dr
787	   Mars, PA 16046
788	   United States of America
789	   Email: br@brianrosen.net

791	   Roger Marshall
792	   Comtech TCS
793	   2401 Elliott Avenue
794	   2nd Floor
795	   Seattle, WA 98121
796	   United States of America
797	   Email: roger.marshall@comtechtel.com

799	   Jeff Martin
800	   Comtech TCS
801	   2401 Elliott Avenue
802	   2nd Floor
803	   Seattle, WA 98121
804	   United States of America
805	   Email: jeff.martin@comtechtel.com