idnits 2.17.00 (12 Aug 2021) /tmp/idnits61695/draft-rosen-ecrit-completed-location-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2010) is 4457 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV B. Rosen 3 Internet-Draft Neustar 4 Intended status: Standards Track H. Schulzrinne 5 Expires: September 2, 2010 Columbia U. 6 March 1, 2010 8 Completing the Request Location 9 draft-rosen-ecrit-completed-location-00 11 Abstract 13 This document defines an extension to LoST (RFC5222) that allows a 14 request to specify that a PIDF be returned in the response if the 15 location was valid, but there were some missing elements. For 16 example, an civic location that did not include a postal code, but 17 was otherwise a complete, and unambiguous location, would receive a 18 complete PIDF in the response that included the postal code. 20 Status of This Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 2, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions used in this document . . . . . . . . . . . . . . 4 62 3. element . . . . . . . . . . . . . . 4 63 4. element . . . . . . . . . . . . . 4 64 5. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 7.1. Relax NG Schema Registration . . . . . . . . . . . . . . . 12 68 7.2. LoST Namespace Registration . . . . . . . . . . . . . . . 13 69 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 This document describes an update to the LoST protocol [RFC5222] 74 which allows a request to complete the location in the 75 response. The PIDF returned would have all of the civic address 76 elements of the PIDF in the request, but would contain additional 77 elements not in the request PIDF that the LoST server knew were part 78 of the location. 80 When performing a validation function, the criteria to determine if a 81 location is valid used will often be that the information provided 82 was sufficient to uniquely identify the location proffered in the 83 request. It may not be necessary that the request PIDF-LO contain 84 all of the elements that the LoST server may know about for the 85 location. So long as there were sufficient elements to uniquely 86 identify the location, the location could be considered valid. 87 However, when the location is subsequently used (in a LoST request, 88 or for any other use), having those fields that the LoST server has, 89 but the requestor does not, may be valuable. 91 For example, the input PIDF-LO may contain the element (the 92 postal community name) and a element (the postal code), but may 93 be missing the element (city, township). Having the postal 94 addressing information may be sufficient (along with the other 95 information in the PIDF-LO) to determine exactly where the PIDF-LO 96 refers to. However, the post office name may be different from the 97 actual municipality, and the PSAP that serves it may depend on the 98 actual municipality. To cite a specific, the Postal Code 16046, with 99 the postal community name "Mars", in the state of Pennsylvania in the 100 United States spans a county boundary and four communities. A street 101 name of "Conrad" is in Allegheny County, in Pine Township. There is 102 a Mars township, but it is in Butler County. Allegheny County is 103 served by the Allegheny PSAP, Butler County is served by the Butler 104 PSAP. If the PIDF-LO in the request included: 106 US 107 PA 108 16046 109 Mars 110 Conrad 111 DR 112 470 114 the information in this PIDF may be enough to precisely locate the 115 target in Pine Township, Allegheny County (because there is only one 116 Conrad Drive in postal code 16046). The requestor may need to know 117 that this is Pine, and not Mars. The response to this request 118 arising from the use of the extension described in this document may 119 include: 121 US 122 PA 123 Allegheny 124 Pine 125 16046 126 Mars 127 Conrad 128 DR 129 470 131 This extension allows the requester to ask the LoST server to 132 complete the location, that is, return a complete PIDF with the 133 elements it may have that were not in the request, provided that the 134 location was valid. If the location was not valid, the LoST server 135 would not know what to return. 137 This feature is not a 'partial location matching function' which 138 might be used to guess at what a valid location might be given a 139 less-than-unique set of elements. When the LoST server returns 140 additional elements, it does so knowing that the elements it returns 141 indeed belong to the location described by the request. 143 2. Conventions used in this document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. element 151 This document defines a new attribute to called 152 'requestLocation'. When the LoST server receives a 153 request containing a 'requestLocation' attribute with values of 154 'true', and the PIDF in the element within the request is 155 valid, it will include a PIDF in the response. 157 4. element 159 When the request contains a requestCompletedLocation 160 attribute set to true, and in the request is valid, then 161 the server MUST include a element in the 162 containing a PIDF will all the elements of the 163 PIDF, plus any additional elements that the LoST server 164 may have that pertain to that location. 166 If the request contains requestLocation, but the location was 167 invalid, the server MUST NOT send a PIDF in the response. The 168 locationInvalid response will indicate to the requestor that no PIDF 169 should be expected in the response. requestLocation is independent of 170 locationValidation in the request. 172 5. Relax NG Schema 174 The Relax NG schema in [RFC5222] is modified to be: 176 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 177 default namespace ns1 = "urn:ietf:params:xml:ns:lost1" 179 ## 180 ## Location-to-Service Translation (LoST) Protocol 182 ## 183 ## A LoST XML instance has three request types, each with 184 ## a corresponding response type: find service, list services, 185 ## and get service boundary. 186 ## 187 start = 188 findService 189 | listServices 190 | listServicesByLocation 191 | getServiceBoundary 192 | findServiceResponse 193 | listServicesResponse 194 | listServicesByLocationResponse 195 | getServiceBoundaryResponse 196 | errors 197 | redirect 199 ## 200 ## The queries. 201 ## 202 div { 203 findService = 204 element findService { 205 requestLocation, 206 commonRequestPattern, 207 attribute validateLocation { 208 xsd:boolean >> a:defaultValue [ "false" ] 209 }?, 210 attribute requestCompletedLocation { 211 xsd:boolean >> a:defaultValue [ "false" ] 212 }?, 213 attribute serviceBoundary { 214 ("reference" | "value") >> a:defaultValue [ "reference" ] 216 }?, 217 attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? 218 } 219 listServices = element listServices { commonRequestPattern } 220 listServicesByLocation = 221 element listServicesByLocation { 222 requestLocation, 223 commonRequestPattern, 224 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 225 } 226 getServiceBoundary = 227 element getServiceBoundary { serviceBoundaryKey, extensionPoint } 228 } 230 ## 231 ## The responses. 232 ## 233 div { 234 findServiceResponse = 235 element findServiceResponse { 236 mapping+, locationValidation?, responseCompletedLocation?, 237 commonResponsePattern, locationUsed 238 } 239 listServicesResponse = 240 element listServicesResponse { serviceList, commonResponsePattern } 241 listServicesByLocationResponse = 242 element listServicesByLocationResponse { 243 serviceList, commonResponsePattern, locationUsed 244 } 245 getServiceBoundaryResponse = 246 element getServiceBoundaryResponse { 247 serviceBoundary, commonResponsePattern 248 } 249 } 251 ## 252 ## A pattern common to some of the queries. 253 ## 254 div { 255 commonRequestPattern = service, path?, extensionPoint 256 } 258 ## 259 ## A pattern common to responses. 260 ## 261 div { 262 commonResponsePattern = warnings*, path, extensionPoint 263 } 264 ## 265 ## Location in Requests 266 ## 267 div { 268 requestLocation = 269 element location { 270 attribute id { xsd:token }, 271 locationInformation 272 }+ 273 } 275 ## 276 ## Completed Location in Responses 277 ## 278 div { 279 responseCompletedLocation = 280 element location { 281 attribute id { xsd:token }, 282 locationInformation 283 }+ 284 } 286 ## 287 ## Location Information 288 ## 289 div { 290 locationInformation = 291 extensionPoint+, 292 attribute profile { xsd:NMTOKEN }? 293 } 295 ## 296 ## Service Boundary 297 ## 298 div { 299 serviceBoundary = element serviceBoundary { locationInformation }+ 300 } 302 ## 303 ## Service Boundary Reference 304 ## 305 div { 306 serviceBoundaryReference = 307 element serviceBoundaryReference { 308 source, serviceBoundaryKey, extensionPoint 309 } 310 serviceBoundaryKey = attribute key { xsd:token } 311 } 312 ## 313 ## Path - 314 ## Contains a list of via elements - 315 ## places through which information flowed 316 ## 317 div { 318 path = 319 element path { 320 element via { source, extensionPoint }+ 321 } 322 } 324 ## 325 ## Location Used 326 ## 327 div { 328 locationUsed = 329 element locationUsed { 330 attribute id { xsd:token } 331 }? 332 } 334 ## 335 ## Expires pattern 336 ## 337 div { 338 expires = 339 attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } 340 } 342 ## 343 ## A QName list 344 ## 345 div { 346 qnameList = list { xsd:QName* } 347 } 349 ## 350 ## A location-to-service mapping. 351 ## 352 div { 353 mapping = 354 element mapping { 355 element displayName { 356 xsd:string, 357 attribute xml:lang { xsd:language } 358 }*, 359 service, 360 (serviceBoundary | serviceBoundaryReference)?, 361 element uri { xsd:anyURI }*, 362 element serviceNumber { 363 xsd:token { pattern = "[0-9*#]+" } 364 }?, 365 extensionPoint, 366 expires, 367 attribute lastUpdated { xsd:dateTime }, 368 source, 369 attribute sourceId { xsd:token }, 370 message 371 } 372 } 374 ## 375 ## Location validation 376 ## 377 div { 378 locationValidation = 379 element locationValidation { 380 element valid { qnameList }?, 381 element invalid { qnameList }?, 382 element unchecked { qnameList }?, 383 extensionPoint 384 } 385 } 387 ## 388 ## Errors and Warnings Container. 389 ## 390 div { 391 exceptionContainer = 392 (badRequest? 393 & internalError? 394 & serviceSubstitution? 395 & defaultMappingReturned? 396 & forbidden? 397 & notFound? 398 & loop? 399 & serviceNotImplemented? 400 & serverTimeout? 401 & serverError? 402 & locationInvalid? 403 & locationProfileUnrecognized?), 404 extensionPoint, 405 source 406 errors = element errors { exceptionContainer } 407 warnings = element warnings { exceptionContainer } 409 } 410 ## 411 ## Basic Exceptions 412 ## 413 div { 415 ## 416 ## Exception pattern. 417 ## 418 basicException = message, extensionPoint 419 badRequest = element badRequest { basicException } 420 internalError = element internalError { basicException } 421 serviceSubstitution = element serviceSubstitution { basicException } 422 defaultMappingReturned = 423 element defaultMappingReturned { basicException } 424 forbidden = element forbidden { basicException } 425 notFound = element notFound { basicException } 426 loop = element loop { basicException } 427 serviceNotImplemented = 428 element serviceNotImplemented { basicException } 429 serverTimeout = element serverTimeout { basicException } 430 serverError = element serverError { basicException } 431 locationInvalid = element locationInvalid { basicException } 432 locationValidationUnavailable = 433 element locationValidationUnavailable { basicException } 434 locationProfileUnrecognized = 435 element locationProfileUnrecognized { 436 attribute unsupportedProfiles { xsd:NMTOKENS }, 437 basicException 438 } 439 } 441 ## 442 ## Redirect. 443 ## 444 div { 446 ## 447 ## Redirect pattern 448 ## 449 redirect = 450 element redirect { 451 attribute target { appUniqueString }, 452 source, 453 message, 454 extensionPoint 455 } 456 } 457 ## 458 ## Some common patterns. 459 ## 460 div { 461 message = 462 (attribute message { xsd:token }, 463 attribute xml:lang { xsd:language })? 464 service = element service { xsd:anyURI }? 465 appUniqueString = 466 xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } 467 source = attribute source { appUniqueString } 468 serviceList = 469 element serviceList { 470 list { xsd:anyURI* } 471 } 472 } 474 ## 475 ## Patterns for inclusion of elements from schemas in 476 ## other namespaces. 477 ## 478 div { 480 ## 481 ## Any element not in the LoST namespace. 482 ## 483 notLost = element * - (ns1:* | ns1:*) { anyElement } 485 ## 486 ## A wildcard pattern for including any element 487 ## from any other namespace. 488 ## 489 anyElement = 490 (element * { anyElement } 491 | attribute * { text } 492 | text)* 494 ## 495 ## A point where future extensions 496 ## (elements from other namespaces) 497 ## can be added. 498 ## 499 extensionPoint = notLost* 500 } 501 6. Security Considerations 503 The contains more information than the 504 requestor originally had. However, the response does provide any 505 more fine grained location ability: the request needed to have 506 sufficient information to uniquely locate the target in order to be 507 valid, and the response only contains additional information the LoST 508 server may know about the location. For this reason, the privacy 509 implications of this feature are not any more significant that those 510 raised in RFC5222. 512 The addition of the PIDF in the response does not have any other 513 security implications beyond those discussed in RFC5222. 515 7. IANA Considerations 517 7.1. Relax NG Schema Registration 519 URI: urn:ietf:params:xml:schema:lost2 521 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 522 (br@brianrosen.net). 524 Relax NG Schema: The Relax NG schema to be registered is contained 525 in Section 6. Its first line is 527 default namespace = "urn:ietf:params:xml:ns:lost2" 529 and its last line is 531 } 533 7.2. LoST Namespace Registration 535 URI: urn:ietf:params:xml:ns:lost2 537 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 538 (br@brianrosen.net). 540 XML: 542 BEGIN 543 544 546 547 548 550 LoST Namespace 551 552 553

Namespace for LoST

554

urn:ietf:params:xml:ns:lost2

555

See 556 RFC5222.

557 558 559 END 561 8. Normative References 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 567 Tschofenig, "LoST: A Location-to-Service Translation 568 Protocol", RFC 5222, August 2008. 570 Authors' Addresses 572 Brian Rosen 573 Neustar 574 470 Conrad Dr 575 Mars, PA 16046 576 US 578 EMail: br@brianrosen.net 580 Henning Schulzrinne 581 Columbia University 582 Department of Computer Science 583 450 Computer Science Building 584 New York, NY 10027 585 US 587 Phone: +1 212 939 7042 588 EMail: hgs@cs.columbia.edu 589 URI: http://www.cs.columbia.edu