idnits 2.17.1 draft-ietf-ecrit-similar-location-05.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 20 characters in excess of 72. ** 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 (March 5, 2018) is 2241 days in the past. Is this intentional? 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Marshall 3 Internet-Draft J. Martin 4 Intended status: Standards Track Comtech TCS 5 Expires: September 6, 2018 B. Rosen 6 Neustar 7 March 5, 2018 9 A LoST extension to return complete and similar location info 10 draft-ietf-ecrit-similar-location-05 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 https://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 September 6, 2018. 45 Copyright Notice 47 Copyright (c) 2018 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 (https://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. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8.1. XML Schema Registration . . . . . . . . . . . . . . . . . 14 73 8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 14 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 9.2. Informative References . . . . . . . . . . . . . . . . . 15 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 incorrect. One such use case is that of location based emergency 101 calling. The use of this protocol extension will protocol extension 102 will facilitate the correction of errors, and allow location servers 103 to be more easily provisioned with complete address information. 105 The structure of this document includes terminology, Section 2, 106 followed by a discussion of the basic elements involved in location 107 validation. The use of these elements, by way of example, is 108 discussed in an overview section, Section 3, with accompanying 109 rationale, and a brief discussion of the impacts to LoST, and its 110 current schema. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 The following terms are defined in this document: 120 Location: The term Location can be used to refer to either a civic 121 location or a geodetic location. 123 Geodetic Location: a geographic coordinate set of values that 124 describes a point within a defined geographic datum. For example, 125 a WGS84 referenced latitude, longitude coordinate pair (2D), or 126 latitude, longitude, and altitude (3D). Note: geodetic location 127 is defined here for context, but is not used elsewhere within this 128 document. 130 Civic Location: The term civic location applies to a set of one or 131 more civic address elements that are used in conjunction with each 132 other, and in accordance with a known ruleset to designate a 133 specific place within a region of geography, or a region of 134 geography by itself as defined in [RFC5139]. 136 Civic Address: The term Civic Address is used interchangeably with 137 the term Civic Location within this document. 139 Civic Address Element: The term Civic Address Element is used within 140 this document to apply to an individual CAtype data descriptor, 141 for example, as is described in [RFC4776], [RFC5774], and 142 [RFC6848]. 144 Invalid Location: A Civic Location that was included in a LoST 145 request and subsequently returned with one or more civic address 146 elements marked as invalid. Note that location information may be 147 submitted in the findRequest that causes the LoST server to return 148 locationInvalid. It is also possible that the location 149 information submitted is so inaccurate that this extension can not 150 be used, and the LoST server may return a notFound. In this 151 document, we use the term Invalid Location only to refer to a case 152 where the LoST server returns one or more elements in the invalid 153 list. 155 Valid Location: A Civic Location that was included in a LoST request 156 and subsequently returned with all civic address elements in the 157 valid or unchecked lists. 159 Complete Location: An expanded civic location that includes other 160 civic address elements in addition to the existing validated civic 161 address elements provided as input to a LoST server. 163 Similar Location: A suggested civic location that is comparatively 164 close to the civic location which was input, but which had one or 165 more invalid civic address elements returned by the LoST server. 167 Returned Location Information: A set of civic locations returned in 168 a LoST response. 170 3. Overview of Returned Location Information 172 This document describes an extension to LoST [RFC5222] to allow 173 additional location information to be returned in a 174 findServiceResponse where the location information in the request is 175 in a civic profile as described in RFC5222 or location in another 176 profile derived from that civic profile, for two different use cases. 178 When a LoST server is asked to validate a civic location, its goal is 179 to take the set of civic address elements provided as the location 180 information in the LoST request, and find a unique location in its 181 database that matches the information in the request. Uniqueness 182 might not require values for all possible elements in the civic 183 address that the database might hold. Further, the input location 184 information might not represent the form of location the users of the 185 LoST service prefer to have. As an example, there are LoST civic 186 address elements that could be used to define a postal location, 187 suitable for delivery of mail as well as a municipal location 188 suitable for responding to an emergency call. While the LoST server 189 might be able to determine the location from the postal elements 190 provided, the emergency services would prefer that the municipal 191 location be used for any subsequent emergency call. Since validation 192 is often performed well in advance of an end-user placing an 193 emergency call, if the LoST server could return the preferred form of 194 location (or more properly in this example, the municipal elements in 195 addition to the postal elements), those elements could be stored in a 196 LIS and used in a later emergency call. 198 In addition, this document describes the reuse of the same mechanism, 199 but for a different purpose: to supply similar location information 200 in the case where a LoST server response includes one or more civic 201 address elements marked as invalid, constituting an invalid location 202 response. In this case, the response contains one or more suggested 203 alternative, but valid locations. 205 In a LoST indicating a valid location - i.e. 206 containing a element with no elements listed as 207 invalid - the element may use this extension to 208 include additional location information. As an example, the query 209 might contain a HNO (house number), RD (road name) A3 (city), At 210 (state/province) and a few more CAtype elements, but might not 211 contain A2 (county) or PC (Postal Code) CAtypes. The HNO, RD, STS, 212 POD, A3 and A1 civic address elements might be sufficient enough to 213 the LoST server to uniquely locate the address specified in the 214 request and thus be considered valid. Yet, downstream entities might 215 find it helpful to have the additional A2 (county), and PC, (Postal 216 Code), civic address elements that are present within the LoST 217 server, be included as part of a complete location response. Since 218 [RFC5222] currently does not have a way for this additional location 219 information to be returned in the findServiceResponse, this document 220 extends the LoST protocol so that it can include a completeLocation 221 element within the findServiceResponse message, allowing for the 222 representation of complete location information. 224 An example showing complete location information supplied: 226 input address: 6000 15th Ave NW Seattle 228 complete location: 6000 15th Ave NW Seattle, WA 98105 US 230 The information provided in the request may be enough to identify a 231 unique location in the LoST server, but that may not be the location 232 intended by the user. The completeLocation information may alert the 233 user to a mismatch between the provided location information and the 234 unique location the server interpreted that information to identify. 236 By contrast, when invalid location is received from the LoST server, 237 with this extension, the same mechanism works as follows: if a LoST 238 server returns a response to a findService request that contains a 239 set of civic address elements with one or more labeled as invalid, 240 the location information in the findServiceResponse is extended to 241 include additional location information that it suspects might be the 242 location desired. 244 In the example cited above, policy at the LoST server might deem a 245 missing A3 element as invalid, even if the location information in 246 the request was sufficient to identify a unique address. In that 247 case, the missing element would be listed in the invalid list, and 248 similarLocation could be returned in the response showing the missing 249 elements including A3, the same as the above example. 251 As another example of the use of similarLocation, consider the 252 results based on a similar data set as used above, where the HNO, RD, 253 STS, A1, and A3 civic address elements are not sufficient to locate a 254 unique address, which leads to an invalid location result. This is 255 the case, despite the fact that the LoST server typically contains 256 additional civic address elements which could have resulted in a 257 uniquely identifiable location if additional data had been supplied 258 with the query. Since [RFC5222] currently does not have a way for 259 this additional location information to be returned in the 260 findServiceResponse, this document extends [RFC5222] so that the LoST 261 findServiceResponse message can include one or more similarLocation 262 elements within the findServiceResponse message representing similar 263 civic locations. 265 To show this, suppose that a slightly modified address as above is 266 inserted within a Lost findService request: 268 input address: 6000 15th Ave N Seattle, WA. 270 This time we make the assumption that the address is deemed "invalid" 271 by the LoST server because there is no such thing as "15th Ave N" 272 within the LoST server's data for the city of Seattle. However, we 273 also happen to know for this example that there are two addresses 274 within the address dataset that are "similar", when all parts of the 275 address are taken as a whole. These similar addresses that could be 276 suggested to the user are as follows: 278 similar address #1: 6000 15th Ave NW Seattle, WA 98107 280 similar address #2: 6000 15th Ave NE Seattle, WA 98105 282 This extension would allow the LoST server to include the above 283 similar addresses as civicAddress elements in the response to 284 locationValidation. The next section shows examples of the LoST 285 request and response xml message fragments for the above valid and 286 invalid scenarios, returning the complete or similar addresses, 287 respectively. 289 4. Returned Location Information 291 The LoST server implementing this extension MAY include 292 completeLocation or similarLocation in the findService response. 293 completeLocation and similarLocation contain a list of civic address 294 elements identical to the elements used in the location element with 295 the "civic profile" in [RFC5222] or another profile derived from the 296 civic profile. 298 The LoST server MAY include more than one similarLocation elements in 299 the response, but SHOULD NOT return more than a few possible similar 300 locations. If there are too many possible locations, the server MAY 301 return none, or it MAY return the few it considers most likely. The 302 definition of "few" is left to the implementation of the LoST server. 303 The server is unable to know what the intended location information 304 was suppose to be; it is guessing. Therefore the correct location 305 may or may not be one of the similarLocation elements the server 306 provides, and the client cannot assume that any of them are the 307 correct one. 309 Where a LoST server contains additional location information relating 310 to that civic address, the findServiceResponse message MAY return 311 additional location information along with the original validated 312 civic address elements in order to form a complete location based on 313 local implementation policy in the completeLocation element. 314 completeLocation MUST NOT be returned in response messages where any 315 civic address elements occur in the invalid list of the response, or 316 where the set of civic address elements in the request do not 317 identify a unique location. The complete location MUST NOT contain 318 any elements that would be marked as invalid, or cause an error, if a 319 recipient of that location performs a subsequent findService request 320 using the complete location. However, if a subsequent request 321 includes the complete location, the corresponding request MAY include 322 elements in the unchecked list. 324 Clients can control the return of additional location information by 325 including an optional element with 326 possible values "none", "similar", "complete" or "any". Where "none" 327 means to not return additional location information, "similar" and 328 "complete" mean to only return the respective type of additional 329 location information (if the server could send any) and "any" means 330 to include similar and/or complete location (if the server could send 331 any). If the request includes this option, the server MUST NOT send 332 location information contravening the client's request. Not 333 including this option in the request is equivalent to "any". 335 The server may determine that there are many possible similar 336 locations and decide not to send them all. The number of similar 337 locations sent is entirely up to the server, but MUST be less than 338 10. The server MAY include a element which 339 contains a non-zero integer of the number of similar locations not 340 included in the response. The server is NOT obligated to make this 341 number accurate, in that there may be more than the indicated similar 342 locations available in the data held by the server. 344 Clients MAY ignore the location information this extension defines in 345 the response. The information is optional to send, and optional to 346 use. In the case where the location information in the request was 347 valid, this extension does not change the validity. In the case 348 where the location information in the request is invalid, but 349 alternate location information is returned, the original location 350 remains invalid, and the LoST server does not change the mapping 351 response other than optionally including the information defined by 352 this extension. 354 completeLocation and similarLocation use the locationInformation 355 element from [RFC5222] including the profile attribute which is 356 useful if the request contains location information in a profile 357 derived from the civic profile. 359 5. Examples 361 5.1. Complete Location returned for Valid Location response 363 Based on the example input request, returned location information is 364 provided in a findServiceResponse message when the original input 365 address is considered valid, but is missing some additional data that 366 the LoST server has. 368 370 373 374 377 US 378 WA 379 Seattle 380 15th 381 Ave 382 NW 383 6000 385 386 388 urn:service:sos 390 392 394 395 xmlns="urn:ietf:params:xml:ns:lost1" 396 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 397 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 399 405 Seattle 911 406 urn:service:sos 407 sip:seattle-911@example.com 408 911 410 412 ca:country ca:A1 ca:A3 ca:RD ca:STS ca:POD ca:HNO< 415 /valid> 416 417 419 420 421 US 422 WA 423 KING COUNTY 424 SEATTLE 425 15TH 426 AVENUE 427 NORTHWEST 428 6000 429 98106 430 SEATTLE 431 433 435 437 438 439 441 443 445 447 5.2. Similar Location returned for Invalid Location response 449 The following example shows returned location information provided in 450 a findServiceResponse message when the original input address is 451 considered invalid, because of the unmatchable POD data (in this 452 example) that the LoST server needs to provide a unique mapping. 454 456 459 460 463 US 464 WA 465 Seattle 466 15th 467 Ave 468 N 469 6000 471 472 474 urn:service:sos 476 478 480 481 xmlns="urn:ietf:params:xml:ns:lost1" 482 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 483 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 485 491 Seattle 911 492 urn:service:sos 493 sip:seattle-911@example.com 494 911 496 498 ca:country ca:A1 ca:A3 ca:STS ca:RD 501 ca:POD 502 ca:HNO 504 505 506 US 507 WA 508 KING COUNTY 509 SEATTLE 510 15TH 511 AVENUE 512 NORTHWEST 513 6000 514 98106 515 SEATTLE 516 517 518 519 520 US 521 WA 522 KING COUNTY 523 SEATTLE 524 15TH 525 AVENUE 526 NORTHEAST 527 6000 528 98105 529 SEATTLE 530 531 533 535 536 537 539 541 543 545 6. XML Schema 547 This section provides the schema of LoST extensions based on the 548 schema in draft-ietf-lost-planned-changes" /> 550 551 555 556 557 558 559 560 561 562 563 564 565 566 567 568 570 571 572 573 574 575 576 577 579 580 582 583 584 585 587 588 589 591 7. Security Considerations 593 Whether the input to the LoST server is valid or invalid, the LoST 594 server ultimately determines what it considers to be valid. Even in 595 the case where the input location is valid, the requester still might 596 not actually understand where that location is. For this kind of 597 valid location use case, this described extension would typically 598 return more location information than the requester started with, 599 which might reveal more about the location. While this might be very 600 desirable in some scenarios including, for example, supporting an 601 emergency call, it might not be as desirable for other services. 602 Individual LoST server implementations SHOULD consider the risk of 603 releasing more detail versus the value in doing so. Generally, it is 604 not expected that this would be a significant problem as the 605 requester must have enough location information to be considered 606 valid, which in most cases is enough to uniquely locate the address. 607 Providing more CAtypes generally doesn't actually reveal anything 608 more. For invalid locations that are submitted, this extension would 609 allow the LoST response to include location information which is 610 similar to what was input, again resulting in more information 611 provided in the response than was known during input. LoST server 612 implementations SHOULD evaluate the particular use cases where this 613 extension is supported, and weigh the risks around its use. Many 614 similar database services available today via the Internet offer 615 similar features, such as "did you mean", and address completion, so 616 this capability is not introducing any fundamentally new threat. 618 8. IANA Considerations 620 8.1. XML Schema Registration 622 URI: urn:ietf:params:xml:schema:lost-rli1 624 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 625 (br@brianrosen.net). 627 XML Schema: The XML schema to be registered is contained 628 in Section 7. 630 8.2. LoST-RLI Namespace Registration 631 URI: urn:ietf:params:xml:ns:lost-rli1 633 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 634 (br@brianrosen.net). 636 XML: 638 BEGIN 639 640 642 643 644 646 LoST Returned Location Information Namespace 647 648 649

Namespace for LoST Returned Location Information extension

650

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

651

See 652 RFC????.

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