idnits 2.17.1
draft-ietf-ecrit-similar-location-08.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 abstract seems to contain references ([RFC5222]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 22, 2019) is 1740 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-03
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 ECRIT R. Marshall
3 Internet-Draft J. Martin
4 Intended status: Standards Track Comtech TCS
5 Expires: January 23, 2020 B. Rosen
6 July 22, 2019
8 A LoST extension to return complete and similar location info
9 draft-ietf-ecrit-similar-location-08
11 Abstract
13 This document introduces a new way to provide returned location
14 information in LoST responses that is either of a completed or
15 similar form to the original input civic location, based on whether
16 valid or invalid civic address elements are returned within the
17 findServiceResponse message. This document defines a new extension
18 to the findServiceResponse message within the LoST protocol [RFC5222]
19 that enables the LoST protocol to return a completed civic address
20 element set for a valid location response, and one or more suggested
21 sets of similar location information for invalid LoST responses.
22 These two types of civic addresses are referred to as either
23 "complete location" or "similar location", and are included as a
24 compilation of CAtype xml elements within the existing LoST
25 findServiceResponse message structure.
27 Status of This Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at https://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on January 23, 2020.
44 Copyright Notice
46 Copyright (c) 2019 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (https://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 3. Overview of Returned Location Information . . . . . . . . . . 4
64 4. Returned Location Information . . . . . . . . . . . . . . . . 7
65 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
66 5.1. Complete Location returned for Valid Location response . 8
67 5.2. Similar Location returned for Invalid Location response . 10
68 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 12
69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
71 8.1. XML Schema Registration . . . . . . . . . . . . . . . . . 14
72 8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 14
73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
74 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
75 9.2. Informative References . . . . . . . . . . . . . . . . . 16
76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
78 1. Introduction
80 The LoST protcol [RFC5222] supports the validation of civic location
81 information as input, by providing a set of validation result status
82 indicators. The current usefulness of the supported xml elements,
83 "valid", "invalid", and "unchecked", is limited, because while they
84 each provide an indication of validity for any one location element
85 as a part of the whole civic address, the mechanism is insufficient
86 in providing either the complete set of civic address elements that
87 the LoST server contains, or of providing alternate suggestions
88 (hints) as to which civic address is intended for use.
90 Whether the input civic location is valid and missing information, or
91 invalid due to missing or wrong information during input, this
92 document provides a mechanism to return a complete set of civic
93 address elements for those valid or invalid cases.
95 This enhancement to the validation feature within LoST is required by
96 systems that rely on accurate location for processing in order to
97 increase the likelihood that the correct and/or complete form of a
98 civic location becomes known in those cases where it is incomplete or
99 incorrect. One such use case is that of location based emergency
100 calling. The use of this protocol extension will protocol extension
101 will facilitate the correction of errors, and allow location servers
102 to be more easily provisioned with complete address information.
104 The structure of this document includes terminology, Section 2,
105 followed by a discussion of the basic elements involved in location
106 validation. The use of these elements, by way of example, is
107 discussed in an overview section, Section 3, with accompanying
108 rationale, and a brief discussion of the impacts to LoST, and its
109 current schema.
111 2. Terminology
113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
115 document are to be interpreted as described in RFC 2119 [RFC2119].
117 The following terms are defined in this document:
119 Location: The term Location can be used to refer to either a civic
120 location or a geodetic location.
122 Geodetic Location: a geographic coordinate set of values that
123 describes a point within a defined geographic datum. For example,
124 a WGS84 referenced latitude, longitude coordinate pair (2D), or
125 latitude, longitude, and altitude (3D). Note: geodetic location
126 is defined here for context, but is not used elsewhere within this
127 document.
129 Civic Location: The term civic location applies to a set of one or
130 more civic address elements that are used in conjunction with each
131 other, and in accordance with a known ruleset to designate a
132 specific place within a region of geography, or a region of
133 geography by itself as defined in [RFC5139].
135 Civic Address: The term Civic Address is used interchangeably with
136 the term Civic Location within this document.
138 Civic Address Element: The term Civic Address Element is used within
139 this document to apply to an individual CAtype data descriptor,
140 for example, as is described in [RFC4776], [RFC5774], and
141 [RFC6848].
143 Invalid Location: A Civic Location that was included in a LoST
144 request and subsequently returned with one or more civic address
145 elements marked as invalid. Note that location information may be
146 submitted in the findRequest that causes the LoST server to return
147 locationInvalid. It is also possible that the location
148 information submitted is so inaccurate that this extension can not
149 be used, and the LoST server may return a notFound. In this
150 document, we use the term Invalid Location only to refer to a case
151 where the LoST server returns one or more elements in the invalid
152 list.
154 Valid Location: A Civic Location that was included in a LoST request
155 and subsequently returned with all civic address elements in the
156 valid or unchecked lists.
158 Complete Location: An expanded civic location that includes other
159 civic address elements in addition to the existing validated civic
160 address elements provided as input to a LoST server.
162 Similar Location: A suggested civic location that is comparatively
163 close to the civic location which was input, but which had one or
164 more invalid civic address elements returned by the LoST server.
166 Returned Location Information: A set of civic locations returned in
167 a LoST response.
169 3. Overview of Returned Location Information
171 This document describes an extension to LoST [RFC5222] to allow
172 additional location information to be returned in locationValidation
173 element of a findServiceResponse, where the location information in
174 the request is in a civic profile as described in RFC5222 or location
175 in another profile derived from that civic profile, for two different
176 use cases.
178 When a LoST server is asked to validate a civic location, its goal is
179 to take the set of civic address elements provided as the location
180 information in the LoST request, and find a unique location in its
181 database that matches the information in the request. Uniqueness
182 might not require values for all possible elements in the civic
183 address that the database might hold. Further, the input location
184 information might not represent the form of location the users of the
185 LoST service prefer to have. As an example, there are LoST civic
186 address elements that could be used to define a postal location,
187 suitable for delivery of mail as well as a municipal location
188 suitable for responding to an emergency call. While the LoST server
189 might be able to determine the location from the postal elements
190 provided, the emergency services would prefer that the municipal
191 location be used for any subsequent emergency call. Since validation
192 is often performed well in advance of an end-user placing an
193 emergency call, if the LoST server could return the preferred form of
194 location (or more properly in this example, the municipal elements in
195 addition to the postal elements), those elements could be stored in a
196 LIS and used in a later emergency call.
198 In addition, this document describes the reuse of the same mechanism,
199 but for a different purpose: to supply similar location information
200 in the case where a LoST server response includes one or more civic
201 address elements marked as invalid, constituting an invalid location
202 response. In this case, the response contains one or more suggested
203 alternative, but valid locations.
205 In a LoST findServiceResponse indicating a valid location - i.e.
206 containing a locationValidation element with no elements listed as
207 invalid - the locationValidation element may use this extension to
208 include additional location information. As an example, the query
209 might contain a HNO (house number), RD (road name) A3 (city), At
210 (state/province) and a few more CAtype elements, but might not
211 contain A2 (county) or PC (Postal Code) CAtypes. The HNO, RD, STS,
212 POD, A3 and A1 civic address elements might be sufficient enough to
213 the LoST server to uniquely locate the address specified in the
214 request and thus be considered valid. Yet, downstream entities might
215 find it helpful to have the additional A2 (county), and PC, (Postal
216 Code), civic address elements that are present within the LoST
217 server, be included as part of a complete location response. Since
218 [RFC5222] currently does not have a way for this additional location
219 information to be returned in the findServiceResponse, this document
220 extends the LoST protocol so that it can include a completeLocation
221 element within the locationValidation element of the
222 findServiceResponse message, allowing for the representation of
223 complete location information.
225 An example showing complete location information supplied:
227 input address: 6000 15th Ave NW Seattle
229 complete location: 6000 15th Ave NW Seattle, WA 98105 US
231 The information provided in the request may be enough to identify a
232 unique location in the LoST server, but that may not be the location
233 intended by the user. The completeLocation information may alert the
234 user to a mismatch between the provided location information and the
235 unique location the server interpreted that information to identify.
237 By contrast, when invalid location is received from the LoST server,
238 with this extension, the same mechanism works as follows: if a LoST
239 server returns a response to a findService request that contains a
240 set of civic address elements with one or more labeled as invalid,
241 the location information in the findServiceResponse is extended to
242 include additional location information that it suspects might be the
243 location desired.
245 In the example cited above, policy at the LoST server might deem a
246 missing A3 element as invalid, even if the location information in
247 the request was sufficient to identify a unique address. In that
248 case, the missing element would be listed in the invalid list, and
249 similarLocation could be returned in the response showing the missing
250 elements including A3, the same as the above example.
252 As another example of the use of similarLocation, consider the
253 results based on a similar data set as used above, where the HNO, RD,
254 STS, A1, and A3 civic address elements are not sufficient to locate a
255 unique address, which leads to an invalid location result. This is
256 the case, despite the fact that the LoST server typically contains
257 additional civic address elements which could have resulted in a
258 uniquely identifiable location if additional data had been supplied
259 with the query. Since [RFC5222] currently does not have a way for
260 this additional location information to be returned in the
261 findServiceResponse, this document extends [RFC5222] so that the LoST
262 locationValidation element of the findServiceResponse message can
263 include one or more similarLocation elements representing similar
264 civic locations.
266 To show this, suppose that a slightly modified address as above is
267 inserted within a Lost findService request:
269 input address: 6000 15th Ave N Seattle, WA.
271 This time we make the assumption that the address is deemed "invalid"
272 by the LoST server because there is no such thing as "15th Ave N"
273 within the LoST server's data for the city of Seattle. However, we
274 also happen to know for this example that there are two addresses
275 within the address dataset that are "similar", when all parts of the
276 address are taken as a whole. These similar addresses that could be
277 suggested to the user are as follows:
279 similar address #1: 6000 15th Ave NW Seattle, WA 98107
281 similar address #2: 6000 15th Ave NE Seattle, WA 98105
283 This extension would allow the LoST server to include the above
284 similar addresses as civicAddress elements in the response to
285 locationValidation. The next section shows examples of the LoST
286 request and response xml message fragments for the above valid and
287 invalid scenarios, returning the complete or similar addresses,
288 respectively.
290 4. Returned Location Information
292 The LoST server implementing this extension MAY include
293 completeLocation or similarLocation within the locationValidation
294 portion of the findService response. completeLocation and
295 similarLocation contain a list of civic address elements identical to
296 the elements used in the location element with the "civic profile" in
297 [RFC5222] or another profile derived from the civic profile.
299 The LoST server MAY include more than one similarLocation elements in
300 the response. If there are too many possible locations, the server
301 MAY return none, or it MAY return the few it considers most likely.
302 The definition of "few" is left to the implementation of the LoST
303 server. The server is unable to know what the intended location
304 information was suppose to be; it is guessing. Therefore the correct
305 location may or may not be one of the similarLocation elements the
306 server provides, and the client cannot assume that any of them are
307 the correct one.
309 Where a LoST server contains additional location information relating
310 to that civic address, the findServiceResponse message MAY return
311 additional location information along with the original validated
312 civic address elements in order to form a complete location based on
313 local implementation policy in the completeLocation element. The
314 completeLocation element MUST NOT be returned in response messages
315 where any civic address elements occur in the invalid list of the
316 response, or where the set of civic address elements in the request
317 do not identify a unique location. The complete location MUST NOT
318 contain any elements that would be marked as invalid, or cause an
319 error, if a recipient of that location performs a subsequent
320 findService request using the complete location. However, if a
321 subsequent request includes the complete location, the corresponding
322 request MAY include elements in the unchecked list.
324 Clients can control the return of additional location information by
325 including an optional returnAdditionalLocation attribute with
326 possible values "none", "similar", "complete" or "any". Where "none"
327 means to not return additional location information, "similar" and
328 "complete" mean to only return the respective type of additional
329 location information (if the server could send any) and "any" means
330 to include similar and/or complete location (if the server could send
331 any). If the request includes this option, the server MUST NOT send
332 location information contravening the client's request. Not
333 including this option in the request is equivalent to "none".
335 The server may determine that there are many possible similar
336 locations and decide not to send them all. The number of similar
337 locations sent is entirely up to the server. The server MAY include
338 a similarLocationsLimited attribute which contains a non-zero integer
339 of the number of similar locations not included in the response. The
340 server is NOT obligated to make this number accurate, in that there
341 may be more than the indicated similar locations available in the
342 data held by the server.
344 Clients MAY ignore the location information this extension defines in
345 the response. The information is optional to send, and optional to
346 use. In the case where the location information in the request was
347 valid, this extension does not change the validity. In the case
348 where the location information in the request is invalid, but
349 alternate location information is returned, the original location
350 remains invalid, and the LoST server does not change the mapping
351 response other than optionally including the information defined by
352 this extension.
354 completeLocation and similarLocation use the locationInformation
355 element from [RFC5222] updated by
356 [I-D.ietf-ecrit-lost-planned-changes] including the profile attribute
357 which is useful if the request contains location information in a
358 profile derived from the civic profile. The profile attribute MUST
359 be included in both the request and the response and MUST be the same
360 profile in both.
362 5. Examples
364 5.1. Complete Location returned for Valid Location response
366 Based on the example input request, returned location information is
367 provided in a findServiceResponse message when the original input
368 address is considered valid, but is missing some additional data that
369 the LoST server has.
371
373
See 662 RFC????.
663 664 665 END 667 9. References 669 9.1. Normative References 671 [I-D.ietf-ecrit-lost-planned-changes] 672 Rosen, B., "Validation of Locations Around a Planned 673 Change", draft-ietf-ecrit-lost-planned-changes-03 (work in 674 progress), April 2019. 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, 679