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