idnits 2.17.1 draft-ietf-ecrit-lost-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2270. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 22, 2006) is 6396 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) ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2717 (ref. '4') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2818 (ref. '5') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (ref. '9') (Obsoleted by RFC 6838) == Outdated reference: A later version (-07) exists of draft-ietf-ecrit-service-urn-05 == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-revised-civic-lo-04 == Outdated reference: A later version (-02) exists of draft-daigle-unaptr-00 -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. '15') (Obsoleted by RFC 6121) == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-security-threats-03 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-requirements-12 == Outdated reference: A later version (-04) exists of draft-ietf-ecrit-mapping-arch-00 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-00 Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardie 3 Internet-Draft Qualcomm, Inc. 4 Intended status: Standards Track A. Newton 5 Expires: April 25, 2007 SunRocket 6 H. Schulzrinne 7 Columbia U. 8 H. Tschofenig 9 Siemens 10 October 22, 2006 12 LoST: A Location-to-Service Translation Protocol 13 draft-ietf-ecrit-lost-02.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 25, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document describes an XML-based protocol for mapping service 47 identifiers and geodetic or civic location information to service 48 contact URIs. In particular, it can be used to determine the 49 location-appropriate PSAP for emergency services. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 8 57 5. LoST Uniform Resource Locators and Their Resolution . . . . . 9 58 6. Mapping a Location and Service to URLs: . . . . 10 59 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 6.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 10 62 6.2.2. Civic Address Mapping Example . . . . . . . . . . . . 11 63 6.3. Components of Request . . . . . . . . . . . 13 64 6.3.1. The Element . . . . . . . . . . . . . . . . 13 65 6.3.2. The Element . . . . . . . . . . . . . . . . 13 66 6.3.3. Recursion or Redirection . . . . . . . . . . . . . . . 13 67 6.3.4. Configuring the Response . . . . . . . . . . . . . . . 14 68 6.4. Components of the Mapping Response 69 . . . . . . . . . . . . . . . . . . 16 70 6.4.1. Source of Response: Element . . . . . . . . . . 16 71 6.4.2. Service URLs: the Element . . . . . . . . . . . 16 72 6.4.3. Describing the Service with the 73 Element . . . . . . . . . . . . . . . . . . . . . . . 17 74 6.4.4. Approximating Services: the Element . . . . 17 75 6.4.5. Defining the Service Region with the 76 Element . . . . . . . . . . . . . . 17 77 6.4.6. Service Boundaries by Reference: the 78 Element . . . . . . . . . . 17 79 6.4.7. The Service Number . . . . . . . . . . . . . . . . . . 18 80 6.4.8. Civic Address Validation . . . . . . . . . . . . . . . 18 81 6.4.9. Validity: The 'timeToLive' Attribute . . . . . . . . . 18 82 7. Retrieving the Service Boundary via . . . 19 83 8. List Services: . . . . . . . . . . . . . . . . 21 84 9. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 23 85 9.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 23 86 9.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 26 87 9.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 26 88 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 27 89 10.1. Basic Errors . . . . . . . . . . . . . . . . . . . . . . . 27 90 10.2. Response Errors . . . . . . . . . . . . . . . . . . . . . 27 91 10.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 28 92 11. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 29 93 12. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 30 94 13. Internationalization Considerations . . . . . . . . . . . . . 37 95 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 96 14.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 38 97 14.2. Content-type registration for 'application/lost+xml' . . . 38 98 14.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 40 99 14.4. LoST Namespace Registration . . . . . . . . . . . . . . . 40 100 14.5. Registration Template . . . . . . . . . . . . . . . . . . 41 101 14.6. LoST Location Profile Registry . . . . . . . . . . . . . . 42 102 15. Security Considerations . . . . . . . . . . . . . . . . . . . 43 103 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 104 17. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45 105 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 106 18.1. Normative References . . . . . . . . . . . . . . . . . . . 46 107 18.2. Informative References . . . . . . . . . . . . . . . . . . 47 108 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 48 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 110 Intellectual Property and Copyright Statements . . . . . . . . . . 62 112 1. Introduction 114 This document describes a protocol for mapping a service identifier 115 [10] and location information compatible with PIDF-LO [8] to one or 116 more service contact URIs. Example contact URI schemes include sip 117 [14], xmpp [15], and tel [16]. While the initial focus is on 118 providing mapping functions for emergency services, it is likely that 119 the protocol is applicable to any service URN. For example, in the 120 United States, the "2-1-1" and "3-1-1" services follow a similar 121 location-to-service behavior as emergency services. 123 This document names this protocol "LoST", for Location-to-Service 124 Translation. LoST Satisfies the requirements [18] for mapping 125 protocols. LoST provides a number of operations, centered around 126 mapping locations and service URNs to URIs and associated 127 information. LoST mapping queries can contain either civic or 128 geodetic location information. For civic addresses, LoST can 129 indicate which parts of the civic address are known to be valid or 130 invalid, thus providing address validation. LoST indicates errors in 131 the location data to facilitate debugging and proper user feedback, 132 but also provides best-effort answers. 134 LoST queries can be resolved recursively or iteratively. To minimize 135 round trips, LoST caches individual mappings and indicates the region 136 for which the same answer would be returned ("service region"). 138 As currently defined, LoST messages are carried in HTTP and HTTPS 139 protocol exchanges, facilitating use of TLS for protecting the 140 integrity and confidentiality of requests and responses. 142 This document focuses on the description of the protocol between the 143 mapping client (seeker or resolver) and the mapping server (resolver 144 or other servers). The relationship between other functions, such as 145 discovery of mapping servers, data replication and the overall 146 mapping server architecture are described in a separate document 147 [19]. 149 The query message carries location information and a service 150 identifier encoded as a Uniform Resource Name (URN) (see [10]) from 151 the LoST client to the LoST server. The LoST server uses its 152 database to map the input values to one or more Uniform Resource 153 Identifiers (URI) and returns those URIs along with optional 154 information such as hints about the service boundary in a response 155 message to the LoST client. If the server cannot resolve the query 156 itself, it may in turn query another server or return the address of 157 another LoST server, identified by a LoST URL (Section 5). In 158 addition to the mapping function described in Section 6, the protocol 159 also allows to retrieve the service boundary Section 7 and to list 160 the services available for a particular location Section 8. 162 2. Requirements Notation 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [1]. 168 3. Terminology 170 This document furthermore uses the terminology defined in [18]. 172 In examples, the XML sent by the client is prepended with "C:" and 173 the XML sent by the server is prepended with "S:". 175 4. Overview of Protocol Usage 177 The client may perform the mapping at any time. Among the common 178 triggers for mapping requests are: 180 1. When the client initially starts up or attaches to a network. 182 2. When the client detects that its location has changed 183 sufficiently that it is outside the bounds of the service region 184 returned in an earlier LoST query. 186 3. When cached mapping information has expired. 188 4. When invoking a particular service. At that time, a client may 189 omit requests for service boundaries or other auxiliary 190 information. 192 A service-specific BCP such as [20] governs whether a client is 193 expected to invoke the mapping service just before needing the 194 service or whether to rely on cached answers. Cache entries expire 195 according to their time-to-live value (see Section 6.4.9, or they 196 become invalid if the caller's device moves beyond the boundaries of 197 the service region. 199 5. LoST Uniform Resource Locators and Their Resolution 201 LoST servers are identified by LoST Uniform Resource Locators (URLs), 202 which follow the format of URLs defined in RFC 3986 [7], with the 203 following ABNF: 205 LoST-URI = "lost:" host 207 'host' is defined in Section 3.2.2 of RFC 3986 [7]. 209 An example is 'lost:lostserver.example.com' 211 If a LoST URL contains a host name rather than an IP address, clients 212 need to use U-NAPTR [12] using the U-NAPTR specification described 213 below to obtain a URI (indicating host and protocol) for the 214 applicable LoST service. In this document, only the HTTP and HTTPS 215 URL schemes are defined. Note that the HTTP URL can be any valid 216 HTTP URL, including those containing path elements. 218 The following two DNS entries resolve the LoST URL "lost:example.com" 219 to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL 220 http://lostserver.example.com, with the former being preferred. 222 example.com. 224 IN NAPTR 100 10 "u" "LoST:https" 225 "!*.!https://lostserver.example.com/secure!" "" 227 IN NAPTR 200 10 "u" "LoST:http" 228 "!*.!http://lostserver.example.com!" "" 230 6. Mapping a Location and Service to URLs: 232 6.1. Overview 234 The query constitutes the core of the LoST 235 functionality, mapping civic or geodetic locations to URLs and 236 associated data. After giving an example, we enumerate the elements 237 of the query and response. 239 6.2. Examples 241 6.2.1. Example Using Geodetic Coordinates 243 The following is an example of mapping a service to a location using 244 geodetic coordinates, for the service associated with the police 245 (urn:service:sos.police). 247 248 251 253 254 40.8089897 -73.9612492 255 256 257 urn:service:sos.police 258 260 Figure 2: A Geodetic Query 262 Given the query above, a server would respond with a service, and 263 information related to that service. In the example below, the 264 server has mapped the location given by the client for a police 265 service to the New York City Police Deparment, instructing the client 266 that it may contact them via the URIs sip:nypd@example.com and 267 xmpp:nypd@example.com. The server has also given the client a 268 geodetic, two-dimensional boundary for this service and time-to-live 269 value of 3,600 seconds. This instructs the client that if its 270 location changes beyond the give service boundary or if 3,600 seconds 271 has elapsed, it would need to requery for this information. 273 274 276 277 New York City Police Department 278 279 urn:service:sos.police 280 282 283 284 285 37.775 -122.4194 286 37.555 -122.4194 287 37.555 -122.4264 288 37.775 -122.4264 289 37.775 -122.4194 290 291 292 293 294 sip:nypd@example.com 295 xmpp:nypd@example.com 296 911 297 299 Figure 3: A Geodetic Answer 301 6.2.2. Civic Address Mapping Example 303 The following is an example of mapping a service to a location much 304 like the example in Section 6.2.1, but using civic address location 305 information. In this example, the client requests the service 306 associated with police (urn:service:sos.police) along with a specific 307 civic address (house number 96 on a street named Neu Perlach in 308 Munich, Germany). 310 311 314 316 318 Germany 319 Bavaria 320 Munich 321 Neu Perlach 322 96 323 81675 324 325 326 urn:service:sos.police 327 329 Figure 4: A Civic Address Query 331 Given the query above, a server would respond with a service, and 332 information related to that service. In the example below, the 333 server has mapped the location given by the client for a police 334 service to the Mȭnchen Polizei-Abteilung, instructing the client 335 that it may contact them via the URIs sip:munich-police@example.com 336 and xmpp:munich-police@example.com. The server has also given the 337 client a civic address boundary (the city of Munich) for this service 338 and time-to-live value of 3,600 seconds. This instructs the client 339 that if its location changes beyond the give service boundary (i.e. 340 beyond the city of Munich) or if 3,600 seconds has elapsed, it would 341 need to requery for this information. 343 344 346 347 Mȭnchen Polizei-Abteilung 348 349 urn:service:sos.police 350 352 354 Germany 355 Bavaria 356 Munich 357 81675 358 359 360 sip:munich-police@example.com 361 xmpp:munich-police@example.com 362 110 363 365 Figure 5: A Civic Address Answer 367 6.3. Components of Request 369 6.3.1. The Element 371 The query communicates location using one or more 372 elements, which MUST conform to a location profile 373 (Section 9). 375 6.3.2. The Element 377 The type of service desired is specified by the element. 378 It contains service URNs from the registry established in [10]. 380 6.3.3. Recursion or Redirection 382 LoST queries can be recursive or iterative, as 383 indicated by the 'recursive' attribute. A value of "true" indicates 384 a recursive query, a value of "false" an iterative query, with 385 iterative being the default. When the LoST server cannot answer the 386 query and the query requested iterative resolution, it will return an 387 (Section 10.3) error message with the LoST 388 URI pointing to a different LoST server that the LoST client should 389 contact. In recursive mode, the LoST server initiates a query and 390 returns the result to the original querier, inserting a element 391 to track the response chain. 393 6.3.4. Configuring the Response 395 The 'include' attribute enumerates all the XML elements that the 396 client wants the LoST server to provide in the mapping response. The 397 server ignores any element names that it does not understand. The 398 ordering of the tokens is immaterial. 400 Among other features, it determines whether service boundaries are 401 returned and whether they are returned by value or reference 402 Section 7, and whether to validate civic locations. 404 Address validation is requested by including the XML element names 405 that provide address validation in the 'include' attribute, namely 406 'valid', 'invalid' and 'unchecked'. The following example 407 demonstrates address validation. 409 C: 410 C: 414 C: 416 C: 418 C: Germany 419 C: Bavaria 420 C: Munich 421 C: Neu Perlach 422 C: 96 423 C: 81675 424 C: 425 C: 426 C: urn:service:sos.police 427 C: 429 S: 430 S: 432 S: 433 S: Mȭnchen Polizei-Abteilung 434 S: 435 S: urn:service:sos.police 436 S: 438 S: 440 S: Germany 441 S: Bavaria 442 S: Munich 443 S: 81675 444 S: 445 S: 446 S: sip:munich-police@example.com 447 S: xmpp:munich-police@example.com 448 S: 110 449 S: country A1 A3 A6 450 S: PC 451 S: 453 Figure 6: Address Validation Exchange 455 6.4. Components of the Mapping Response 457 6.4.1. Source of Response: Element 459 A indicates the source of the response by 460 including a element with a LoST URL as the first element. 461 Thus, each server "initials" its own response. Thus, responses to 462 iterative queries contain one element, while responses to 463 recursive queries may reach the original querier with multiple 464 elements, one for each server that was used in the resolution. The 465 following example illustrates the use of : 467 468 470 lost:esgw.uber-110.de.example 471 lost:polizei.munchen.de.example 472 473 Mȭnchen Polizei-Abteilung 474 475 urn:service:sos.police 476 478 480 Germany 481 Bavaria 482 Munich 483 81675 484 485 486 sip:munich-police@example.com 487 xmpp:munich-police@example.com 488 110 489 491 Figure 7: An Example of a Response Using 493 The example above indicates that the this answer was given to the 494 responding server by the LoST server at esgw.uber-110.de.example, 495 which got the answer from the LoST server at 496 polizei.munchen.de.example. 498 6.4.2. Service URLs: the Element 500 The response returns the service URLs in one or more elements. 501 The URLs MUST be absolute URLs. 503 6.4.3. Describing the Service with the Element 505 The element describes the service with a string that is 506 suitable for display to human users, annotated with the 'xml:lang' 507 attribute that contains a language tag to aid in the rendering of 508 text. 510 6.4.4. Approximating Services: the Element 512 If the requested service, identified by the service URN [10] in the 513 element in the request, does not exist for the location 514 indicated, the server can either return an 515 (Section 10.2) error or can provide an alternate service that 516 approximates the desired service for that location. In the latter 517 case, the server MUST include a element with the 518 alternative service URN. The choice of service URN is left to local 519 policy, but the alternate service should be able to satisfy the 520 original service request. 522 6.4.5. Defining the Service Region with the Element 524 A response can indicate the region for which the service URL returned 525 would be the same as in the actual query, the so-called service 526 region. The service region can be indicated by value or by reference 527 Section 6.4.6. If a client moves outside the service area, it MUST 528 send a new query with its current location to obtain valid service 529 data. The service region is described by value in one or more 530 elements, each formatted according to a different 531 location profile. The client only processes the first element that 532 it can understand according to its list of supported location 533 profiles. Thus, the elements are alternative descriptions of the 534 same service region, not additive geometries. 536 The server returns all suitable service regions, using all available 537 location profiles, so that intermediate caches have this information 538 available for future queries. 540 6.4.6. Service Boundaries by Reference: the 541 Element 543 Since geodetic service boundaries may contain thousands of points and 544 thus be quite large, clients may opt to conserve bandwidth and 545 request a reference to the service boundary instead of the value 546 described in Section 6.4.5. The identifier of the service boundary 547 is returned in the element, along with a 548 LoST URL identifying the server from where it can be retrieved. The 549 actual value of the service boundary is then retrieved with the 550 getServiceBoundary (Section 7) request. 552 The identifier is a random token with at least 128 bits of entropy 553 and can be assumed to be globally unique. The identifier uniquely 554 references a particular boundary; if the boundary changes, a new 555 identifier must be chosen. Because of these properties, a client 556 receiving a mapping response can simply check if it already has a 557 copy of the boundary with that identifier. If so, it can skip 558 checking with the server whether the boundary has been updated. 559 Since service boundaries are likely to remain unchanged for extended 560 periods of time, possibly exceeding the normal lifetime of the 561 service URL, this approach avoids refreshing the boundary information 562 even if the cached service response has gotten stale. 564 6.4.7. The Service Number 566 The service number is returned in the optional 567 element. It contains a string of digits, * and # that a user on a 568 device with a 12-key dial pad could use to reach that particular 569 service. 571 6.4.8. Civic Address Validation 573 A server can indicate in its response which civic address elements it 574 has recognized as valid, which ones it has ignored and which ones it 575 has checked and found to be invalid. Each element contains a list of 576 tokens separated by white space, enumerating the civic location 577 lables used in child elements of the element. The 578 element enumerates those civic address elements that have 579 been recognized as valid by the LoST server and that have been used 580 to determine the mapping. The elements enumerates the 581 civic address elements that the server did not check and that were 582 not used in determining the response. The element 583 enumerate civic address elements that the server attempted to check, 584 but that did not match the other civic address elements found in the 585 list. 587 The example (Figure 6) indicates that the tokens 'country', 'A1', 588 'A3', and 'A6' have been validated by the LoST server. The server 589 considered the postal code 81675 in the element as not valid for 590 this location. 592 6.4.9. Validity: The 'timeToLive' Attribute 594 The timeToLive attribute contains the number of seconds the response 595 is to be considered valid. The contents of this attribute is a 596 positive integer. See Section 4 regarding how this value is to be 597 utilized with a cache. [TBD: This could also be an absolute time.] 599 7. Retrieving the Service Boundary via 601 As discussed in Section 6.4.5, the response can return 602 a globally unique identifier that can be used to retrieve the service 603 boundary, rather than returning the boundary by value. This is shown 604 in the example in Figure 8. The client can then retrieve the 605 boundary using the request and obtains the 606 boundary in the , illustrated in the 607 example in Section 7. The client issues the request to the server 608 identified in the 'server' attribute of the 609 element. 611 C: 612 C: 616 C: 618 C: 619 C: 40.809 -73.9612 620 C: 621 C: 622 C: urn:service:sos.police 623 C: 625 S: 626 S: 628 S: 629 S: New York City Police Department 630 S: 631 S: urn:service:sos.police 632 S: 634 S: sip:nypd@example.com 635 S: xmpp:nypd@example.com 636 S: 911 637 S: 639 Figure 8: findService with Service Boundary Reference 641 C: 642 C: 645 S: 646 S: 649 S: 650 S: 652 S: 653 S: 654 S: 655 S: 40.701 -74.020 656 S: 40.876 -73.926 657 S: 40.797 -73.936 658 S: 40.714 -73.984 659 S: 40.701 -74.020 660 S: 661 S: 662 S: 663 S: 664 S: 665 S: 667 Figure 9: Requesting a Service Boundary with getServiceBoundary 669 The request may also be used to retrieve service 670 boundaries that are expressed as civic addresses, as illustrated in 671 Figure 10. 673 674 676 678 680 US 681 New York 682 New York 683 684 685 687 Figure 10: Civic Address Service Boundary Response 689 8. List Services: 691 A LoST client can ask a LoST server for the list of services it 692 supports. The query contains one or more 693 elements, each from a different location profile (Section 9), and may 694 contain the element. If the query contains the 695 element the LoST server returns only immediate child services of the 696 queried service that are available for the provided location. If the 697 element is absent, the LoST service returns all top-level 698 services available for the provided location that it knows about. 700 A server responds to this query with a 701 response. This response has may contain elements 702 (Section 6.4.1) and must contain a element, consisting 703 of a whitespace-separated list of service URNs. The query and 704 response are illustrated in Figure 11. 706 C: 707 C: 711 C: 713 C: 714 C: 37:46:30N 122:25:10W 715 C: 716 C: 717 C: urn:service:sos 718 C: 720 S: 721 S: 722 S: 723 S: urn:service:sos.ambulance 724 S: urn:service:sos.animal-control 725 S: urn:service:sos.fire 726 S: urn:service:sos.gas 727 S: urn:service:sos.mountain 728 S: urn:service:sos.marine 729 S: urn:service:sos.physician 730 S: urn:service:sos.poison 731 S: urn:service:sos.police 732 S: urn:service:sos.suicide 733 S: 734 S: 735 Figure 11: ListService Query Example 737 9. Location Profiles 739 Currently, LoST uses location information in elements in 740 requests and elements in responses. Such location 741 information may be expressed in a variety of ways. This variety can 742 cause interoperability problems where a request or response contains 743 location information in a format not understood by the server or 744 client, respectively. To achieve interoperability, LoST defines two 745 must-implement baseline location profiles to define the manner in 746 which location information is transmitted and makes it possible to 747 standardize other profiles in the future. The two baseline profiles 748 are: 750 geodetic-2d: a simple profile for two-dimensional geodetic location 751 information, described in Section 9.2); 753 civic: a profile consisting of civic address location information, 754 described in Section 9.3. 756 Requests and responses containing or 757 elements MUST contain location information in exactly one of the two 758 baseline profiles, in addition to zero or more additional profiles. 759 The ordering of location information indicates a preference on the 760 part of the sender. 762 Standards action may create other profiles. A location profile MUST 763 define: 765 1. The token identifying it in the LoST location profile registry; 767 2. The formal definition of the XML to be used in requests, i.e., an 768 enumeration and definition of the XML child elements of the 769 element; 771 3. The formal definition of the XML to be used in responses, i.e., 772 an enumeration and definition of the XML child elements of the 773 the element; 775 4. The declaration of whether geodetic-2d or civic is to be used as 776 the baseline profile. It is necessary to explicitly declare the 777 baseline profile as future profiles may be combinations of 778 geodetic and civic location information. 780 9.1. Location Profile Usage 782 A location profile is identified by a URN in the 783 urn:ietf:params:lost:location-profile registry. (Note that this is 784 not an XML schema or namespace identifier.) Clients send location 785 information compliant with a location profile, and servers respond 786 with location information compliant with that same location profile. 788 When a LoST client sends a request which provides location 789 information, it contains one or more elements. Each of 790 these elements contains location information compliant with a 791 location profile and specifies which profile has been used in the 792 'profile' attribute. This allows the client to convey location 793 information for multiple location profiles in the same request. 795 When a LoST server sends a response which contains location 796 information, it uses the elements much like the 797 client uses the elements. Each element 798 contains location information conformant to the location profile 799 specified in the 'profile' attribute. This allows the server to send 800 location information compliant with multiple location profiles. 802 Using the location profiles defined in this document, the following 803 rules insure basic interoperatiblity between clients and servers: 805 1. A client MUST be capable of understanding the response for the 806 baseline profiles it used in the request. 808 2. If a client sends location information conformant to any location 809 profile other than geodetic-2d or civic, it MUST also send, in 810 the same request, location information conformant to one of the 811 baseline profiles. Otherwise, the server might not be able to 812 understand the request. 814 3. Servers MUST implement the geodetic-2d and civic profiles. 816 4. A server ignores any location information using non-baseline 817 profiles it does not understand. 819 5. If a server receives a request that only contains location 820 information using profiles it does not understand, the server 821 responds with a (Section 10.2). 823 These rules enable the use of location profiles not yet specified, 824 while ensuring baseline interoperability. Take, for example, this 825 scenario. Client X has had its firmware upgraded to support the 826 uber-complex-3D location profile. Client X sends location 827 information to Server Y, which does not understand the 828 uber-complex-3D location profile. If Client X also sends location 829 information using the geodetic-2D baseline profile, then Server Y 830 will still be able to understand the request and provide an 831 understandable response, though with location information that might 832 not be as precise or expressive as desired. This is possible because 833 both Client X and Server Y understand the baseline profile. The 834 following transaction, where the XML sent by the client is prepended 835 with 'C:' and the XML sent by the server is prepended with 'S:', 836 demonstrates this: 838 C: 839 C: 842 C: 844 C: 845 C: 40.8089897 -73.9612492 846 C: 847 C: 848 C: 851 C: 852 C: 37.775 -122.422 25 853 C: 854 C: 855 C: 856 C: 857 C: 40.80 -73.96 24 858 C: 40.81 -73.95 27 859 C: 40.80 -73.96 24 860 C: 861 C: 862 C: 863 C: 864 C: urn:service:sos.police 865 C: 867 S: 868 S: 870 S: 874 S: 875 S: New York City Police Department 876 S: 877 S: urn:service:sos.police 878 S: 880 S: 881 S: 882 S: 883 S: 40.701 -74.020 884 S: 40.876 -73.926 885 S: 40.797 -73.936 886 S: 40.714 -73.984 887 S: 40.701 -74.020 888 S: 889 S: 890 S: 891 S: 892 S: sip:nypd@example.com 893 S: 895 Figure 12: Example of a findServices query with baseline profile 896 interoperability 898 9.2. Two Dimensional Geodetic Profile 900 The geodetic-2d location profile is identified by geodetic-2d. 901 Clients use this profile by placing a GML [13] element 902 within the element. This is defined by the 'point2D' 903 pattern in the LoST schema (see Section 12). 905 Servers use this profile by placing a GML [13] element 906 within the element. This is defined by the 907 'polygon' pattern in the LoST schema (see Section 12). 909 9.3. Basic Civic Profile 911 The basic-civic location profile is identified by the token 'civic'. 912 Clients use this profile by placing a element, defined 913 in [11], within the element. 915 Servers use this profile by placing a element, defined 916 in [11], within the element. 918 10. Error Handling 920 Errors are indicated by error-specific elements. Depending on the 921 nature of the error, the error element may occur along with other 922 response elements, indicating that the request was only partially 923 satisfied and that not all information in the request was processed 924 correctly. Errors labeled as fatal means 926 10.1. Basic Errors 928 LoST defines a pattern for errors, defined as "errors" in the Relax 929 NG schema. This pattern defines a 'message' attribute containing 930 human readable text and an 'xml:lang' attribute denoting the language 931 of the human readable text. 933 LoST defines the following elements as following this pattern: 935 badRequest The server could not parse or otherwise understand a 936 request. This is a top-level element, and is returned if the 937 server did not understand the outermost LoST XML element 938 identifying the request. 940 serviceSubstitution The server substituted one service for another. 941 See Section 6.4.4. 943 10.2. Response Errors 945 LoST defines a pattern for errors that may generated by referrent 946 LoST serves queried on behalf of seekers by a resolving LoST server. 947 This pattern builds on the basic errors pattern (Section 10.1). It 948 also provides the option of specifying the source server using the 949 'source' attribute, as well as specifying the query that caused the 950 error. 952 LoST defines the following elements as following this pattern: 954 forbidden The server refused to send an answer. 956 notFound The server could not find an answer to the query. 958 serviceNotImplemented The requested service is not implemented. 960 internalError The server could not satisfy a request due to 961 misconfiguration or other operational and non-protocol related 962 reasons. 964 serverTimeout A time out occurred before an answer was received. 966 serverError An answer was received but it could not be parsed or 967 otherwise understood. 969 locationProfileError A location profile in the query given is not 970 recognized. The element may also have an 'unsupportedProfiles' 971 attribute, which contains a whitespace separated list of profile 972 URNs. See Section 9. 974 10.3. Redirects 976 LoST defines a pattern for redirect responses. This pattern builds 977 on the basic error pattern (Section 10.1) and includes a 'url' 978 attribute indicating the LoST URL that the client should be 979 contacting next. 981 Currently, LoST only defines the element along this 982 pattern. 984 11. LoST Transport 986 LoST needs an underlying protocol transport mechanisms to carry 987 requests and responses. This document defines the use of LoST over 988 HTTP and HTTP-over-TLS; other mechanisms are left to future 989 documents. The available transport mechanisms are determined through 990 the use of the LoST U-NAPTR application. In protocols that support 991 content type indication, LoST uses the media type application/ 992 lost+xml. 994 When using HTTP [3] and HTTP-over-TLS [5], LoST requests use the HTTP 995 POST method. All HTTP responses are applicable. The HTTP URL is 996 derived from the LoST URL via U-NAPTR application, as discussed in 997 Section 5. 999 12. Relax NG Schema 1001 This section provides the Relax NG schema used by LoST protocol in 1002 the compact form. The verbose form is included in Appendix A. 1004 default namespace = "http://www.opengis.net/gml" 1005 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 1006 namespace ns1 = "urn:ietf:params:xml:ns:lost1" 1008 ## 1009 ## Location-to-Service Translation Protocol (LoST) 1010 ## 1011 ## A LoST XML instance has three request types, each with 1012 ## a cooresponding response type: find service, list services, 1013 ## and get service boundary. 1014 ## 1015 start = 1016 findService 1017 | listServices 1018 | getServiceBoundary 1019 | findServiceResponse 1020 | listServicesResponse 1021 | getServiceBoundaryResponse 1023 ## 1024 ## The queries. 1025 ## 1026 div { 1027 findService = 1028 element ns1:findService { 1029 query, 1030 attribute include { 1031 list { 1032 ("uri" 1033 | "serviceNumber" 1034 | "displayName" 1035 | "service" 1036 | "valid" 1037 | "invalid" 1038 | "unchecked" 1039 | "serviceBoundary" 1040 | "serviceBoundaryReference")* 1041 } 1042 >> a:defaultValue [ "uri serviceNumber" ] 1043 }? 1044 } 1046 listServices = element ns1:listServices { query } 1047 getServiceBoundary = 1048 element ns1:getServiceBoundary { 1049 serviceBoundaryKey, extensionPoint 1050 } 1051 } 1053 ## 1054 ## The responses. 1055 ## 1056 div { 1057 findServiceResponse = 1058 element ns1:findServiceResponse { 1059 via, 1060 ((locationProfileError?, serviceSubstitution?, serviceResult) 1061 | badRequest 1062 | internalError 1063 | forbidden 1064 | notFound 1065 | serviceNotImplemented 1066 | serverTimeout 1067 | serverError 1068 | movedPermenantly 1069 | movedTemporarily 1070 | iterativeSearchExhausted), 1071 extensionPoint 1072 } 1073 listServicesResponse = 1074 element ns1:listServicesResponse { 1075 via, 1076 ((locationProfileError?, 1077 element ns1:serviceList { 1078 list { xsd:anyURI* } 1079 })), 1080 extensionPoint 1081 } 1082 getServiceBoundaryResponse = 1083 element ns1:getServiceBoundaryResponse { 1084 (serviceBoundary 1085 | badRequest 1086 | internalError 1087 | forbidden 1088 | notFound), 1089 extensionPoint 1090 } 1091 } 1093 ## 1094 ## A pattern common to some of the queries. 1095 ## 1096 div { 1097 query = 1098 element ns1:location { locationInformation }+, 1099 element ns1:service { xsd:anyURI }?, 1100 extensionPoint, 1101 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 1102 } 1104 ## 1105 ## Location Information 1106 ## 1107 div { 1108 locationInformation = 1109 extensionPoint+, 1110 attribute profile { xsd:anyURI } 1111 } 1113 ## 1114 ## Service Boundary 1115 ## 1116 div { 1117 serviceBoundary = element ns1:serviceBoundary 1118 { locationInformation }+ 1119 } 1121 ## 1122 ## Service Boundary Key 1123 ## 1124 div { 1125 serviceBoundaryKey = 1126 attribute key { 1127 xsd:string { pattern = "[a-zA-Z0-9/+=]+" } 1128 } 1129 } 1131 ## 1132 ## Via - list of places through which information flowed 1133 ## 1134 div { 1135 via = element ns1:via { xsd:anyURI }* 1136 } 1138 ## 1139 ## Time-to-live pattern 1140 ## 1141 div { 1142 timeToLive = attribute timeToLive { xsd:positiveInteger } 1143 } 1145 ## 1146 ## A QName list 1147 ## 1148 div { 1149 qnameList = list { xsd:QName* } 1150 } 1152 ## 1153 ## A location-to-service result. 1154 ## 1155 div { 1156 serviceResult = 1157 element ns1:displayName { 1158 xsd:string, 1159 attribute xml:lang { xsd:language } 1160 }?, 1161 element ns1:service { xsd:anyURI }?, 1162 (serviceBoundary 1163 | element ns1:serviceBoundaryReference { serviceBoundaryKey })?, 1164 element ns1:uri { xsd:anyURI }*, 1165 element ns1:serviceNumber { 1166 xsd:string { pattern = "[0-9]+" } 1167 }?, 1168 element ns1:valid { qnameList }?, 1169 element ns1:invalid { qnameList }?, 1170 element ns1:unchecked { qnameList }?, 1171 extensionPoint, 1172 timeToLive, 1173 message 1174 } 1176 ## 1177 ## Basic Errors 1178 ## 1179 div { 1181 ## 1182 ## Error pattern. 1183 ## 1184 error = message, extensionPoint 1185 badRequest = element ns1:badRequest { error } 1186 internalError = element ns1:internalError { error } 1187 serviceSubstitution = element ns1:serviceSubstitution { error } 1188 } 1189 ## 1190 ## Recursion Errors. 1191 ## 1192 div { 1194 ## 1195 ## Recursion error. 1196 ## 1197 recursionError = 1198 attribute failedReferral { xsd:anyURI }?, 1199 (findService | listServices | getServiceBoundary)?, 1200 error 1201 forbidden = 1202 element ns1:forbidden { recursionError }, 1203 timeToLive 1204 notFound = 1205 element ns1:notFound { recursionError }, 1206 timeToLive 1207 serviceNotImplemented = 1208 element ns1:serviceNotImplemented { recursionError }, 1209 timeToLive 1210 serverTimeout = 1211 element ns1:serverTimeout { recursionError }, 1212 timeToLive 1213 serverError = 1214 element ns1:serverError { recursionError }, 1215 timeToLive 1216 locationProfileError = 1217 element ns1:locationProfileError { 1218 attribute unsupportedProfiles { 1219 list { xsd:anyURI* } 1220 }, 1221 recursionError 1222 } 1223 } 1225 ## 1226 ## Redirects. 1227 ## 1228 div { 1230 ## 1231 ## Redirect pattern 1232 ## 1233 redirect = 1234 attribute redirect { xsd:anyURI }, 1235 error 1236 movedPermenantly = element ns1:movedPermanently { redirect } 1237 movedTemporarily = 1238 element ns1:movedTemporarily { redirect }, 1239 timeToLive 1240 iterativeSearchExhausted = 1241 element ns1:iterativeSearchExhausted { redirect }, 1242 timeToLive 1243 } 1245 ## 1246 ## Message pattern. 1247 ## 1248 div { 1249 message = 1250 (attribute message { xsd:string }, 1251 attribute xml:lang { xsd:language })? 1252 } 1254 ## 1255 ## Patterns for inclusion of elements from schemas in 1256 ## other namespaces. 1257 ## 1258 div { 1260 ## 1261 ## Any element not in the LoST namespace. 1262 ## 1263 notLost = element * - (ns1:* | ns1:*) { anyElement } 1265 ## 1266 ## A wildcard pattern for including any element 1267 ## from any other namespace. 1268 ## 1269 anyElement = 1270 (element * { anyElement } 1271 | attribute * { text } 1272 | text)* 1274 ## 1275 ## A point where future extensions 1276 ## (elements from other namespaces) 1277 ## can be added. 1278 ## 1279 extensionPoint = notLost* 1281 ## 1282 ## A 2D point from GML. 1283 ## 1284 point2d = 1285 element position { 1286 element Point { 1287 attribute srsName { "urn:ogc:def:crs:EPSG:4326" }, 1288 element pos { text } 1289 } 1290 } 1292 ## 1293 ## A Linear Ring from GML. 1294 ## 1295 linearRing = 1296 element LinearRing { 1297 element pos { text } 1298 } 1300 ## 1301 ## A Polygon from GML. 1302 ## 1303 polygon = 1304 element Polygon { 1305 attribute srsName { "urn:ogc:def:crs:EPSG:4979" }, 1306 element exterior { linearRing }, 1307 element interior { linearRing }* 1308 } 1309 } 1311 13. Internationalization Considerations 1313 This mechanism is largely for passing protocol information from one 1314 subsystem to another; as such, most of its elements are tokens not 1315 meant for direct human consumption. If these tokens are presented to 1316 the end user, some localization may need to occur. The content of 1317 the element and the 'message' attributes may be 1318 displayed to the end user, and they are thus a complex types designed 1319 for this purpose. 1321 LoST exchanges information using XML. All XML processors are 1322 required to understand UTF-8 and UTF-16 encodings, and therefore all 1323 LoST clients and servers MUST understand UTF-8 and UTF-16 encoded 1324 XML. Additionally, LoST servers and clients MUST NOT encode XML with 1325 encodings other than UTF-8 or UTF-16. 1327 14. IANA Considerations 1329 14.1. U-NAPTR Registrations 1331 This document registers the following U-NAPTR application service 1332 tag: 1334 Application Service Tag: LoST 1336 Defining Publication: The specification contained within this 1337 document. 1339 This document registers the following U-NAPTR application protocol 1340 tags: 1342 o 1344 Application Protocol Tag: http 1346 Defining Publication: RFC 2616 [3] 1348 o 1350 Application Protocol Tag: https 1352 Defining Publication: RFC 2818 [5] 1354 14.2. Content-type registration for 'application/lost+xml' 1356 This specification requests the registration of a new MIME type 1357 according to the procedures of RFC 4288 [9] and guidelines in RFC 1358 3023 [6]. 1360 MIME media type name: application 1362 MIME subtype name: lost+xml 1364 Mandatory parameters: none 1366 Optional parameters: charset 1368 Indicates the character encoding of enclosed XML. 1370 Encoding considerations: 1372 Uses XML, which can employ 8-bit characters, depending on the 1373 character encoding used. See RFC 3023 [6], Section 3.2. 1375 Security considerations: 1377 This content type is designed to carry LoST protocol payloads. 1379 Interoperability considerations: None 1381 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 1382 replace XXXX with the RFC number of this specification.] this 1383 document 1385 Applications which use this media type: 1387 Emergency and Location-based Systems 1389 Additional information: 1391 Magic Number: None 1393 File Extension: .lostxml 1395 Macintosh file type code: 'TEXT' 1397 Personal and email address for further information: Hannes 1398 Tschofenig, Hannes.Tschofenig@siemens.com 1400 Intended usage: LIMITED USE 1402 Author: 1404 This specification is a work item of the IETF ECRIT working group, 1405 with mailing list address . 1407 Change controller: 1409 The IESG 1411 14.3. LoST Relax NG Schema Registration 1413 URI: urn:ietf:params:xml:ns:lost 1415 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1416 (Hannes.Tschofenig@siemens.com). 1418 Relax NG Schema: The Relax NG schema to be registered is contained 1419 in Section 12. Its first line is 1421 default namespace = "urn:ietf:params:xml:ns:lost1" 1423 and its last line is 1425 } 1427 14.4. LoST Namespace Registration 1429 URI: urn:ietf:params:xml:ns:lost 1431 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1432 (Hannes.Tschofenig@siemens.com). 1434 XML: 1436 BEGIN 1437 1438 1440 1441 1442 1444 LoST Namespace 1445 1446 1447

Namespace for LoST

1448

urn:ietf:params:xml:ns:lost

1449

See RFCXXXX 1450 [NOTE TO IANA/RFC-EDITOR: 1451 Please replace XXXX with the RFC number of this 1452 specification.].

1453 1454 1455 END 1457 14.5. Registration Template 1459 This registration template is in accordance with [4]. 1461 URL scheme name: 1463 lost 1465 URL scheme syntax: 1467 See Section 5 1469 Character encoding considerations: 1471 See Section 5 1473 Intended Use: 1475 The intended usage is described in this document. 1477 Application and protocols which use this scheme: 1479 The usage of the LoST URL scheme is targeted for this document and 1480 hence for location-based services that make use of the mapping 1481 protocol specified in this document. 1483 Interoperability considerations: 1485 None 1487 Security considerations: 1489 See Section 15 1491 Relevant publications: 1493 This document provides the relevant context for this URL scheme. 1495 Contact: 1497 Hannes Tschofenig, Hannes.Tschofenig@siemens.com 1499 Author/Change controller: 1501 The IESG 1503 14.6. LoST Location Profile Registry 1505 This document seeks to create a registry of location profile names 1506 for the LoST protocol. Profile names are XML tokens. This registry 1507 will operate in accordance with RFC 2434 [2], Standards Action. 1509 geodetic-2d: Defined in TBD 1511 civic: Defined in TBD 1513 15. Security Considerations 1515 There are multiple threats to the overall system of which service 1516 mapping forms a part. An attacker that can obtain service contact 1517 URIs can use those URIs to attempt to disrupt those services. An 1518 attacker that can prevent the lookup of contact URIs can impair the 1519 reachability of such services. An attacker that can eavesdrop on the 1520 communication requesting this lookup can surmise the existence of an 1521 emergency and possibly its nature, and may be able to use this to 1522 launch a physical attack on the caller. 1524 To avoid that an attacker can modify the query or its result, the use 1525 of channels security, such as TLS, is RECOMMENDED. 1527 A more detailed description of threats and security requirements are 1528 provided in [17]. 1530 16. Acknowledgments 1532 [Editor's Note: Names need to be added here. Forgot it...Sorry.] 1534 17. Open Issues 1536 Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ 1538 18. References 1540 18.1. Normative References 1542 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1543 Levels", BCP 14, RFC 2119, March 1997. 1545 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1546 Considerations Section in RFCs", BCP 26, RFC 2434, 1547 October 1998. 1549 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1550 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1551 HTTP/1.1", RFC 2616, June 1999. 1553 [4] Petke, R. and I. King, "Registration Procedures for URL Scheme 1554 Names", BCP 35, RFC 2717, November 1999. 1556 [5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1558 [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1559 RFC 3023, January 2001. 1561 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1562 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1563 January 2005. 1565 [8] Peterson, J., "A Presence-based GEOPRIV Location Object 1566 Format", RFC 4119, December 2005. 1568 [9] Freed, N. and J. Klensin, "Media Type Specifications and 1569 Registration Procedures", BCP 13, RFC 4288, December 2005. 1571 [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", 1572 draft-ietf-ecrit-service-urn-05 (work in progress), 1573 August 2006. 1575 [11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 1576 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in 1577 progress), September 2006. 1579 [12] Daigle, L., "Domain-based Application Service Location Using 1580 URIs and the Dynamic Delegation Discovery Service (DDDS)", 1581 draft-daigle-unaptr-00 (work in progress), June 2006. 1583 [13] OpenGIS, "Open Geography Markup Language (GML) Implementation 1584 Specification", OGC OGC 02-023r4, January 2003. 1586 18.2. Informative References 1588 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1589 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1590 Session Initiation Protocol", RFC 3261, June 2002. 1592 [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1593 Protocol (XMPP): Instant Messaging and Presence", RFC 3921, 1594 October 2004. 1596 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 1597 December 2004. 1599 [17] Taylor, T., "Security Threats and Requirements for Emergency 1600 Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 1601 (work in progress), July 2006. 1603 [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 1604 Context Resolution with Internet Technologies", 1605 draft-ietf-ecrit-requirements-12 (work in progress), 1606 August 2006. 1608 [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1609 Framework", draft-ietf-ecrit-mapping-arch-00 (work in 1610 progress), August 2006. 1612 [20] Rosen, B. and J. Polk, "Best Current Practice for 1613 Communications Services in support of Emergency Calling", 1614 draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006. 1616 Appendix A. Non-Normative RELAX NG Schema in XML Syntax 1618 1619 1624 1625 1626 Location-to-Service Translation Protocol (LoST) 1628 A LoST XML instance has three request types, each with 1629 a cooresponding response type: find service, list services, 1630 and get service boundary. 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1642
1643 1644 The queries. 1645 1647 1648 1649 1650 1651 1652 1653 1654 1655 uri 1656 serviceNumber 1657 displayName 1658 service 1659 valid 1660 invalid 1661 unchecked 1662 serviceBoundary 1663 serviceBoundaryReference 1664 1665 1666 1667 uri serviceNumber 1668 1669 1670 1671 1673 1674 1675 1676 1677 1679 1680 1681 1682 1683 1684 1686
1688
1689 1690 The responses. 1691 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1757
1759
1760 1761 A pattern common to some of the queries. 1762 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 true 1780 1781 1782 1784
1786
1787 1788 Location Information 1789 1791 1792 1793 1794 1795 1796 1797 1798 1799
1801
1802 1803 Service Boundary 1804 1805 1806 1807 1808 1809 1810 1811 1812
1814
1815 1816 Service Boundary Key 1817 1819 1820 1821 1822 [a-zA-Z0-9/+=]+ 1823 1824 1825 1826
1828
1829 1830 Via - list of places through which information flowed 1831 1833 1834 1835 1836 1837 1838 1839 1840
1842
1843 1844 Time-to-live pattern 1845 1847 1848 1849 1850 1851 1852
1853
1854 1855 A QName list 1856 1858 1859 1860 1861 1862 1863 1864 1865
1867
1868 1869 A location-to-service result. 1870 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 [0-9]+ 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1926
1928
1929 1930 Basic Errors 1931 1933 1934 1935 Error pattern. 1936 1937 1938 1939 1941 1942 1943 1944 1945 1947 1948 1949 1950 1951 1953 1954 1955 1956 1957 1959
1961
1962 1963 Recursion Errors. 1964 1966 1967 1968 Recursion error. 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1985 1986 1987 1988 1989 1990 1992 1993 1994 1995 1996 1998 2000 2001 2002 2003 2004 2005 2007 2008 2009 2010 2011 2012 2014 2015 2016 2017 2018 2019 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2034
2036
2037 2038 Redirects. 2039 2041 2042 2043 Redirect pattern 2044 2045 2046 2047 2048 2049 2051 2052 2053 2054 2055 2057 2058 2059 2060 2061 2062 2064 2065 2066 2067 2068 2069 2071
2073
2074 2075 Message pattern. 2076 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2091
2093
2094 2095 Patterns for inclusion of elements from schemas in 2096 other namespaces. 2097 2099 2100 2101 Any element not in the LoST namespace. 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2114 2115 2116 A wildcard pattern for including any element 2117 from any other namespace. 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2133 2134 2135 A point where future extensions 2136 (elements from other namespaces) 2137 can be added. 2138 2139 2140 2142 2143 2145 2146 2147 A 2D point from GML. 2148 2149 2150 2151 2152 urn:ogc:def:crs:EPSG:4326 2153 2154 2155 2156 2157 2158 2159 2161 2162 2163 A Linear Ring from GML. 2164 2165 2166 2167 2168 2169 2170 2172 2173 2174 A Polygon from GML. 2175 2176 2177 2178 urn:ogc:def:crs:EPSG:4979 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2191
2193 2195 Authors' Addresses 2197 Ted Hardie 2198 Qualcomm, Inc. 2200 Email: hardie@qualcomm.com 2202 Andrew Newton 2203 SunRocket 2204 8045 Leesburg Pike, Suite 300 2205 Vienna, VA 22182 2206 US 2208 Phone: +1 703 636 0852 2209 Email: andy@hxr.us 2211 Henning Schulzrinne 2212 Columbia University 2213 Department of Computer Science 2214 450 Computer Science Building 2215 New York, NY 10027 2216 US 2218 Phone: +1 212 939 7004 2219 Email: hgs+ecrit@cs.columbia.edu 2220 URI: http://www.cs.columbia.edu 2222 Hannes Tschofenig 2223 Siemens 2224 Otto-Hahn-Ring 6 2225 Munich, Bavaria 81739 2226 Germany 2228 Phone: +49 89 636 40390 2229 Email: Hannes.Tschofenig@siemens.com 2230 URI: http://www.tschofenig.com 2232 Full Copyright Statement 2234 Copyright (C) The Internet Society (2006). 2236 This document is subject to the rights, licenses and restrictions 2237 contained in BCP 78, and except as set forth therein, the authors 2238 retain all their rights. 2240 This document and the information contained herein are provided on an 2241 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2242 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2243 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2244 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2245 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2246 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2248 Intellectual Property 2250 The IETF takes no position regarding the validity or scope of any 2251 Intellectual Property Rights or other rights that might be claimed to 2252 pertain to the implementation or use of the technology described in 2253 this document or the extent to which any license under such rights 2254 might or might not be available; nor does it represent that it has 2255 made any independent effort to identify any such rights. Information 2256 on the procedures with respect to rights in RFC documents can be 2257 found in BCP 78 and BCP 79. 2259 Copies of IPR disclosures made to the IETF Secretariat and any 2260 assurances of licenses to be made available, or the result of an 2261 attempt made to obtain a general license or permission for the use of 2262 such proprietary rights by implementers or users of this 2263 specification can be obtained from the IETF on-line IPR repository at 2264 http://www.ietf.org/ipr. 2266 The IETF invites any interested party to bring to its attention any 2267 copyrights, patents or patent applications, or other proprietary 2268 rights that may cover technology that may be required to implement 2269 this standard. Please address the information to the IETF at 2270 ietf-ipr@ietf.org. 2272 Acknowledgment 2274 Funding for the RFC Editor function is provided by the IETF 2275 Administrative Support Activity (IASA).