idnits 2.17.1 draft-marshall-ecrit-similar-location-01.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 (July 12, 2011) is 4644 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBA' is mentioned on line 423, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 TCS 5 Expires: January 13, 2012 B. Rosen 6 Neustar 7 July 12, 2011 9 A LoST extension to support return of complete and similar location info 10 draft-marshall-ecrit-similar-location-01 12 This document may contain material from IETF Documents or IETF 13 Contributions published or made publicly available before November 14 10, 2008. The person(s) controlling the copyright in some of this 15 material may not have granted the IETF Trust the right to allow 16 modifications of such material outside the IETF Standards Process. 17 Without obtaining an adequate license from the person(s) controlling 18 the copyright in such materials, this document may not be modified 19 outside the IETF Standards Process, and derivative works of it may 20 not be created outside the IETF Standards Process, except to format 21 it for publication as an RFC or to translate it into languages other 22 than English. 24 Abstract 26 This document introduces a new way to provide returned location 27 information in LoST responses that is either of a completed or 28 similar form to the original input civic location, based on whether a 29 valid or invalid location is returned within the findServiceResponse 30 message. This document defines a new extension to the 31 findServiceResponse message within the LoST protocol [RFC5222] that 32 enables the LoST protocol to return a completed civic location 33 element set for a valid response, and one or more suggested sets of 34 civic location information for invalid LoST responses. These two 35 types of civic addresses are referred to as either "complete" or 36 "similar" locations, and are included as compilation of ca type xml 37 elements within the existing response message structure. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on January 13, 2012. 56 Copyright Notice 58 Copyright (c) 2011 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. Overview of Returned Location Information . . . . . . . . . . 7 76 4. Returned Location Information . . . . . . . . . . . . . . . . 9 77 5. Complete Location returned for Valid response . . . . . . . . 10 78 6. Similar Location returned for Invalid Response . . . . . . . . 12 79 7. Relax NG schema . . . . . . . . . . . . . . . . . . . . . . . 14 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 85 11.2. Informative References . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 The LoST protcol [RFC5222] supports the validation of civic location 91 information as input, by providing a set of validation result status 92 indicators. The current usefullness of the supported xml elements, 93 "valid", "invalid", and "unchecked", is limited, because while they 94 each provide an indication of validity for any one element as a part 95 of the whole address, the mechanism is insufficient in providing 96 either the complete set of address elements that the LoST server 97 contains, or of providing alternate suggestions (hints) as to which 98 civic address is intended. 100 Whether the input civic location is valid and missing information, or 101 invalid due to missing or wrong information during input, this 102 document provides a mechanism to return full address information for 103 those valid or invalid cases. 105 This enhancement to the validation feature within LoST is required in 106 order to ensure a high level of address matching, to overcome user 107 and system input errors, and to support the usefullness of location- 108 based systems in general. 110 The structure of this document includes terminology, Section 2, 111 followed by a discussion of the basic elements involved in location 112 validation. These use of these elements, by way of example, is 113 discussed in an overview section, Section 3, with accompanying 114 rationale, and a brief discussion of the impacts to LoST, and its 115 current schema. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119], 122 with the important qualification that, unless otherwise stated, these 123 terms apply to the design of the Location Configuration Protocol and 124 the Location Dereferencing Protocol, not its implementation or 125 application. 127 The following terms are defined in this document: 129 Address: The term Address is used interchangeably with the concept 130 of Civic Location. 132 Invalid: The result of the attempt to match an individual input data 133 as part of a larger set of data that has already been successfully 134 matched. 136 Invalid Civic Element: An unmatched result of an individual civic 137 location element as part of a broader set of elements that make up 138 a civic location. 140 Invalid Civic Location: An unmatched result of an input civic 141 location, when taken as a whole, based on one or more individual 142 unmatched civic address elements. 144 Complete Location: An expanded civic location that includes 145 additional address elements in addition to the existing validated 146 civic elements provided. 148 Similar Location: A suggested civic location that is comparatively 149 close to the civic location which was input, but which had one or 150 more invalid element. 152 Returned Location Information: A set of standard civic location 153 elements returned in a LoST response. 155 3. Overview of Returned Location Information 157 This document describes an extension to LoST [RFC5222], to allow 158 additional location information to be returned in a 159 findServiceResponse for two different use cases. 161 Since a LoST server often contains more data than what is often 162 included within a findService request, it is expected that this 163 additional location information could be returned within response 164 messages that may be both valid and invalid. For valid responses, 165 where a LoST server contains additional location information relating 166 to that civic address, the findServiceResponse message can return 167 additional location information along with the original validated 168 elements in order to form a complete civic location. 170 On the other hand, for an invalid LoST response that contains address 171 elements returned with one or more of them marked as invalid, and 172 constituting an invalid location, this document introduces the idea 173 of reusing this same mechanism, but for a different purpose - to 174 supply similar location information - again, information that is 175 contained within the LoST server, but is provided as a complete 176 "similar" civic location put forward as a suggested alternative 177 address that is also a valid location. 179 In valid location responses, this works in the following way: when a 180 LoST server returns a response to a findService request that contains 181 a set of CAtype elements considered valid, the location information 182 in the findServiceResponse is extended to include additional location 183 information specific for that location. As an example, the query may 184 contain a HNO (house number), RD (road name) and A3 (city) but may 185 not contain A1, A2, PC (Postal Code) CAtypes. The RD and PC elements 186 may be sufficient to locate the address specified in the request and 187 thus be considered valid. Yet, downstream entities may find it 188 helpful to have the additional A1, A2, and PC location elements that 189 exist, and so the mechanism described here supports their inclusion. 190 Since [RFC5222] currently does not have a way for this additional 191 location information to be returned in the findServiceResponse, this 192 document extends RFC5222 so that it can include a completeLocation 193 element within the findServiceResponse message, representing a 194 "complete" civic location. 196 input address: 6000 15th Ave NW Seattle 198 completed address: 6000 15th Ave NW Seattle, WA 98105 US 200 When invalid location responses are received, the same mechanism 201 works as follows: when a LoST server returns a response to a 202 findService request that contains a set of CAtype elements with one 203 or more that are tagged as invalid, the location information in the 204 findServiceResponse is extended to include additional location 205 information specific for that location. Differing results in the 206 same data used in the above example, where the RD and PC elements are 207 not sufficient to locate a unique address leads to an "invalid" 208 result. This is the case, despite the fact that the LoST server 209 typically contains additional location elements which could have 210 resulted in a uniquely identifiable location if additional data had 211 been supplied in the query. Since [RFC5222] currently does not have 212 a way for this additional location information to be returned in the 213 findServiceResponse, this document extends RFC5222 so that it can 214 include one or more similarLocation elements within the 215 findServiceResponse message representing "similar" civic locations. 217 To show this, suppose that a similar address as above is inserted 218 within a Lost findService request: 220 input address: 6000 15th Ave Seattle, WA. 222 Different from the above case, this time we make the assumption that 223 the address is deemed "invalid" by the LoST server because there is 224 no plain "15th Ave" in the city of Seattle with a house number that 225 matches 6000. However there are two addresses within the address 226 dataset that are "similar", when all parts of the address are taken 227 as a whole. These similar addresses that could be suggested to the 228 user are as follows: 230 similar address #1: 6000 15th Ave NW Seattle, WA 98107 232 similar address #2: 6000 15th Ave NE Seattle, WA 98105 234 This document proposes to include the above similar addresses as 235 civicAddress elements in the response to locationValidation. The 236 next section shows examples of the LoST request and response xml 237 message fragments for the above valid and invalid scenarios, 238 returning the complete or similar addresses, respectively: 240 4. Returned Location Information 242 The LoST server knows the data that is available internally, and can 243 determine which additional elements can be provided either as part of 244 a complete civic location (CCL) or a similar civic location (SCL). 245 The inclusion of either CCL or SCL is not triggered by any message 246 parameter, but is triggered based on whether the returned location 247 information is valid or invalid. It is not turned on or off, but is 248 implementation specific. 250 5. Complete Location returned for Valid response 252 Based on the example input request, returned location information is 253 provided in a findServiceResponse message when the original input 254 address is considered valid, but is missing some additional data that 255 the LoST server has. 257 259 262 263 266 Seattle 267 15th 268 Ave 269 NW 270 6000 272 273 275 urn:service:sos 277 279 281 283 289 Seattle 911 290 urn:service:sos 291 sip:seattle-911@example.com 292 911 294 296 299 ca:A3 ca:A6 ca:STS ca:POD ca:HNO 300 301 303 304 305 US 306 WA 307 SEATTLE 308 15TH 309 AVE 310 NW 311 6000 312 98106 313 SEATTLE 314 316 318 320 321 322 324 326 328 330 6. Similar Location returned for Invalid Response 332 The following example shows returned location information provided in 333 a findServiceResponse message when the original input address is 334 considered invalid, because (in this case) of missing data that the 335 LoST server needs to provide a unique mapping. 337 339 342 343 346 US 347 WA 348 Seattle 349 15th Ave 350 6000 352 353 355 urn:service:sos 357 359 361 363 369 Seattle 911 370 urn:service:sos 371 sip:seattle-911@example.com 372 911 374 375 378 ca:country ca:A1 ca:A3 379 ca:A6 380 ca:HNO 382 383 384 US 385 WA 386 SEATTLE 387 15TH 388 AVE 389 NW 390 6000 391 98106 392 SEATTLE 393 395 396 US 397 WA 398 SEATTLE 399 15TH 400 AVE 401 NE 402 6000 403 98105 404 SEATTLE 405 406 408 410 411 412 414 416 418 420 7. Relax NG schema 422 This section provides the Relax NG schema of LoST extensions in the 423 compact form. The verbose form is included in a later section [TBA]. 425 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 426 default namespace ns1 = "urn:ietf:params:xml:ns:lost-ext2" 428 ## 429 ## Extensions to the Location-to-Service Translation (LoST) 430 ## Protocol 432 ## 433 ## LoST Extensions define two new elements: completeLocation and 434 ## similarLocation. 435 ## 436 start = 437 completeLocation 438 | similarLocation 440 ## 441 ## complete Location 442 ## 443 div { 444 completeLocation= 445 element completeLocation 446 } 448 ## 449 ## similar Location 450 ## 451 div { 452 similarLocation= 453 element completeLocation 454 } 456 ## 457 ## Patterns for inclusion of elements from schemas in 458 ## other namespaces. 459 ## 460 div { 462 ## 463 ## Any element not in the LoST Extensions 464 ## namespace. 466 ## 467 notLostExt = element * - (ns1:* | ns1:*) { anyElement } 469 ## 470 ## A wildcard pattern for including any element 471 ## from any other namespace. 472 ## 473 anyElement = 474 (element * { anyElement } 475 | attribute * { text } 476 | text)* 478 ## 479 ## A point where future extensions 480 ## (elements from other namespaces) 481 ## can be added. 482 ## 483 extensionPoint = notLostExt* 484 } 486 [Editor's note: above needs refinement] 488 8. Security Considerations 490 Whether the input to the LoST server is valid or invalid, the LoST 491 server ultimately determines what it considers to be valid. In the 492 case where the input location is valid, the requester still may not 493 actually understand where that locaiton is. For valid location use 494 cases, this extension returns more location information than the 495 requester may have had which, in turn, may reveal more about the 496 location. While this may be very desirable when, for example, 497 supporing an emergency call, it may not be as desirable for other 498 services. The LoST server implementation should consider the risk of 499 releasing more detail verses the value in doing so. Generally, we do 500 not believe this is a significant problem as the requester must have 501 enough location information to be considered valid, which in most 502 cases is enough to uniquely locate the address. Providing more 503 CAtypes generally doesn't actually reveal anything more. 505 9. IANA Considerations 506 10. Acknowledgements 507 11. References 509 11.1. Normative References 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 11.2. Informative References 516 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 517 Tschofenig, "LoST: A Location-to-Service Translation 518 Protocol", RFC 5222, August 2008. 520 Authors' Addresses 522 Roger Marshall 523 TeleCommunication Systems, Inc. 524 2401 Elliott Avenue 525 2nd Floor 526 Seattle, WA 98121 527 US 529 Phone: +1 206 792 2424 530 Email: rmarshall@telecomsys.com 531 URI: http://www.telecomsys.com 533 Jeff Martin 534 TeleCommunication Systems, Inc. 535 2401 Elliott Avenue 536 2nd Floor 537 Seattle, WA 98121 538 US 540 Phone: +1 206 792 2584 541 Email: jmartin@telecomsys.com 542 URI: http://www.telecomsys.com 544 Brian Rosen 545 Neustar 546 470 Conrad Dr 547 Mars, PA 16046 548 US 550 Phone: 551 Email: br@brianrosen.net 552 URI: