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