idnits 2.17.1 draft-ietf-ecrit-similar-location-10.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. -- The draft header indicates that this document updates RFC5222, but the abstract doesn't seem to directly say this. It does mention RFC5222 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5222, updated by this document, for RFC5378 checks: 2006-06-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (2 September 2021) is 966 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-04 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft 4 Updates: 5222 (if approved) R. Marshall 5 Intended status: Standards Track J. Martin 6 Expires: 6 March 2022 Comtech TCS 7 2 September 2021 9 A LoST extension to return complete and similar location info 10 draft-ietf-ecrit-similar-location-10 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 in it's response a completed 21 civic address element set for a valid location response, and one or 22 more suggested sets of similar location information for an invalid 23 location. These two types of civic addresses are referred to as 24 either "complete location" or "similar location", and are included as 25 a 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 6 March 2022. 45 Copyright Notice 47 Copyright (c) 2021 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 (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as 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 68 response . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 8.1. XML Schema Registration . . . . . . . . . . . . . . . . . 15 73 8.2. LoST-RLI Namespace Registration . . . . . . . . . . . . . 15 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 76 9.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 The LoST protcol [RFC5222] supports the validation of civic location 82 information sent in a findService request, by providing a set of 83 validation result status indicators in the response. The current 84 usefulness of the supported xml elements, "valid", "invalid", and 85 "unchecked" is limited, because while they each provide an indication 86 of validity for any one location element as a part of the whole civic 87 address, the mechanism is insufficient in providing either the 88 complete set of civic address elements that the LoST server contains, 89 or of providing alternate suggestions (hints) as to which civic 90 address is intended for use. 92 Whether the input civic location is valid but missing information, or 93 invalid due to missing or wrong information, this document provides a 94 mechanism to return a complete set of civic address elements for 95 those valid or invalid cases. 97 This enhancement to the validation feature within LoST is required by 98 systems that rely on accurate location for processing. Use of this 99 enhancement increases the likelihood that the correct and/or complete 100 form of a civic location becomes timely known in those cases where it 101 is incomplete or incorrect. One such use case is that of location 102 based emergency calling. The use of this protocol extension 103 facilitates the timely correction of errors, and allows location 104 servers to be more easily provisioned with complete address 105 information. 107 The structure of this document includes terminology, Section 2, 108 followed by a discussion of the basic elements involved in location 109 validation. The use of these elements, by way of example, is 110 discussed in an overview section, Section 3, with accompanying 111 rationale, and a brief discussion of the impacts to LoST, and its 112 current schema. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 The following terms are defined in this document: 122 Location: The term Location can be used to refer to either a civic 123 location or a geodetic location. 125 Geodetic Location: a geographic coordinate set of values that 126 describes a point within a defined geographic datum. For example, 127 a WGS84 referenced latitude, longitude coordinate pair (2D), or 128 latitude, longitude, and altitude (3D). Note: geodetic location 129 is defined here for context, but is not used elsewhere within this 130 document. 132 Civic Location: The term Civic Location applies to a set of one or 133 more Civic Address Elements that are used in conjunction with each 134 other, and in accordance with a known ruleset to designate a 135 specific place within a region of geography, or a region of 136 geography by itself as defined in [RFC5139]. 138 Civic Address: The term Civic Address is used interchangeably with 139 the term Civic Location within this document. 141 Civic Address Element: The term Civic Address Element is used within 142 this document to apply to an individual CAtype data descriptor, 143 for example, as is described in [RFC4776], [RFC5774], and 144 [RFC6848]. 146 Invalid Location: A Civic Location that was included in a LoST 147 validateLocation request and subsequently returned with one or 148 more Civic Address Elements marked as invalid. Note that location 149 information may be submitted in the findRequest that causes the 150 LoST server to return Civic Address Elements in the invalid list. 151 It is also possible that the location information submitted is so 152 inaccurate that this extension can not be used, and the LoST 153 server may return a notFound. In this document, we use the term 154 Invalid Location only to refer to a case where the LoST server 155 returns one or more elements in the invalid list. 157 Valid Location: A Civic Location that was included in a LoST 158 validateLocation request and subsequently returned with all Civic 159 Address Elements in the valid or unchecked lists. 161 Complete Location: An expanded civic location that includes other 162 Civic Address Elements in addition to the existing validated Civic 163 Address Elements provided as input to a LoST server. 165 Similar Location: A suggested civic location that is similar to the 166 civic location which was input, but which had one or more invalid 167 civic address elements returned by the LoST server or was missing 168 Civic Adddress Elements the server has for the location. 170 Returned Location Information: A set of civic locations returned in 171 a LoST response. 173 3. Overview of Returned Location Information 175 This document describes an extension to LoST [RFC5222] to allow 176 additional location information to be returned in the 177 locationValidation element of a findServiceResponse. This extension 178 is applicable when the location information in the findServiceRequest 179 is in a civic profile as described in RFC5222 or in another profile 180 derived from that civic profile. This extension has two different 181 use cases: first, when the input location is incomplete but the LoST 182 server can identify the intended unique address, and second, when the 183 input location is invalid and the LoST server can identify one or 184 more likely intended locations. 186 When a LoST server is asked to validate a civic location, its goal is 187 to take the set of Civic Address Elements provided as the location 188 information in the LoST request, and find a unique location in its 189 database that matches the information in the request. Uniqueness 190 might not require values for all possible elements in the Civic 191 Address that the database might hold. Further, the input location 192 information might not represent the form of location the users of the 193 LoST service prefer to have. As an example, there are LoST Civic 194 Address Elements that could be used to define a postal location, 195 suitable for delivery of mail as well as a municipal location 196 suitable for responding to an emergency call. While the LoST server 197 might be able to determine the location from the postal elements 198 provided, the emergency services would prefer that the municipal 199 location be used for any subsequent emergency call. Since validation 200 is often performed well in advance of an end-user placing an 201 emergency call, if the LoST server could return the preferred form of 202 location (or more properly in this example, the municipal elements in 203 addition to the postal elements), those elements could be stored in a 204 LIS or client application and used in a later emergency call. 206 In addition, this document describes the reuse of the same mechanism, 207 but for a different purpose: to supply similar location information 208 in the case where a LoST server response includes one or more Civic 209 Address Elements marked as invalid, constituting an Invalid Location 210 response. In this case, the response contains one or more suggested 211 alternative Valid Locations. 213 In a LoST findServiceResponse indicating a Valid Location -- i.e., 214 containing a locationValidation element with no elements listed as 215 invalid -- the LoST server can use this extension to include 216 additional location information in a locationValidation element. As 217 an example, the query might contain a HNO (house number), RD (road 218 name) A3 (city), A1 (state/province) and a few more CAtype elements, 219 but might not contain A2 (county) or PC (Postal Code) CAtypes. The 220 civic location in the request might contain HNO, RD, STS, POD, A3 and 221 A1 Civic Address Elements that are sufficient enough for the LoST 222 server to uniquely locate the address specified in the request and 223 thus be considered Valid. Yet, other entities involved in a 224 subsequent emergency call might find it helpful to have additional 225 Civic Address Elements such as A2 (county), PC, (Postal Code) be 226 included as part of a complete civic location. Since [RFC5222] 227 currently does not have a way for this additional location 228 information to be returned in the findServiceResponse, this document 229 extends the LoST protocol so that it can include a completeLocation 230 element within the locationValidation element of the 231 findServiceResponse message, allowing for the representation of 232 complete location information. 234 An example showing complete location information supplied: 236 Input address: 6000 15th Ave NW Seattle 238 Complete Location: 6000 15th Ave NW Seattle, WA 98105 US 239 The information provided in the request may be enough to identify a 240 unique location in the LoST server, but that may not be the location 241 intended by the user. The completeLocation information may alert the 242 user to a mismatch between the provided location information and the 243 unique location the server interpreted that information to identify. 245 The other use case for this extension is when Invalid Location is 246 received from the LoST server. When a LoST server returns a response 247 to a findService request that contains a set of Civic Address 248 Elements with one or more labeled as invalid, the location 249 information in the findServiceResponse can be extended to include one 250 or more locations that might be the location desired. 252 In the example cited above, policy at the LoST server might deem a 253 missing A3 element as invalid, even if the location information in 254 the request was sufficient to identify a unique address. In that 255 case, the missing element would be listed in the invalid list, and a 256 similarLocation element could be returned in the response showing a 257 complete civic location that includes the missing A3 element, just as 258 in the above example. 260 As another example of the use of similarLocation, consider the 261 results based on a similar data set as used above, where the HNO, RD, 262 STS, A1, and A3 Civic Address Elements are not sufficient to locate a 263 unique address, which leads to an invalid location result. Because 264 the LoST server typically contains additional civic address elements 265 which could have resulted in a uniquely identifiable location if 266 these additional elements had been included in the location sent in 267 the query. Since [RFC5222] currently does not have a way for this 268 additional location information to be returned in the 269 findServiceResponse, this document extends [RFC5222] so that the LoST 270 locationValidation element of the findServiceResponse message can 271 include one or more similarLocation elements representing similar 272 civic locations. 274 To show this, suppose that a slightly modified version of the above 275 address is sent within a Lost findService request: 277 Input address: 6000 15th Ave N Seattle, WA. 279 This time we make the assumption that the address is deemed "invalid" 280 by the LoST server because there is no such thing as "15th Ave N" 281 within the LoST server's data for the city of Seattle. However, we 282 also happen to know for this example that there are two addresses 283 within the address dataset that are "similar", when all parts of the 284 address are taken as a whole. These similar addresses that could be 285 returned to the client are as follows: 287 Similar address #1: 6000 15th Ave NW Seattle, WA 98107 289 Similar address #2: 6000 15th Ave NE Seattle, WA 98105 291 This extension allows the LoST server to include the above similar 292 addresses in the response to locationValidation. The next section 293 shows examples of the LoST request and response XML message fragments 294 for the above valid and invalid scenarios, returning the complete or 295 similar addresses respectively. 297 4. Returned Location Information 299 The LoST server implementing this extension MAY include 300 completeLocation or similarLocation elements within the 301 locationValidation portion of the findService response. The 302 completeLocation and similarLocation elements contain a list of Civic 303 Address Elements identical to the elements used in the location 304 element with the "civic profile" in [RFC5222] or another profile 305 derived from the civic profile. 307 The LoST server MAY include more than one similarLocation element in 308 the response. If there are too many possible locations, the server 309 MAY return none, or it MAY return a subset considered most likely. 310 How many to return is left to the implementation of the LoST server. 311 The server is unable to know what the intended location information 312 was suppose to be; it is guessing. Therefore the correct location 313 may or may not be one of the similarLocation elements the server 314 provides, and the client cannot assume that any of them are the 315 correct location. 317 Where a LoST server contains additional location information relating 318 to the Civic Address used in a findServiceRequest, the 319 findServiceResponse message MAY include a completeLocation element 320 containing additional location information along with the original 321 validated Civic Address Elements; the additional Civic Address 322 Elements may be deemed by local policy as necessary to form a 323 Complete Location. The completeLocation element MUST NOT be returned 324 in response messages where any Civic Address Elements occur in the 325 invalid list of the response, or where the set of Civic Address 326 Elements in the request do not identify a unique location. The 327 Complete Location MUST NOT contain any elements that would be marked 328 as invalid, or cause an error, if a recipient of that location 329 performs a subsequent findService request using the Complete 330 Location. However, if a subsequent request includes the Complete 331 Location, the corresponding request MAY include elements in the 332 unchecked list. 334 Clients can control the return of additional location information by 335 including an optional returnAdditionalLocation attribute with 336 possible values "none", "similar", "complete" or "any". The value 337 "none" means to not return additional location information, "similar" 338 and "complete" mean to only return the respective type of additional 339 location information (if the server could send any) and "any" means 340 to include Similar and/or Complete Location (if the server could send 341 any). If the request includes this attribute, the server MUST NOT 342 send location information contravening the client's request. 343 Omitting this attribute in the request is equivalent to including it 344 with the value "none". 346 The server may determine that there are many possible Similar 347 Locations and decide not to send them all. The number of Similar 348 Locations sent is entirely up to the server. The server MAY include 349 a similarLocationsLimited attribute which contains a non-zero integer 350 indicating the number of Similar Locations not included in the 351 response. The server is NOT obligated to make this number accurate, 352 in that there may be more than the indicated similar locations 353 available in the data held by the server. 355 Clients MAY ignore the location information this extension defines. 356 The information is optional to send, and optional to use. In the 357 case where the location information in the request was valid, this 358 extension does not change the validity. In the case where the 359 location information in the request is invalid, but alternate 360 location information is returned, the original location remains 361 invalid, and the LoST server does not change the mapping response 362 other than optionally including the information defined by this 363 extension. 365 The completeLocation and similarLocation elements use the 366 locationInformation element from [RFC5222] updated by 367 [I-D.ietf-ecrit-lost-planned-changes], including the profile 368 attribute, which is useful if the request contains location 369 information in a profile derived from the civic profile. The profile 370 attribute MUST be included in both the request and the response and 371 MUST be the same profile in both. 373 5. Examples 375 5.1. Complete Location returned for Valid Location response 377 Based on the example input request above, Returned Location 378 Information is provided in a findServiceResponse message since the 379 original input address is considered valid but is missing some 380 additional data that the LoST server has. 382 384 388 389 392 US 393 WA 394 Seattle 395 15th 396 Avenue 397 Northwest 398 6000 400 401 403 urn:service:sos 405 407 409 410 xmlns="urn:ietf:params:xml:ns:lost1" 411 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 412 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 414 420 Seattle 911 421 urn:service:sos 422 sip:seattle-911@example.com 423 911 425 426 428 ca:country ca:A1 ca:A3 ca:RD ca:STS ca:POD ca:HNO 429 430 431 433 434 435 US 436 WA 437 KING COUNTY 438 SEATTLE 439 15TH 440 AVENUE 441 NORTHWEST 442 6000 443 98106 444 SEATTLE 445 447 449 451 452 453 455 457 459 461 5.2. Similar Location returned for Invalid Location response 463 The following example shows two returned Similar Locations in a 464 findServiceResponse message when the original input address is 465 considered invalid, in this example because the LoST server needed 466 the omitted POD data to match a unique address. 468 470 475 476 479 US 480 WA 481 KING COUNTY 482 SEATTLE 483 15TH 484 AVENUE 485 6000 486 98106 487 SEATTLE 489 490 492 urn:service:sos 494 496 498 499 xmlns="urn:ietf:params:xml:ns:lost1" 500 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 501 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 503 509 Seattle 911 510 urn:service:sos 511 sip:seattle-911@example.com 512 911 514 516 518 ca:country ca:A1 ca:A3 ca:STS ca:RD 519 ca:POD 520 ca:HNO 522 523 524 US 525 WA 526 KING COUNTY 527 SEATTLE 528 15TH 529 AVENUE 530 NORTHWEST 531 6000 532 98106 533 SEATTLE 534 535 536 537 538 US 539 WA 540 KING COUNTY 541 SEATTLE 542 15TH 543 AVENUE 544 NORTHEAST 545 6000 546 98105 547 SEATTLE 548 549 551 553 554 555 557 559 560 562 6. XML Schema 564 This section provides the schema of the LoST extensions, based on the 565 schema in [I-D.ietf-ecrit-lost-planned-changes] 566 567 572 573 574 577 578 579 580 581 582 583 584 585 586 588 590 591 592 595 597 598 600 601 602 603 604 605 606 607 609 611 7. Security Considerations 613 Whether the input to the LoST server is a Valid or Invalid Location, 614 the LoST server ultimately determines what it considers to be a Valid 615 Location. Even in the case where the input location is valid, the 616 requester still might not actually understand where that location is. 617 For this kind of Valid Location use case, this extension would 618 typically return more location information than what the requester 619 started with, which might reveal to the requester additional 620 information (additional CAtypes) about the location. While this is 621 very desirable in some scenarios such as supporting an emergency 622 call, it might not be as desirable for other services. Individual 623 LoST server implementations SHOULD consider the risk of releasing 624 more detail versus the value in doing so. Generally, supplying more 625 information (CAtypes) is not considered to be a significant problem 626 because the requester has to already have enough information for the 627 location to be considered valid, which in most cases is enough to 628 uniquely locate the address. Providing more CAtypes generally 629 doesn't actually reveal anything more. When Invalid Locations are 630 submitted, this extension allows the LoST response to include 631 locations that are similar to what was input, again resulting in more 632 information provided in the response than was sent in the request. 633 LoST server implementations SHOULD evaluate the particular use cases 634 where this extension is supported, and weigh the risks around its 635 use. Many services available today via the Internet offer similar 636 features, such as "did you mean" or address completion, so this 637 capability is not introducing any fundamentally new threat. 639 8. IANA Considerations 641 8.1. XML Schema Registration 643 URI: urn:ietf:params:xml:schema:lost-rli1 645 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 646 (br@brianrosen.net). 648 XML Schema: The XML schema to be registered is contained 649 in Section 7. 651 8.2. LoST-RLI Namespace Registration 652 URI: urn:ietf:params:xml:ns:lost-rli1 654 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 655 (br@brianrosen.net). 657 XML: 659 BEGIN 660 661 663 664 665 667 LoST Returned Location Information Namespace 668 669 670

Namespace for LoST Returned Location Information extension

671

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

672

See 673 RFC????.

674 675 676 END 678 9. References 680 9.1. Normative References 682 [I-D.ietf-ecrit-lost-planned-changes] 683 Rosen, B., "Validation of Locations Around a Planned 684 Change", Work in Progress, Internet-Draft, draft-ietf- 685 ecrit-lost-planned-changes-04, 19 August 2021, 686 . 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, 691 DOI 10.17487/RFC2119, March 1997, 692 . 694 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 695 Tschofenig, "LoST: A Location-to-Service Translation 696 Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, 697 . 699 9.2. Informative References 701 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 702 (DHCPv4 and DHCPv6) Option for Civic Addresses 703 Configuration Information", RFC 4776, 704 DOI 10.17487/RFC4776, November 2006, 705 . 707 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 708 Format for Presence Information Data Format Location 709 Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, 710 February 2008, . 712 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 713 Addresses in the Presence Information Data Format Location 714 Object (PIDF-LO): Guidelines and IANA Registry 715 Definition", BCP 154, RFC 5774, DOI 10.17487/RFC5774, 716 March 2010, . 718 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 719 R. George, "Specifying Civic Address Extensions in the 720 Presence Information Data Format Location Object (PIDF- 721 LO)", RFC 6848, DOI 10.17487/RFC6848, January 2013, 722 . 724 Authors' Addresses 726 Brian Rosen 727 470 Conrad Dr 728 Mars, PA 16046 729 United States of America 731 Email: br@brianrosen.net 733 Roger Marshall 734 Comtech TCS 735 2401 Elliott Avenue 736 2nd Floor 737 Seattle, WA 98121 738 United States of America 740 Email: roger.marshall@comtechtel.com 741 Jeff Martin 742 Comtech TCS 743 2401 Elliott Avenue 744 2nd Floor 745 Seattle, WA 98121 746 United States of America 748 Email: jeff.martin@comtechtel.com