idnits 2.17.1
draft-marshall-ecrit-similar-location-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
== The document seems to contain a disclaimer for pre-RFC5378 work, but was
first submitted on or after 10 November 2008. The disclaimer is usually
necessary only for documents that revise or obsolete older RFCs, and that
take significant amounts of text from those RFCs. If you can contact all
authors of the source material and they are willing to grant the BCP78
rights to the IETF Trust, you can and should remove the disclaimer.
Otherwise, the disclaimer is needed and you can ignore this comment.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 2011) is 4817 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RFC5222' is mentioned on line 85, but not defined
Summary: 1 error (**), 0 flaws (~~), 4 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: Informational TCS
5 Expires: August 5, 2011 February 2011
7 A LoST extension to support return of similar location info
8 draft-marshall-ecrit-similar-location-00
10 This document may contain material from IETF Documents or IETF
11 Contributions published or made publicly available before November
12 10, 2008. The person(s) controlling the copyright in some of this
13 material may not have granted the IETF Trust the right to allow
14 modifications of such material outside the IETF Standards Process.
15 Without obtaining an adequate license from the person(s) controlling
16 the copyright in such materials, this document may not be modified
17 outside the IETF Standards Process, and derivative works of it may
18 not be created outside the IETF Standards Process, except to format
19 it for publication as an RFC or to translate it into languages other
20 than English.
22 Abstract
24 This document introduces a new way to return similar civic locations
25 (i.e., address sets) when original input location is returned not
26 valid within the findServiceResponse message. This document defines
27 a new extension to the findServiceResponse message within the LoST
28 protocol [RFC5222], that enables the LoST protocol to return one or
29 more suggested sets of civic location information. This "similar"
30 address information is included as compilation of ca type xml
31 elements within the existing response message structure.
33 Status of this Memo
35 This Internet-Draft is submitted in full conformance with the
36 provisions of BCP 78 and BCP 79.
38 Internet-Drafts are working documents of the Internet Engineering
39 Task Force (IETF). Note that other groups may also distribute
40 working documents as Internet-Drafts. The list of current Internet-
41 Drafts is at http://datatracker.ietf.org/drafts/current/.
43 Internet-Drafts are draft documents valid for a maximum of six months
44 and may be updated, replaced, or obsoleted by other documents at any
45 time. It is inappropriate to use Internet-Drafts as reference
46 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on August 5, 2011.
50 Copyright Notice
52 Copyright (c) 2011 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
69 3. Overview of Location Transformation . . . . . . . . . . . . . 7
70 4. Similar Location Example in findServiceResponse . . . . . . . 8
71 5. Precedent for Similar Address Services . . . . . . . . . . . . 10
72 6. Similar Address Input Parameters . . . . . . . . . . . . . . . 11
73 7. Errors and Warnings . . . . . . . . . . . . . . . . . . . . . 12
74 8. Relax NG schema Impacts . . . . . . . . . . . . . . . . . . . 13
75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
77 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
79 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
80 12.2. Informative References . . . . . . . . . . . . . . . . . 17
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
83 1. Introduction
85 The LoST protcol [RFC5222] supports the validation of civic location
86 information as input, by providing a set of validation result status
87 indicators. The current usefullness of the supported xml elements,
88 "valid", "invalid", and "unchecked", is limited, because while they
89 each provide an indication of validity for any one element as a part
90 of the whole address, the mechanism is insufficient in providing
91 hints or alternate suggestions as to other close fits, or similar
92 civic locations.
94 As with the example below, a civic location that is input for
95 validation using an incorrect street suffix will result in an invalid
96 civic location. This document provides a mechanism to provide
97 additional clues, and suggestions for addresses that are very similar
98 to the original.
100 This enhancement to the validation within LoST is required to ensure
101 a high level of address matching, to overcome user and system input
102 errors, and to support the usefullness of location-based systems in
103 general.
105 The structure of this document includes terminology, Section 2,
106 followed by a discussion of the basic elements involved in location
107 validation. These 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],
117 with the important qualification that, unless otherwise stated, these
118 terms apply to the design of the Location Configuration Protocol and
119 the Location Dereferencing Protocol, not its implementation or
120 application.
122 The following terms are defined in this document:
124 Address: The term Address is used interchangeably with the concept
125 of Civic Location.
127 Invalid: The result of the attempt to match an individual input data
128 as part of a larger set of data that has already been successfully
129 matched.
131 Invalid Civic Element: An unmatched result of an individual civic
132 location element as part of a broader set of elements that make up
133 a civic location.
135 Invalid Civic Location: An unmatched result of an input civic
136 location, when taken as a whole, based on one or more individual
137 unmatched civic address elements.
139 Similar Address: A suggested civic location that is comparitively
140 close to the civic location which was input, but which had one or
141 more invalid element.
143 3. Overview of Location Transformation
145 This section lays out an example of how similar addresses are shown
146 to work.
148 Suppose that someone submits this address to Lost: 6000 15th Ave
149 Seattle, WA This address is deemed "invalid" because there is no
150 plain "15th Ave" in the city of Seattle with a house number equal to
151 6000. However there are two addresses within the address dataset
152 that are "similar", when all parts of the address are taken as a
153 whole. These similar addresses that could be suggested to the user
154 are as follows: similar address #1: 6000 15th Ave NW Seattle, WA
155 98107 similar address #2: 6000 15th Ave NE Seattle, WA 98105 This
156 document proposes to include the above similar addresses as
157 civicAddress elements in the response to locationValidation. The
158 next section shows the LoST request and response xml message fragment
159 for the above example, returning the "similar" addresses:
161 4. Similar Location Example in findServiceResponse
163 The LoST server knows the data that is available internally, and can
164 choose which type of similar addresses that it wants to return.
166
168
171
172
175 US
176 WA
177 Seattle
178 15th Ave
179 6000
181
182
184 urn:service:sos
186
188
190
192
198 Seattle 911
199 urn:service:sos
200 sip:seattle-911@example.com
201 911
203
204
207 ca:country ca:A1 ca:A3
208 ca:A6
209 ca:HNO
211
212 US
213 WA
214 SEATTLE
215 15TH
216 AVE
217 NW
218 6000
219 98107
220 SEATTLE
221
223
224 US
225 WA
226 SEATTLE
227 15TH
228 AVE
229 NE
230 6000
231 98105
232 SEATTLE
233
235
237
238
239
241
243
245
247 5. Precedent for Similar Address Services
249 There are many web-based applications that already use address
250 matching to refine user input when the exact address is not known -
251 or is represented in a way that is not commonly known or familiar.
253 One example is a public transportation system that offers a trip
254 planner application, but requires a start and end address to be able
255 to determine a route. In some cases, the seekers of the route
256 information are the ones with the least familiarity with the region,
257 so having the ability to obtain similar addresses would be beneficial
258 to the user.
260 Another example is Public Safety. Next Generation emergency call
261 architectures have founded on the IETF's ECRIT LoST protocol, which
262 makes the need to assure that the call routing mechanism will work.
263 LoST can take advantage of this proposal during location validation
264 step, ahead of an emergency call, to assure the user (or LoST
265 client), their emergency call witll route appropriately, and that
266 they will have the correctly selected dispatch location used.
268 6. Similar Address Input Parameters
270 Additional input parameters that request the server to return a
271 greater number of similar addresses, or specify the type(s) of data
272 to substitute (i.e., a matching algorithm), is left as out-of-scope
273 in this draft.
275 7. Errors and Warnings
277 [This section to be supplied]
279 8. Relax NG schema Impacts
281 The above proposal is already compatible with RFC-5222 RELAX NG
282 definition for the element, based on the
283 inclusion in the locationValidation definition of "extensionPoint",
284 which allows for the inclusion of any non-LoST elements.
286 The proposal does not, therefore, need to redefine the current RFC-
287 5222 RELAX NG definitions, the proposal simply needs to say that when
288 a LoST Server returns a with a
289 locationValidation that contains an invalid, it is recommended that
290 the LoST server try to include one or more in the
291 , where each is a fully valid address that is
292 "similar" to the input address. User-facing GUIs should present
293 these "similar" addresses to help the user resolve the invalid
294 address in their original request.
296 The proposal does not try and define exactly how to compute "similar"
297 addresses. Lost server implementers are free to choose whatever
298 technique to compute similar addresses -- any "similar" address is
299 likely to be helpful for the user.
301 9. Security Considerations
303 [This section to be supplied]
305 10. IANA Considerations
307 [This section to be supplied]
309 11. Acknowledgements
311 [This section to be supplied]
313 12. References
315 12.1. Normative References
317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
318 Requirement Levels", BCP 14, RFC 2119, March 1997.
320 12.2. Informative References
321 Authors' Addresses
323 Roger Marshall
324 TeleCommunication Systems, Inc.
325 2401 Elliott Avenue
326 2nd Floor
327 Seattle, WA 98121
328 US
330 Phone: +1 206 792 2424
331 Email: rmarshall@telecomsys.com
332 URI: http://www.telecomsys.com
334 Jeff Martin
335 TeleCommunication Systems, Inc.
336 2401 Elliott Avenue
337 2nd Floor
338 Seattle, WA 98121
339 US
341 Phone: +1 206 792 2584
342 Email: jmartin@telecomsys.com
343 URI: http://www.telecomsys.com