idnits 2.17.1 draft-ietf-ecrit-similar-location-08.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 22, 2019) is 1740 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-03 Summary: 1 error (**), 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: January 23, 2020 B. Rosen 6 July 22, 2019 8 A LoST extension to return complete and similar location info 9 draft-ietf-ecrit-similar-location-08 11 Abstract 13 This document introduces a new way to provide returned location 14 information in LoST responses that is either of a completed or 15 similar form to the original input civic location, based on whether 16 valid or invalid civic address elements are returned within the 17 findServiceResponse message. This document defines a new extension 18 to the findServiceResponse message within the LoST protocol [RFC5222] 19 that enables the LoST protocol to return a completed civic address 20 element set for a valid location response, and one or more suggested 21 sets of similar location information for invalid LoST responses. 22 These two types of civic addresses are referred to as either 23 "complete location" or "similar location", and are included as a 24 compilation of CAtype xml elements within the existing LoST 25 findServiceResponse message structure. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 23, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Overview of Returned Location Information . . . . . . . . . . 4 64 4. Returned Location Information . . . . . . . . . . . . . . . . 7 65 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Complete Location returned for Valid Location response . 8 67 5.2. Similar Location returned for Invalid Location response . 10 68 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 8.1. XML Schema Registration . . . . . . . . . . . . . . . . . 14 72 8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 14 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 75 9.2. Informative References . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 The LoST protcol [RFC5222] supports the validation of civic location 81 information as input, by providing a set of validation result status 82 indicators. The current usefulness of the supported xml elements, 83 "valid", "invalid", and "unchecked", is limited, because while they 84 each provide an indication of validity for any one location element 85 as a part of the whole civic address, the mechanism is insufficient 86 in providing either the complete set of civic address elements that 87 the LoST server contains, or of providing alternate suggestions 88 (hints) as to which civic address is intended for use. 90 Whether the input civic location is valid and missing information, or 91 invalid due to missing or wrong information during input, this 92 document provides a mechanism to return a complete set of civic 93 address elements for those valid or invalid cases. 95 This enhancement to the validation feature within LoST is required by 96 systems that rely on accurate location for processing in order to 97 increase the likelihood that the correct and/or complete form of a 98 civic location becomes known in those cases where it is incomplete or 99 incorrect. One such use case is that of location based emergency 100 calling. The use of this protocol extension will protocol extension 101 will facilitate the correction of errors, and allow location servers 102 to be more easily provisioned with complete address information. 104 The structure of this document includes terminology, Section 2, 105 followed by a discussion of the basic elements involved in location 106 validation. The use of these elements, by way of example, is 107 discussed in an overview section, Section 3, with accompanying 108 rationale, and a brief discussion of the impacts to LoST, and its 109 current schema. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 The following terms are defined in this document: 119 Location: The term Location can be used to refer to either a civic 120 location or a geodetic location. 122 Geodetic Location: a geographic coordinate set of values that 123 describes a point within a defined geographic datum. For example, 124 a WGS84 referenced latitude, longitude coordinate pair (2D), or 125 latitude, longitude, and altitude (3D). Note: geodetic location 126 is defined here for context, but is not used elsewhere within this 127 document. 129 Civic Location: The term civic location applies to a set of one or 130 more civic address elements that are used in conjunction with each 131 other, and in accordance with a known ruleset to designate a 132 specific place within a region of geography, or a region of 133 geography by itself as defined in [RFC5139]. 135 Civic Address: The term Civic Address is used interchangeably with 136 the term Civic Location within this document. 138 Civic Address Element: The term Civic Address Element is used within 139 this document to apply to an individual CAtype data descriptor, 140 for example, as is described in [RFC4776], [RFC5774], and 141 [RFC6848]. 143 Invalid Location: A Civic Location that was included in a LoST 144 request and subsequently returned with one or more civic address 145 elements marked as invalid. Note that location information may be 146 submitted in the findRequest that causes the LoST server to return 147 locationInvalid. It is also possible that the location 148 information submitted is so inaccurate that this extension can not 149 be used, and the LoST server may return a notFound. In this 150 document, we use the term Invalid Location only to refer to a case 151 where the LoST server returns one or more elements in the invalid 152 list. 154 Valid Location: A Civic Location that was included in a LoST request 155 and subsequently returned with all civic address elements in the 156 valid or unchecked lists. 158 Complete Location: An expanded civic location that includes other 159 civic address elements in addition to the existing validated civic 160 address elements provided as input to a LoST server. 162 Similar Location: A suggested civic location that is comparatively 163 close to the civic location which was input, but which had one or 164 more invalid civic address elements returned by the LoST server. 166 Returned Location Information: A set of civic locations returned in 167 a LoST response. 169 3. Overview of Returned Location Information 171 This document describes an extension to LoST [RFC5222] to allow 172 additional location information to be returned in locationValidation 173 element of a findServiceResponse, where the location information in 174 the request is in a civic profile as described in RFC5222 or location 175 in another profile derived from that civic profile, for two different 176 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 findServiceResponse indicating a valid location - i.e. 206 containing a locationValidation element with no elements listed as 207 invalid - the locationValidation 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 locationValidation element of the 222 findServiceResponse message, allowing for the representation of 223 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 completeLocation information may alert the 234 user to a mismatch between the provided location information and the 235 unique location the server interpreted that information to identify. 237 By contrast, when invalid location is received from the LoST server, 238 with this extension, the same mechanism works as follows: if a LoST 239 server returns a response to a findService request that contains a 240 set of civic address elements with one or more labeled as invalid, 241 the location information in the findServiceResponse is extended to 242 include additional location information that it suspects might be the 243 location desired. 245 In the example cited above, policy at the LoST server might deem a 246 missing A3 element as invalid, even if the location information in 247 the request was sufficient to identify a unique address. In that 248 case, the missing element would be listed in the invalid list, and 249 similarLocation could be returned in the response showing the missing 250 elements including A3, the same as the above example. 252 As another example of the use of similarLocation, consider the 253 results based on a similar data set as used above, where the HNO, RD, 254 STS, A1, and A3 civic address elements are not sufficient to locate a 255 unique address, which leads to an invalid location result. This is 256 the case, despite the fact that the LoST server typically contains 257 additional civic address elements which could have resulted in a 258 uniquely identifiable location if additional data had been supplied 259 with the query. Since [RFC5222] currently does not have a way for 260 this additional location information to be returned in the 261 findServiceResponse, this document extends [RFC5222] so that the LoST 262 locationValidation element of the findServiceResponse message can 263 include one or more similarLocation elements representing similar 264 civic locations. 266 To show this, suppose that a slightly modified address as above is 267 inserted within a Lost findService request: 269 input address: 6000 15th Ave N Seattle, WA. 271 This time we make the assumption that the address is deemed "invalid" 272 by the LoST server because there is no such thing as "15th Ave N" 273 within the LoST server's data for the city of Seattle. However, we 274 also happen to know for this example that there are two addresses 275 within the address dataset that are "similar", when all parts of the 276 address are taken as a whole. These similar addresses that could be 277 suggested to the user are as follows: 279 similar address #1: 6000 15th Ave NW Seattle, WA 98107 281 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 within the locationValidation 294 portion of the findService response. completeLocation and 295 similarLocation contain a list of civic address elements identical to 296 the elements used in the location element with the "civic profile" in 297 [RFC5222] or another profile derived from the civic profile. 299 The LoST server MAY include more than one similarLocation elements in 300 the response. If there are too many possible locations, the server 301 MAY return none, or it MAY return the few it considers most likely. 302 The definition of "few" is left to the implementation of the LoST 303 server. The server is unable to know what the intended location 304 information was suppose to be; it is guessing. Therefore the correct 305 location may or may not be one of the similarLocation elements the 306 server provides, and the client cannot assume that any of them are 307 the 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. The 314 completeLocation element MUST NOT be returned in response messages 315 where any civic address elements occur in the invalid list of the 316 response, or where the set of civic address elements in the request 317 do not identify a unique location. The complete location MUST NOT 318 contain any elements that would be marked as invalid, or cause an 319 error, if a recipient of that location performs a subsequent 320 findService request using the complete location. However, if a 321 subsequent request includes the complete location, the corresponding 322 request MAY include elements in the unchecked list. 324 Clients can control the return of additional location information by 325 including an optional returnAdditionalLocation attribute 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 "none". 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. The server MAY include 338 a similarLocationsLimited attribute which contains a non-zero integer 339 of the number of similar locations not included in the response. The 340 server is NOT obligated to make this number accurate, in that there 341 may be more than the indicated similar locations available in the 342 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] updated by 356 [I-D.ietf-ecrit-lost-planned-changes] including the profile attribute 357 which is useful if the request contains location information in a 358 profile derived from the civic profile. The profile attribute MUST 359 be included in both the request and the response and MUST be the same 360 profile in both. 362 5. Examples 364 5.1. Complete Location returned for Valid Location response 366 Based on the example input request, returned location information is 367 provided in a findServiceResponse message when the original input 368 address is considered valid, but is missing some additional data that 369 the LoST server has. 371 373 377 378 381 US 382 WA 383 Seattle 384 15th 385 Avenue 386 Northwest 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 420 421 423 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 464 465 468 US 469 WA 470 KING COUNTY 471 SEATTLE 472 15TH 473 AVENUE 474 6000 475 98106 476 SEATTLE 478 479 481 urn:service:sos 483 485 487 488 xmlns="urn:ietf:params:xml:ns:lost1" 489 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 490 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 492 498 Seattle 911 499 urn:service:sos 500 sip:seattle-911@example.com 501 911 503 505 ca:country ca:A1 ca:A3 ca:STS ca:RD 508 ca:POD 509 ca:HNO 511 512 513 US 514 WA 515 KING COUNTY 516 SEATTLE 517 15TH 518 AVENUE 519 NORTHWEST 520 6000 521 98106 522 SEATTLE 523 524 525 526 527 US 528 WA 529 KING COUNTY 530 SEATTLE 531 15TH 532 AVENUE 533 NORTHEAST 534 6000 535 98105 536 SEATTLE 537 538 540 542 543 544 546 548 550 552 6. XML Schema 554 This section provides the schema of LoST extensions based on the 555 schema in [I-D.ietf-ecrit-lost-planned-changes] 556 557 562 563 564 567 568 569 570 571 572 573 574 575 576 578 580 581 582 585 587 588 590 591 592 593 594 595 596 597 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 versus 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. XML 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 XML Schema: The XML schema to be registered is contained 638 in Section 7. 640 8.2. LoST-RLI Namespace Registration 641 URI: urn:ietf:params:xml:ns:lost-rli1 643 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 644 (br@brianrosen.net). 646 XML: 648 BEGIN 649 650 652 653 654 656 LoST Returned Location Information Namespace 657 658 659

Namespace for LoST Returned Location Information extension

660

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

661

See 662 RFC????.

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