idnits 2.17.1 draft-marshall-ecrit-similar-location-02.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 date (July 16, 2013) is 3937 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 435, but not defined Summary: 1 error (**), 0 flaws (~~), 3 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 17, 2014 B. Rosen 6 Neustar 7 July 16, 2013 9 A LoST extension to support return of complete and similar location info 10 draft-marshall-ecrit-similar-location-02 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 a 17 valid or invalid location is returned within the findServiceResponse 18 message. This document defines a new extension to the 19 findServiceResponse message within the LoST protocol [RFC5222] that 20 enables the LoST protocol to return a completed civic location 21 element set for a valid response, and one or more suggested sets of 22 civic location information for invalid LoST responses. These two 23 types of civic addresses are referred to as either "complete" or 24 "similar" locations, and are included as compilation of ca type xml 25 elements within the existing response 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 http://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 17, 2014. 44 Copyright Notice 46 Copyright (c) 2013 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 (http://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 . . . . . . . . . . . . . . . . 6 65 5. Complete Location returned for Valid response . . . . . . . . 6 66 6. Similar Location returned for Invalid Response . . . . . . . 8 67 7. Relax NG schema . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 11.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The LoST protcol [RFC5222] supports the validation of civic location 79 information as input, by providing a set of validation result status 80 indicators. The current usefullness of the supported xml elements, 81 "valid", "invalid", and "unchecked", is limited, because while they 82 each provide an indication of validity for any one element as a part 83 of the whole address, the mechanism is insufficient in providing 84 either the complete set of address elements that the LoST server 85 contains, or of providing alternate suggestions (hints) as to which 86 civic address is intended. 88 Whether the input civic location is valid and missing information, or 89 invalid due to missing or wrong information during input, this 90 document provides a mechanism to return a complete set of location 91 information for those valid or invalid cases. 93 This enhancement to the validation feature within LoST is required in 94 order to ensure a high level of address matching, to overcome user 95 and system input errors, and to support the usefulness of location- 96 based systems in general. 98 The structure of this document includes terminology, Section 2, 99 followed by a discussion of the basic elements involved in location 100 validation. These use of these elements, by way of example, is 101 discussed in an overview section, Section 3, with accompanying 102 rationale, and a brief discussion of the impacts to LoST, and its 103 current schema. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119], 110 with the important qualification that, unless otherwise stated, these 111 terms apply to the design of the Location Configuration Protocol and 112 the Location Dereferencing Protocol, not its implementation or 113 application. 115 The following terms are defined in this document: 117 Address: The term Address is used interchangeably with the concept 118 of Civic Location. 120 Invalid: The result of the attempt to match an individual input data 121 as part of a larger set of data that has already been successfully 122 matched. 124 Invalid Civic Element: An unmatched result of an individual civic 125 location element as part of a broader set of elements that make up 126 a civic location. 128 Invalid Civic Location: An unmatched result of an input civic 129 location, when taken as a whole, based on one or more individual 130 unmatched civic address elements. 132 Complete Location: An expanded civic location that includes 133 additional address elements in addition to the existing validated 134 civic elements provided. 136 Similar Location: A suggested civic location that is comparatively 137 close to the civic location which was input, but which had one or 138 more invalid element. 140 Returned Location Information: A set of standard civic location 141 elements returned in a LoST response. 143 3. Overview of Returned Location Information 145 This document describes an extension to LoST [RFC5222], to allow 146 additional location information to be returned in a 147 findServiceResponse for two different use cases. 149 When a LoST server is asked to validate a location, its goal is to 150 take the set of elements in the location information in the request, 151 and find a unique location in its database that matches the 152 information in the request. Uniqueness may not require values for 153 all possible elements in the civic address that the database may 154 hold. Further, the input location information may not represent the 155 form of location the users of the LoST service prefer to have. As an 156 example, there are LoST elements that could be used to define a 157 postal location, suitable for delivery mail as well as a municipal 158 location suitable for responding to an emergency call. While the 159 LoST server may be able to determine the location from the postal 160 elements provided, the emergency services would prefer that the 161 municipal location be used for any subsequent emergency call. Since 162 validation is often performed well in advance of an emergency call, 163 if the LoST server could return the preferred form of location (or 164 more properly, the municipal elements in addition to the postal 165 elements), those elements could be stored in a LIS and used in a 166 subsequent emergence call. 168 Since a LoST server often contains more data than what is often 169 included within a findService request, it is expected that this 170 additional location information could be returned within response 171 messages that may be both valid and invalid. For valid responses, 172 where a LoST server contains additional location information relating 173 to that civic address, the findServiceResponse message can return 174 additional location information along with the original validated 175 elements in order to form a complete civic location. 177 On the other hand, for an invalid LoST response that contains address 178 elements returned with one or more of them marked as invalid, and 179 constituting an invalid location, this document introduces the idea 180 of reusing this same mechanism, but for a different purpose - to 181 supply similar location information - again, information that is 182 contained within the LoST server, but is provided as a complete 183 "similar" civic location put forward as a suggested alternative 184 address that is also a valid location. 186 In valid location responses, when a LoST server returns a response to 187 a findService request that contains a set of CAtype elements 188 considered valid, the location information in the findServiceResponse 189 is extended to include additional location information specific for 190 that location. As an example, the query may contain a HNO (house 191 number), RD (road name) and A3 (city) but may not contain A1, A2, PC 192 (Postal Code) CAtypes. The RD and PC elements may be sufficient to 193 locate the address specified in the request and thus be considered 194 valid. Yet, downstream entities may find it helpful to have the 195 additional A1, A2, and PC location elements that exist, and so the 196 mechanism described here supports their inclusion. Since [RFC5222] 197 currently does not have a way for this additional location 198 information to be returned in the findServiceResponse, this document 199 extends RFC5222 so that it can include a completeLocation element 200 within the findServiceResponse message, representing a "complete" 201 civic location. 203 input address: 6000 15th Ave NW Seattle 205 completed address: 6000 15th Ave NW Seattle, WA 98105 US 207 When invalid location responses are received, the same mechanism 208 works as follows: when a LoST server returns a response to a 209 findService request that contains a set of CAtype elements with one 210 or more that are tagged as invalid, the location information in the 211 findServiceResponse is extended to include additional location 212 information specific for that location. Differing results in the 213 same data used in the above example, where the RD and PC elements are 214 not sufficient to locate a unique address leads to an "invalid" 215 result. This is the case, despite the fact that the LoST server 216 typically contains additional location elements which could have 217 resulted in a uniquely identifiable location if additional data had 218 been supplied in the query. Since [RFC5222] currently does not have 219 a way for this additional location information to be returned in the 220 findServiceResponse, this document extends RFC5222 so that it can 221 include one or more similarLocation elements within the 222 findServiceResponse message representing "similar" civic locations. 224 To show this, suppose that a similar address as above is inserted 225 within a Lost findService request: 227 input address: 6000 15th Ave Seattle, WA. 229 Different from the above case, this time we make the assumption that 230 the address is deemed "invalid" by the LoST server because there is 231 no plain "15th Ave" in the city of Seattle with a house number that 232 matches 6000. However there are two addresses within the address 233 dataset that are "similar", when all parts of the address are taken 234 as a whole. These similar addresses that could be suggested to the 235 user are as follows: 237 similar address #1: 6000 15th Ave NW Seattle, WA 98107 239 similar address #2: 6000 15th Ave NE Seattle, WA 98105 241 This document proposes to include the above similar addresses as 242 civicAddress elements in the response to locationValidation. The 243 next section shows examples of the LoST request and response xml 244 message fragments for the above valid and invalid scenarios, 245 returning the complete or similar addresses, respectively: 247 4. Returned Location Information 249 The LoST server knows the data that is available internally, and can 250 determine which additional elements can be provided either as part of 251 a complete civic location (CCL) or a similar civic location (SCL). 252 The inclusion of either CCL or SCL is not triggered by any message 253 parameter, but is triggered based on whether the returned location 254 information is valid or invalid. It is not turned on or off, but is 255 implementation specific. 257 5. Complete Location returned for Valid response 259 Based on the example input request, returned location information is 260 provided in a findServiceResponse message when the original input 261 address is considered valid, but is missing some additional data that 262 the LoST server has. 264 266 269 270 273 Seattle 274 15th 275 Ave 276 NW 277 6000 279 280 282 urn:service:sos 284 286 288 289 xmlns="urn:ietf:params:xml:ns:lost1" 290 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 291 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 293 299 Seattle 911 300 urn:service:sos 301 sip:seattle-911@example.com 302 911 304 306 ca:A3 ca:A6 ca:STS ca:POD ca:HNO 309 310 312 313 314 US 315 WA 316 SEATTLE 317 15TH 318 AVE 319 NW 320 6000 321 98106 322 SEATTLE 323 325 327 329 330 331 333 335 337 339 6. Similar Location returned for Invalid Response 341 The following example shows returned location information provided in 342 a findServiceResponse message when the original input address is 343 considered invalid, because (in this case) of missing data that the 344 LoST server needs to provide a unique mapping. 346 348 351 352 355 US 356 WA 357 Seattle 358 15th Ave 359 6000 361 362 364 urn:service:sos 366 368 369 370 xmlns="urn:ietf:params:xml:ns:lost1" 371 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 372 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 374 380 Seattle 911 381 urn:service:sos 382 sip:seattle-911@example.com 383 911 385 387 ca:country ca:A1 ca:A3 390 ca:A6 391 ca:HNO 393 394 395 US 396 WA 397 SEATTLE 398 15TH 399 AVE 400 NW 401 6000 402 98106 403 SEATTLE 404 406 407 US 408 WA 409 SEATTLE 410 15TH 411 AVE 412 NE 413 6000 414 98105 415 SEATTLE 416 418 420 422 423 424 426 428 430 432 7. Relax NG schema 434 This section provides the Relax NG schema of LoST extensions in the 435 compact form. The verbose form is included in a later section [TBA]. 437 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 438 default namespace ns1 = "urn:ietf:params:xml:ns:lost-rl11" 440 ## 441 ## Extension to LoST to support returned location information 442 ## 443 start = 444 returnedLocation 446 div { 447 returnedLocationResponse = 448 element returnedLocationResponse { 449 completeLocation, similarLocation, extensionPoint 450 } 451 } 453 ## 454 ## completeLocation 455 ## 456 div { 457 completeLocation = 458 element location { 459 attribute id { xsd:token }, 460 locationInformation 461 }+ 462 } 464 ## 465 ## similarLocation 466 ## 467 div { 468 similarLocation = 469 element location { 470 attribute id { xsd:token }, 471 locationInformation 472 }+ 473 } 474 ## 475 ## Location Information 476 ## 477 div { 478 locationInformation = 479 extensionPoint+, 480 attribute profile { xsd:NMTOKEN }? 481 } 483 ## 484 ## Patterns for inclusion of elements from schemas in 485 ## other namespaces. 486 ## 487 div { 489 ## 490 ## Any element not in the LoST namespace. 491 ## 492 notLost = element * - (ns1:* | ns1:*) { anyElement } 494 ## 495 ## A wildcard pattern for including any element 496 ## from any other namespace. 497 ## 498 anyElement = 499 (element * { anyElement } 500 | attribute * { text } 501 | text)* 503 ## 504 ## A point where future extensions 505 ## (elements from other namespaces) 506 ## can be added. 508 ## 509 extensionPoint = notRLI* 510 } 512 8. Security Considerations 514 Whether the input to the LoST server is valid or invalid, the LoST 515 server ultimately determines what it considers to be valid. In the 516 case where the input location is valid, the requester still may not 517 actually understand where that locaiton is. For valid location use 518 cases, this extension returns more location information than the 519 requester may have had which, in turn, may reveal more about the 520 location. While this may be very desirable when, for example, 521 supporting an emergency call, it may not be as desirable for other 522 services. The LoST server implementation should consider the risk of 523 releasing more detail verses the value in doing so. Generally, we do 524 not believe this is a significant problem as the requester must have 525 enough location information to be considered valid, which in most 526 cases is enough to uniquely locate the address. Providing more 527 CAtypes generally doesn't actually reveal anything more. 529 9. IANA Considerations 531 10. Acknowledgements 533 11. References 535 11.1. Normative References 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 11.2. Informative References 542 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 543 Tschofenig, "LoST: A Location-to-Service Translation 544 Protocol", RFC 5222, August 2008. 546 Authors' Addresses 547 Roger Marshall 548 TeleCommunication Systems, Inc. 549 2401 Elliott Avenue 550 2nd Floor 551 Seattle, WA 98121 552 US 554 Phone: +1 206 792 2424 555 Email: rmarshall@telecomsys.com 556 URI: http://www.telecomsys.com 558 Jeff Martin 559 TeleCommunication Systems, Inc. 560 2401 Elliott Avenue 561 2nd Floor 562 Seattle, WA 98121 563 US 565 Phone: +1 206 792 2584 566 Email: jmartin@telecomsys.com 567 URI: http://www.telecomsys.com 569 Brian Rosen 570 Neustar 571 470 Conrad Dr 572 Mars, PA 16046 573 US 575 Email: br@brianrosen.net