idnits 2.17.1 draft-marshall-ecrit-similar-location-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5222]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 14, 2014) is 3725 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBA' is mentioned on line 433, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Marshall 3 Internet-Draft J. Martin 4 Intended status: Standards Track TCS 5 Expires: August 18, 2014 B. Rosen 6 Neustar 7 February 14, 2014 9 A LoST extension to support return of complete and similar location info 10 draft-marshall-ecrit-similar-location-03 12 Abstract 14 This document introduces a new way to provide returned location 15 information in LoST responses that is either of a completed or 16 similar form to the original input civic location, based on whether a 17 valid or invalid location is returned within the findServiceResponse 18 message. This document defines a new extension to the 19 findServiceResponse message within the LoST protocol [RFC5222] that 20 enables the LoST protocol to return a completed civic location 21 element set for a valid response, and one or more suggested sets of 22 civic location information for invalid LoST responses. These two 23 types of civic addresses are referred to as either "complete" or 24 "similar" locations, and are included as compilation of ca type xml 25 elements within the existing response 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 http://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 August 18, 2014. 44 Copyright Notice 46 Copyright (c) 2014 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 (http://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 . . . . . . . . . . . . . . . . 6 65 5. Complete Location returned for Valid response . . . . . . . . 6 66 6. Similar Location returned for Invalid Response . . . . . . . 8 67 7. Relax NG schema . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 9.1. Relax NG Schema Registration . . . . . . . . . . . . . . 12 71 9.2. LoST Namespace Registration . . . . . . . . . . . . . . . 12 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 11.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 usefullness 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 element as a part 85 of the whole address, the mechanism is insufficient in providing 86 either the complete set of address elements that the LoST server 87 contains, or of providing alternate suggestions (hints) as to which 88 civic address is intended. 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 location 93 information for those valid or invalid cases. 95 This enhancement to the validation feature within LoST is required in 96 order to ensure a high level of address matching, to overcome user 97 and system input errors, and to support the usefulness of location- 98 based systems in general. 100 The structure of this document includes terminology, Section 2, 101 followed by a discussion of the basic elements involved in location 102 validation. These use of these elements, by way of example, is 103 discussed in an overview section, Section 3, with accompanying 104 rationale, and a brief discussion of the impacts to LoST, and its 105 current schema. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119], 112 with the important qualification that, unless otherwise stated, these 113 terms apply to the design of the Location Configuration Protocol and 114 the Location Dereferencing Protocol, not its implementation or 115 application. 117 The following terms are defined in this document: 119 Address: The term Address is used interchangeably with the concept 120 of Civic Location. 122 Invalid: The result of the attempt to match an individual input data 123 as part of a larger set of data that has already been successfully 124 matched. 126 Invalid Civic Element: An unmatched result of an individual civic 127 location element as part of a broader set of elements that make up 128 a civic location. 130 Invalid Civic Location: An unmatched result of an input civic 131 location, when taken as a whole, based on one or more individual 132 unmatched civic address elements. 134 Complete Location: An expanded civic location that includes 135 additional address elements in addition to the existing validated 136 civic elements provided. 138 Similar Location: A suggested civic location that is comparatively 139 close to the civic location which was input, but which had one or 140 more invalid element. 142 Returned Location Information: A set of standard civic location 143 elements returned in a LoST response. 145 3. Overview of Returned Location Information 147 This document describes an extension to LoST [RFC5222], to allow 148 additional location information to be returned in a 149 findServiceResponse for two different use cases. 151 When a LoST server is asked to validate a location, its goal is to 152 take the set of elements in the location information in the request, 153 and find a unique location in its database that matches the 154 information in the request. Uniqueness may not require values for 155 all possible elements in the civic address that the database may 156 hold. Further, the input location information may not represent the 157 form of location the users of the LoST service prefer to have. As an 158 example, there are LoST elements that could be used to define a 159 postal location, suitable for delivery mail as well as a municipal 160 location suitable for responding to an emergency call. While the 161 LoST server may be able to determine the location from the postal 162 elements provided, the emergency services would prefer that the 163 municipal location be used for any subsequent emergency call. Since 164 validation is often performed well in advance of an emergency call, 165 if the LoST server could return the preferred form of location (or 166 more properly, the municipal elements in addition to the postal 167 elements), those elements could be stored in a LIS and used in a 168 subsequent emergence call. 170 Since a LoST server often contains more data than what is included 171 within a findService request, it is expected that this additional 172 location information could be returned within response messages that 173 may be both valid and invalid. For valid responses, where a LoST 174 server contains additional location information relating to that 175 civic address, the findServiceResponse message can return additional 176 location information along with the original validated elements in 177 order to form a complete civic location. 179 On the other hand, for an invalid LoST response that contains address 180 elements returned with one or more of them marked as invalid, and 181 constituting an invalid location, this document introduces the idea 182 of reusing this same mechanism, but for a different purpose - to 183 supply similar location information - again, information that is 184 contained within the LoST server, but is provided as a complete 185 "similar" civic location put forward as a suggested alternative 186 address that is also a valid location. 188 In valid location responses, when a LoST server returns a response to 189 a findService request that contains a set of CAtype elements 190 considered valid, the location information in the findServiceResponse 191 is extended to include additional location information specific for 192 that location. As an example, the query may contain a HNO (house 193 number), RD (road name) and A3 (city) but may not contain A1, A2, PC 194 (Postal Code) CAtypes. The RD and PC elements may be sufficient to 195 locate the address specified in the request and thus be considered 196 valid. Yet, downstream entities may find it helpful to have the 197 additional A1, A2, and PC location elements that exist, and so the 198 mechanism described here supports their inclusion. Since [RFC5222] 199 currently does not have a way for this additional location 200 information to be returned in the findServiceResponse, this document 201 extends RFC5222 so that it can include a completeLocation element 202 within the findServiceResponse message, representing a "complete" 203 civic location. 205 input address: 6000 15th Ave NW Seattle 207 completed address: 6000 15th Ave NW Seattle, WA 98105 US 209 When invalid location responses are received, the same mechanism 210 works as follows: when a LoST server returns a response to a 211 findService request that contains a set of CAtype elements with one 212 or more that are tagged as invalid, the location information in the 213 findServiceResponse is extended to include additional location 214 information specific for that location. Differing results in the 215 same data used in the above example, where the RD and PC elements are 216 not sufficient to locate a unique address leads to an "invalid" 217 result. This is the case, despite the fact that the LoST server 218 typically contains additional location elements which could have 219 resulted in a uniquely identifiable location if additional data had 220 been supplied in the query. Since [RFC5222] currently does not have 221 a way for this additional location information to be returned in the 222 findServiceResponse, this document extends RFC5222 so that it can 223 include one or more similarLocation elements within the 224 findServiceResponse message representing "similar" civic locations. 226 To show this, suppose that a similar address as above is inserted 227 within a Lost findService request: 229 input address: 6000 15th Ave Seattle, WA. 231 Different from the above case, this time we make the assumption that 232 the address is deemed "invalid" by the LoST server because there is 233 no plain "15th Ave" in the city of Seattle with a house number that 234 matches 6000. However there are two addresses within the address 235 dataset that are "similar", when all parts of the address are taken 236 as a whole. These similar addresses that could be suggested to the 237 user are as follows: 239 similar address #1: 6000 15th Ave NW Seattle, WA 98107 240 similar address #2: 6000 15th Ave NE Seattle, WA 98105 242 This document proposes to include the above similar addresses as 243 civicAddress elements in the response to locationValidation. The 244 next section shows examples of the LoST request and response xml 245 message fragments for the above valid and invalid scenarios, 246 returning the complete or similar addresses, respectively: 248 4. Returned Location Information 250 The LoST server knows the data that is available internally, and can 251 determine which additional elements can be provided either as part of 252 a complete civic location (CCL) or a similar civic location (SCL). 253 The inclusion of either CCL or SCL is not triggered by any message 254 parameter, but is triggered based on whether the returned location 255 information is valid or invalid. It is not turned on or off, but is 256 implementation specific. 258 5. Complete Location returned for Valid response 260 Based on the example input request, returned location information is 261 provided in a findServiceResponse message when the original input 262 address is considered valid, but is missing some additional data that 263 the LoST server has. 265 267 270 271 274 Seattle 275 15th 276 Ave 277 NW 278 6000 280 281 283 urn:service:sos 285 286 288 289 xmlns="urn:ietf:params:xml:ns:lost1" 290 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 291 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 293 299 Seattle 911 300 urn:service:sos 301 sip:seattle-911@example.com 302 911 304 306 ca:A3 ca:A6 ca:STS ca:POD ca:HNO 309 310 312 313 314 US 315 WA 316 SEATTLE 317 15TH 318 AVE 319 NW 320 6000 321 98106 322 SEATTLE 323 325 327 329 330 331 332 334 336 338 6. Similar Location returned for Invalid Response 340 The following example shows returned location information provided in 341 a findServiceResponse message when the original input address is 342 considered invalid, because (in this case) of missing data that the 343 LoST server needs to provide a unique mapping. 345 347 350 351 354 US 355 WA 356 Seattle 357 15th Ave 358 6000 360 361 363 urn:service:sos 365 367 369 370 xmlns="urn:ietf:params:xml:ns:lost1" 371 xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"> 372 xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> 373 379 Seattle 911 380 urn:service:sos 381 sip:seattle-911@example.com 382 911 384 386 ca:country ca:A1 ca:A3 389 ca:A6 390 ca:HNO 392 393 394 US 395 WA 396 SEATTLE 397 15TH 398 AVE 399 NW 400 6000 401 98106 402 SEATTLE 403 405 406 US 407 WA 408 SEATTLE 409 15TH 410 AVE 411 NE 412 6000 413 98105 414 SEATTLE 415 416 418 420 421 422 424 426 428 430 7. Relax NG schema 432 This section provides the Relax NG schema of LoST extensions in the 433 compact form. The verbose form is included in a later section [TBA]. 435 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 436 default namespace ns1 = "urn:ietf:params:xml:ns:lost-similarLocation1" 438 ## 439 ## Extension to LoST to support returned location information 440 ## 441 start = 442 returnedLocation 444 div { 445 returnedLocationResponse = 446 element returnedLocationResponse { 447 completeLocation, similarLocation, extensionPoint 448 } 449 } 451 ## 452 ## completeLocation 453 ## 454 div { 455 completeLocation = 456 element location { 457 attribute id { xsd:token }, 458 locationInformation 459 }+ 460 } 462 ## 463 ## similarLocation 464 ## 465 div { 466 similarLocation = 467 element location { 468 attribute id { xsd:token }, 469 locationInformation 470 }+ 471 } 472 ## 473 ## Location Information 474 ## 475 div { 476 locationInformation = 477 extensionPoint+, 478 attribute profile { xsd:NMTOKEN }? 479 } 481 ## 482 ## Patterns for inclusion of elements from schemas in 483 ## other namespaces. 484 ## 485 div { 487 ## 488 ## Any element not in the LoST namespace. 489 ## 490 notLost = element * - (ns1:* | ns1:*) { anyElement } 492 ## 493 ## A wildcard pattern for including any element 494 ## from any other namespace. 495 ## 496 anyElement = 497 (element * { anyElement } 498 | attribute * { text } 499 | text)* 501 ## 502 ## A point where future extensions 503 ## (elements from other namespaces) 504 ## can be added. 505 ## 506 extensionPoint = notRLI* 507 } 509 8. Security Considerations 511 Whether the input to the LoST server is valid or invalid, the LoST 512 server ultimately determines what it considers to be valid. In the 513 case where the input location is valid, the requester still may not 514 actually understand where that location is. For valid location use 515 cases, this extension returns more location information than the 516 requester may have had which, in turn, may reveal more about the 517 location. While this may be very desirable when, for example, 518 supporting an emergency call, it may not be as desirable for other 519 services. The LoST server implementation should consider the risk of 520 releasing more detail verses the value in doing so. Generally, we do 521 not believe this is a significant problem as the requester must have 522 enough location information to be considered valid, which in most 523 cases is enough to uniquely locate the address. Providing more 524 CAtypes generally doesn't actually reveal anything more. 526 9. IANA Considerations 528 9.1. Relax NG Schema Registration 530 URI: urn:ietf:params:xml:schema:lost-similarLocation1 532 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 533 (br@brianrosen.net). 535 Relax NG Schema: The Relax NG schema to be registered is contained 536 in Section 7. Its first line is 538 default namespace = "urn:ietf:params:xml:ns:lost-similarLocation1 540 and its last line is 542 } 544 9.2. LoST Namespace Registration 545 URI: urn:ietf:params:xml:ns:lost-similarLocation1 547 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 548 (br@brianrosen.net). 550 XML: 552 BEGIN 553 554 556 557 558 560 LoST Planned Change Namespace 561 562 563

Namespace for LoST Similar Location extension

564

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

565

See 566 RFC????.

567 568 569 END 571 10. Acknowledgements 573 11. References 575 11.1. Normative References 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, March 1997. 580 11.2. Informative References 582 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 583 Tschofenig, "LoST: A Location-to-Service Translation 584 Protocol", RFC 5222, August 2008. 586 Authors' Addresses 587 Roger Marshall 588 TeleCommunication Systems, Inc. 589 2401 Elliott Avenue 590 2nd Floor 591 Seattle, WA 98121 592 US 594 Phone: +1 206 792 2424 595 Email: rmarshall@telecomsys.com 596 URI: http://www.telecomsys.com 598 Jeff Martin 599 TeleCommunication Systems, Inc. 600 2401 Elliott Avenue 601 2nd Floor 602 Seattle, WA 98121 603 US 605 Phone: +1 206 792 2584 606 Email: jmartin@telecomsys.com 607 URI: http://www.telecomsys.com 609 Brian Rosen 610 Neustar 611 470 Conrad Dr 612 Mars, PA 16046 613 US 615 Email: br@brianrosen.net