idnits 2.17.00 (12 Aug 2021) /tmp/idnits2658/draft-ietf-ecrit-lost-05.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 2658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2682. 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 (March 4, 2007) is 5557 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) == Unused Reference: '8' is defined on line 1951, but no explicit reference was found in the text ** 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) ** Downref: Normative reference to an Informational RFC: RFC 2818 (ref. '4') ** Obsolete normative reference: RFC 3023 (ref. '5') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (ref. '7') (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4395 (ref. '8') (Obsoleted by RFC 7595) == Outdated reference: draft-ietf-ecrit-service-urn has been published as RFC 5031 == Outdated reference: draft-ietf-geopriv-revised-civic-lo has been published as RFC 5139 == Outdated reference: draft-daigle-unaptr has been published as RFC 4848 -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. '15') (Obsoleted by RFC 6121) == Outdated reference: draft-ietf-ecrit-security-threats has been published as RFC 5069 == Outdated reference: draft-ietf-ecrit-requirements has been published as RFC 5012 == Outdated reference: draft-ietf-ecrit-mapping-arch has been published as RFC 5582 == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 11 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: September 5, 2007 SunRocket 6 H. Schulzrinne 7 Columbia U. 8 H. Tschofenig 9 Siemens Networks GmbH & Co KG 10 March 4, 2007 12 LoST: A Location-to-Service Translation Protocol 13 draft-ietf-ecrit-lost-05.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 September 5, 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 servers and Their Resolution . . . . . . . . . . . . . . 9 57 5. The Element . . . . . . . . . . . . . . . . . . . . 10 58 5.1. The Data Source: 'source', 'sourceId' and 59 'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10 60 5.2. Validity: The 'expires' Attribute . . . . . . . . . . . . 10 61 5.3. Describing the Service with the Element . . 11 62 5.4. The Mapped Service: the Element . . . . . . . . 11 63 5.5. Defining the Service Region with the 64 Element . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.6. Service Boundaries by Reference: the 66 Element . . . . . . . . . . . . 12 67 5.7. The Service Number Element . . . . . . . . . . . . . . . . 13 68 5.8. Service URLs: the Element . . . . . . . . . . . . . 13 69 6. Path of a Request: Element . . . . . . . . . . . . . . 14 70 7. Mapping a Location and Service to URLs: . . . . 15 71 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 15 74 7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 16 75 7.3. Components of the Request . . . . . . . . . 18 76 7.3.1. The Element . . . . . . . . . . . . . . . . 18 77 7.3.2. Identifying the Service: The Element . . . 19 78 7.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 19 79 7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 19 80 7.3.5. Requesting Civic Location Validation . . . . . . . . . 19 81 7.4. Components of the Mapping Response 82 . . . . . . . . . . . . . . . . . . 21 83 7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21 84 7.4.2. Civic Address Validation: the 85 Element . . . . . . . . . . . . . 22 86 8. Retrieving the Service Boundary via . . . 23 87 9. List Services: . . . . . . . . . . . . . . . . 26 88 10. List Services By Location: . . . . . 27 89 11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 29 90 11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 30 91 11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 33 92 11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 34 93 12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 35 94 12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 95 12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 36 96 12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 37 97 13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 38 98 14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 39 99 15. Internationalization Considerations . . . . . . . . . . . . . 46 100 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 101 16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 47 102 16.2. Content-type registration for 'application/lost+xml' . . . 47 103 16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 49 104 16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 49 105 16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 50 106 17. Security Considerations . . . . . . . . . . . . . . . . . . . 51 107 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 108 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 54 109 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 110 20.1. Normative References . . . . . . . . . . . . . . . . . . . 55 111 20.2. Informative References . . . . . . . . . . . . . . . . . . 56 112 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 57 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 114 Intellectual Property and Copyright Statements . . . . . . . . . . 71 116 1. Introduction 118 Numerous techniques have been specified for the discovery of servers 119 for a particular service, including NAPTR records, SVRLOC and similar 120 protocols. However, there are an important class of services where 121 the specific service instance that is to be connected to depends on 122 the identity of the service and the location of the entity that needs 123 to reach it. An example of this is emergency telecommunications 124 services, where the service instance is a Public Safety Answering 125 Point (PSAP) that has jurisdiction over the location of the user 126 making the call. Here, the desired PSAP isn't necessarily the one 127 that is topologically or even line-of-sight closest to the caller; 128 rather, it is the one that serves the callers location based on 129 geopolitical boundaries. For this reason, the selected service 130 instance is a function of location and the desired service. 132 This document describes a protocol for mapping a service identifier 133 [9] and location information compatible with PIDF-LO [6], namely 134 revised civic location information [10] and GML [12]) to one or more 135 service URL. Example service URL schemes include sip [14], xmpp 136 [15], and tel [16]. While the initial focus is on providing mapping 137 functions for emergency services, it is likely that the protocol is 138 applicable to any service URN. For example, in the United States, 139 the "2-1-1" and "3-1-1" service numbers follow a similar location-to- 140 service behavior as emergency services. 142 This document names this protocol "LoST", for Location-to-Service 143 Translation. LoST Satisfies the requirements [18] for mapping 144 protocols. LoST provides a number of operations, centered around 145 mapping locations and service URNs to service URLs and associated 146 information. LoST mapping queries can contain either civic or 147 geodetic location information. For civic addresses, LoST can 148 indicate which parts of the civic address are known to be valid or 149 invalid, thus providing address validation (see Section 3.5 of [18] 150 for a description of validation). LoST indicates errors in the 151 location data to facilitate debugging and proper user feedback, but 152 also provides best-effort answers. 154 LoST queries can be resolved recursively or iteratively. To minimize 155 round trips and to provide robustness against network failures, LoST 156 supports caching of individual mappings and indicates the region for 157 which the same answer would be returned ("service region"). 159 As defined in this document, LoST messages are carried in HTTP and 160 HTTPS protocol exchanges, facilitating use of TLS for protecting the 161 integrity and confidentiality of requests and responses. 163 This document focuses on the description of the protocol between the 164 mapping client and the mapping server. Other functions, such as 165 discovery of mapping servers, data replication and the overall 166 mapping server architecture are described in a separate document 167 [19]. 169 The query message carries location information and a service 170 identifier encoded as a Uniform Resource Name (URN) (see [9]) from 171 the LoST client to the LoST server. The LoST server uses its 172 database to map the input values to one or more Uniform Resource 173 Identifiers (URI) and returns those URIs along with optional 174 information, such as hints about the service boundary, in a response 175 message to the LoST client. If the server cannot resolve the query 176 itself, it may in turn query another server or return the address of 177 another LoST server, identified by a LoST server name. In addition 178 to the mapping function described in Section 7, the protocol also 179 allows to retrieve the service boundary (see Section 8) and to list 180 the services available for a particular location (see Section 10) or 181 supported by a particular server (see Section 9). 183 2. Terminology and Requirements Notation 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [1]. 189 This document uses the following terms: 191 Mapping: 193 Mapping is a process that takes a location and a service 194 identifier as inputs and returns one or more URIs that point to a 195 host providing that service or acting as an intermediary to 196 establish communication with the serving entity. This definition 197 is a generalization of the term "mapping" as used in [18], because 198 of the potential for LoST to be used for non-emergency services. 200 LoST Client and Server: 202 "LoST client" is the role played by an entity that sends LoST 203 query messages and receives LoST response messages. "LoST server" 204 is the role played by an entity that receives LoST query messages 205 and sends LoST response messages. In recursive operation, the 206 same entity may play both roles. This document also uses the term 207 "authoritative server" to designate an entity that acts in the 208 LoST server role only and successfully resolves the input location 209 and service identifier to a URI or set of URIs. 211 Service Boundary: 213 A service boundary is the boundary or set of boundaries of a 214 geographic region, respectively set of geographic regions, within 215 which all locations will map to the same URI or set of URIs for a 216 given service. 218 Validation: 220 The term "validation" as used in this document is a concrete 221 realization of the term "location validation" as defined in 222 Section 3.5 of [18]. 224 Additional emergency service terminology can be found in [18]. 226 3. Overview of Protocol Usage 228 The LoST protocol supports the following type of queries and 229 responses: 231 and 233 This message pattern allows to perform retrieve contact URIs based 234 on location information together with a service identifier. The 235 same query type may also ask for location validation and for 236 service numbers, either integrated into mapping request or 237 separately. The details can be found in Section 7 and 238 Section 7.4. 240 and 242 This message pattern allows query for a service boundary. The 243 details can be found in Section 8. 245 and 247 This message pattern enables a LoST client to ask a LoST server 248 for the services it supports. The details can be found in 249 Section 9. 251 and 253 This message pattern provides the LoST client with the services 254 that are available for a specific location region. The details 255 can be found in Section 10. 257 LoST clients may initiate any of the above queries at any time. 258 Among the common triggers are: 260 1. When the client initially starts up or attaches to a network. 262 2. When the client detects that its location has changed 263 sufficiently that it is outside the bounds of the service region. 265 3. An incoming message at a SIP proxy in a location-based routing 266 scenario that requires a routing decision to be made. 268 4. When cached mapping information has expired. 270 5. When invoking a particular service. At that time, a client may 271 omit requests for service boundaries or other auxiliary 272 information. 274 A service-specific Best Current Practice (BCP) document, such as 275 [20], governs whether a client is expected to invoke the mapping 276 service just before needing the service or whether to rely on cached 277 answers. Cache entries expire at their expiration time (see 278 Section 5.2), or they become invalid if the caller's device moves 279 beyond the boundaries of the service region. 281 4. LoST servers and Their Resolution 283 LoST servers are identified by U-NAPTR/DDDS [11] application unique 284 strings, in the form of a DNS name. 286 An example is 'lostserver.example.com' 288 Clients need to use the U-NAPTR [11] specification described below to 289 obtain a URI (indicating host and protocol) for the applicable LoST 290 service. In this document, only the HTTP and HTTPS URL schemes are 291 defined. Note that the HTTP URL can be any valid HTTP URL, including 292 those containing path elements. 294 The following two DNS entries show the U-NAPTR resolution for 295 "example.com" to the HTTPS URL https://lostserv.example.com/secure or 296 the HTTP URL http://lostserver.example.com, with the former being 297 preferred. 299 example.com. 301 IN NAPTR 100 10 "u" "LoST:https" 302 "!.*!https://lostserver.example.com/secure!" "" 304 IN NAPTR 200 10 "u" "LoST:http" 305 "!.*!http://lostserver.example.com!" "" 307 Clients learn the LoST server's host name by means beyond the scope 308 of this specification, such as SIP configuration and DHCP. 310 5. The Element 312 The element is the core data element in LoST, describing a 313 service region and the associated service URLs. Its attributes and 314 elements are described in subsections below. 316 5.1. The Data Source: 'source', 'sourceId' and 'lastUpdated' Attributes 318 The 'source', the 'sourceId' and the 'lastUpdated' attributes 319 uniquely identify a particular mapping record. They are created by 320 the authoritative source for a mapping and never modified when a 321 mapping is served from a cache. All three attributes are REQUIRED 322 for all elements. A receiver can replace a mapping with 323 another one having the same 'source' and 'sourceId' and a more recent 324 datum in 'lastUpdated'. 326 The 'source' attribute contains a LoST application unique string 327 identifying the authoritative generator of the mapping. See 328 Section 4. 330 The 'sourceId' attribute identifies a particular mapping and contains 331 an opaque token that MUST be unique among all different mappings 332 maintained by the authoritative source for that particular service. 333 For example, a Universally Unique Identifier (UUID) is a suitable 334 format. 336 The 'lastUpdated' attribute describes when a specific instance of 337 mapping, identified by the combination of 'source' and 'sourceId', 338 was last changed. The contents of this attribute has the XML data 339 type dateTime in its timezoned form, using canonical UTC 340 representation with the letter 'Z' as the timezone indicator. 342 5.2. Validity: The 'expires' Attribute 344 The 'expires' attribute contains the absolute time at which the 345 mapping becomes invalid. The contents of this attribute is a 346 timezoned XML type dateTime, in canonical representation. See 347 Section 3 regarding how this value is to be utilized with a cache. 348 The 'expires' attribute is REQUIRED to be included in the 349 element. 351 Optionally, this attribute may contain the values of 'NO-CACHE' and 352 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is 353 an indication that the mapping should not be cached. The value of 354 'NO-EXPIRATION' is an indication that the mapping does not expire. 356 On occasion, a server may be forced to return an expired mapping if 357 it cannot reach the authoritative server or the server fails to 358 return a usable answer. Clients and servers MAY cache the mapping so 359 that they have at least some information available. Caching servers 360 that have such stale information SHOULD re-attempt the query each 361 time a client requests a mapping. Since the expired mapping will be 362 returned to the client as a non-error/non-warning response it is the 363 responsibility of the client to check the 'expires' attribute 364 associated with mapping data returned in a LoST response to detemine 365 whether the mapping is fresh. 367 5.3. Describing the Service with the Element 369 Zero or more elements describe the service with a 370 string that is suitable for display to human users, each annotated 371 with the 'xml:lang' attribute that contains a language tag to aid in 372 the rendering of text. 374 5.4. The Mapped Service: the Element 376 The element identifies the service for which this mapping 377 applies. Two cases need to be distinguished when the LoST server 378 sets the element in the response message: 380 1. If the requested service, identified by the service URN [9] in 381 the element of the request, exists for the location 382 indicated, then the LoST server puts the service URN from the 383 request into the element. 385 2. If, however, the requested service, identified by the service URN 386 [9] in the element in the request, does not exist for 387 the location indicated, the server can either return an 388 (Section 12.1) error or can provide an 389 alternate service that approximates the desired service for that 390 location. In the latter case, the server MUST include a 391 element with the alternative service URN. The choice 392 of service URN is left to local policy, but the alternate service 393 should be able to satisfy the original service request. 395 The element is optional but may also be required if the 396 mapping is to be digitally signed. 398 5.5. Defining the Service Region with the Element 400 A response MAY indicate the region for which the service URL returned 401 would be the same as in the actual query, the so-called _service 402 region_. The service region can be indicated by value or by 403 reference (see Section 5.6). If a client moves outside the service 404 area and wishes to obtain current service data, it sends a new query 405 with its current location. The service region is described by value 406 in one or more elements, each formatted according 407 to a different location profile, identified by the 'profile' atribute 408 (see Section 11). If included in a response, the 409 element MUST contain at least one service boundary that uses the same 410 profile as the request. The client only processes the first element 411 that it can understand according to its list of supported location 412 profiles. Thus, elements with geospatial coordinates are alternative 413 descriptions of the same service region, not additive geometries. 415 A service boundary is requested by the client (using the 416 'serviceBoundary' attribute in the request with the value set to 417 "value"). 419 A response MAY contain more than one element with 420 profile 'civic'. Each element describes a set of 421 civic addresses that fall within the service boundary, namely all 422 addresses that textually match the civic address elements provided, 423 regardless of the value of other address elements. A location falls 424 within the mapping's service boundary if it matches any of the 425 elements. 427 5.6. Service Boundaries by Reference: the 428 Element 430 Since geodetic service boundaries may contain thousands of points and 431 thus be quite large, clients may opt to conserve bandwidth and 432 request a reference to the service boundary instead of the value 433 described in Section 5.5. The identifier of the service boundary is 434 returned as an attribute of the element, 435 along with a LoST application unique string (see Section 4) 436 identifying the server from where it can be retrieved. The actual 437 value of the service boundary is then retrieved with the 438 getServiceBoundary (Section 8) request. 440 A reference to a service boundary is requested by the client (using 441 the 'serviceBoundary' attribute in the request with the value set to 442 "reference"). A LoST server may decide, based on local policy, to 443 return the service boundary per value or to omit the 444 element in the response. 446 The identifier is a random token with at least 128 bits of entropy 447 and can be assumed to be globally unique. It uniquely references a 448 particular boundary. If the boundary changes, a new identifier MUST 449 be chosen. Because of these properties, a client receiving a mapping 450 response can simply check if it already has a copy of the boundary 451 with that identifier. If so, it can skip checking with the server 452 whether the boundary has been updated. Since service boundaries are 453 likely to remain unchanged for extended periods of time, possibly 454 exceeding the normal lifetime of the service URL, this approach 455 avoids unnecessarily refreshing the boundary information just because 456 the the remainder of the mapping has become invalid. 458 5.7. The Service Number Element 460 The service number is returned in the optional 461 element. It contains a string of digits, * and # that a user on a 462 device with a 12-key dial pad could use to reach that particular 463 service. 465 5.8. Service URLs: the Element 467 The response returns the service URLs in one or more elements. 468 The URLs MUST be absolute URLs. The ordering of the URLs has no 469 particular significance. Each URL scheme MUST only appear at most 470 once, but it is permissible to include both secured and regular 471 versions of a protocol, such as both 'http' and 'https' or 'sip' and 472 'sips'. 474 6. Path of a Request: Element 476 To prevent loops and to allow tracing of request and response paths, 477 all requests that allow recursion include a element that 478 contains one or more elements, each possessing an attribute 479 containing a LoST application unique string (see Section 4). The 480 order of elements corresponds to the order of LoST servers, 481 i.e., the first element identifies the server that initially 482 received the request from the client issuing the request. The 483 element is inserted logically on receipt of the request, so that 484 every server in a recursive query operation is included in the 485 element. 487 The server that answers the request instead of forwarding it, such as 488 the authoritative server, copies the element verbatim into the 489 response. The element is not modified in responses as the 490 responses traverses the server chain back to the querying client. 492 If a query is answered iteratively, the querier includes all servers 493 that it has already contacted. 495 The example in Figure 5 indicates that the answer was given to the 496 client by the LoST server at esgw.ueber-110.de.example, which got the 497 answer from the (authoritative) LoST server at 498 polizei.muenchen.de.example. 500 7. Mapping a Location and Service to URLs: 502 7.1. Overview 504 The query constitutes the core of the LoST 505 functionality, mapping civic or geodetic locations to URLs and 506 associated data. After giving an example, we enumerate the elements 507 of the query and response. 509 7.2. Examples 511 7.2.1. Example Using Geodetic Coordinates 513 The following is an example of mapping a service to a location using 514 geodetic coordinates, for the service associated with the police 515 (urn:service:sos.police). 517 518 524 525 526 37.775 -122.422 527 528 529 urn:service:sos.police 531 533 Figure 2: A geodetic query 535 Given the query above, a server would respond with a service, and 536 information related to that service. In the example below, the 537 server has mapped the location given by the client for a police 538 service to the New York City Police Deparment, instructing the client 539 that it may contact them via the URIs "sip:nypd@example.com" and 540 "xmpp:nypd@example.com". The server has also given the client a 541 geodetic, two-dimensional boundary for this service. The mapping was 542 last updated on November 1, 2006 and expires on January 1, 2007. If 543 the client's location changes beyond the given service boundary or 544 the expiration time has been reached, it may want to requery for this 545 information, depending on the usage environment of LoST. 547 548 550 555 556 New York City Police Department 557 558 urn:service:sos.police 559 560 561 562 563 37.775 -122.4194 564 37.555 -122.4194 565 37.555 -122.4264 566 37.775 -122.4264 567 37.775 -122.4194 568 569 570 571 572 sip:nypd@example.com 573 xmpp:nypd@example.com 574 911 575 576 577 578 579 580 582 Figure 3: A geodetic answer 584 7.2.2. Civic Address Mapping Example 586 The following is an example of mapping a service to a location much 587 like the example in Section 7.2.1, but using civic address location 588 information. In this example, the client requests the service 589 associated with police (urn:service:sos.police) along with a specific 590 civic address (house number 6 on a street named Otto-Hahn-Ring in 591 Munich, Germany). 593 594 596 598 600 Germany 601 Bavaria 602 Munich 603 Otto-Hahn-Ring 604 6 605 81675 606 607 608 urn:service:sos.police 609 611 Figure 4: A civic address query 613 Given the query above, a server would respond with a service, and 614 information related to that service. In the example below, the 615 server has mapped the location given by the client for a police 616 service to the Muenchen Polizei-Abteilung, instructing the client 617 that it may contact them via the URIs sip:munich-police@example.com 618 and xmpp:munich-police@example.com. The server has also given the 619 client a civic address boundary (the city of Munich) for this 620 service. The mapping was last updated on November 1, 2006 by the 621 authoritative source "polizei.muenchen.de.example" and expires on 622 January 1, 2007. This instructs the client to requery for the 623 information if its location changes beyond the given service boundary 624 (i.e., beyond the city of Munich) or after January 1, 2007. 626 627 628 633 634 Muenchen Polizei-Abteilung 635 636 urn:service:sos.police 637 639 641 Germany 642 Bavaria 643 Munich 644 81675 645 646 647 sip:munich-police@example.com 648 xmpp:munich-police@example.com 649 110 650 651 652 653 654 655 657 Figure 5: A civic address answer 659 7.3. Components of the Request 661 The request includes attributes that govern whether the 662 request is handled iteratively or recursively, whether location 663 validation is performed and which elements may be contained in the 664 response. 666 7.3.1. The Element 668 The query communicates location information using one 669 or more elements, which MUST conform to a location profile 670 (see Section 11). There MUST NOT be more than one location element 671 for each distinct location profile. The order of location objects is 672 significant; the server uses the first location object where it 673 understands the location profile. 675 7.3.2. Identifying the Service: The Element 677 The type of service desired is specified by the element. 678 It contains service URNs from the registry established in [9]. 680 7.3.3. Recursion and Iteration 682 LoST can operate in either recursive or iterative mode, on a request- 683 by-request basis. In recursive mode, the LoST server initiates 684 queries on behalf of the requester and returns the result to the 685 requester. 687 In iterative mode, the server contacted returns a redirection 688 response indicating the next server to be queried. 690 For the queries defined in this document, only LoST and 691 queries can be recursive, as indicated by 692 the 'recursive' attribute. A value of "true" indicates a recursive 693 query, with the default being "false" when the attribute is omitted. 694 Regardless of the attribute, a server MAY always answer a query by 695 providing a LoST application unique string (see Section 4), i.e., 696 indirection, however, it MUST NOT recurse if the attribute is 697 "false". 699 7.3.4. Service Boundary 701 LoST elements can describe the service boundary either by 702 value or by reference. Returning a service boundary reference is 703 generally more space-efficient for geospatial (polygon) boundaries 704 and if the boundaries change rarely, but does incur an additional 705 request. The querier can express a preference 706 for one or the other modality with the 'serviceBoundary' attribute in 707 the request, but the server makes the final decision as 708 to whether to return a reference or a value. 710 7.3.5. Requesting Civic Location Validation 712 Civic address validation is requested by setting the optional 713 attribute 'validateLocation' to true. If the attribute is omitted, 714 it is assumed to be false. The response is described in 715 Section 7.4.2. The example in Figure 6 demonstrates address 716 validation, omitting the standard response elements. 718 719 724 725 727 DE 728 Bavaria 729 Munich 730 Otto-Hahn-Ring 731 6 732 81675 733 734 735 urn:service:sos.police 736 738 Figure 6: A query with address validation request 740 741 742 748 749 Muenchen Polizei-Abteilung 750 751 urn:service:sos.police 752 753 755 Germany 756 Bavaria 757 Munich 758 81675 759 760 761 sip:munich-police@example.com 762 xmpp:munich-police@example.com 763 110 764 765 766 country A1 A3 A6 767 PC 768 769 770 771 772 773 775 Figure 7: A message with address validation 776 information 778 7.4. Components of the Mapping Response 780 7.4.1. Overview 782 Mapping responses consist of the element (Section 5) 783 describing the mapping itself, possibly followed by warnings 784 (Section 12.2), location validation information (Section 7.4.2), and 785 an indication of the path (Section 6) the response has taken. 787 7.4.2. Civic Address Validation: the Element 789 A server can indicate in its response which civic address elements it 790 has recognized as valid, which ones it has ignored and which ones it 791 has checked and found to be invalid. The server SHOULD include this 792 information if the 'validateLocation' attribute in the request was 793 true but local policy at the server may allow this information to be 794 omitted. Each element contains a list of tokens separated by white 795 space, enumerating the civic location lables used in child elements 796 of the element. The element enumerates those 797 civic address elements that have been recognized as valid by the LoST 798 server and that have been used to determine the mapping. The 799 elements enumerates the civic address elements that the 800 server did not check and that were not used in determining the 801 response. The element enumerate civic address elements 802 that the server attempted to check, but that did not match the other 803 civic address elements found in the list. 805 Note that the same address can yield different responses if parts of 806 the civic address contradict each other. For example, if the postal 807 code does not match the city, local server policy determines whether 808 the postal code or the city is considered valid. The mapping 809 naturally corresponds to the valid elements. 811 The example (Figure 6) indicates that the tokens 'country', 'A1', 812 'A3', and 'A6' have been validated by the LoST server. The server 813 considered the postal code 81675 in the element as not valid for 814 this location. 816 8. Retrieving the Service Boundary via 818 As discussed in Section 5.5, the can return a 819 globally unique identifier in the 'serviceBoundary' attribute that 820 can be used to retrieve the service boundary, rather than returning 821 the boundary by value. This is shown in the example in Figure 8. 822 The client can then retrieve the boundary using the 823 request and obtains the boundary in the 824 , illustrated in the example in 825 Figure 10. The client issues the request to the server identified in 826 the 'server' attribute of the element. 827 These requests are always directed to the authoritative server and do 828 not recurse. 830 831 836 837 838 37.775 -122.422 839 840 841 urn:service:sos.police 842 844 Figure 8: request and response with service boundary 845 reference 847 848 850 856 857 New York City Police Department 858 859 urn:service:sos.police 860 863 sip:nypd@example.com 864 xmpp:nypd@example.com 865 911 866 867 868 869 870 871 873 Figure 9: message with service boundary 874 reference 876 877 880 Figure 10: Requesting a service boundary with 882 The request may also be used to retrieve service 883 boundaries that are expressed as civic addresses, as illustrated in 884 Figure 11. 886 887 889 891 893 US 894 New York 895 New York 896 897 898 899 900 901 902 904 Figure 11: Civic Address Service Boundary Response 906 9. List Services: 908 A LoST client can ask a LoST server for the list of services that it 909 understands, primarily for diagnostic purposes. The query does not 910 contain location information, as it simply provides an indication of 911 which services the server can look up, not whether a particular 912 service is offered for a particular area. Typically, only top-level 913 services are included in the answer, implying support for all sub- 914 services. Since the query is answered by the queried server, there 915 is no notion of recursion or indirection and no path indication. The 916 921 923 urn:service:sos 924 926 Figure 12: Example of query 928 929 931 932 urn:service:sos.ambulance 933 urn:service:sos.animal-control 934 urn:service:sos.fire 935 urn:service:sos.gas 936 urn:service:sos.mountain 937 urn:service:sos.marine 938 urn:service:sos.physician 939 urn:service:sos.poison 940 urn:service:sos.police 941 urn:service:sos.suicide 942 943 945 Figure 13: Example of 947 10. List Services By Location: 949 A LoST client can ask a LoST server for the list of services it knows 950 about for a particular area. The query 951 contains one or more elements, each from a different 952 location profile (Section 11), and may contain the element. 953 As for , the server selects the first location element 954 that has a profile the server understands and it can operate either 955 recursively or iteratively; < via> elements track the progress of the 956 request. By its nature, the query can only indicate the services 957 that a particular server can determine, not all possible services 958 that might be offered. Unlike , the answer describes 959 the services available at a specific location, not just those 960 understood by the server. 962 If the query contains the element, the LoST server returns 963 only immediate child services of the queried service that are 964 available for the provided location. If the element is 965 absent, the LoST service returns all top-level services available for 966 the provided location that it knows about. 968 A server responds to this query with a 969 response. This response MAY contain 970 elements (see Section 6) and MUST contain a 971 element, consisting of a whitespace-separated list of service URNs. 972 The query and response are illustrated in Figure 14 and in Figure 15, 973 respectively. 975 976 980 981 982 -34.407 150.883 983 984 985 urn:service:sos 986 988 Figure 14: Example of query 990 991 993 994 urn:service:sos.ambulance 995 urn:service:sos.animal-control 996 urn:service:sos.fire 997 urn:service:sos.gas 998 urn:service:sos.mountain 999 urn:service:sos.marine 1000 urn:service:sos.physician 1001 urn:service:sos.poison 1002 urn:service:sos.police 1003 urn:service:sos.suicide 1004 1005 1006 1007 1008 1009 1011 Figure 15: Example of response 1013 11. Location Profiles 1015 LoST uses location information in elements in requests and 1016 elements in responses. Such location information 1017 may be expressed in a variety of ways. This variety can cause 1018 interoperability problems where a request or response contains 1019 location information in a format not understood by the server or the 1020 client, respectively. To achieve interoperability, this document 1021 defines two mandatory-to-implement baseline location profiles to 1022 define the manner in which location information is transmitted. It 1023 possible to standardize other profiles in the future. The two 1024 baseline profiles are: 1026 geodetic-2d: 1028 a simple profile for two-dimensional geodetic location 1029 information, as described in Section 11.2; 1031 civic: 1033 a profile consisting of civic address location information, as 1034 described in Section 11.3. 1036 Requests and responses containing or 1037 elements MUST contain location information in exactly one of the two 1038 baseline profiles, in addition to zero or more additional profiles. 1039 The ordering of location information indicates a preference on the 1040 part of the sender. 1042 Standards action is required for defining new profiles. A location 1043 profile MUST define: 1045 1. The token identifying it in the LoST location profile registry; 1047 2. The formal definition of the XML to be used in requests, i.e., an 1048 enumeration and definition of the XML child elements of the 1049 element; 1051 3. The formal definition of the XML to be used in responses, i.e., 1052 an enumeration and definition of the XML child elements of the 1053 element; 1055 4. The declaration of whether geodetic-2d or civic is to be used as 1056 the baseline profile. It is necessary to explicitly declare the 1057 baseline profile as future profiles may be combinations of 1058 geodetic and civic location information. 1060 11.1. Location Profile Usage 1062 A location profile is identified by a token in an IANA-maintained 1063 registry (Section 16.5). Clients send location information compliant 1064 with a location profile, and servers respond with location 1065 information compliant with that same location profile. 1067 When a LoST client sends a request that provides 1068 location information, it includes one or more elements. A 1069 element carries a mandatory 'profile' attribute that 1070 indicates the location format of the child elements. The concept of 1071 location profiles are described in Section 11. With the ability to 1072 specify more than one element the client is able to convey 1073 location information for multiple location profiles in the same 1074 request. 1076 When a LoST server sends a response that contains location 1077 information, it uses the elements much like the 1078 client uses the elements. Each element 1079 contains location information conformant to the location profile 1080 specified in the 'profile' attribute. When multiple 1081 elements are included then it enables the server to send location 1082 information compliant with multiple location profiles. 1084 Using the location profiles defined in this document, the following 1085 rules insure basic interoperatiblity between clients and servers: 1087 1. A client MUST be capable of understanding the response for the 1088 baseline profiles it used in the request. 1090 2. If a client sends location information conformant to any location 1091 profile other than geodetic-2d or civic, it MUST also send, in 1092 the same request, location information conformant to one of the 1093 baseline profiles. Otherwise, the server might not be able to 1094 understand the request. 1096 3. A client SHOULD NOT send multiple profiles of derived 1097 from different baseline profiles. Or said another way, a client 1098 should only send location profiles from the same baseline profile 1099 in the same query. If a client has location information 1100 primarily of geodetic nature and location information primarily 1101 of a civic nature, it should send separate requests containing 1102 each type of location information. 1104 4. There can only be one instance of each location profile in a 1105 query. 1107 5. Servers MUST implement the geodetic-2d and civic profiles. 1109 6. A server uses the first-listed location profile that it 1110 understands and ignores the others. 1112 7. If a server receives a request that only contains location 1113 information using profiles it does not understand, the server 1114 responds with a (Section 12.1). 1116 8. The element MUST use the same location profile 1117 that was used to retrieve the answer and indicates which profile 1118 has been used with the 'profile' attribute. 1120 These rules enable the use of location profiles not yet specified, 1121 while ensuring baseline interoperability. Take, for example, this 1122 scenario. Client X has had its firmware upgraded to support the 1123 uber-complex-3D location profile. Client X sends location 1124 information to Server Y, which does not understand the 1125 uber-complex-3D location profile. If Client X also sends location 1126 information using the geodetic-2D baseline profile, then Server Y 1127 will still be able to understand the request and provide an 1128 understandable response, though with location information that might 1129 not be as precise or expressive as desired. This is possible because 1130 both Client X and Server Y understand the baseline profile. 1132 1133 1138 1139 1140 37.775 -122.422 1141 1142 1143 1144 1145 37.775 -122.4194 1146 37.555 -122.4194 1147 37.555 -122.4264 1148 37.775 -122.4264 1149 37.775 -122.4194 1150 1151 1152 1153 1154 -122.422 37.775 1155 1156 1157 1158 1159 37.775 -122.422 1160 1161 1162 urn:service:sos.police 1163 1165 Figure 16: Example of a query with baseline profile 1166 interoperability 1168 1169 1172 1178 1179 New York City Police Department 1180 1181 urn:service:sos.police 1182 1183 1184 1185 1186 37.775 -122.4194 1187 37.555 -122.4194 1188 37.555 -122.4264 1189 37.775 -122.4264 1190 37.775 -122.4194 1191 1192 1193 1194 1195 sip:nypd@example.com 1196 1197 1198 1199 1200 1201 1203 Figure 17: Example of a message with baseline 1204 profile interoperability 1206 11.2. Two Dimensional Geodetic Profile 1208 The geodetic-2d location profile is identified by geodetic-2d. 1209 Clients use this profile by placing a element, as described 1210 in Section 7.2.1 of [13], within the element. Section 1211 7.2.1 of [13] describes the specification of a with either a 1212 two dimensional position (latitude and longitude) or three 1213 dimensional position (latitude, longitude, and altitude). A client 1214 MAY use the three dimensional position, and servers MAY interpret a 1215 three dimensional position as a two dimensional position by ignoring 1216 altitude. 1218 Servers use this profile by placing a element, as described 1219 in Section 7.2.2 of [13], within the element. This 1220 is defined by the 'polygon' pattern in the LoST schema (see 1221 Section 14). 1223 With respect to the description in Section 7.2.2 of [13] the 1224 restriction to 16 points for a polygon is not applicable to this 1225 document. With this profile servers MUST use WGS 84 (latitude, 1226 longitude), i.e., the srsName set to 'urn:ogc:def:crs:EPSG::4326' 1227 where altitude information is omitted. The orientation of the points 1228 in the polygon is upward normal as described in Section 7.2.2 of 1229 [13]. 1231 11.3. Basic Civic Profile 1233 The basic-civic location profile is identified by the token 'civic'. 1234 Clients use this profile by placing a element, defined 1235 in [10], within the element. 1237 Servers use this profile by placing a element, defined 1238 in [10], within the element. 1240 12. Errors, Warnings, and Redirects 1242 When a LoST server cannot fulfill a request completely, it can return 1243 either an error or a warning, depending on the severity of the 1244 problem. It returns an error element if no useful response can be 1245 returned for the query. It returns a element as part of 1246 another response element if it was able to respond in part, but the 1247 response may not be quite what the client had desired. This document 1248 does not define warnings. For both elements, the 'source' attribute 1249 names the server that originally generated the error or warning, such 1250 as the authoritative server. Unless otherwise noted, all elements 1251 below can be either an error or a warning, depending on whether a 1252 default response, such as a mapping, is included. 1254 12.1. Errors 1256 LoST defines a pattern for errors, defined as elements in 1257 the Relax NG schema. This pattern defines a 'message' attribute 1258 containing human readable text and an 'xml:lang' attribute denoting 1259 the language of the human readable text. One or more such error 1260 elements are contained in the element. 1262 The following errors follow this basic pattern: 1264 badRequest 1266 The server could not parse or otherwise understand a request, 1267 e.g., because the XML was malformed. 1269 forbidden 1271 The server refused to send an answer. This generally only occurs 1272 for recursive queries, namely if the client tried to contact the 1273 authoritative server and was refused. (For HTTP as the underlying 1274 protocol, an HTTP 401 error would be returned.) 1276 internalError 1278 The server could not satisfy a request due to misconfiguration or 1279 other operational and non-protocol related reasons. 1281 locationProfileUnrecognized 1283 None of the profiles in the request were recognized by the server 1284 (see Section 11). 1286 loop 1288 During a recursive query, the server was about to visit a server 1289 that was already in the server list in the element, 1290 indicating a request loop. 1292 notFound 1294 The server could not find an answer to the query. 1296 serverError 1298 An answer was received from another LoST server, but it could not 1299 be parsed or otherwise understood. This error occurs only for 1300 recursive queries. 1302 serverTimeout 1304 A time out occurred before an answer was received. 1306 serviceNotImplemented 1308 The requested service URN is not implemented and no substitution 1309 was available. 1311 An example is below: 1313 1314 1316 1317 1319 Figure 18: Example of an error resonse 1321 12.2. Warnings 1323 A response MAY contain zero or more warnings. This pattern defines a 1324 'message' attribute containing human readable text and an 'xml:lang' 1325 attribute denoting the language of the human readable text. One or 1326 more such warning elements are contained in the element. 1328 This version of the specification does not define any warning 1329 elements. 1331 12.3. Redirects 1333 A LoST server can respond indicating that the querier should redirect 1334 the query to another server, using the element. The 1335 element includes a 'target' attribute indicating the LoST application 1336 unique string (see Section 4) that the client SHOULD be contacting 1337 next, as well as the 'source' attribute indicating the server that 1338 generated the redirect response and a 'message' attribute explaining 1339 the reason for the redirect response. During a recursive query, a 1340 server receiving a response can decide whether it wants to 1341 follow the redirection or simply return the response to its upstream 1342 querier. 1344 An example is below: 1346 1347 1352 Figure 19: Example of a redirect resonse 1354 13. LoST Transport 1356 LoST needs an underlying protocol transport mechanisms to carry 1357 requests and responses. This document defines the use of LoST over 1358 HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future 1359 documents. The available transport mechanisms are determined through 1360 the use of the LoST U-NAPTR application. In protocols that support 1361 content type indication, LoST uses the media type application/ 1362 lost+xml. 1364 When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP 1365 POST method. All HTTP responses are applicable. The HTTP URL is 1366 derived from the LoST server name via U-NAPTR application, as 1367 discussed above 1369 14. Relax NG Schema 1371 This section provides the Relax NG schema used by LoST protocol in 1372 the compact form. The verbose form is included in Appendix A. 1374 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 1375 default namespace ns1 = "urn:ietf:params:xml:ns:lost1" 1377 ## 1378 ## Location-to-Service Translation Protocol (LoST) 1379 ## 1380 ## A LoST XML instance has three request types, each with 1381 ## a cooresponding response type: find service, list services, 1382 ## and get service boundary. 1383 ## 1384 start = 1385 findService 1386 | listServices 1387 | listServicesByLocation 1388 | getServiceBoundary 1389 | findServiceResponse 1390 | listServicesResponse 1391 | listServicesByLocationResponse 1392 | getServiceBoundaryResponse 1393 | errors 1394 | redirect 1396 ## 1397 ## The queries. 1398 ## 1399 div { 1400 findService = 1401 element findService { 1402 element location { locationInformation }+, 1403 commonRequestPattern, 1404 attribute validateLocation { 1405 xsd:boolean >> a:defaultValue [ "false" ] 1406 }?, 1407 attribute serviceBoundary { 1408 ("reference" | "value") >> a:defaultValue [ "reference" ] 1409 }?, 1410 attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? 1411 } 1412 listServices = element listServices { commonRequestPattern } 1413 listServicesByLocation = 1414 element listServicesByLocation { 1415 element location { locationInformation }*, 1416 commonRequestPattern, 1417 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 1418 } 1419 getServiceBoundary = 1420 element getServiceBoundary { serviceBoundaryKey, extensionPoint } 1421 } 1423 ## 1424 ## The responses. 1425 ## 1426 div { 1427 findServiceResponse = 1428 element findServiceResponse { 1429 mapping+, locationValidation?, commonResponsePattern 1430 } 1431 listServicesResponse = 1432 element listServicesResponse { serviceList, commonResponsePattern } 1433 listServicesByLocationResponse = 1434 element listServicesByLocationResponse { 1435 serviceList, commonResponsePattern 1436 } 1437 getServiceBoundaryResponse = 1438 element getServiceBoundaryResponse { 1439 serviceBoundary, commonResponsePattern 1440 } 1441 } 1443 ## 1444 ## A pattern common to some of the queries. 1445 ## 1446 div { 1447 commonRequestPattern = service, path?, extensionPoint 1448 } 1450 ## 1451 ## A pattern common to responses. 1452 ## 1453 div { 1454 commonResponsePattern = warnings*, path, extensionPoint 1455 } 1457 ## 1458 ## Location Information 1459 ## 1460 div { 1461 locationInformation = 1462 extensionPoint+, 1463 attribute profile { xsd:NMTOKEN } 1464 } 1466 ## 1467 ## Service Boundary 1468 ## 1469 div { 1470 serviceBoundary = element serviceBoundary { locationInformation }+ 1471 } 1473 ## 1474 ## Service Boundary Reference 1475 ## 1476 div { 1477 serviceBoundaryReference = 1478 element serviceBoundaryReference { 1479 source, serviceBoundaryKey, extensionPoint 1480 } 1481 serviceBoundaryKey = attribute key { xsd:token } 1482 } 1484 ## 1485 ## Path - 1486 ## Contains a list of via elements - 1487 ## places through which information flowed 1488 ## 1489 div { 1490 path = 1491 element path { 1492 element via { source, extensionPoint }+ 1493 } 1494 } 1496 ## 1497 ## Expires pattern 1498 ## 1499 div { 1500 expires = 1501 attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } 1502 } 1504 ## 1505 ## A QName list 1506 ## 1507 div { 1508 qnameList = list { xsd:QName* } 1509 } 1510 ## 1511 ## A location-to-service mapping. 1512 ## 1513 div { 1514 mapping = 1515 element mapping { 1516 element displayName { 1517 xsd:string, 1518 attribute xml:lang { xsd:language } 1519 }*, 1520 service, 1521 (serviceBoundary | serviceBoundaryReference)?, 1522 element uri { xsd:anyURI }*, 1523 element serviceNumber { 1524 xsd:string { pattern = "[0-9*#]+" } 1525 }?, 1526 extensionPoint, 1527 expires, 1528 attribute lastUpdated { xsd:dateTime }, 1529 source, 1530 attribute sourceId { xsd:token }, 1531 message 1532 } 1533 } 1535 ## 1536 ## Location validation 1537 ## 1538 div { 1539 locationValidation = 1540 element locationValidation { 1541 element valid { qnameList }?, 1542 element invalid { qnameList }?, 1543 element unchecked { qnameList }?, 1544 extensionPoint 1545 } 1546 } 1548 ## 1549 ## Errors and Warnings Container. 1550 ## 1551 div { 1552 errorContainer = 1553 (badRequest? 1554 & internalError? 1555 & serviceSubstitution? 1556 & forbidden? 1557 & notFound? 1558 & loop? 1559 & serviceNotImplemented? 1560 & serverTimeout? 1561 & serverError? 1562 & locationProfileUnrecognized?), 1563 extensionPoint, 1564 source 1565 errors = element errors { errorContainer } 1566 warnings = element warnings { errorContainer } 1567 } 1569 ## 1570 ## Basic Errors 1571 ## 1572 div { 1574 ## 1575 ## Error pattern. 1576 ## 1577 basicError = message, extensionPoint 1578 badRequest = element badRequest { basicError } 1579 internalError = element internalError { basicError } 1580 serviceSubstitution = element serviceSubstitution { basicError } 1581 forbidden = element forbidden { basicError } 1582 notFound = element notFound { basicError } 1583 loop = element loop { basicError } 1584 serviceNotImplemented = element serviceNotImplemented { basicError } 1585 serverTimeout = element serverTimeout { basicError } 1586 serverError = element serverError { basicError } 1587 locationProfileUnrecognized = 1588 element locationProfileUnrecognized { 1589 attribute unsupportedProfiles { xsd:NMTOKENS }, 1590 basicError 1591 } 1592 } 1594 ## 1595 ## Redirect. 1596 ## 1597 div { 1599 ## 1600 ## Redirect pattern 1601 ## 1602 redirect = 1603 element redirect { 1604 attribute target { appUniqueString }, 1605 source, 1606 message, 1607 extensionPoint 1608 } 1609 } 1611 ## 1612 ## Some common patterns. 1613 ## 1614 div { 1615 message = 1616 (attribute message { xsd:string }, 1617 attribute xml:lang { xsd:language })? 1618 service = element service { xsd:anyURI }? 1619 appUniqueString = 1620 xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } 1621 source = attribute source { appUniqueString } 1622 serviceList = 1623 element serviceList { 1624 list { xsd:anyURI* } 1625 } 1626 } 1628 ## 1629 ## Patterns for inclusion of elements from schemas in 1630 ## other namespaces. 1631 ## 1632 div { 1634 ## 1635 ## Any element not in the LoST namespace. 1636 ## 1637 notLost = element * - (ns1:* | ns1:*) { anyElement } 1639 ## 1640 ## A wildcard pattern for including any element 1641 ## from any other namespace. 1642 ## 1643 anyElement = 1644 (element * { anyElement } 1645 | attribute * { text } 1646 | text)* 1648 ## 1649 ## A point where future extensions 1650 ## (elements from other namespaces) 1651 ## can be added. 1652 ## 1653 extensionPoint = notLost* 1655 } 1657 Figure 20: RelaxNG schema 1659 15. Internationalization Considerations 1661 This mechanism is largely for passing protocol information from one 1662 subsystem to another; as such, most of its elements are tokens not 1663 meant for direct human consumption. If these tokens are presented to 1664 the end user, some localization may need to occur. The content of 1665 the element and the 'message' attributes may be 1666 displayed to the end user, and they are thus a complex types designed 1667 for this purpose. 1669 LoST exchanges information using XML. All XML processors are 1670 required to understand UTF-8 and UTF-16 encodings, and therefore all 1671 LoST clients and servers MUST understand UTF-8 and UTF-16 encoded 1672 XML. Additionally, LoST servers and clients MUST NOT encode XML with 1673 encodings other than UTF-8 or UTF-16. 1675 16. IANA Considerations 1677 16.1. U-NAPTR Registrations 1679 This document registers the following U-NAPTR application service 1680 tag: 1682 Application Service Tag: LoST 1684 Defining Publication: The specification contained within this 1685 document. 1687 This document registers the following U-NAPTR application protocol 1688 tags: 1690 o 1692 Application Protocol Tag: http 1694 Defining Publication: RFC 2616 [3] 1696 o 1698 Application Protocol Tag: https 1700 Defining Publication: RFC 2818 [4] 1702 16.2. Content-type registration for 'application/lost+xml' 1704 This specification requests the registration of a new MIME type 1705 according to the procedures of RFC 4288 [7] and guidelines in RFC 1706 3023 [5]. 1708 MIME media type name: application 1710 MIME subtype name: lost+xml 1712 Mandatory parameters: none 1714 Optional parameters: charset 1716 Indicates the character encoding of enclosed XML. 1718 Encoding considerations: 1720 Uses XML, which can employ 8-bit characters, depending on the 1721 character encoding used. See RFC 3023 [5], Section 3.2. 1723 Security considerations: 1725 This content type is designed to carry LoST protocol payloads. 1727 Interoperability considerations: None 1729 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 1730 replace XXXX with the RFC number of this specification.] this 1731 document 1733 Applications which use this media type: 1735 Emergency and Location-based Systems 1737 Additional information: 1739 Magic Number: None 1741 File Extension: .lostxml 1743 Macintosh file type code: 'TEXT' 1745 Personal and email address for further information: Hannes 1746 Tschofenig, Hannes.Tschofenig@siemens.com 1748 Intended usage: LIMITED USE 1750 Author: 1752 This specification is a work item of the IETF ECRIT working group, 1753 with mailing list address . 1755 Change controller: 1757 The IESG 1759 16.3. LoST Relax NG Schema Registration 1761 URI: urn:ietf:params:xml:ns:lost1 1763 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1764 (Hannes.Tschofenig@siemens.com). 1766 Relax NG Schema: The Relax NG schema to be registered is contained 1767 in Section 14. Its first line is 1769 default namespace = "urn:ietf:params:xml:ns:lost1" 1771 and its last line is 1773 } 1775 16.4. LoST Namespace Registration 1777 URI: urn:ietf:params:xml:ns:lost1 1779 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1780 (Hannes.Tschofenig@siemens.com). 1782 XML: 1784 BEGIN 1785 1786 1788 1789 1790 1792 LoST Namespace 1793 1794 1795

Namespace for LoST

1796

urn:ietf:params:xml:ns:lost1

1797

See RFCXXXX 1798 [NOTE TO IANA/RFC-EDITOR: 1799 Please replace XXXX with the RFC number of this 1800 specification.].

1801 1802 1803 END 1805 16.5. LoST Location Profile Registry 1807 This document seeks to create a registry of location profile names 1808 for the LoST protocol. Profile names are XML tokens. This registry 1809 will operate in accordance with RFC 2434 [2], Standards Action. 1811 geodetic-2d: 1813 Defined in Section 11.2 1815 civic: 1817 Defined in Section 11.3 1819 17. Security Considerations 1821 There are multiple threats to the overall system of which service 1822 mapping forms a part. An attacker that can obtain service contact 1823 URIs can use those URIs to attempt to disrupt those services. An 1824 attacker that can prevent the lookup of contact URIs can impair the 1825 reachability of such services. An attacker that can eavesdrop on the 1826 communication requesting this lookup can surmise the existence of an 1827 emergency and possibly its nature, and may be able to use this to 1828 launch a physical attack on the caller. 1830 To avoid that an attacker can modify the query or its result, the use 1831 of channel security, such as TLS, is RECOMMENDED. 1833 Generally, authentication and authorization is not required for 1834 mapping queries. If it is, authentication mechanism of the 1835 underlying transport mechanism, such as HTTP basic and digest 1836 authentication, MAY be used. (Basic authentication SHOULD only be 1837 used in combination with TLS.) 1839 A more detailed description of threats and security requirements are 1840 provided in [17]. 1842 18. Acknowledgments 1844 We would like to the thank the following working group members for 1845 the detailed review of previous LoST document versions: 1847 o Martin Thomson (Review July 2006) 1849 o Jonathan Rosenberg (Review July 2006) 1851 o Leslie Daigle (Review September 2006) 1853 o Shida Schubert (Review November 2006) 1855 o Martin Thomson (Review December 2006) 1857 o Barbara Stark (Review January 2007) 1859 o Patrik Faeltstroem (Review January 2007 1861 o Shida Schubert (Review January 2007 as a designated expert 1862 reviewer) 1864 o Jonathan Rosenberg (Review February 2007) 1866 o Tom Taylor (Review February 2007) 1868 o Theresa Reese (Review February 2007) 1870 o Shida Schubert (Review February 2007) 1872 We would also like to thank the following working group members for 1873 their input to selected design aspects of the LoST protocol: 1875 o Leslie Daigle and Martin Thomson (DNS-based LoST discovery 1876 procedure) 1878 o John Schnizlein (authoritive LoST answers) 1880 o Rohan Mahy (display names) 1882 o James Polk (error handling) 1884 o Ron Watro and Richard Barnes (expiry of cached data) 1886 o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James 1887 Winterbottom (Indication of PSAP Confidence Level) 1889 o Martin Thomson (service boundary references) 1891 o Martin Thomson (service URN in LoST response message) 1893 o Cullen Jennings (service boundaries) 1895 o Clive D.W. Feather, Martin Thomson (Validation Functionality) 1897 o Roger Marshall (PSAP Preference in LoST response) 1899 o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, 1900 Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. 1901 Feather, Richard Stastny, John Hearty, Roger Marshall, Jean- 1902 Francois Mule, Pierre Desjardins (Location Profiles) 1904 o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson, 1905 Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, 1906 Keith (List Services functionality) 1908 o Thomson, Martin, Michael Hammer (Mapping of Services) 1910 o Shida Schubert, James Winterbottom, Keith Drage (default service 1911 URN) 1913 o Otmar Lendl (LoST aggregation) 1915 o Tom Taylor (Terminology) 1917 Klaus Darilion and Marc Linsner provided miscellaneous input to the 1918 design of the protocol. Finally, we would like to thank Brian Rosen 1919 who participated in almost every discussion thread. 1921 19. Open Issues 1923 Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ 1925 20. References 1927 20.1. Normative References 1929 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1930 Levels", BCP 14, RFC 2119, March 1997. 1932 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1933 Considerations Section in RFCs", BCP 26, RFC 2434, 1934 October 1998. 1936 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1937 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1938 HTTP/1.1", RFC 2616, June 1999. 1940 [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1942 [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1943 RFC 3023, January 2001. 1945 [6] Peterson, J., "A Presence-based GEOPRIV Location Object 1946 Format", RFC 4119, December 2005. 1948 [7] Freed, N. and J. Klensin, "Media Type Specifications and 1949 Registration Procedures", BCP 13, RFC 4288, December 2005. 1951 [8] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 1952 Registration Procedures for New URI Schemes", BCP 115, 1953 RFC 4395, February 2006. 1955 [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", 1956 draft-ietf-ecrit-service-urn-05 (work in progress), 1957 August 2006. 1959 [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 1960 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in 1961 progress), February 2007. 1963 [11] Daigle, L., "Domain-based Application Service Location Using 1964 URIs and the Dynamic Delegation Discovery Service (DDDS)", 1965 draft-daigle-unaptr-02 (work in progress), February 2007. 1967 [12] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, 1968 "Geographic information - Geography Markup Language (GML)", OGC 1969 Standard OpenGIS 03-105r1, April 2004. 1971 [13] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application 1972 Schema for use by the Internet Engineering Task Force (IETF)", 1973 Candidate OpenGIS Implementation Specification , December 2006. 1975 20.2. Informative References 1977 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1978 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1979 Session Initiation Protocol", RFC 3261, June 2002. 1981 [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1982 Protocol (XMPP): Instant Messaging and Presence", RFC 3921, 1983 October 2004. 1985 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 1986 December 2004. 1988 [17] Taylor, T., "Security Threats and Requirements for Emergency 1989 Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 1990 (work in progress), July 2006. 1992 [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 1993 Context Resolution with Internet Technologies", 1994 draft-ietf-ecrit-requirements-12 (work in progress), 1995 August 2006. 1997 [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1998 Framework", draft-ietf-ecrit-mapping-arch-01 (work in 1999 progress), December 2006. 2001 [20] Rosen, B. and J. Polk, "Best Current Practice for 2002 Communications Services in support of Emergency Calling", 2003 draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006. 2005 Appendix A. Non-Normative RELAX NG Schema in XML Syntax 2007 2008 2012 2013 2014 Location-to-Service Translation Protocol (LoST) 2015 A LoST XML instance has three request types, each with 2016 a cooresponding response type: find service, list services, 2017 and get service boundary. 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032
2033 2034 The queries. 2035 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 false 2049 2050 2051 2052 2053 2054 reference 2055 value 2056 2057 reference 2058 2059 2060 2061 2062 2063 false 2064 2065 2066 2067 2069 2070 2071 2072 2073 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 true 2087 2088 2089 2090 2092 2093 2094 2095 2096 2097 2099
2100
2101 2102 The responses. 2103 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2117 2118 2119 2120 2121 2122 2124 2125 2126 2127 2128 2129 2131 2132 2133 2134 2135 2136 2138
2140
2141 2142 A pattern common to some of the queries. 2143 2144 2145 2146 2147 2148 2149 2150 2151
2153
2154 2155 A pattern common to responses. 2156 2158 2159 2160 2161 2162 2163 2164 2165
2167
2168 2169 Location Information 2170 2172 2173 2174 2175 2176 2177 2178 2179 2180
2182
2183 2184 Service Boundary 2185 2187 2188 2189 2190 2191 2193 2194 2195
2197
2198 2199 Service Boundary Reference 2200 2202 2204 2205 2206 2207 2208 2209 2211 2212 2213 2214 2215 2217
2219
2220 2221 Path - 2222 Contains a list of via elements - 2223 places through which information flowed 2224 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236
2238
2239 2240 Expires pattern 2242 2244 2245 2246 2247 2248 NO-CACHE 2249 NO-EXPIRATION 2250 2251 2252 2253
2255
2256 2257 A QName list 2258 2260 2261 2262 2263 2264 2265 2266 2267
2269
2270 2271 A location-to-service mapping. 2272 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 [0-9*#]+ 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2317
2319
2320 2321 Location validation 2322 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2340 2341 2342 2343 2344 2345
2347
2348 2349 Errors and Warnings Container. 2350 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2394 2395 2396 2397 2398 2400
2402
2403 2404 Basic Errors 2405 2407 2408 2409 Error pattern. 2410 2411 2412 2413 2415 2416 2417 2418 2419 2421 2422 2423 2424 2425 2427 2428 2429 2430 2431 2433 2434 2435 2437 2438 2440 2441 2442 2443 2444 2446 2447 2448 2449 2450 2452 2453 2454 2455 2456 2458 2459 2460 2461 2462 2464 2465 2466 2467 2468 2470 2471 2472 2473 2474 2475 2476 2477 2479
2481
2482 2483 Redirect. 2484 2485 2486 2487 Redirect pattern 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2499
2501
2502 2503 Some common patterns. 2504 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2519 2520 2521 2522 2523 2524 2525 2527 2528 2529 ([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+ 2530 2531 2532 2533 2534 2535 2536 2538 2539 2540 2541 2542 2543 2544 2545 2546 2548
2550
2551 2552 Patterns for inclusion of elements from schemas in 2553 other namespaces. 2554 2556 2557 2558 Any element not in the LoST namespace. 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2571 2572 2573 A wildcard pattern for including any element 2574 from any other namespace. 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2590 2591 2592 A point where future extensions 2593 (elements from other namespaces) 2594 can be added. 2595 2596 2597 2598 2599 2601
2603 2605 Figure 24 2607 Authors' Addresses 2609 Ted Hardie 2610 Qualcomm, Inc. 2612 Email: hardie@qualcomm.com 2614 Andrew Newton 2615 SunRocket 2616 8045 Leesburg Pike, Suite 300 2617 Vienna, VA 22182 2618 US 2620 Phone: +1 703 636 0852 2621 Email: andy@hxr.us 2623 Henning Schulzrinne 2624 Columbia University 2625 Department of Computer Science 2626 450 Computer Science Building 2627 New York, NY 10027 2628 US 2630 Phone: +1 212 939 7004 2631 Email: hgs+ecrit@cs.columbia.edu 2632 URI: http://www.cs.columbia.edu 2634 Hannes Tschofenig 2635 Siemens Networks GmbH & Co KG 2636 Otto-Hahn-Ring 6 2637 Munich, Bavaria 81739 2638 Germany 2640 Phone: +49 89 636 40390 2641 Email: Hannes.Tschofenig@siemens.com 2642 URI: http://www.tschofenig.com 2644 Full Copyright Statement 2646 Copyright (C) The IETF Trust (2007). 2648 This document is subject to the rights, licenses and restrictions 2649 contained in BCP 78, and except as set forth therein, the authors 2650 retain all their rights. 2652 This document and the information contained herein are provided on an 2653 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2654 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2655 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2656 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2657 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2658 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2660 Intellectual Property 2662 The IETF takes no position regarding the validity or scope of any 2663 Intellectual Property Rights or other rights that might be claimed to 2664 pertain to the implementation or use of the technology described in 2665 this document or the extent to which any license under such rights 2666 might or might not be available; nor does it represent that it has 2667 made any independent effort to identify any such rights. Information 2668 on the procedures with respect to rights in RFC documents can be 2669 found in BCP 78 and BCP 79. 2671 Copies of IPR disclosures made to the IETF Secretariat and any 2672 assurances of licenses to be made available, or the result of an 2673 attempt made to obtain a general license or permission for the use of 2674 such proprietary rights by implementers or users of this 2675 specification can be obtained from the IETF on-line IPR repository at 2676 http://www.ietf.org/ipr. 2678 The IETF invites any interested party to bring to its attention any 2679 copyrights, patents or patent applications, or other proprietary 2680 rights that may cover technology that may be required to implement 2681 this standard. Please address the information to the IETF at 2682 ietf-ipr@ietf.org. 2684 Acknowledgment 2686 Funding for the RFC Editor function is provided by the IETF 2687 Administrative Support Activity (IASA).