idnits 2.17.1 draft-marshall-ecrit-similar-location-04.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 date (July 23, 2014) is 3564 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 24, 2015 B. Rosen 6 Neustar 7 July 23, 2014 9 A LoST extension to return complete and similar location info 10 draft-marshall-ecrit-similar-location-04 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 25 compilation of ca type 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 http://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 January 24, 2015. 45 Copyright Notice 47 Copyright (c) 2014 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 (http://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 . . . . . . . . . . 5 65 4. Returned Location Information . . . . . . . . . . . . . . . . 7 66 5. Complete Location returned for Valid Location response . . . 7 67 6. Similar Location returned for Invalid Location response . . . 9 68 7. Relax NG schema . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 9.1. Relax NG Schema Registration . . . . . . . . . . . . . . 14 72 9.2. LoST Namespace Registration . . . . . . . . . . . . . . . 14 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 74 11. Changes from Previous Versions . . . . . . . . . . . . . . . 15 75 11.1. Changes from draft-marshall-03 to -04 . . . . . . . . . 15 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 12.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 The LoST protcol [RFC5222] supports the validation of civic location 84 information as input, by providing a set of validation result status 85 indicators. The current usefullness of the supported xml elements, 86 "valid", "invalid", and "unchecked", is limited, because while they 87 each provide an indication of validity for any one location element 88 as a part of the whole civic address, the mechanism is insufficient 89 in providing either the complete set of civic address elements that 90 the LoST server contains, or of providing alternate suggestions 91 (hints) as to which civic address is intended for use. 93 Whether the input civic location is valid and missing information, or 94 invalid due to missing or wrong information during input, this 95 document provides a mechanism to return a complete set of civic 96 address elements for those valid or invalid cases. 98 This enhancement to the validation feature within LoST is required by 99 systems that rely on accurate location for processing in order to 100 increase the likelyhood that the correct and/or complete form of a 101 civic location becomes known in those cases where it is incomplete or 102 just plain wrong. One such use case is that of location based 103 emergency calling. The use of this protocol extension will reduce 104 user and system input errors, and will result in a higher level of 105 civic address matching, reducing the number of mismatch errors, where 106 a civic address that appears to be valid gets wrongly associated with 107 the physical location of the caller. 109 The structure of this document includes terminology, Section 2, 110 followed by a discussion of the basic elements involved in location 111 validation. The use of these elements, by way of example, is 112 discussed in an overview section, Section 3, with accompanying 113 rationale, and a brief discussion of the impacts to LoST, and its 114 current schema. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119], 121 with the important qualification that, unless otherwise stated, these 122 terms apply to the design of the Location Configuration Protocol and 123 the Location Dereferencing Protocol, not its implementation or 124 application. 126 The following terms are defined in this document: 128 Location: The term Location can be used to refer to either a civic 129 location or a geodetic location. 131 Geodetic Location: a geographic coordinate set of values that 132 describes a point within a defined geographic datum. For example, 133 a WGS84 referenced lattitude, longitude coordinate pair (2D), or 134 lattitude, longitude, and altitude (3D). Note: geodetic location 135 is defined here for context, but is not used elsewhere within this 136 document. 138 Civic Location: The term civic location applies to a set of one or 139 more civic address elements that are used in conjunction with each 140 other, and in accordance with a known ruleset to designates a 141 place within a defined grid or basemap, The example used within 142 this document is a street address as defined in [RFC5139] 144 Civic Address: The term Civic Address is used interchangeably with 145 the term Civic Location within this document. 147 Street Address: The term Street Address is used to represent a 148 place, or location on a defined grid or map. While generally 149 equated to both terms, Civic Location and Civic Address, it is not 150 used within this document. 152 Civic Address Element: The term Civic Address Element is used within 153 this document to apply to an individual CAtype data descriptor, 154 for example, as is defined in [RFC4776] 156 Invalid: The status result of the unsuccessful attempt to match an 157 individual input data as part of a larger set of data that has 158 already been successfully matched and as shown by the [RFC5222] 159 defined xml named element 161 Valid: The status result of the successful attempt to match an 162 individual input data as part of a larger set of data that has 163 already also been successfully matched and shown by the [RFC5222] 164 defined xml named element 166 Invalid Location: A Civic Location that was included in a LoST 167 request and subsequently returned with one or more civic address 168 elements marked as invalid. 170 Valid Location: A Civic Location that was included in a LoST request 171 and subsequently returned with all civic address elements marked 172 as valid. 174 Complete Location: An expanded civic location that includes other 175 civic address elements in addition to the existing validated civic 176 address elements provided as input to a LoST server. 178 Similar Location: A suggested civic location that is comparatively 179 close to the civic location which was input, but which had one or 180 more invalid civic address elements returned by the LoST server. 182 Returned Location Information: A set of standard civic address 183 elements returned in a LoST response. 185 3. Overview of Returned Location Information 187 This document describes an extension to LoST [RFC5222] to allow 188 additional location information to be returned in a 189 findServiceResponse for two different use cases. 191 When a LoST server is asked to validate a civic location, its goal is 192 to take the set of civic address elements provided as the location 193 information in the LoST request, and find a unique location in its 194 database that matches the information in the request. Uniqueness 195 might not require values for all possible elements in the civic 196 address that the database might hold. Further, the input location 197 information might not represent the form of location the users of the 198 LoST service prefer to have. As an example, there are LoST civic 199 address elements that could be used to define a postal location, 200 suitable for delivery mail as well as a municipal location suitable 201 for responding to an emergency call. While the LoST server might be 202 able to determine the location from the postal elements provided, the 203 emergency services would prefer that the municipal location be used 204 for any subsequent emergency call. Since validation is often 205 performed well in advance of an end-user placing an emergency call, 206 if the LoST server could return the preferred form of location (or 207 more properly, the municipal elements in addition to the postal 208 elements), those elements could be stored in a LIS and used in a 209 later emergency call. 211 Since a LoST server often contains more data than what is included 212 within a findService request, it is expected that this additional 213 location information, if present, SHOULD be returned within response 214 messages that contain valid civic address elements. For valid 215 location responses, where a LoST server contains additional location 216 information relating to that civic address, the findServiceResponse 217 message MAY return additional location information along with the 218 original validated civic address elements in order to form a complete 219 location based on local implementation policy. 221 In addition, this document describes the reuse of the same mechanism, 222 but for a different purpose: to supply similar location information 223 in the case where a LoST server response includes one or more civic 224 address elements marked as invalid, constituting an invalid location 225 response, offerring one or more suggested alternative address that 226 would consist of one or more valid locations. 228 LoST servers that implement this extension have no way to alert 229 clients that may not be aware of the extension's capabilities, other 230 than supplying the extended data set. It is expected that a LoST 231 client implementation that is not aware of this extension for 232 complete and/or similar location SHOULD be able to still receive the 233 findServiceResponse data, while throwing away any extra complete or 234 similar location data. 236 In a valid location response, a LoST server returns a response to a 237 findService request that contains a set of civic address elements 238 marked valid, the location information in the findServiceResponse 239 message MAY be extended to include additional location information 240 specific for that location. As an example, the query might contain a 241 HNO (house number), RD (road name) and A3 (city) and a few more 242 caType elements, but might not contain A1 (state), PC (Postal Code) 243 CAtypes. The HNO, RD, STS, POD, and A3 civic address elements might 244 be sufficient enough to the LoST server to uniquely locate the 245 address specified in the request and thus be considered valid. Yet, 246 downstream entities might find it helpful to have the additional 247 country, A1 (state), and PC, (Postal Code), civic address elements 248 that are present within the LoST server, be included as part of a 249 complete location response. Since [RFC5222] currently does not have 250 a way for this additional location information to be returned in the 251 findServiceResponse, this document extends the LoST protocol so that 252 it can include a completeLocation element within the 253 findServiceResponse message, allowing for the representation of 254 complete location information. 256 An example showing complete location information supplied: 258 input address: 6000 15th Ave NW Seattle 260 complete location: 6000 15th Ave NW Seattle, WA 98105 US 262 By constrast, when invalid location is received from the LoST server, 263 with this extension, the same mechanism works as follows: if a LoST 264 server returns a response to a findService request that contains a 265 set of civic address elements with one or more labeled as invalid, 266 the location information in the findServiceResponse is extended to 267 include additional location information that it knows is specific for 268 that location. Differing results based on somewhat close input data 269 as used above, where the HNO, RD, STS, A1, and A3 civic address 270 elements are not sufficient to locate a unique address leads to an 271 invalid location result. This is the case, despite the fact that the 272 LoST server typically contains additional civic address elements 273 which could have resulted in a uniquely identifiable location if 274 additional data had been supplied with the query. Since [RFC5222] 275 currently does not have a way for this additional location 276 information to be returned in the findServiceResponse, this document 277 extends [RFC5222] so that the LoST findServiceResponse message can 278 include one or more similarLocation elements within the 279 findServiceResponse message representing similar civic locations. 281 To show this, suppose that a slightly modified address as above is 282 inserted within a Lost findService request: 284 input address: 6000 15th Ave N Seattle, WA. 286 Different from the previous use case, this time we make the 287 assumption that the address is deemed "invalid" by the LoST server 288 because there is no such thing as "15th Ave N" within the LoST 289 server's data for the city of Seattle. However, we also happen to 290 know for this example that there are two addresses within the address 291 dataset that are "similar", when all parts of the address are taken 292 as a whole. These similar addresses that could be suggested to the 293 user are as follows: 295 similar address #1: 6000 15th Ave NW Seattle, WA 98107 297 similar address #2: 6000 15th Ave NE Seattle, WA 98105 299 This document proposes to include the above similar addresses as 300 civicAddress elements in the response to locationValidation. The 301 next section shows examples of the LoST request and response xml 302 message fragments for the above valid and invalid scenarios, 303 returning the complete or similar addresses, respectively: 305 4. Returned Location Information 307 The LoST server knows the data that is available internally, and can 308 determine which additional civic address elements can be provided 309 either as part of a complete location or a similar location. The 310 inclusion of either complete location or similar location is not 311 triggered by any message parameter, but is triggered based on whether 312 the returned location information is valid or invalid. It is not 313 turned on or off, but is implementation specific. 315 5. Complete Location returned for Valid Location response 317 Based on the example input request, returned location information is 318 provided in a findServiceResponse message when the original input 319 address is considered valid, but is missing some additional data that 320 the LoST server has. 322 324 326 327 330 WA 331 Seattle 332 15th 333 Ave 334 NW 335 6000 337 338 340 urn:service:sos 342 344 346 347 xmlns="urn:ietf:params:xml:ns:lost1" 348 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 349 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 351 357 Seattle 911 358 urn:service:sos 359 sip:seattle-911@example.com 360 911 362 364 ca:A3 ca:RD ca:STS ca:POD ca:HNO 367 368 370 371 372 US 373 WA 374 SEATTLE 375 15TH 376 AVE 377 NW 378 6000 379 98106 380 SEATTLE 381 383 385 387 388 389 391 393 395 397 6. Similar Location returned for Invalid Location response 399 The following example shows returned location information provided in 400 a findServiceResponse message when the original input address is 401 considered invalid, because of the unmatchable POD data (in this 402 example) that the LoST server needs to provide a unique mapping. 404 406 409 410 413 US 414 WA 415 Seattle 416 15th 417 Ave 418 N 419 6000 421 422 424 urn:service:sos 426 428 430 431 xmlns="urn:ietf:params:xml:ns:lost1" 432 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 433 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 435 441 Seattle 911 442 urn:service:sos 443 sip:seattle-911@example.com 444 911 446 448 ca:country ca:A1 ca:A3 ca:STS ca:RD 451 ca:POD 452 ca:HNO 454 455 456 US 457 WA 458 SEATTLE 459 15TH 460 AVE 461 NW 462 6000 463 98106 464 SEATTLE 465 467 468 US 469 WA 470 SEATTLE 471 15TH 472 AVE 473 NE 474 6000 475 98105 476 SEATTLE 477 478 480 482 483 484 486 488 490 492 7. Relax NG schema 494 This section provides the Relax NG schema of LoST extensions in the 495 compact form. The verbose form is included in a later section [to be 496 supplied in a later version of this draft]. 498 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 499 default namespace ns1 = "urn:ietf:params:xml:ns:lost-rli1" 501 ## 502 ## Extension to LoST to support returned location information 503 ## 504 start = 505 returnedLocation 507 div { 508 returnedLocationResponse = 509 element returnedLocationResponse { 510 completeLocation, similarLocation, extensionPoint 511 } 512 } 514 ## 515 ## completeLocation 516 ## 517 div { 518 completeLocation = 519 element location { 520 attribute id { xsd:token }, 521 locationInformation 522 }+ 523 } 525 ## 526 ## similarLocation 527 ## 528 div { 529 similarLocation = 530 element location { 531 attribute id { xsd:token }, 532 locationInformation 533 }+ 534 } 535 ## 536 ## Location Information 537 ## 538 div { 539 locationInformation = 540 extensionPoint+, 541 attribute profile { xsd:NMTOKEN }? 542 } 544 ## 545 ## Patterns for inclusion of elements from schemas in 546 ## other namespaces. 547 ## 548 div { 550 ## 551 ## Any element not in the LoST namespace. 552 ## 553 notLost = element * - (ns1:* | ns1:*) { anyElement } 555 ## 556 ## A wildcard pattern for including any element 557 ## from any other namespace. 558 ## 559 anyElement = 560 (element * { anyElement } 561 | attribute * { text } 562 | text)* 564 ## 565 ## A point where future extensions 566 ## (elements from other namespaces) 567 ## can be added. 568 ## 569 extensionPoint = notRLI* 570 } 572 8. Security Considerations 574 Whether the input to the LoST server is valid or invalid, the LoST 575 server ultimately determines what it considers to be valid. Even in 576 the case where the input location is valid, the requester still might 577 not actually understand where that location is. For this kind of 578 valid location use case, this described extension would typically 579 return more location information than the requester started with, 580 which might reveal more about the location. While this might be very 581 desirable in some scenarios including, for example, supporting an 582 emergency call, it might not be as desirable for other services. 583 Individual LoST server implementations SHOULD consider the risk of 584 releasing more detail verses the value in doing so. Generally, it is 585 not expected that this would be a significant problem as the 586 requester must have enough location information to be considered 587 valid, which in most cases is enough to uniquely locate the address. 588 Providing more CAtypes generally doesn't actually reveal anything 589 more. For invalid locations that are submitted, this extension would 590 allow the LoST response to include location information which is 591 similar to what was input, again resulting in more information 592 provided in the response than was known during input. LoST server 593 implementations SHOULD evaluate the particular use cases where this 594 extension is supported, and weigh the risks around its use. Many 595 similar database services available today via the Internet offer 596 similar features, such as "did you mean", and address completion, so 597 this capability is not introducing any fundamentally new threat. 599 9. IANA Considerations 601 9.1. Relax NG Schema Registration 603 URI: urn:ietf:params:xml:schema:lost-rli1 605 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 606 (br@brianrosen.net). 608 Relax NG Schema: The Relax NG schema to be registered is contained 609 in Section 7. Its first line is 611 default namespace = "urn:ietf:params:xml:ns:lost-rli1 613 and its last line is 615 } 617 9.2. LoST Namespace Registration 619 URI: urn:ietf:params:xml:ns:lost-rli1 621 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 622 (br@brianrosen.net). 624 XML: 626 BEGIN 627 628 630 631 632 634 LoST Planned Change Namespace 635 636 637

Namespace for LoST Returned Location Information extension

638

urn:ietf:params:xml:ns:lost-rli1

639

See 640 RFC????.

641 642 643 END 645 10. Acknowledgements 647 11. Changes from Previous Versions 649 11.1. Changes from draft-marshall-03 to -04 651 o Revised the text in Section 1 to better describe how this 652 extension can be useful (Bradner)- 654 o Utilized RFC2119 language in the draft rather than removing the 655 reference to it(Bradner) 657 o Added some text to explain how notification of this extension is 658 expected for those clients that are not aware of this extension 659 could be notified (Bradner) 661 o Modified security section text to include security considerations 662 for both valid and invalid addresses used as input. (Stark) 664 o Acknowledged: need for extension point RNG/detailed xml and 665 examples (Stark) 667 o Reworked terminology section and aligned with text based on 668 comments (Stark) 670 o General editorial cleanup 672 12. References 674 12.1. Normative References 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, March 1997. 679 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 680 Tschofenig, "LoST: A Location-to-Service Translation 681 Protocol", RFC 5222, August 2008. 683 12.2. Informative References 685 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 686 (DHCPv4 and DHCPv6) Option for Civic Addresses 687 Configuration Information", RFC 4776, November 2006. 689 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 690 Format for Presence Information Data Format Location 691 Object (PIDF-LO)", RFC 5139, February 2008. 693 Authors' Addresses 695 Roger Marshall 696 TeleCommunication Systems, Inc. 697 2401 Elliott Avenue 698 2nd Floor 699 Seattle, WA 98121 700 US 702 Phone: +1 206 792 2424 703 Email: rmarshall@telecomsys.com 704 URI: http://www.telecomsys.com 706 Jeff Martin 707 TeleCommunication Systems, Inc. 708 2401 Elliott Avenue 709 2nd Floor 710 Seattle, WA 98121 711 US 713 Phone: +1 206 792 2584 714 Email: jmartin@telecomsys.com 715 URI: http://www.telecomsys.com 717 Brian Rosen 718 Neustar 719 470 Conrad Dr 720 Mars, PA 16046 721 US 723 Email: br@brianrosen.net