idnits 2.17.1 draft-ietf-ecrit-similar-location-03.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 18, 2016) is 2838 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 Comtech TCS 5 Expires: January 19, 2017 B. Rosen 6 Neustar 7 July 18, 2016 9 A LoST extension to return complete and similar location info 10 draft-ietf-ecrit-similar-location-03 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 a 25 compilation of CAtype 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 19, 2017. 45 Copyright Notice 47 Copyright (c) 2016 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 . . . . . . . . . . 4 65 4. Returned Location Information . . . . . . . . . . . . . . . . 7 66 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. Complete Location returned for Valid Location response . 8 68 5.2. Similar Location returned for Invalid Location response . 10 69 6. Relax NG schema . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8.1. Relax NG Schema Registration . . . . . . . . . . . . . . 14 73 8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 15 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 9.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 The LoST protcol [RFC5222] supports the validation of civic location 82 information as input, by providing a set of validation result status 83 indicators. The current usefulness of the supported xml elements, 84 "valid", "invalid", and "unchecked", is limited, because while they 85 each provide an indication of validity for any one location element 86 as a part of the whole civic address, the mechanism is insufficient 87 in providing either the complete set of civic address elements that 88 the LoST server contains, or of providing alternate suggestions 89 (hints) as to which civic address is intended for use. 91 Whether the input civic location is valid and missing information, or 92 invalid due to missing or wrong information during input, this 93 document provides a mechanism to return a complete set of civic 94 address elements for those valid or invalid cases. 96 This enhancement to the validation feature within LoST is required by 97 systems that rely on accurate location for processing in order to 98 increase the likelihood that the correct and/or complete form of a 99 civic location becomes known in those cases where it is incomplete or 100 just plain wrong. One such use case is that of location based 101 emergency calling. The use of this protocol extension will protocol 102 extension will facilitate the correction of errors, and allow 103 location servers to be more easily provisioned with complete address 104 information. 106 The structure of this document includes terminology, Section 2, 107 followed by a discussion of the basic elements involved in location 108 validation. The use of these elements, by way of example, is 109 discussed in an overview section, Section 3, with accompanying 110 rationale, and a brief discussion of the impacts to LoST, and its 111 current schema. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 The following terms are defined in this document: 121 Location: The term Location can be used to refer to either a civic 122 location or a geodetic location. 124 Geodetic Location: a geographic coordinate set of values that 125 describes a point within a defined geographic datum. For example, 126 a WGS84 referenced lattitude, longitude coordinate pair (2D), or 127 lattitude, longitude, and altitude (3D). Note: geodetic location 128 is defined here for context, but is not used elsewhere within this 129 document. 131 Civic Location: The term civic location applies to a set of one or 132 more civic address elements that are used in conjunction with each 133 other, and in accordance with a known ruleset to to designate a 134 specific place within a region of geography, or a region of 135 geography by itself as defined in [RFC5139]. 137 Civic Address: The term Civic Address is used interchangeably with 138 the term Civic Location within this document. 140 Civic Address Element: The term Civic Address Element is used within 141 this document to apply to an individual CAtype data descriptor, 142 for example, as is described in [RFC4776], [RFC5774], and 143 [RFC6848]. 145 Invalid Location: A Civic Location that was included in a LoST 146 request and subsequently returned with one or more civic address 147 elements marked as invalid. Note that location information may be 148 submitted in the findRequest that causes the LoST server to return 149 locationInvalid. It is also possible that the location 150 information submitted is so inaccurate that this extension can not 151 be used, and the LoST server may return a notFound. In this 152 document, we use the term Invalid Location only to refer to a case 153 where the LoST server returns one or more elements in the invalid 154 list. 156 Valid Location: A Civic Location that was included in a LoST request 157 and subsequently returned with all civic address elements in the 158 valid or unchecked lists. 160 Complete Location: An expanded civic location that includes other 161 civic address elements in addition to the existing validated civic 162 address elements provided as input to a LoST server. 164 Similar Location: A suggested civic location that is comparatively 165 close to the civic location which was input, but which had one or 166 more invalid civic address elements returned by the LoST server. 168 Returned Location Information: A set of civic locations returned in 169 a LoST response. 171 3. Overview of Returned Location Information 173 This document describes an extension to LoST [RFC5222] to allow 174 additional location information to be returned in a 175 findServiceResponse where the location information in the request is 176 in a civic profile as described in RFC5222 or location in another 177 profile derived from that civic profile, for two different use cases. 179 When a LoST server is asked to validate a civic location, its goal is 180 to take the set of civic address elements provided as the location 181 information in the LoST request, and find a unique location in its 182 database that matches the information in the request. Uniqueness 183 might not require values for all possible elements in the civic 184 address that the database might hold. Further, the input location 185 information might not represent the form of location the users of the 186 LoST service prefer to have. As an example, there are LoST civic 187 address elements that could be used to define a postal location, 188 suitable for delivery of mail as well as a municipal location 189 suitable for responding to an emergency call. While the LoST server 190 might be able to determine the location from the postal elements 191 provided, the emergency services would prefer that the municipal 192 location be used for any subsequent emergency call. Since validation 193 is often performed well in advance of an end-user placing an 194 emergency call, if the LoST server could return the preferred form of 195 location (or more properly in this example, the municipal elements in 196 addition to the postal elements), those elements could be stored in a 197 LIS and used in a later emergency call. 199 In addition, this document describes the reuse of the same mechanism, 200 but for a different purpose: to supply similar location information 201 in the case where a LoST server response includes one or more civic 202 address elements marked as invalid, constituting an invalid location 203 response. In this case, the response contains one or more suggested 204 alternative, but valid locations. 206 In a LoST indicating a valid location - i.e. 207 containing a element with no elements listed as 208 invalid - the element may use this extension to 209 include additional location information. As an example, the query 210 might contain a HNO (house number), RD (road name) A3 (city), At 211 (state/province) and a few more CAtype elements, but might not 212 contain A2 (county) or PC (Postal Code) CAtypes. The HNO, RD, STS, 213 POD, A3 and A1 civic address elements might be sufficient enough to 214 the LoST server to uniquely locate the address specified in the 215 request and thus be considered valid. Yet, downstream entities might 216 find it helpful to have the additional A2 (county), and PC, (Postal 217 Code), civic address elements that are present within the LoST 218 server, be included as part of a complete location response. Since 219 [RFC5222] currently does not have a way for this additional location 220 information to be returned in the findServiceResponse, this document 221 extends the LoST protocol so that it can include a completeLocation 222 element within the findServiceResponse message, allowing for the 223 representation of complete location information. 225 An example showing complete location information supplied: 227 input address: 6000 15th Ave NW Seattle 229 complete location: 6000 15th Ave NW Seattle, WA 98105 US 231 The information provided in the request may be enough to identify a 232 unique location in the LoST server, but that may not be the location 233 intended by the user. The completedLocation information may alert 234 the user to a mismatch between the provided location information and 235 the unique location the server interpreted that information to 236 identify. 238 By contrast, when invalid location is received from the LoST server, 239 with this extension, the same mechanism works as follows: if a LoST 240 server returns a response to a findService request that contains a 241 set of civic address elements with one or more labeled as invalid, 242 the location information in the findServiceResponse is extended to 243 include additional location information that it suspects might be the 244 location desired. 246 In the example cited above, policy at the LoST server might deem a 247 missing A3 element as invalid, even if the location information in 248 the request was sufficient to identify a unique address. In that 249 case, the missing element would be listed in the invalid list, and 250 similarLocation could be returned in the response showing the missing 251 elements including A3, the same as the above example. 253 As another example of the use of similarLocation, consider the 254 results based on a similar data set as used above, where the HNO, RD, 255 STS, A1, and A3 civic address elements are not sufficient to locate a 256 unique address, which leads to an invalid location result. This is 257 the case, despite the fact that the LoST server typically contains 258 additional civic address elements which could have resulted in a 259 uniquely identifiable location if additional data had been supplied 260 with the query. Since [RFC5222] currently does not have a way for 261 this additional location information to be returned in the 262 findServiceResponse, this document extends [RFC5222] so that the LoST 263 findServiceResponse message can include one or more similarLocation 264 elements within the findServiceResponse message representing similar 265 civic locations. 267 To show this, suppose that a slightly modified address as above is 268 inserted within a Lost findService request: 270 input address: 6000 15th Ave N Seattle, WA. 272 This time we make the assumption that the address is deemed "invalid" 273 by the LoST server because there is no such thing as "15th Ave N" 274 within the LoST server's data for the city of Seattle. However, we 275 also happen to know for this example that there are two addresses 276 within the address dataset that are "similar", when all parts of the 277 address are taken as a whole. These similar addresses that could be 278 suggested to the user are as follows: 280 similar address #1: 6000 15th Ave NW Seattle, WA 98107 282 similar address #2: 6000 15th Ave NE Seattle, WA 98105 283 This extension would allow the LoST server to include the above 284 similar addresses as civicAddress elements in the response to 285 locationValidation. The next section shows examples of the LoST 286 request and response xml message fragments for the above valid and 287 invalid scenarios, returning the complete or similar addresses, 288 respectively. 290 4. Returned Location Information 292 The LoST server implementing this extension MAY include 293 completeLocation or similarLocation in the findService response. 294 completeLocation and similarLocation contain a list of civic address 295 elements identical to the elements used in the location element with 296 the "civic profile" in [RFC5222] or another profile derived from the 297 civic profile. 299 The LoST server MAY include more than one similarLocation elements in 300 the response, but SHOULD NOT return more than a few possible similar 301 locations. If there are too many possible locations, the server MAY 302 return none, or it MAY return the few it considers most likely. The 303 definition of "few" is left to the implementation of the LoST server. 304 The server is unable to know what the intended location information 305 was suppose to be; it is guessing. Therefore the correct location 306 may or may not be one of the similarLocation elements the server 307 provides, and the client cannot assume that any of them are the 308 correct one. 310 Where a LoST server contains additional location information relating 311 to that civic address, the findServiceResponse message MAY return 312 additional location information along with the original validated 313 civic address elements in order to form a complete location based on 314 local implementation policy in the completeLocation element. 315 completeLocation MUST NOT be returned in response messages where any 316 civic address elements occur in the invalid list of the response, or 317 where the set of civic address elements in the request do not 318 identify a unique location. The complete location MUST NOT contain 319 any elements that would be marked as invalid, or cause an error, if a 320 recipient of that location performs a subsequent findService request 321 using the complete location. However, if a subsequent request 322 includes the complete location, the corresponding request MAY include 323 elements in the unchecked list. 325 Clients MAY ignore the location information this extension defines in 326 the response. The information is optional to send, and optional to 327 use. In the case where the location information in the request was 328 valid, this extension does not change the validity. In the case 329 where the location information in the request is invalid, but 330 alternate location information is returned, the original location 331 remains invalid, and the LoST server does not change the mapping 332 response other than optionally including the information defined by 333 this extension. 335 completeLocation and similarLocation use the locationInformation 336 element from [RFC5222] including the profile attribute which is 337 useful if the request contains location information in a profile 338 derived from the civic profile. 340 5. Examples 342 5.1. Complete Location returned for Valid Location response 344 Based on the example input request, returned location information is 345 provided in a findServiceResponse message when the original input 346 address is considered valid, but is missing some additional data that 347 the LoST server has. 349 351 354 355 358 US 359 WA 360 Seattle 361 15th 362 Ave 363 NW 364 6000 366 367 369 urn:service:sos 371 373 374 375 xmlns="urn:ietf:params:xml:ns:lost1" 376 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 377 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 379 385 Seattle 911 386 urn:service:sos 387 sip:seattle-911@example.com 388 911 390 392 ca:country ca:A1 ca:A3 ca:RD ca:STS ca:POD ca:HNO< 395 /valid> 396 397 399 400 401 US 402 WA 403 KING 404 SEATTLE 405 15TH 406 AVE 407 NW 408 6000 409 98106 410 SEATTLE 411 413 415 417 418 419 421 423 425 427 5.2. Similar Location returned for Invalid Location response 429 The following example shows returned location information provided in 430 a findServiceResponse message when the original input address is 431 considered invalid, because of the unmatchable POD data (in this 432 example) that the LoST server needs to provide a unique mapping. 434 436 439 440 443 US 444 WA 445 Seattle 446 15th 447 Ave 448 N 449 6000 451 452 454 urn:service:sos 456 458 460 461 xmlns="urn:ietf:params:xml:ns:lost1" 462 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 463 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 464 470 Seattle 911 471 urn:service:sos 472 sip:seattle-911@example.com 473 911 475 477 ca:country ca:A1 ca:A3 ca:STS ca:RD 480 ca:POD 481 ca:HNO 483 484 485 US 486 WA 487 KING 488 SEATTLE 489 15TH 490 AVE 491 NW 492 6000 493 98106 494 SEATTLE 495 497 498 US 499 WA 500 KING 501 SEATTLE 502 15TH 503 AVE 504 NE 505 6000 506 98105 507 SEATTLE 508 509 511 512 513 514 516 518 520 522 6. Relax NG schema 524 This section provides the Relax NG schema of LoST extensions in the 525 compact form. The verbose form is included in a later section [to be 526 supplied in a later version of this draft]. 528 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 529 default namespace ns1 = "urn:ietf:params:xml:ns:lost-rli1" 530 namespace local="" 532 ## 533 ## Extension to LoST to support returned location information 534 ## 535 start = 536 returnedLocation 538 div { 539 returnedLocationResponse = 540 element returnedLocationResponse { 541 completeLocation, similarLocation, extensionPoint 542 } 543 } 545 ## 546 ## completeLocation 547 ## 548 div { 549 completeLocation = 550 element completedlocation { 551 locationInformation 552 }+ 553 } 555 ## 556 ## similarLocation 557 ## 558 div { 559 similarLocation = 560 element similarLocation { 561 locationInformation 562 }+ 563 } 564 ## 565 ## Location Information 566 ## 567 div { 568 locationInformation = 569 extensionPoint+, 570 attribute profile { xsd:NMTOKEN }? 571 } 573 ## 574 ## Patterns for inclusion of elements from schemas in 575 ## other namespaces. 576 ## 577 div { 579 ## 580 ## Any element not in the LoST-RLI namespace. 581 ## 582 notRLI = element * - (ns1:* | local:*) { anyElement } 584 ## 585 ## A wildcard pattern for including any element 586 ## from any other namespace. 587 ## 588 anyElement = 589 (element * { anyElement } 590 | attribute * { text } 591 | text)* 593 ## 594 ## A point where future extensions 595 ## (elements from other namespaces) 596 ## can be added. 597 ## 598 extensionPoint = notRLI* 599 } 601 7. Security Considerations 603 Whether the input to the LoST server is valid or invalid, the LoST 604 server ultimately determines what it considers to be valid. Even in 605 the case where the input location is valid, the requester still might 606 not actually understand where that location is. For this kind of 607 valid location use case, this described extension would typically 608 return more location information than the requester started with, 609 which might reveal more about the location. While this might be very 610 desirable in some scenarios including, for example, supporting an 611 emergency call, it might not be as desirable for other services. 612 Individual LoST server implementations SHOULD consider the risk of 613 releasing more detail verses the value in doing so. Generally, it is 614 not expected that this would be a significant problem as the 615 requester must have enough location information to be considered 616 valid, which in most cases is enough to uniquely locate the address. 617 Providing more CAtypes generally doesn't actually reveal anything 618 more. For invalid locations that are submitted, this extension would 619 allow the LoST response to include location information which is 620 similar to what was input, again resulting in more information 621 provided in the response than was known during input. LoST server 622 implementations SHOULD evaluate the particular use cases where this 623 extension is supported, and weigh the risks around its use. Many 624 similar database services available today via the Internet offer 625 similar features, such as "did you mean", and address completion, so 626 this capability is not introducing any fundamentally new threat. 628 8. IANA Considerations 630 8.1. Relax NG Schema Registration 632 URI: urn:ietf:params:xml:schema:lost-rli1 634 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 635 (br@brianrosen.net). 637 Relax NG Schema: The Relax NG schema to be registered is contained 638 in Section 7. Its first line is 640 default namespace = "urn:ietf:params:xml:ns:lost-rli1 642 and its last line is 644 } 646 8.2. LoST-RLI Namespace Registration 648 URI: urn:ietf:params:xml:ns:lost-rli1 650 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 651 (br@brianrosen.net). 653 XML: 655 BEGIN 656 657 659 660 661 663 LoST Returned Location Information Namespace 664 665 666

Namespace for LoST Returned Location Information extension

667

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

668

See 669 RFC????.

670 671 672 END 674 9. References 676 9.1. Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, 680 DOI 10.17487/RFC2119, March 1997, 681 . 683 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 684 Tschofenig, "LoST: A Location-to-Service Translation 685 Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, 686 . 688 9.2. Informative References 690 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 691 (DHCPv4 and DHCPv6) Option for Civic Addresses 692 Configuration Information", RFC 4776, 693 DOI 10.17487/RFC4776, November 2006, 694 . 696 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 697 Format for Presence Information Data Format Location 698 Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, 699 February 2008, . 701 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 702 Addresses in the Presence Information Data Format Location 703 Object (PIDF-LO): Guidelines and IANA Registry 704 Definition", BCP 154, RFC 5774, DOI 10.17487/RFC5774, 705 March 2010, . 707 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 708 R. George, "Specifying Civic Address Extensions in the 709 Presence Information Data Format Location Object (PIDF- 710 LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013, 711 . 713 Authors' Addresses 715 Roger Marshall 716 Comtech TCS 717 2401 Elliott Avenue 718 2nd Floor 719 Seattle, WA 98121 720 US 722 Email: rmarshall@comtechtel.com 724 Jeff Martin 725 Comtech TCS 726 2401 Elliott Avenue 727 2nd Floor 728 Seattle, WA 98121 729 US 731 Email: jmartin@comtechtel.com 732 Brian Rosen 733 Neustar 734 470 Conrad Dr 735 Mars, PA 16046 736 US 738 Email: br@brianrosen.net