idnits 2.17.1 draft-ietf-ecrit-similar-location-06.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 is 1 instance of too long lines in the document, the longest one being 4 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 (October 23, 2018) is 2012 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) == Outdated reference: A later version (-09) exists of draft-ietf-ecrit-lost-planned-changes-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: April 26, 2019 B. Rosen 6 Neustar 7 October 23, 2018 9 A LoST extension to return complete and similar location info 10 draft-ietf-ecrit-similar-location-06 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 April 26, 2019. 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 . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 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 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 locationValidation 174 element of a findServiceResponse, where the location information in 175 the request is in a civic profile as described in RFC5222 or location 176 in another profile derived from that civic profile, for two different 177 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 findServiceResponse indicating a valid location - i.e. 207 containing a locationValidation element with no elements listed as 208 invalid - the locationValidation 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 locationValidation element of the 223 findServiceResponse message, allowing for the representation of 224 complete location information. 226 An example showing complete location information supplied: 228 input address: 6000 15th Ave NW Seattle 230 complete location: 6000 15th Ave NW Seattle, WA 98105 US 232 The information provided in the request may be enough to identify a 233 unique location in the LoST server, but that may not be the location 234 intended by the user. The completeLocation information may alert the 235 user to a mismatch between the provided location information and the 236 unique location the server interpreted that information to 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 locationValidation element of the findServiceResponse message can 264 include one or more similarLocation elements 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 284 This extension would allow the LoST server to include the above 285 similar addresses as civicAddress elements in the response to 286 locationValidation. The next section shows examples of the LoST 287 request and response xml message fragments for the above valid and 288 invalid scenarios, returning the complete or similar addresses, 289 respectively. 291 4. Returned Location Information 293 The LoST server implementing this extension MAY include 294 completeLocation or similarLocation within the locationValidation 295 portion of the findService response. completeLocation and 296 similarLocation contain a list of civic address elements identical to 297 the elements used in the location element with the "civic profile" in 298 [RFC5222] or another profile derived from the civic profile. 300 The LoST server MAY include more than one similarLocation elements in 301 the response. If there are too many possible locations, the server 302 MAY return none, or it MAY return the few it considers most likely. 303 The definition of "few" is left to the implementation of the LoST 304 server. The server is unable to know what the intended location 305 information was suppose to be; it is guessing. Therefore the correct 306 location may or may not be one of the similarLocation elements the 307 server provides, and the client cannot assume that any of them are 308 the 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. The 315 completeLocation element MUST NOT be returned in response messages 316 where any civic address elements occur in the invalid list of the 317 response, or where the set of civic address elements in the request 318 do not identify a unique location. The complete location MUST NOT 319 contain any elements that would be marked as invalid, or cause an 320 error, if a recipient of that location performs a subsequent 321 findService request using the complete location. However, if a 322 subsequent request includes the complete location, the corresponding 323 request MAY include elements in the unchecked list. 325 Clients can control the return of additional location information by 326 including an optional returnAdditionalLocation attribute with 327 possible values "none", "similar", "complete" or "any". Where "none" 328 means to not return additional location information, "similar" and 329 "complete" mean to only return the respective type of additional 330 location information (if the server could send any) and "any" means 331 to include similar and/or complete location (if the server could send 332 any). If the request includes this option, the server MUST NOT send 333 location information contravening the client's request. Not 334 including this option in the request is equivalent to "none". 336 The server may determine that there are many possible similar 337 locations and decide not to send them all. The number of similar 338 locations sent is entirely up to the server. The server MAY include 339 a similarLocationsLimited attribute which contains a non-zero integer 340 of the number of similar locations not included in the response. The 341 server is NOT obligated to make this number accurate, in that there 342 may be more than the indicated similar locations available in the 343 data held by the server. 345 Clients MAY ignore the location information this extension defines in 346 the response. The information is optional to send, and optional to 347 use. In the case where the location information in the request was 348 valid, this extension does not change the validity. In the case 349 where the location information in the request is invalid, but 350 alternate location information is returned, the original location 351 remains invalid, and the LoST server does not change the mapping 352 response other than optionally including the information defined by 353 this extension. 355 completeLocation and similarLocation use the locationInformation 356 element from [RFC5222] updated by 357 [I-D.ietf-ecrit-lost-planned-changes] including the profile attribute 358 which is useful if the request contains location information in a 359 profile derived from the civic profile. The profile attribute MUST 360 be included in both the request and the response and MUST be the same 361 profile in both. 363 5. Examples 365 5.1. Complete Location returned for Valid Location response 367 Based on the example input request, returned location information is 368 provided in a findServiceResponse message when the original input 369 address is considered valid, but is missing some additional data that 370 the LoST server has. 372 374 377 378 381 US 382 WA 383 Seattle 384 15th 385 Ave 386 NW 387 6000 389 390 392 urn:service:sos 394 396 398 399 xmlns="urn:ietf:params:xml:ns:lost1" 400 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 401 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 403 409 Seattle 911 410 urn:service:sos 411 sip:seattle-911@example.com 412 911 414 416 ca:country ca:A1 ca:A3 ca:RD ca:STS ca:POD ca:HNO< 419 /valid> 420 421 423 profile="civic" 424 425 US 426 WA 427 KING COUNTY 428 SEATTLE 429 15TH 430 AVENUE 431 NORTHWEST 432 6000 433 98106 434 SEATTLE 435 437 439 441 442 443 445 447 449 451 5.2. Similar Location returned for Invalid Location response 453 The following example shows returned location information provided in 454 a findServiceResponse message when the original input address is 455 considered invalid, because of the unmatchable POD data (in this 456 example) that the LoST server needs to provide a unique mapping. 458 460 463 465 467 US 468 WA 469 KING COUNTY 470 SEATTLE 471 15TH 472 AVENUE 473 6000 474 98106 475 SEATTLE 477 478 480 urn:service:sos 482 484 486 487 xmlns="urn:ietf:params:xml:ns:lost1" 488 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 489 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 491 497 Seattle 911 498 urn:service:sos 499 sip:seattle-911@example.com 500 911 502 504 ca:country ca:A1 ca:A3 ca:STS ca:RD 507 ca:POD 508 ca:HNO 510 511 512 US 513 WA 514 KING COUNTY 515 SEATTLE 516 15TH 517 AVENUE 518 NORTHWEST 519 6000 520 98106 521 SEATTLE 522 523 524 525 526 US 527 WA 528 KING COUNTY 529 SEATTLE 530 15TH 531 AVENUE 532 NORTHEAST 533 6000 534 98105 535 SEATTLE 536 537 539 541 542 543 545 547 549 551 6. XML Schema 553 This section provides the schema of LoST extensions based on the 554 schema in [I-D.ietf-ecrit-lost-planned-changes] 555 556 560 561 562 565 566 567 568 569 570 571 572 573 574 576 578 579 580 581 582 583 584 585 587 588 590 591 592 593 595 596 597 599 7. Security Considerations 601 Whether the input to the LoST server is valid or invalid, the LoST 602 server ultimately determines what it considers to be valid. Even in 603 the case where the input location is valid, the requester still might 604 not actually understand where that location is. For this kind of 605 valid location use case, this described extension would typically 606 return more location information than the requester started with, 607 which might reveal more about the location. While this might be very 608 desirable in some scenarios including, for example, supporting an 609 emergency call, it might not be as desirable for other services. 610 Individual LoST server implementations SHOULD consider the risk of 611 releasing more detail versus the value in doing so. Generally, it is 612 not expected that this would be a significant problem as the 613 requester must have enough location information to be considered 614 valid, which in most cases is enough to uniquely locate the address. 615 Providing more CAtypes generally doesn't actually reveal anything 616 more. For invalid locations that are submitted, this extension would 617 allow the LoST response to include location information which is 618 similar to what was input, again resulting in more information 619 provided in the response than was known during input. LoST server 620 implementations SHOULD evaluate the particular use cases where this 621 extension is supported, and weigh the risks around its use. Many 622 similar database services available today via the Internet offer 623 similar features, such as "did you mean", and address completion, so 624 this capability is not introducing any fundamentally new threat. 626 8. IANA Considerations 628 8.1. XML Schema Registration 630 URI: urn:ietf:params:xml:schema:lost-rli1 632 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 633 (br@brianrosen.net). 635 XML Schema: The XML schema to be registered is contained 636 in Section 7. 638 8.2. LoST-RLI Namespace Registration 639 URI: urn:ietf:params:xml:ns:lost-rli1 641 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 642 (br@brianrosen.net). 644 XML: 646 BEGIN 647 648 650 651 652 654 LoST Returned Location Information Namespace 655 656 657

Namespace for LoST Returned Location Information extension

658

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

659

See 660 RFC????.

661 662 663 END 665 9. References 667 9.1. Normative References 669 [I-D.ietf-ecrit-lost-planned-changes] 670 Rosen, B., "Validation of Locations Around a Planned 671 Change", draft-ietf-ecrit-lost-planned-changes-01 (work in 672 progress), March 2018. 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, 676 DOI 10.17487/RFC2119, March 1997, 677 . 679 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 680 Tschofenig, "LoST: A Location-to-Service Translation 681 Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, 682 . 684 9.2. Informative References 686 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 687 (DHCPv4 and DHCPv6) Option for Civic Addresses 688 Configuration Information", RFC 4776, 689 DOI 10.17487/RFC4776, November 2006, 690 . 692 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 693 Format for Presence Information Data Format Location 694 Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, 695 February 2008, . 697 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 698 Addresses in the Presence Information Data Format Location 699 Object (PIDF-LO): Guidelines and IANA Registry 700 Definition", BCP 154, RFC 5774, DOI 10.17487/RFC5774, 701 March 2010, . 703 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 704 R. George, "Specifying Civic Address Extensions in the 705 Presence Information Data Format Location Object (PIDF- 706 LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013, 707 . 709 Authors' Addresses 711 Roger Marshall 712 Comtech TCS 713 2401 Elliott Avenue 714 2nd Floor 715 Seattle, WA 98121 716 US 718 Email: rmarshall@comtechtel.com 720 Jeff Martin 721 Comtech TCS 722 2401 Elliott Avenue 723 2nd Floor 724 Seattle, WA 98121 725 US 727 Email: jmartin@comtechtel.com 728 Brian Rosen 729 Neustar 730 470 Conrad Dr 731 Mars, PA 16046 732 US 734 Email: br@brianrosen.net