idnits 2.17.1 draft-ietf-ecrit-lost-03.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, updated by RFC 4748 on line 2630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2654. 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 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 (January 17, 2007) is 6310 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-01 -- 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-01 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-00 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT T. Hardie 3 Internet-Draft Qualcomm, Inc. 4 Intended status: Standards Track A. Newton 5 Expires: July 21, 2007 SunRocket 6 H. Schulzrinne 7 Columbia U. 8 H. Tschofenig 9 Siemens Networks GmbH & Co KG 10 January 17, 2007 12 LoST: A Location-to-Service Translation Protocol 13 draft-ietf-ecrit-lost-03.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 July 21, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 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. Terminology and Requirements Notation . . . . . . . . . . . . 6 55 3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7 56 4. LoST Uniform Resource Locators and Their Resolution . . . . . 8 57 5. The Element . . . . . . . . . . . . . . . . . . . . 9 58 5.1. Data source and version: The 'source', 'sourceId' and 59 'version' Attributes . . . . . . . . . . . . . . . . . . . 9 60 5.2. Time of Last Update: The 'lastUpdated' Attribute . . . . . 9 61 5.3. Validity: The 'expires' Attribute . . . . . . . . . . . . 9 62 5.4. Describing the Service with the Element . . 10 63 5.5. The Mapped Service: the Element . . . . . . . . 10 64 5.6. Defining the Service Region with the 65 Element . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.7. Service Boundaries by Reference: the 67 Element . . . . . . . . . . . . 11 68 5.8. The Service Number . . . . . . . . . . . . . . . . . . . . 11 69 5.9. Service URLs: the Element . . . . . . . . . . . . . 11 70 6. Path of Request: Element . . . . . . . . . . . . . . . 12 71 7. Mapping a Location and Service to URLs: . . . . 13 72 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 13 75 7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 14 76 7.3. Components of the Request . . . . . . . . . 16 77 7.3.1. The Element . . . . . . . . . . . . . . . . 16 78 7.3.2. Identifying the Service: The Element . . . 17 79 7.3.3. Recursion . . . . . . . . . . . . . . . . . . . . . . 17 80 7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 17 81 7.3.5. Requesting Civic Location Validation . . . . . . . . . 17 82 7.4. Components of the Mapping Response 83 . . . . . . . . . . . . . . . . . . 19 84 7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 19 85 7.4.2. Civic Address Validation: the 86 Element . . . . . . . . . . . . . 20 87 8. Retrieving the Service Boundary via . . . 21 88 9. List Services: . . . . . . . . . . . . . . . . 24 89 10. List Services By Location: . . . . . 25 90 11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 27 91 11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 28 92 11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 30 93 11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 31 94 12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 32 95 12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 32 96 12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 34 98 13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 35 99 14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 36 100 15. Internationalization Considerations . . . . . . . . . . . . . 43 101 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 102 16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 44 103 16.2. Content-type registration for 'application/lost+xml' . . . 44 104 16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 46 105 16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 46 106 16.5. URL Registration Template . . . . . . . . . . . . . . . . 47 107 16.6. LoST Location Profile Registry . . . . . . . . . . . . . . 48 108 17. Security Considerations . . . . . . . . . . . . . . . . . . . 49 109 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 110 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 52 111 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 112 20.1. Normative References . . . . . . . . . . . . . . . . . . . 53 113 20.2. Informative References . . . . . . . . . . . . . . . . . . 54 114 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 55 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 116 Intellectual Property and Copyright Statements . . . . . . . . . . 70 118 1. Introduction 120 This document describes a protocol for mapping a service identifier 121 [10] and location information compatible with PIDF-LO [8], namely 122 revised civic location information [11] and GML [13]) to one or more 123 service URL. Example service URL schemes include sip [14], xmpp 124 [15], and tel [16]. While the initial focus is on providing mapping 125 functions for emergency services, it is likely that the protocol is 126 applicable to any service URN. For example, in the United States, 127 the "2-1-1" and "3-1-1" service numbers follow a similar location-to- 128 service behavior as emergency services. 130 This document names this protocol "LoST", for Location-to-Service 131 Translation. LoST Satisfies the requirements [18] for mapping 132 protocols. LoST provides a number of operations, centered around 133 mapping locations and service URNs to service URLs and associated 134 information. LoST mapping queries can contain either civic or 135 geodetic location information. For civic addresses, LoST can 136 indicate which parts of the civic address are known to be valid or 137 invalid, thus providing address validation (see Section 3.5 of [18] 138 for a description of validation). LoST indicates errors in the 139 location data to facilitate debugging and proper user feedback, but 140 also provides best-effort answers. 142 LoST queries can be resolved recursively or iteratively. To minimize 143 round trips and to provide robustness against network failures, LoST 144 caches individual mappings and indicates the region for which the 145 same answer would be returned ("service region"). 147 As defined in this document, LoST messages are carried in HTTP and 148 HTTPS protocol exchanges, facilitating use of TLS for protecting the 149 integrity and confidentiality of requests and responses. 151 This document focuses on the description of the protocol between the 152 mapping client (seeker or resolver) and the mapping server (resolver 153 or other servers). The relationship between other functions, such as 154 discovery of mapping servers, data replication and the overall 155 mapping server architecture are described in a separate document 156 [19]. 158 The query message carries location information and a service 159 identifier encoded as a Uniform Resource Name (URN) (see [10]) from 160 the LoST client to the LoST server. The LoST server uses its 161 database to map the input values to one or more Uniform Resource 162 Identifiers (URI) and returns those URIs along with optional 163 information, such as hints about the service boundary, in a response 164 message to the LoST client. If the server cannot resolve the query 165 itself, it may in turn query another server or return the address of 166 another LoST server, identified by a LoST URL (Section 4). In 167 addition to the mapping function described in Section 7, the protocol 168 also allows to retrieve the service boundary (see Section 8) and to 169 list the services available for a particular location (see 170 Section 10) or supported by a particular server (see Section 9). 172 2. Terminology and Requirements Notation 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [1]. 178 This document furthermore uses the terminology defined in [18]. 180 3. Overview of Protocol Usage 182 The client may perform the mapping at any time. Among the common 183 triggers for mapping requests are: 185 1. When the client initially starts up or attaches to a network. 187 2. When the client detects that its location has changed 188 sufficiently that it is outside the bounds of the service region 189 returned in an earlier LoST query. 191 3. When cached mapping information has expired. 193 4. When invoking a particular service. At that time, a client may 194 omit requests for service boundaries or other auxiliary 195 information. 197 A service-specific Best Current Practice (BCP) document, such as 198 [20], governs whether a client is expected to invoke the mapping 199 service just before needing the service or whether to rely on cached 200 answers. Cache entries expire at their expiration time (see 201 Section 5.3), or they become invalid if the caller's device moves 202 beyond the boundaries of the service region. 204 4. LoST Uniform Resource Locators and Their Resolution 206 LoST servers are identified by LoST Uniform Resource Locators (URLs), 207 which follow the format of URLs defined in RFC 3986 [7], with the 208 following ABNF: 210 LoST-URI = "lost:" host 212 'host' is defined in Section 3.2.2 of RFC 3986 [7]. 214 An example is 'lost:lostserver.example.com' 216 If a LoST URL contains a host name rather than an IP address, clients 217 need to use U-NAPTR [12] using the U-NAPTR specification described 218 below to obtain a URI (indicating host and protocol) for the 219 applicable LoST service. In this document, only the HTTP and HTTPS 220 URL schemes are defined. Note that the HTTP URL can be any valid 221 HTTP URL, including those containing path elements. 223 The following two DNS entries resolve the LoST URL "lost:example.com" 224 to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL 225 http://lostserver.example.com, with the former being preferred. 227 example.com. 229 IN NAPTR 100 10 "u" "LoST:https" 230 "!*.!https://lostserver.example.com/secure!" "" 232 IN NAPTR 200 10 "u" "LoST:http" 233 "!*.!http://lostserver.example.com!" "" 235 5. The Element 237 The element is the core data element in LoST, describing a 238 service region and the associated service URLs. Its parameters 239 indicate when the mapping was last updated, how long it is valid, its 240 version and the authoritative source for the mapping, along with a 241 unique identifier. Elements within the element then 242 provide a human-readable description, the service URN, a service 243 boundary, the service URIs, and a service number. All elements 244 except the service URN are optional. Below, we describe the 245 components in turn. 247 5.1. Data source and version: The 'source', 'sourceId' and 'version' 248 Attributes 250 The 'source', 'sourceId' and 'version' attributes uniquely identify a 251 particular mapping record. They are created by the authoritative 252 source for a mapping and never modified when a mapping is served from 253 a cache. The 'source' attribute contains a LoST URL identifying the 254 authoritative generator of the mapping. The 'sourceId' attribute 255 identifies a particular mapping. The attribute contains a token, 256 which is opaque, but MUST be unique among all different mappings 257 maintained by the authoritative source for that particular service. 258 For example, a UUID is a suitable format. The 'version' attribute is 259 a positive integer that is incremented by one for each change in the 260 mapping. Thus, a higher version number refers to a more recent 261 mapping. A mapping maintains its sourceId value as long as it 262 remains logically the same, e.g., represents the same service 263 boundary or replaces an earlier service boundary. A receiver should 264 be able to replace a mapping with another one having the same 265 'source' and 'sourceId' and a higher version number. All three 266 attributes are REQUIRED for all elements. 268 5.2. Time of Last Update: The 'lastUpdated' Attribute 270 The 'lastUpdated' attribute describes when the mapping was last 271 changed. The contents of this attribute is a timezoned XML type 272 dateTime, in canonical representation. The attribute is REQUIRED. 274 5.3. Validity: The 'expires' Attribute 276 The 'expires' attribute contains the absolute time until which the 277 mapping is to be considered valid. The contents of this attribute is 278 a timezoned XML type dateTime, in canonical representation. See 279 Section 3 regarding how this value is to be utilized with a cache. 280 The 'expires' attribute is REQUIRED to be included in the 281 element. 283 On occasion, a resolver may be forced to return an expired mapping if 284 it cannot reach the authoritative server or the server fails to 285 return a usable answer. Seekers and resolvers MAY cache the mapping 286 so that they have at least some information available. Resolvers 287 SHOULD re-attempt the query each time a seeker requests a mapping. 289 5.4. Describing the Service with the Element 291 The element describes the service with a string that is 292 suitable for display to human users, annotated with the 'xml:lang' 293 attribute that contains a language tag to aid in the rendering of 294 text. 296 5.5. The Mapped Service: the Element 298 The 'service' element identifies the service for which this mapping 299 applies. It is usually the same service URN as in the request. 300 However, if the requested service, identified by the service URN [10] 301 in the element in the request, does not exist for the 302 location indicated, the server can either return an 303 (Section 12.1) error or can provide an 304 alternate service that approximates the desired service for that 305 location. In the latter case, the server MUST include a 306 element with the alternative service URN. The choice of service URN 307 is left to local policy, but the alternate service should be able to 308 satisfy the original service request. The element may also 309 be required if the mapping is to be digitally signed. 311 5.6. Defining the Service Region with the Element 313 A response can indicate the region for which the service URL returned 314 would be the same as in the actual query, the so-called _service 315 region_. The service region can be indicated by value or by 316 reference (see Section 5.7). If a client moves outside the service 317 area and wishes to obtain current service data, it MUST send a new 318 query with its current location. The service region is described by 319 value in one or more elements, each formatted 320 according to a different location profile, identified by the 321 'profile' atribute. The client only processes the first element that 322 it can understand according to its list of supported location 323 profiles. Thus, the elements are alternative descriptions of the 324 same service region, not additive geometries. 326 The server returns all suitable service regions, using all available 327 location profiles, so that intermediate caches have this information 328 available for future queries. 330 5.7. Service Boundaries by Reference: the 331 Element 333 Since geodetic service boundaries may contain thousands of points and 334 thus be quite large, clients may opt to conserve bandwidth and 335 request a reference to the service boundary instead of the value 336 described in Section 5.6. The identifier of the service boundary is 337 returned as an attribute of the element, 338 along with a LoST URL identifying the server from where it can be 339 retrieved. The actual value of the service boundary is then 340 retrieved with the getServiceBoundary (Section 8) request. 342 The identifier is a random token with at least 128 bits of entropy 343 and can be assumed to be globally unique. It uniquely references a 344 particular boundary. If the boundary changes, a new identifier MUST 345 be chosen. Because of these properties, a client receiving a mapping 346 response can simply check if it already has a copy of the boundary 347 with that identifier. If so, it can skip checking with the server 348 whether the boundary has been updated. Since service boundaries are 349 likely to remain unchanged for extended periods of time, possibly 350 exceeding the normal lifetime of the service URL, this approach 351 avoids refreshing the boundary information even if the cached service 352 response has gotten stale. 354 5.8. The Service Number 356 The service number is returned in the optional 357 element. It contains a string of digits, * and # that a user on a 358 device with a 12-key dial pad could use to reach that particular 359 service. 361 5.9. Service URLs: the Element 363 The response returns the service URLs in one or more elements. 364 The URLs MUST be absolute URLs. The ordering of the URLs has no 365 particular significance. Each URL scheme MUST only appear at most 366 once, but it is permissible to include both secured and regular 367 versions of a protocol, such as both 'http' and 'https' or 'sip' and 368 'sips'. 370 6. Path of Request: Element 372 To prevent loops and to allow tracing of request and response paths, 373 all requests that allow recursion include a element that 374 contains one or more elements, each possessing an attribute 375 containing a LoST URL. The order of elements corresponds to 376 the order of LoST servers, i.e., the first element identifies 377 the server that first received the request from the seeker. The 378 authoritative server copies the element verbatim into the 379 response. 381 If a query is answered iteratively, the querier includes all servers 382 that it has already contacted. 384 The example in Figure 5 indicates that the answer was given to the 385 responding server by the LoST server at esgw.ueber-110.de.example, 386 which got the answer from the LoST server at 387 polizei.muenchen.de.example. 389 7. Mapping a Location and Service to URLs: 391 7.1. Overview 393 The query constitutes the core of the LoST 394 functionality, mapping civic or geodetic locations to URLs and 395 associated data. After giving an example, we enumerate the elements 396 of the query and response. 398 7.2. Examples 400 7.2.1. Example Using Geodetic Coordinates 402 The following is an example of mapping a service to a location using 403 geodetic coordinates, for the service associated with the police 404 (urn:service:sos.police). 406 407 413 414 415 37.775 -122.422 416 417 418 urn:service:sos.police 420 422 Figure 2: A geodetic query 424 Given the query above, a server would respond with a service, and 425 information related to that service. In the example below, the 426 server has mapped the location given by the client for a police 427 service to the New York City Police Deparment, instructing the client 428 that it may contact them via the URIs "sip:nypd@example.com" and 429 "xmpp:nypd@example.com". The server has also given the client a 430 geodetic, two-dimensional boundary for this service. The mapping was 431 last updated on November 1, 2006 and expires on January 1, 2007. 432 This instructs the client that if its location changes beyond the 433 give service boundary or the expiration time has been reached, it 434 would need to requery for this information. 436 437 439 444 445 New York City Police Department 446 447 urn:service:sos.police 448 449 450 451 452 37.775 -122.4194 453 37.555 -122.4194 454 37.555 -122.4264 455 37.775 -122.4264 456 37.775 -122.4194 457 458 459 460 461 sip:nypd@example.com 462 xmpp:nypd@example.com 463 911 464 465 466 467 468 469 471 Figure 3: A geodetic answer 473 7.2.2. Civic Address Mapping Example 475 The following is an example of mapping a service to a location much 476 like the example in Section 7.2.1, but using civic address location 477 information. In this example, the client requests the service 478 associated with police (urn:service:sos.police) along with a specific 479 civic address (house number 6 on a street named Otto-Hahn-Ring in 480 Munich, Germany). 482 483 485 487 489 Germany 490 Bavaria 491 Munich 492 Otto-Hahn-Ring 493 6 494 81675 495 496 497 urn:service:sos.police 498 500 Figure 4: A civic address query 502 Given the query above, a server would respond with a service, and 503 information related to that service. In the example below, the 504 server has mapped the location given by the client for a police 505 service to the Muenchen Polizei-Abteilung, instructing the client 506 that it may contact them via the URIs sip:munich-police@example.com 507 and xmpp:munich-police@example.com. The server has also given the 508 client a civic address boundary (the city of Munich) for this 509 service. The mapping was last updated on November 1, 2006 by the 510 authoritative source "lost:polizei.muenchen.de.example" and expires 511 on January 1, 2007. This instructs the client to requery for the 512 information if its location changes beyond the given service boundary 513 (i.e., beyond the city of Munich) or after January 1, 2007. 515 516 517 522 523 Muenchen Polizei-Abteilung 524 525 urn:service:sos.police 526 528 530 Germany 531 Bavaria 532 Munich 533 81675 534 535 536 sip:munich-police@example.com 537 xmpp:munich-police@example.com 538 110 539 540 541 542 543 544 546 Figure 5: A civic address answer 548 7.3. Components of the Request 550 The request includes attributes that govern whether the 551 request is handled iteratively or recursively, whether location 552 validation is performed and which elements must be contained in the 553 response. 555 7.3.1. The Element 557 The query communicates location using one or more 558 elements, which MUST conform to a location profile (see 559 Section 11). There MUST be no more than one location element for 560 each distinct location profile. The order of location objects is 561 significant; the server uses the first location object where it 562 understands the location profile. 564 7.3.2. Identifying the Service: The Element 566 The type of service desired is specified by the element. 567 It contains service URNs from the registry established in [10]. 569 7.3.3. Recursion 571 LoST and queries can be 572 recursive, as indicated by the 'recursive' attribute. A value of 573 "true" indicates a recursive query, with the default being "false" 574 when the attribute is omitted. In recursive mode, the LoST server 575 initiates queries on behalf of the requester and returns the result 576 to the requester, inserting a element to track the response 577 chain. The elements are appended in responses in order of 578 visit, i.e., the first element contains the authoritative 579 server and elements below indicate servers that the response 580 traversed on its way back to the original querier. 582 7.3.4. Service Boundary 584 LoST elements can describe the service boundary either by 585 value or by reference. Returning a service boundary reference is 586 generally more space-efficient for geospatial (polygon) boundaries 587 and if the boundaries change rarely, but does incur an additional 588 request. The querier can express a preference 589 for one or the other modality with the 'serviceBoundary' attribute in 590 the request, but the server makes the final decision as 591 to whether to return a reference or a value. Servers SHOULD NOT 592 return a by-value service boundaries if the querier requested a 593 reference. 595 7.3.5. Requesting Civic Location Validation 597 Civic address validation is requested by setting the optional 598 attribute 'validateLocation' to true. If the attribute is omitted, 599 it is assumed to be false. The response is described in 600 Section 7.4.2. The example in Figure 6 demonstrates address 601 validation, omitting the standard response elements. 603 604 609 610 612 DE 613 Bavaria 614 Munich 615 Otto-Hahn-Ring 616 6 617 81675 618 619 620 urn:service:sos.police 621 623 Figure 6: A query with address validation request 625 626 627 633 634 Muenchen Polizei-Abteilung 635 636 urn:service:sos.police 637 638 640 Germany 641 Bavaria 642 Munich 643 81675 644 645 646 sip:munich-police@example.com 647 xmpp:munich-police@example.com 648 110 649 650 651 country A1 A3 A6 652 PC 653 654 655 656 657 658 660 Figure 7: A message with address validation 661 information 663 7.4. Components of the Mapping Response 665 7.4.1. Overview 667 Mapping responses consist of the element (Section 5) 668 describing the mapping itself, possibly followed by warnings 669 (Section 12.2), location validation information (Section 7.4.2), and 670 an indication of the path (Section 6) the response has taken. 672 7.4.2. Civic Address Validation: the Element 674 A server can indicate in its response which civic address elements it 675 has recognized as valid, which ones it has ignored and which ones it 676 has checked and found to be invalid. The server MUST include this 677 information if the 'validateLocation' attribute in the request was 678 true. Each element contains a list of tokens separated by white 679 space, enumerating the civic location lables used in child elements 680 of the element. The element enumerates those 681 civic address elements that have been recognized as valid by the LoST 682 server and that have been used to determine the mapping. The 683 elements enumerates the civic address elements that the 684 server did not check and that were not used in determining the 685 response. The element enumerate civic address elements 686 that the server attempted to check, but that did not match the other 687 civic address elements found in the list. 689 Note that the same address can yield different responses if parts of 690 the civic address contradict each other. For example, if the postal 691 code does not match the city, local server policy determines whether 692 the postal code or the city is considered valid. The mapping 693 naturally corresponds to the valid elements. 695 The example (Figure 6) indicates that the tokens 'country', 'A1', 696 'A3', and 'A6' have been validated by the LoST server. The server 697 considered the postal code 81675 in the element as not valid for 698 this location. 700 8. Retrieving the Service Boundary via 702 As discussed in Section 5.6, the can return a 703 globally unique identifier in the 'serviceBoundary' attribute that 704 can be used to retrieve the service boundary, rather than returning 705 the boundary by value. This is shown in the example in Figure 8. 706 The client can then retrieve the boundary using the 707 request and obtains the boundary in the 708 , illustrated in the example in 709 Figure 10. The client issues the request to the server identified in 710 the 'server' attribute of the element. 711 These requests are always directed to the authoritative server and do 712 not recurse. 714 715 720 721 722 37.775 -122.422 723 724 725 urn:service:sos.police 726 728 Figure 8: request and response with service boundary 729 reference 731 732 734 740 741 New York City Police Department 742 743 urn:service:sos.police 744 747 sip:nypd@example.com 748 xmpp:nypd@example.com 749 911 750 751 752 753 754 755 757 Figure 9: message with service boundary 758 reference 760 761 764 Figure 10: Requesting a service boundary with 766 The request may also be used to retrieve service 767 boundaries that are expressed as civic addresses, as illustrated in 768 Figure 11. 770 771 773 775 777 US 778 New York 779 New York 780 781 782 783 784 785 786 788 Figure 11: Civic Address Service Boundary Response 790 9. List Services: 792 A LoST client can ask a LoST server for the list of services that it 793 understands, primarily for diagnostic purposes. The query does not 794 contain location information, as it simply provides an indication of 795 which services the server can look up, not whether a particular 796 service is offered for a particular area. Typically, only top-level 797 services are included in the answer, implying support for all sub- 798 services. Since the query is answered by the queried server, there 799 is no notion of recursion or indirection and no path indication. The 800 805 807 urn:service:sos 808 810 Figure 12: Example of query 812 813 815 816 urn:service:sos.ambulance 817 urn:service:sos.animal-control 818 urn:service:sos.fire 819 urn:service:sos.gas 820 urn:service:sos.mountain 821 urn:service:sos.marine 822 urn:service:sos.physician 823 urn:service:sos.poison 824 urn:service:sos.police 825 urn:service:sos.suicide 826 827 829 Figure 13: Example of 831 10. List Services By Location: 833 A LoST client can ask a LoST server for the list of services it knows 834 about for a particular area. The query 835 contains one or more elements, each from a different 836 location profile (Section 11), and may contain the element. 837 As for , the server selects the first location element 838 that has a profile the server understands and it can operate either 839 recursively or iteratively; < via> elements track the progress of the 840 request. By its nature, the query can only indicate the services 841 that a particular server can determine, not all possible services 842 that might be offered. Unlike , the answer describes 843 the services available at a specific location, not just those 844 understood by the server. 846 If the query contains the element, the LoST server returns 847 only immediate child services of the queried service that are 848 available for the provided location. If the element is 849 absent, the LoST service returns all top-level services available for 850 the provided location that it knows about. 852 A server responds to this query with a 853 response. This response MAY contain 854 elements (see Section 6) and MUST contain a 855 element, consisting of a whitespace-separated list of service URNs. 856 The query and response are illustrated in Figure 14 and in Figure 15, 857 respectively. 859 860 864 865 866 37:46:30N 122:25:10W 867 868 869 urn:service:sos 870 872 Figure 14: Example of query 874 875 877 878 urn:service:sos.ambulance 879 urn:service:sos.animal-control 880 urn:service:sos.fire 881 urn:service:sos.gas 882 urn:service:sos.mountain 883 urn:service:sos.marine 884 urn:service:sos.physician 885 urn:service:sos.poison 886 urn:service:sos.police 887 urn:service:sos.suicide 888 889 890 891 892 893 895 Figure 15: Example of response 897 11. Location Profiles 899 LoST uses location information in elements in requests and 900 elements in responses. Such location information 901 may be expressed in a variety of ways. This variety can cause 902 interoperability problems where a request or response contains 903 location information in a format not understood by the server or the 904 client, respectively. To achieve interoperability, this document 905 defines two mandatory-to-implement baseline location profiles to 906 define the manner in which location information is transmitted. It 907 possible to standardize other profiles in the future. The two 908 baseline profiles are: 910 geodetic-2d: 912 a simple profile for two-dimensional geodetic location 913 information, as described in Section 11.2; 915 civic: 917 a profile consisting of civic address location information, as 918 described in Section 11.3. 920 Requests and responses containing or 921 elements MUST contain location information in exactly one of the two 922 baseline profiles, in addition to zero or more additional profiles. 923 The ordering of location information indicates a preference on the 924 part of the sender. 926 Standards action is required for defining new profiles. A location 927 profile MUST define: 929 1. The token identifying it in the LoST location profile registry; 931 2. The formal definition of the XML to be used in requests, i.e., an 932 enumeration and definition of the XML child elements of the 933 element; 935 3. The formal definition of the XML to be used in responses, i.e., 936 an enumeration and definition of the XML child elements of the 937 element; 939 4. The declaration of whether geodetic-2d or civic is to be used as 940 the baseline profile. It is necessary to explicitly declare the 941 baseline profile as future profiles may be combinations of 942 geodetic and civic location information. 944 11.1. Location Profile Usage 946 A location profile is identified by a token in an IANA-maintained 947 registry (Section 16.6). Clients send location information compliant 948 with a location profile, and servers respond with location 949 information compliant with that same location profile. 951 When a LoST client sends a request that provides 952 location information, it includes one or more elements. 953 Each of these elements contains location information compliant with a 954 location profile and specifies which profile has been used in the 955 'profile' attribute. This allows the client to convey location 956 information for multiple location profiles in the same request. 958 When a LoST server sends a response that contains location 959 information, it uses the elements much like the 960 client uses the elements. Each element 961 contains location information conformant to the location profile 962 specified in the 'profile' attribute. This allows the server to send 963 location information compliant with multiple location profiles. 965 Using the location profiles defined in this document, the following 966 rules insure basic interoperatiblity between clients and servers: 968 1. A client MUST be capable of understanding the response for the 969 baseline profiles it used in the request. 971 2. If a client sends location information conformant to any location 972 profile other than geodetic-2d or civic, it MUST also send, in 973 the same request, location information conformant to one of the 974 baseline profiles. Otherwise, the server might not be able to 975 understand the request. 977 3. There can only be one instance of each location profile in a 978 query. 980 4. Servers MUST implement the geodetic-2d and civic profiles. 982 5. A server uses the first-listed location profile that it 983 understands and ignores the others. 985 6. If a server receives a request that only contains location 986 information using profiles it does not understand, the server 987 responds with a (Section 12.1). 989 7. The element MUST use the same location profile 990 that was used to retrieve the answer and indicates which profile 991 has been used with the 'profile' attribute. 993 These rules enable the use of location profiles not yet specified, 994 while ensuring baseline interoperability. Take, for example, this 995 scenario. Client X has had its firmware upgraded to support the 996 uber-complex-3D location profile. Client X sends location 997 information to Server Y, which does not understand the 998 uber-complex-3D location profile. If Client X also sends location 999 information using the geodetic-2D baseline profile, then Server Y 1000 will still be able to understand the request and provide an 1001 understandable response, though with location information that might 1002 not be as precise or expressive as desired. This is possible because 1003 both Client X and Server Y understand the baseline profile. 1005 1006 1011 1012 1013 37.775 -122.422 1014 1015 1016 1017 1018 37.775 -122.4194 1019 37.555 -122.4194 1020 37.555 -122.4264 1021 37.775 -122.4264 1022 37.775 -122.4194 1023 1024 1025 1026 1027 -122.422 37.775 1028 1029 1030 1031 1032 37.775 -122.422 1033 1034 1035 urn:service:sos.police 1036 1038 Figure 16: Example of a query with baseline profile 1039 interoperability 1041 1042 1045 1051 1052 New York City Police Department 1053 1054 urn:service:sos.police 1055 1056 1057 1058 1059 37.775 -122.4194 1060 37.555 -122.4194 1061 37.555 -122.4264 1062 37.775 -122.4264 1063 37.775 -122.4194 1064 1065 1066 1067 1068 sip:nypd@example.com 1069 1070 1071 1072 1073 1074 1076 Figure 17: Example of a message with baseline 1077 profile interoperability 1079 11.2. Two Dimensional Geodetic Profile 1081 The geodetic-2d location profile is identified by geodetic-2d. 1082 Clients use this profile by placing a GML [13] element 1083 within the element. This is defined by the 'point2D' 1084 pattern in the LoST schema (see Section 14). 1086 Servers use this profile by placing a GML [13] element 1087 within the element. This is defined by the 1088 'polygon' pattern in the LoST schema (see Section 14). 1090 11.3. Basic Civic Profile 1092 The basic-civic location profile is identified by the token 'civic'. 1093 Clients use this profile by placing a element, defined 1094 in [11], within the element. 1096 Servers use this profile by placing a element, defined 1097 in [11], within the element. 1099 12. Errors, Warnings, and Redirects 1101 When a LoST server cannot fulfill a request completely, it can return 1102 either an error or a warning, depending on the severity of the 1103 problem. It returns an error element if no useful response can be 1104 returned for the query. It returns a element as part of 1105 another response element if it was able to respond in part, but the 1106 response may not be quite what the client had desired. For both 1107 elements, the 'source' attribute names the server that originally 1108 generated the error or warning, such as the authoritative server. 1109 Unless otherwise noted, all elements below can be either an error or 1110 a warning, depending on whether a default response, such as a 1111 mapping, is included. 1113 12.1. Errors 1115 LoST defines a pattern for errors, defined as elements in 1116 the Relax NG schema. This pattern defines a 'message' attribute 1117 containing human readable text and an 'xml:lang' attribute denoting 1118 the language of the human readable text. One or more such error 1119 elements are contained in the element. 1121 The following errors follow this basic pattern: 1123 badRequest 1125 The server could not parse or otherwise understand a request, 1126 e.g., because the XML was malformed. 1128 forbidden 1130 The server refused to send an answer. This generally only occurs 1131 for recursive queries, namely if the resolver tried to contact the 1132 authoritative server and was refused. (For HTTP as the underlying 1133 protocol, an HTTP 401 error would be returned.) 1135 internalError 1137 The server could not satisfy a request due to misconfiguration or 1138 other operational and non-protocol related reasons. 1140 locationProfileUnrecognized 1142 None of the profiles in the request were recognized by the server 1143 (see Section 11). 1145 loop 1147 During a recursive query, the server was about to visit a server 1148 that was already in the server list in the element, 1149 indicating a request loop. 1151 notFound 1153 The server could not find an answer to the query. 1155 serverError 1157 An answer was received from another LoST server, but it could not 1158 be parsed or otherwise understood. This error occurs only for 1159 recursive queries. 1161 serverTimeout 1163 A time out occurred before an answer was received. 1165 serviceNotImplemented 1167 The requested service URN is not implemented and no substitution 1168 was available. 1170 An example is below: 1172 1173 1175 1176 1178 Figure 18: Example of an error resonse 1180 12.2. Warnings 1182 A response MAY contain zero or more warnings. This pattern defines a 1183 'message' attribute containing human readable text and an 'xml:lang' 1184 attribute denoting the language of the human readable text. One or 1185 more such warning elements are contained in the element. 1187 This version of the specification does not define any warning 1188 elements. 1190 12.3. Redirects 1192 A LoST server can respond indicating that the querier should redirect 1193 the query to another server, using the element. The 1194 element includes a 'target' attribute indicating the LoST URL that 1195 the client SHOULD be contacting next, as well as the 'source' 1196 attribute indicating the server that generated the redirect response 1197 and a 'message' attribute explaining the reason for the redirect 1198 response. During a recursive query, a server receiving a 1199 response can decide whether it wants to follow the redirection or 1200 simply return the response to its upstream querier. 1202 An example is below: 1204 1205 1210 Figure 19: Example of a redirect resonse 1212 13. LoST Transport 1214 LoST needs an underlying protocol transport mechanisms to carry 1215 requests and responses. This document defines the use of LoST over 1216 HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future 1217 documents. The available transport mechanisms are determined through 1218 the use of the LoST U-NAPTR application. In protocols that support 1219 content type indication, LoST uses the media type application/ 1220 lost+xml. 1222 When using HTTP [3] and HTTP-over-TLS [5], LoST requests use the HTTP 1223 POST method. All HTTP responses are applicable. The HTTP URL is 1224 derived from the LoST URL via U-NAPTR application, as discussed in 1225 Section 4. 1227 14. Relax NG Schema 1229 This section provides the Relax NG schema used by LoST protocol in 1230 the compact form. The verbose form is included in Appendix A. 1232 default namespace = "http://www.opengis.net/gml" 1233 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 1234 namespace ns1 = "urn:ietf:params:xml:ns:lost1" 1236 ## 1237 ## Location-to-Service Translation Protocol (LoST) 1238 ## 1239 ## A LoST XML instance has three request types, each with 1240 ## a cooresponding response type: find service, list services, 1241 ## and get service boundary. 1242 ## 1243 start = 1244 findService 1245 | listServices 1246 | listServicesByLocation 1247 | getServiceBoundary 1248 | findServiceResponse 1249 | listServicesResponse 1250 | listServicesByLocationResponse 1251 | getServiceBoundaryResponse 1252 | errors 1253 | redirect 1255 ## 1256 ## The queries. 1257 ## 1258 div { 1259 findService = 1260 element ns1:findService { 1261 element ns1:location { locationInformation }+, 1262 commonRequestPattern, 1263 attribute validateLocation { 1264 xsd:boolean >> a:defaultValue [ "false" ] 1265 }?, 1266 attribute serviceBoundary { 1267 ("reference" | "value") >> a:defaultValue [ "reference" ] 1268 }?, 1269 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 1270 } 1271 listServices = element ns1:listServices { commonRequestPattern } 1272 listServicesByLocation = 1273 element ns1:listServicesByLocation { 1274 element ns1:location { locationInformation }*, 1275 commonRequestPattern, 1276 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 1277 } 1278 getServiceBoundary = 1279 element ns1:getServiceBoundary { 1280 serviceBoundaryKey, extensionPoint 1281 } 1282 } 1284 ## 1285 ## The responses. 1286 ## 1287 div { 1288 findServiceResponse = 1289 element ns1:findServiceResponse { 1290 mapping+, locationValidation?, commonResponsePattern 1291 } 1292 listServicesResponse = 1293 element ns1:listServicesResponse { 1294 serviceList, commonResponsePattern 1295 } 1296 listServicesByLocationResponse = 1297 element ns1:listServicesByLocationResponse { 1298 serviceList, commonResponsePattern 1299 } 1300 getServiceBoundaryResponse = 1301 element ns1:getServiceBoundaryResponse { 1302 serviceBoundary, commonResponsePattern 1303 } 1304 } 1306 ## 1307 ## A pattern common to some of the queries. 1308 ## 1309 div { 1310 commonRequestPattern = service, extensionPoint 1311 } 1313 ## 1314 ## A pattern common to responses. 1315 ## 1316 div { 1317 commonResponsePattern = warnings*, path, extensionPoint 1318 } 1319 ## 1320 ## Location Information 1321 ## 1322 div { 1323 locationInformation = 1324 extensionPoint+, 1325 attribute profile { xsd:NMTOKEN } 1326 } 1328 ## 1329 ## Service Boundary 1330 ## 1331 div { 1332 serviceBoundary = element ns1:serviceBoundary { locationInformation }+ 1333 } 1335 ## 1336 ## Service Boundary Reference 1337 ## 1338 div { 1339 serviceBoundaryReference = 1340 element ns1:serviceBoundaryReference { 1341 source, serviceBoundaryKey, extensionPoint 1342 } 1343 serviceBoundaryKey = attribute key { xsd:token } 1344 } 1346 ## 1347 ## Path - 1348 ## Contains a list of via elements - 1349 ## places through which information flowed 1350 ## 1351 div { 1352 path = 1353 element ns1:path { 1354 element ns1:via { source, extensionPoint }* 1355 } 1356 } 1358 ## 1359 ## Expires pattern 1360 ## 1361 div { 1362 expires = attribute expires { xsd:dateTime } 1363 } 1365 ## 1366 ## A QName list 1367 ## 1368 div { 1369 qnameList = list { xsd:QName* } 1370 } 1372 ## 1373 ## A location-to-service mapping. 1374 ## 1375 div { 1376 mapping = 1377 element ns1:mapping { 1378 element ns1:displayName { 1379 xsd:string, 1380 attribute xml:lang { xsd:language } 1381 }*, 1382 service, 1383 (serviceBoundary | serviceBoundaryReference)?, 1384 element ns1:uri { xsd:anyURI }*, 1385 element ns1:serviceNumber { 1386 xsd:string { pattern = "[0-9*#]+" } 1387 }?, 1388 extensionPoint, 1389 expires, 1390 attribute lastUpdated { xsd:dateTime }, 1391 source, 1392 attribute sourceId { xsd:token }, 1393 attribute version { xsd:positiveInteger }, 1394 message 1395 } 1396 } 1398 ## 1399 ## Location validation 1400 ## 1401 div { 1402 locationValidation = 1403 element ns1:locationValidation { 1404 element ns1:valid { qnameList }?, 1405 element ns1:invalid { qnameList }?, 1406 element ns1:unchecked { qnameList }?, 1407 extensionPoint 1408 } 1409 } 1411 ## 1412 ## Errors and Warnings Container. 1413 ## 1414 div { 1415 errorContainer = 1416 (badRequest? 1417 & internalError? 1418 & serviceSubstitution? 1419 & forbidden? 1420 & notFound? 1421 & loop? 1422 & serviceNotImplemented? 1423 & serverTimeout? 1424 & serverError? 1425 & locationProfileUnrecognized?), 1426 extensionPoint, 1427 source 1428 errors = element ns1:errors { errorContainer } 1429 warnings = element ns1:warnings { errorContainer } 1430 } 1432 ## 1433 ## Basic Errors 1434 ## 1435 div { 1437 ## 1438 ## Error pattern. 1439 ## 1440 basicError = message, extensionPoint 1441 badRequest = element ns1:badRequest { basicError } 1442 internalError = element ns1:internalError { basicError } 1443 serviceSubstitution = element ns1:serviceSubstitution { basicError } 1444 forbidden = element ns1:forbidden { basicError } 1445 notFound = element ns1:notFound { basicError } 1446 loop = element ns1:loop { basicError } 1447 serviceNotImplemented = 1448 element ns1:serviceNotImplemented { basicError } 1449 serverTimeout = element ns1:serverTimeout { basicError } 1450 serverError = element ns1:serverError { basicError } 1451 locationProfileUnrecognized = 1452 element ns1:locationProfileUnrecognized { 1453 attribute unsupportedProfiles { xsd:NMTOKENS }, 1454 basicError 1455 } 1456 } 1458 ## 1459 ## Redirect. 1460 ## 1461 div { 1462 ## 1463 ## Redirect pattern 1464 ## 1465 redirect = 1466 element ns1:redirect { 1467 attribute target { xsd:anyURI }, 1468 source, 1469 message, 1470 extensionPoint 1471 } 1472 } 1474 ## 1475 ## Some common patterns. 1476 ## 1477 div { 1478 message = 1479 (attribute message { xsd:string }, 1480 attribute xml:lang { xsd:language })? 1481 service = element ns1:service { xsd:anyURI }? 1482 source = attribute source { xsd:anyURI } 1483 serviceList = 1484 element ns1:serviceList { 1485 list { xsd:anyURI* } 1486 } 1487 } 1489 ## 1490 ## Patterns for inclusion of elements from schemas in 1491 ## other namespaces. 1492 ## 1493 div { 1495 ## 1496 ## Any element not in the LoST namespace. 1497 ## 1498 notLost = element * - (ns1:* | ns1:*) { anyElement } 1500 ## 1501 ## A wildcard pattern for including any element 1502 ## from any other namespace. 1503 ## 1504 anyElement = 1505 (element * { anyElement } 1506 | attribute * { text } 1507 | text)* 1509 ## 1510 ## A point where future extensions 1511 ## (elements from other namespaces) 1512 ## can be added. 1513 ## 1514 extensionPoint = notLost* 1516 ## 1517 ## A 2D point from GML. 1518 ## 1519 point2d = 1520 element Point { 1521 attribute srsName { "urn:ogc:def:crs:EPSG::4326" }, 1522 pos 1523 } 1525 ## 1526 ## A GML position 1527 ## 1528 pos = 1529 element pos { 1530 list { xsd:double } 1531 } 1533 ## 1534 ## A Linear Ring from GML. 1535 ## 1536 linearRing = element LinearRing { pos, pos, pos, pos+ } 1538 ## 1539 ## A Polygon from GML. 1540 ## 1541 polygon = 1542 element Polygon { 1543 attribute srsName { "urn:ogc:def:crs:EPSG::4326" }, 1544 element exterior { linearRing }, 1545 element interior { linearRing }* 1546 } 1547 } 1549 Figure 20: RelaxNG schema 1551 15. Internationalization Considerations 1553 This mechanism is largely for passing protocol information from one 1554 subsystem to another; as such, most of its elements are tokens not 1555 meant for direct human consumption. If these tokens are presented to 1556 the end user, some localization may need to occur. The content of 1557 the element and the 'message' attributes may be 1558 displayed to the end user, and they are thus a complex types designed 1559 for this purpose. 1561 LoST exchanges information using XML. All XML processors are 1562 required to understand UTF-8 and UTF-16 encodings, and therefore all 1563 LoST clients and servers MUST understand UTF-8 and UTF-16 encoded 1564 XML. Additionally, LoST servers and clients MUST NOT encode XML with 1565 encodings other than UTF-8 or UTF-16. 1567 16. IANA Considerations 1569 16.1. U-NAPTR Registrations 1571 This document registers the following U-NAPTR application service 1572 tag: 1574 Application Service Tag: LoST 1576 Defining Publication: The specification contained within this 1577 document. 1579 This document registers the following U-NAPTR application protocol 1580 tags: 1582 o 1584 Application Protocol Tag: http 1586 Defining Publication: RFC 2616 [3] 1588 o 1590 Application Protocol Tag: https 1592 Defining Publication: RFC 2818 [5] 1594 16.2. Content-type registration for 'application/lost+xml' 1596 This specification requests the registration of a new MIME type 1597 according to the procedures of RFC 4288 [9] and guidelines in RFC 1598 3023 [6]. 1600 MIME media type name: application 1602 MIME subtype name: lost+xml 1604 Mandatory parameters: none 1606 Optional parameters: charset 1608 Indicates the character encoding of enclosed XML. 1610 Encoding considerations: 1612 Uses XML, which can employ 8-bit characters, depending on the 1613 character encoding used. See RFC 3023 [6], Section 3.2. 1615 Security considerations: 1617 This content type is designed to carry LoST protocol payloads. 1619 Interoperability considerations: None 1621 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 1622 replace XXXX with the RFC number of this specification.] this 1623 document 1625 Applications which use this media type: 1627 Emergency and Location-based Systems 1629 Additional information: 1631 Magic Number: None 1633 File Extension: .lostxml 1635 Macintosh file type code: 'TEXT' 1637 Personal and email address for further information: Hannes 1638 Tschofenig, Hannes.Tschofenig@siemens.com 1640 Intended usage: LIMITED USE 1642 Author: 1644 This specification is a work item of the IETF ECRIT working group, 1645 with mailing list address . 1647 Change controller: 1649 The IESG 1651 16.3. LoST Relax NG Schema Registration 1653 URI: urn:ietf:params:xml:ns:lost1 1655 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1656 (Hannes.Tschofenig@siemens.com). 1658 Relax NG Schema: The Relax NG schema to be registered is contained 1659 in Section 14. Its first line is 1661 default namespace = "urn:ietf:params:xml:ns:lost1" 1663 and its last line is 1665 } 1667 16.4. LoST Namespace Registration 1669 URI: urn:ietf:params:xml:ns:lost1 1671 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1672 (Hannes.Tschofenig@siemens.com). 1674 XML: 1676 BEGIN 1677 1678 1680 1681 1682 1684 LoST Namespace 1685 1686 1687

Namespace for LoST

1688

urn:ietf:params:xml:ns:lost1

1689

See RFCXXXX 1690 [NOTE TO IANA/RFC-EDITOR: 1691 Please replace XXXX with the RFC number of this 1692 specification.].

1693 1694 1695 END 1697 16.5. URL Registration Template 1699 This registration template is in accordance with [4]. 1701 URL scheme name: 1703 lost 1705 URL scheme syntax: 1707 See Section 4 1709 Character encoding considerations: 1711 See Section 4 1713 Intended Use: 1715 The intended usage is described in this document. 1717 Application and protocols which use this scheme: 1719 The usage of the LoST URL scheme is targeted for this document and 1720 hence for location-based services that make use of the mapping 1721 protocol specified in this document. 1723 Interoperability considerations: 1725 None 1727 Security considerations: 1729 See Section 17 1731 Relevant publications: 1733 This document provides the relevant context for this URL scheme. 1735 Contact: 1737 Hannes Tschofenig, Hannes.Tschofenig@siemens.com 1739 Author/Change controller: 1741 The IESG 1743 16.6. LoST Location Profile Registry 1745 This document seeks to create a registry of location profile names 1746 for the LoST protocol. Profile names are XML tokens. This registry 1747 will operate in accordance with RFC 2434 [2], Standards Action. 1749 geodetic-2d: 1751 Defined in Section 11.2 1753 civic: 1755 Defined in Section 11.3 1757 17. Security Considerations 1759 There are multiple threats to the overall system of which service 1760 mapping forms a part. An attacker that can obtain service contact 1761 URIs can use those URIs to attempt to disrupt those services. An 1762 attacker that can prevent the lookup of contact URIs can impair the 1763 reachability of such services. An attacker that can eavesdrop on the 1764 communication requesting this lookup can surmise the existence of an 1765 emergency and possibly its nature, and may be able to use this to 1766 launch a physical attack on the caller. 1768 To avoid that an attacker can modify the query or its result, the use 1769 of channels security, such as TLS, is RECOMMENDED. 1771 A more detailed description of threats and security requirements are 1772 provided in [17]. 1774 18. Acknowledgments 1776 We would like to the thank the following working group members for 1777 the detailed review of previous LoST document versions: 1779 o Barbara Stark (Review in Jan. 2007) 1781 o Martin Thomson (Review in Dec. 2006, Review Jul. 2006) 1783 o Shida Schubert (Review Nov. 2006) 1785 o Leslie Daigle (Review Sep. 2006) 1787 o Jonathan Rosenberg (Review Jul. 2006) 1789 We would also like to thank the following working group members for 1790 their input to selected design aspects of the LoST protocol: 1792 o Leslie Daigle and Martin Thomson (Input to DNS-based LoST 1793 discovery procedure) 1795 o John Schnizlein (Authoritive LoST Answers) 1797 o Rohan Mahy (Display Names) 1799 o James Polk (Error Handling) 1801 o Ron Watro and Richard Barnes (Expiry of cached data) 1803 o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James 1804 Winterbottom (Indication of PSAP Confidence Level) 1806 o Martin Thomson (Service Boundary references) 1808 o Martin Thomson (Service URN in LoST response message) 1810 o Cullen Jennings (Service Boundaries) 1812 o Clive D.W. Feather, Martin Thomson (Validation Functionality) 1814 o Roger Marshall (PSAP Preference in LoST response) 1816 o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, 1817 Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. 1818 Feather, Richard Stastny, John Hearty, Roger Marshall, Jean- 1819 Francois Mule, Pierre Desjardins (Location Profiles) 1821 o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson, 1822 Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, 1823 Keith (List Services functionality) 1825 o Thomson, Martin, Michael Hammer (Mapping of Services) 1827 o Shida Schubert, James Winterbottom, Keith Drage (default service 1828 URN) 1830 o Otmar Lendl (LoST aggregation) 1832 The following working group members provided miscellaneous input to 1833 the design of the protocol: 1835 o Klaus Darilion 1837 o Marc Linsner 1839 Finally, we would like to particularly thank Brian Rosen as a long 1840 term contributor who participated in almost every discussion thread. 1842 19. Open Issues 1844 Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ 1846 20. References 1848 20.1. Normative References 1850 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1851 Levels", BCP 14, RFC 2119, March 1997. 1853 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1854 Considerations Section in RFCs", BCP 26, RFC 2434, 1855 October 1998. 1857 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1858 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1859 HTTP/1.1", RFC 2616, June 1999. 1861 [4] Petke, R. and I. King, "Registration Procedures for URL Scheme 1862 Names", BCP 35, RFC 2717, November 1999. 1864 [5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1866 [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1867 RFC 3023, January 2001. 1869 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1870 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1871 January 2005. 1873 [8] Peterson, J., "A Presence-based GEOPRIV Location Object 1874 Format", RFC 4119, December 2005. 1876 [9] Freed, N. and J. Klensin, "Media Type Specifications and 1877 Registration Procedures", BCP 13, RFC 4288, December 2005. 1879 [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", 1880 draft-ietf-ecrit-service-urn-05 (work in progress), 1881 August 2006. 1883 [11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 1884 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in 1885 progress), September 2006. 1887 [12] Daigle, L., "Domain-based Application Service Location Using 1888 URIs and the Dynamic Delegation Discovery Service (DDDS)", 1889 draft-daigle-unaptr-01 (work in progress), October 2006. 1891 [13] OpenGIS, "Open Geography Markup Language (GML) Implementation 1892 Specification", OGC OGC 02-023r4, January 2003. 1894 20.2. Informative References 1896 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1897 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1898 Session Initiation Protocol", RFC 3261, June 2002. 1900 [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1901 Protocol (XMPP): Instant Messaging and Presence", RFC 3921, 1902 October 2004. 1904 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 1905 December 2004. 1907 [17] Taylor, T., "Security Threats and Requirements for Emergency 1908 Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 1909 (work in progress), July 2006. 1911 [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 1912 Context Resolution with Internet Technologies", 1913 draft-ietf-ecrit-requirements-12 (work in progress), 1914 August 2006. 1916 [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1917 Framework", draft-ietf-ecrit-mapping-arch-01 (work in 1918 progress), December 2006. 1920 [20] Rosen, B. and J. Polk, "Best Current Practice for 1921 Communications Services in support of Emergency Calling", 1922 draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006. 1924 Appendix A. Non-Normative RELAX NG Schema in XML Syntax 1926 1927 1932 1933 1934 Location-to-Service Translation Protocol (LoST) 1936 A LoST XML instance has three request types, each with 1937 a cooresponding response type: find service, list services, 1938 and get service boundary. 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1954
1955 1956 The queries. 1957 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 false 1972 1973 1974 1975 1976 1977 reference 1978 value 1979 1980 reference 1981 1982 1983 1984 1985 1986 true 1987 1988 1989 1990 1992 1993 1994 1995 1996 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 true 2010 2011 2012 2013 2015 2016 2017 2018 2019 2021 2023
2025
2026 2027 The responses. 2028 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2042 2043 2044 2045 2046 2047 2049 2050 2051 2052 2053 2054 2056 2057 2058 2059 2060 2061 2063
2065
2066 2067 A pattern common to some of the queries. 2068 2070 2071 2072 2073 2074
2076
2077 2078 A pattern common to responses. 2079 2081 2082 2083 2084 2085 2086 2087 2088
2090
2091 2092 Location Information 2093 2095 2096 2097 2098 2099 2100 2101 2102 2103
2105
2106 2107 Service Boundary 2108 2110 2111 2112 2113 2115 2116 2117 2118
2120
2121 2122 Service Boundary Reference 2123 2125 2127 2128 2129 2130 2131 2132 2134 2135 2136 2137 2138 2140
2142
2143 2144 Path - 2145 Contains a list of via elements - 2146 places through which information flowed 2147 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159
2161
2162 2163 Expires pattern 2164 2166 2167 2168 2169 2170 2171
2173
2174 2175 A QName list 2176 2178 2179 2180 2181 2182 2183 2184 2185
2187
2188 2189 A location-to-service mapping. 2190 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 [0-9*#]+ 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2237
2239
2240 2241 Location validation 2242 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2260 2261 2262 2263 2264 2265
2267
2268 2269 Errors and Warnings Container. 2270 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2314 2315 2316 2317 2318 2320
2322
2323 2324 Basic Errors 2325 2327 2328 2329 Error pattern. 2330 2331 2332 2333 2335 2336 2337 2338 2339 2341 2342 2343 2344 2345 2347 2348 2349 2350 2351 2353 2354 2355 2357 2358 2360 2361 2362 2363 2364 2366 2367 2368 2369 2370 2372 2373 2374 2375 2376 2378 2379 2380 2381 2382 2384 2385 2386 2387 2388 2390 2391 2392 2393 2394 2395 2396 2397 2399
2401
2402 2403 Redirect. 2404 2405 2406 2407 Redirect pattern 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2419
2421
2422 2423 Some common patterns. 2424 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2439 2440 2441 2442 2443 2444 2445 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2462
2464
2465 2466 Patterns for inclusion of elements from schemas in 2467 other namespaces. 2468 2470 2471 2472 Any element not in the LoST namespace. 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2485 2486 2487 A wildcard pattern for including any element 2488 from any other namespace. 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2504 2505 2506 A point where future extensions 2507 (elements from other namespaces) 2508 can be added. 2509 2510 2511 2512 2513 2515 2516 2517 A 2D point from GML. 2518 2519 2520 2521 urn:ogc:def:crs:EPSG::4326 2522 2523 2524 2525 2527 2528 2529 A GML position 2530 2531 2532 2533 2534 2535 2536 2538 2539 2540 A Linear Ring from GML. 2541 2542 2544 2545 2546 2547 2548 2549 2550 2551 2553 2554 2555 A Polygon from GML. 2556 2557 2559 2560 urn:ogc:def:crs:EPSG::4326 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2573
2575 2577 Figure 24 2579 Authors' Addresses 2581 Ted Hardie 2582 Qualcomm, Inc. 2584 Email: hardie@qualcomm.com 2586 Andrew Newton 2587 SunRocket 2588 8045 Leesburg Pike, Suite 300 2589 Vienna, VA 22182 2590 US 2592 Phone: +1 703 636 0852 2593 Email: andy@hxr.us 2595 Henning Schulzrinne 2596 Columbia University 2597 Department of Computer Science 2598 450 Computer Science Building 2599 New York, NY 10027 2600 US 2602 Phone: +1 212 939 7004 2603 Email: hgs+ecrit@cs.columbia.edu 2604 URI: http://www.cs.columbia.edu 2606 Hannes Tschofenig 2607 Siemens Networks GmbH & Co KG 2608 Otto-Hahn-Ring 6 2609 Munich, Bavaria 81739 2610 Germany 2612 Phone: +49 89 636 40390 2613 Email: Hannes.Tschofenig@siemens.com 2614 URI: http://www.tschofenig.com 2616 Full Copyright Statement 2618 Copyright (C) The IETF Trust (2007). 2620 This document is subject to the rights, licenses and restrictions 2621 contained in BCP 78, and except as set forth therein, the authors 2622 retain all their rights. 2624 This document and the information contained herein are provided on an 2625 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2626 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2627 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2628 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2629 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2630 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2632 Intellectual Property 2634 The IETF takes no position regarding the validity or scope of any 2635 Intellectual Property Rights or other rights that might be claimed to 2636 pertain to the implementation or use of the technology described in 2637 this document or the extent to which any license under such rights 2638 might or might not be available; nor does it represent that it has 2639 made any independent effort to identify any such rights. Information 2640 on the procedures with respect to rights in RFC documents can be 2641 found in BCP 78 and BCP 79. 2643 Copies of IPR disclosures made to the IETF Secretariat and any 2644 assurances of licenses to be made available, or the result of an 2645 attempt made to obtain a general license or permission for the use of 2646 such proprietary rights by implementers or users of this 2647 specification can be obtained from the IETF on-line IPR repository at 2648 http://www.ietf.org/ipr. 2650 The IETF invites any interested party to bring to its attention any 2651 copyrights, patents or patent applications, or other proprietary 2652 rights that may cover technology that may be required to implement 2653 this standard. Please address the information to the IETF at 2654 ietf-ipr@ietf.org. 2656 Acknowledgment 2658 Funding for the RFC Editor function is provided by the IETF 2659 Administrative Support Activity (IASA).