idnits 2.17.1 draft-ietf-ecrit-lost-04.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 2629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2653. 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 (February 11, 2007) is 6283 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: '6' is defined on line 1857, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1867, 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) ** Obsolete normative reference: RFC 2818 (ref. '4') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3023 (ref. '5') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (ref. '8') (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4395 (ref. '9') (Obsoleted by RFC 7595) == 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 (~~), 10 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: August 15, 2007 SunRocket 6 H. Schulzrinne 7 Columbia U. 8 H. Tschofenig 9 Siemens Networks GmbH & Co KG 10 February 11, 2007 12 LoST: A Location-to-Service Translation Protocol 13 draft-ietf-ecrit-lost-04.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 August 15, 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 . . . . . . . . . . . . . . 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 Element . . . . . . . . . . . . . . . . 11 69 5.9. Service URLs: the Element . . . . . . . . . . . . . 12 70 6. Path of Request: Element . . . . . . . . . . . . . . . 13 71 7. Mapping a Location and Service to URLs: . . . . 14 72 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 14 75 7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 15 76 7.3. Components of the Request . . . . . . . . . 17 77 7.3.1. The Element . . . . . . . . . . . . . . . . 17 78 7.3.2. Identifying the Service: The Element . . . 18 79 7.3.3. Recursion . . . . . . . . . . . . . . . . . . . . . . 18 80 7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 18 81 7.3.5. Requesting Civic Location Validation . . . . . . . . . 18 82 7.4. Components of the Mapping Response 83 . . . . . . . . . . . . . . . . . . 20 84 7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 20 85 7.4.2. Civic Address Validation: the 86 Element . . . . . . . . . . . . . 21 87 8. Retrieving the Service Boundary via . . . 22 88 9. List Services: . . . . . . . . . . . . . . . . 25 89 10. List Services By Location: . . . . . 26 90 11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 28 91 11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 29 92 11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 32 93 11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 33 94 12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 34 95 12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 34 96 12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 35 97 12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 36 98 13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 37 99 14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 38 100 15. Internationalization Considerations . . . . . . . . . . . . . 45 101 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 102 16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 46 103 16.2. Content-type registration for 'application/lost+xml' . . . 46 104 16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 48 105 16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 48 106 16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 49 107 17. Security Considerations . . . . . . . . . . . . . . . . . . . 50 108 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 109 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 53 110 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 111 20.1. Normative References . . . . . . . . . . . . . . . . . . . 54 112 20.2. Informative References . . . . . . . . . . . . . . . . . . 55 113 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 56 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 115 Intellectual Property and Copyright Statements . . . . . . . . . . 71 117 1. Introduction 119 This document describes a protocol for mapping a service identifier 120 [10] and location information compatible with PIDF-LO [7], namely 121 revised civic location information [11] and GML [13]) to one or more 122 service URL. Example service URL schemes include sip [14], xmpp 123 [15], and tel [16]. While the initial focus is on providing mapping 124 functions for emergency services, it is likely that the protocol is 125 applicable to any service URN. For example, in the United States, 126 the "2-1-1" and "3-1-1" service numbers follow a similar location-to- 127 service behavior as emergency services. 129 This document names this protocol "LoST", for Location-to-Service 130 Translation. LoST Satisfies the requirements [18] for mapping 131 protocols. LoST provides a number of operations, centered around 132 mapping locations and service URNs to service URLs and associated 133 information. LoST mapping queries can contain either civic or 134 geodetic location information. For civic addresses, LoST can 135 indicate which parts of the civic address are known to be valid or 136 invalid, thus providing address validation (see Section 3.5 of [18] 137 for a description of validation). LoST indicates errors in the 138 location data to facilitate debugging and proper user feedback, but 139 also provides best-effort answers. 141 LoST queries can be resolved recursively or iteratively. To minimize 142 round trips and to provide robustness against network failures, LoST 143 caches individual mappings and indicates the region for which the 144 same answer would be returned ("service region"). 146 As defined in this document, LoST messages are carried in HTTP and 147 HTTPS protocol exchanges, facilitating use of TLS for protecting the 148 integrity and confidentiality of requests and responses. Later 149 documents may describe how LoST messages could be carried over other 150 transports. 152 This document focuses on the description of the protocol between the 153 mapping client and the mapping server. The relationship between 154 other functions, such as discovery of mapping servers, data 155 replication and the overall mapping server architecture are described 156 in a separate document [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 server name. In addition 167 to the mapping function described in Section 7, the protocol also 168 allows to retrieve the service boundary (see Section 8) and to list 169 the services available for a particular location (see Section 10) or 170 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 servers and Their Resolution 206 A LoST server may be discovered using a U-NAPTR/DDDS [12] application 207 unique string (AUS), in the form of a DNS name. 209 An example is 'lostserver.example.com' 211 Clients need to use the U-NAPTR [12] specification described below to 212 obtain a URI (indicating host and protocol) for the applicable LoST 213 service. In this document, only the HTTP and HTTPS URL schemes are 214 defined. Note that the HTTP URL can be any valid HTTP URL, including 215 those containing path elements. 217 The following two DNS entries show the U-NAPTR resolution for the AUS 218 "example.com" to the HTTPS URL https://lostserv.example.com/secure or 219 the HTTP URL http://lostserver.example.com, with the former being 220 preferred. 222 example.com. 224 IN NAPTR 100 10 "u" "LoST:https" 225 "!*.!https://lostserver.example.com/secure!" "" 227 IN NAPTR 200 10 "u" "LoST:http" 228 "!*.!http://lostserver.example.com!" "" 230 Clients learn the LoST server's AUS by means beyond the scope of this 231 specification, such as SIP configuration and DHCP. 233 5. The Element 235 The element is the core data element in LoST, describing a 236 service region and the associated service URLs. Its attributes and 237 elements are described in subsections below. 239 5.1. Data source and version: The 'source', 'sourceId' and 'version' 240 Attributes 242 The 'source', 'sourceId' and 'version' attributes uniquely identify a 243 particular mapping record. They are created by the authoritative 244 source for a mapping and never modified when a mapping is served from 245 a cache. All three attributes are REQUIRED for all 246 elements. A receiver can replace a mapping with another one having 247 the same 'source' and 'sourceId' and a higher version number. 249 The 'source' attribute contains a LoST application unique string 250 identifying the authoritative generator of the mapping. See 251 Section 4. 253 The 'sourceId' attribute identifies a particular mapping and contains 254 an opaque token that MUST be unique among all different mappings 255 maintained by the authoritative source for that particular service. 256 For example, a Universally Unique Identifier (UUID) is a suitable 257 format. 259 The 'version' attribute is a positive integer that is incremented for 260 each change in the mapping. The XML data type does not specify an 261 upper bound for this attribute and thus, the value MUST NOT wrap 262 around. Thus, a higher version number refers to a more recent 263 mapping. A mapping maintains its sourceId value as long as it 264 remains logically the same, e.g., represents the same service 265 boundary or replaces an earlier service boundary. 267 5.2. Time of Last Update: The 'lastUpdated' Attribute 269 The 'lastUpdated' attribute describes when the mapping was last 270 changed. The contents of this attribute has the XML data type 271 dateTime in its timezoned form, using canonical UTC representation 272 with the letter 'Z' as the timezone indicator. The attribute is 273 REQUIRED. 275 5.3. Validity: The 'expires' Attribute 277 The 'expires' attribute contains the absolute time at which the 278 mapping becomes invalid. The contents of this attribute is a 279 timezoned XML type dateTime, in canonical representation. See 280 Section 3 regarding how this value is to be utilized with a cache. 282 The 'expires' attribute is REQUIRED to be included in the 283 element. 285 On occasion, a server may be forced to return an expired mapping if 286 it cannot reach the authoritative server or the server fails to 287 return a usable answer. Clients and servers MAY cache the mapping so 288 that they have at least some information available. Caching servers 289 that have such stale information SHOULD re-attempt the query each 290 time a client requests a mapping. 292 5.4. Describing the Service with the Element 294 Zero or more elements describe the service with a 295 string that is suitable for display to human users, each annotated 296 with the 'xml:lang' attribute that contains a language tag to aid in 297 the rendering of text. 299 5.5. The Mapped Service: the Element 301 The element identifies the service for which this mapping 302 applies. Two cases need to be distinguished when the LoST server 303 sets the element in the response message: 305 1. If the requested service, identified by the service URN [10] in 306 the element of the request, exists for the location 307 indicated, then the LoST server puts the service URN from the 308 request into the element. 310 2. If, however, the requested service, identified by the service URN 311 [10] in the element in the request, does not exist for 312 the location indicated, the server can either return an 313 (Section 12.1) error or can provide an 314 alternate service that approximates the desired service for that 315 location. In the latter case, the server MUST include a 316 element with the alternative service URN. The choice 317 of service URN is left to local policy, but the alternate service 318 should be able to satisfy the original service request. 320 The element is optional but may also be required if the 321 mapping is to be digitally signed. 323 5.6. Defining the Service Region with the Element 325 A response MAY indicate the region for which the service URL returned 326 would be the same as in the actual query, the so-called _service 327 region_. The service region can be indicated by value or by 328 reference (see Section 5.7). If a client moves outside the service 329 area and wishes to obtain current service data, it sends a new query 330 with its current location. The service region is described by value 331 in one or more elements, each formatted according 332 to a different location profile, identified by the 'profile' atribute 333 (see Section 11). The response MUST contain at least one service 334 boundary using the same profile as the request. The client only 335 processes the first element that it can understand according to its 336 list of supported location profiles. Thus, elements with geospatial 337 coordinates are alternative descriptions of the same service region, 338 not additive geometries. 340 A response MAY contain more than one element with 341 profile 'civic'. Each element describes a set of 342 civic addresses that fall within the service boundary, namely all 343 addresses that textually match the civic address elements provided, 344 regardless of the value of other address elements. A location falls 345 within the mapping's service boundary if it matches any of the 346 elements. 348 5.7. Service Boundaries by Reference: the 349 Element 351 Since geodetic service boundaries may contain thousands of points and 352 thus be quite large, clients may opt to conserve bandwidth and 353 request a reference to the service boundary instead of the value 354 described in Section 5.6. The identifier of the service boundary is 355 returned as an attribute of the element, 356 along with a LoST application unique string (see Section 4) 357 identifying the server from where it can be retrieved. The actual 358 value of the service boundary is then retrieved with the 359 getServiceBoundary (Section 8) request. 361 The identifier is a random token with at least 128 bits of entropy 362 and can be assumed to be globally unique. It uniquely references a 363 particular boundary. If the boundary changes, a new identifier MUST 364 be chosen. Because of these properties, a client receiving a mapping 365 response can simply check if it already has a copy of the boundary 366 with that identifier. If so, it can skip checking with the server 367 whether the boundary has been updated. Since service boundaries are 368 likely to remain unchanged for extended periods of time, possibly 369 exceeding the normal lifetime of the service URL, this approach 370 avoids unnecessarily refreshing the boundary information just because 371 the the remainder of the mapping has become invalid. 373 5.8. The Service Number Element 375 The service number is returned in the optional 376 element. It contains a string of digits, * and # that a user on a 377 device with a 12-key dial pad could use to reach that particular 378 service. 380 5.9. Service URLs: the Element 382 The response returns the service URLs in one or more elements. 383 The URLs MUST be absolute URLs. The ordering of the URLs has no 384 particular significance. Each URL scheme MUST only appear at most 385 once, but it is permissible to include both secured and regular 386 versions of a protocol, such as both 'http' and 'https' or 'sip' and 387 'sips'. 389 6. Path of Request: Element 391 To prevent loops and to allow tracing of request and response paths, 392 all requests that allow recursion include a element that 393 contains one or more elements, each possessing an attribute 394 containing a LoST application unique string (see Section 4). The 395 order of elements corresponds to the order of LoST servers, 396 i.e., the first element identifies the server that first 397 received the request from the client. The authoritative server 398 copies the element verbatim into the response. 400 If a query is answered iteratively, the querier includes all servers 401 that it has already contacted. 403 The example in Figure 5 indicates that the answer was given to the 404 responding server by the LoST server at esgw.ueber-110.de.example, 405 which got the answer from the LoST server at 406 polizei.muenchen.de.example. 408 7. Mapping a Location and Service to URLs: 410 7.1. Overview 412 The query constitutes the core of the LoST 413 functionality, mapping civic or geodetic locations to URLs and 414 associated data. After giving an example, we enumerate the elements 415 of the query and response. 417 7.2. Examples 419 7.2.1. Example Using Geodetic Coordinates 421 The following is an example of mapping a service to a location using 422 geodetic coordinates, for the service associated with the police 423 (urn:service:sos.police). 425 426 432 433 434 37.775 -122.422 435 436 437 urn:service:sos.police 439 441 Figure 2: A geodetic query 443 Given the query above, a server would respond with a service, and 444 information related to that service. In the example below, the 445 server has mapped the location given by the client for a police 446 service to the New York City Police Deparment, instructing the client 447 that it may contact them via the URIs "sip:sfpd@example.com" and 448 "xmpp:sfpd@example.com". The server has also given the client a 449 geodetic, two-dimensional boundary for this service. The mapping was 450 last updated on November 1, 2006 and expires on January 1, 2007. If 451 the client's location changes beyond the given service boundary or 452 the expiration time has been reached, it may want to requery for this 453 information, depending on the usage environment of LoST. 455 456 458 463 464 San Francisco Police Department 465 466 urn:service:sos.police 467 468 469 470 471 37.775 -122.4194 472 37.555 -122.4194 473 37.555 -122.4264 474 37.775 -122.4264 475 37.775 -122.4194 476 477 478 479 480 sip:sfpd@example.com 481 xmpp:sfpd@example.com 482 911 483 484 485 486 487 488 490 Figure 3: A geodetic answer 492 7.2.2. Civic Address Mapping Example 494 The following is an example of mapping a service to a location much 495 like the example in Section 7.2.1, but using civic address location 496 information. In this example, the client requests the service 497 associated with police (urn:service:sos.police) along with a specific 498 civic address (house number 6 on a street named Otto-Hahn-Ring in 499 Munich, Germany). 501 502 504 506 508 Germany 509 Bavaria 510 Munich 511 Otto-Hahn-Ring 512 6 513 81675 514 515 516 urn:service:sos.police 517 519 Figure 4: A civic address query 521 Given the query above, a server would respond with a service, and 522 information related to that service. In the example below, the 523 server has mapped the location given by the client for a police 524 service to the Muenchen Polizei-Abteilung, instructing the client 525 that it may contact them via the URIs sip:munich-police@example.com 526 and xmpp:munich-police@example.com. The server has also given the 527 client a civic address boundary (the city of Munich) for this 528 service. The mapping was last updated on November 1, 2006 by the 529 authoritative source "polizei.muenchen.de.example" and expires on 530 January 1, 2007. This instructs the client to requery for the 531 information if its location changes beyond the given service boundary 532 (i.e., beyond the city of Munich) or after January 1, 2007. 534 535 536 541 542 Muenchen Polizei-Abteilung 543 544 urn:service:sos.police 545 547 549 Germany 550 Bavaria 551 Munich 552 81675 553 554 555 sip:munich-police@example.com 556 xmpp:munich-police@example.com 557 110 558 559 560 561 562 563 565 Figure 5: A civic address answer 567 7.3. Components of the Request 569 The request includes attributes that govern whether the 570 request is handled iteratively or recursively, whether location 571 validation is performed and which elements must be contained in the 572 response. 574 7.3.1. The Element 576 The query communicates location information using one 577 or more elements, which MUST conform to a location profile 578 (see Section 11). There MUST NOT be more than one location element 579 for each distinct location profile. The order of location objects is 580 significant; the server uses the first location object where it 581 understands the location profile. 583 7.3.2. Identifying the Service: The Element 585 The type of service desired is specified by the element. 586 It contains service URNs from the registry established in [10]. 588 7.3.3. Recursion 590 LoST and queries can be 591 recursive, as indicated by the 'recursive' attribute. A value of 592 "true" indicates a recursive query, with the default being "false" 593 when the attribute is omitted. Regardless of the attribute, a server 594 MAY always answer a query by providing a LoST application unique 595 string (see Section 4), i.e., indirection, however, it MUST NOT 596 recurse if the attribute is "false". 598 In recursive mode, the LoST server initiates queries on behalf of the 599 requester and returns the result to the requester, inserting a 600 element to track the response chain. The elements are appended 601 in responses in order of visit, i.e., the first element 602 contains the authoritative server and elements below indicate 603 servers that the response traversed on its way back to the original 604 querier. 606 7.3.4. Service Boundary 608 LoST elements can describe the service boundary either by 609 value or by reference. Returning a service boundary reference is 610 generally more space-efficient for geospatial (polygon) boundaries 611 and if the boundaries change rarely, but does incur an additional 612 request. The querier can express a preference 613 for one or the other modality with the 'serviceBoundary' attribute in 614 the request, but the server makes the final decision as 615 to whether to return a reference or a value. Servers SHOULD NOT 616 return a by-value service boundaries if the querier requested a 617 reference. 619 7.3.5. Requesting Civic Location Validation 621 Civic address validation is requested by setting the optional 622 attribute 'validateLocation' to true. If the attribute is omitted, 623 it is assumed to be false. The response is described in 624 Section 7.4.2. The example in Figure 6 demonstrates address 625 validation, omitting the standard response elements. 627 628 633 634 636 DE 637 Bavaria 638 Munich 639 Otto-Hahn-Ring 640 6 641 81675 642 643 644 urn:service:sos.police 645 647 Figure 6: A query with address validation request 649 650 651 657 658 Muenchen Polizei-Abteilung 659 660 urn:service:sos.police 661 662 664 Germany 665 Bavaria 666 Munich 667 81675 668 669 670 sip:munich-police@example.com 671 xmpp:munich-police@example.com 672 110 673 674 675 country A1 A3 A6 676 PC 677 678 679 680 681 682 684 Figure 7: A message with address validation 685 information 687 7.4. Components of the Mapping Response 689 7.4.1. Overview 691 Mapping responses consist of the element (Section 5) 692 describing the mapping itself, possibly followed by warnings 693 (Section 12.2), location validation information (Section 7.4.2), and 694 an indication of the path (Section 6) the response has taken. 696 7.4.2. Civic Address Validation: the Element 698 A server can indicate in its response which civic address elements it 699 has recognized as valid, which ones it has ignored and which ones it 700 has checked and found to be invalid. The server MUST include this 701 information if the 'validateLocation' attribute in the request was 702 true. Each element contains a list of tokens separated by white 703 space, enumerating the civic location lables used in child elements 704 of the element. The element enumerates those 705 civic address elements that have been recognized as valid by the LoST 706 server and that have been used to determine the mapping. The 707 elements enumerates the civic address elements that the 708 server did not check and that were not used in determining the 709 response. The element enumerate civic address elements 710 that the server attempted to check, but that did not match the other 711 civic address elements found in the list. 713 Note that the same address can yield different responses if parts of 714 the civic address contradict each other. For example, if the postal 715 code does not match the city, local server policy determines whether 716 the postal code or the city is considered valid. The mapping 717 naturally corresponds to the valid elements. 719 The example (Figure 6) indicates that the tokens 'country', 'A1', 720 'A3', and 'A6' have been validated by the LoST server. The server 721 considered the postal code 81675 in the element as not valid for 722 this location. 724 8. Retrieving the Service Boundary via 726 As discussed in Section 5.6, the can return a 727 globally unique identifier in the 'serviceBoundary' attribute that 728 can be used to retrieve the service boundary, rather than returning 729 the boundary by value. This is shown in the example in Figure 8. 730 The client can then retrieve the boundary using the 731 request and obtains the boundary in the 732 , illustrated in the example in 733 Figure 10. The client issues the request to the server identified in 734 the 'server' attribute of the element. 735 These requests are always directed to the authoritative server and do 736 not recurse. 738 739 744 745 746 37.775 -122.422 747 748 749 urn:service:sos.police 750 752 Figure 8: request and response with service boundary 753 reference 755 756 758 764 765 San Francisco Police Department 766 767 urn:service:sos.police 768 771 sip:sfpd@example.com 772 xmpp:sfpd@example.com 773 911 774 775 776 777 778 779 781 Figure 9: message with service boundary 782 reference 784 785 788 Figure 10: Requesting a service boundary with 790 The request may also be used to retrieve service 791 boundaries that are expressed as civic addresses, as illustrated in 792 Figure 11. 794 795 797 799 801 US 802 New York 803 New York 804 805 806 807 808 809 810 812 Figure 11: Civic Address Service Boundary Response 814 9. List Services: 816 A LoST client can ask a LoST server for the list of services that it 817 understands, primarily for diagnostic purposes. The query does not 818 contain location information, as it simply provides an indication of 819 which services the server can look up, not whether a particular 820 service is offered for a particular area. Typically, only top-level 821 services are included in the answer, implying support for all sub- 822 services. Since the query is answered by the queried server, there 823 is no notion of recursion or indirection and no path indication. The 824 829 831 urn:service:sos 832 834 Figure 12: Example of query 836 837 839 840 urn:service:sos.ambulance 841 urn:service:sos.animal-control 842 urn:service:sos.fire 843 urn:service:sos.gas 844 urn:service:sos.mountain 845 urn:service:sos.marine 846 urn:service:sos.physician 847 urn:service:sos.poison 848 urn:service:sos.police 849 urn:service:sos.suicide 850 851 853 Figure 13: Example of 855 10. List Services By Location: 857 A LoST client can ask a LoST server for the list of services it knows 858 about for a particular area. The query 859 contains one or more elements, each from a different 860 location profile (Section 11), and may contain the element. 861 As for , the server selects the first location element 862 that has a profile the server understands and it can operate either 863 recursively or iteratively; < via> elements track the progress of the 864 request. By its nature, the query can only indicate the services 865 that a particular server can determine, not all possible services 866 that might be offered. Unlike , the answer describes 867 the services available at a specific location, not just those 868 understood by the server. 870 If the query contains the element, the LoST server returns 871 only immediate child services of the queried service that are 872 available for the provided location. If the element is 873 absent, the LoST service returns all top-level services available for 874 the provided location that it knows about. 876 A server responds to this query with a 877 response. This response MAY contain 878 elements (see Section 6) and MUST contain a 879 element, consisting of a whitespace-separated list of service URNs. 880 The query and response are illustrated in Figure 14 and in Figure 15, 881 respectively. 883 884 888 889 890 37:46:30N 122:25:10W 891 892 893 urn:service:sos 894 896 Figure 14: Example of query 898 899 901 902 urn:service:sos.ambulance 903 urn:service:sos.animal-control 904 urn:service:sos.fire 905 urn:service:sos.gas 906 urn:service:sos.mountain 907 urn:service:sos.marine 908 urn:service:sos.physician 909 urn:service:sos.poison 910 urn:service:sos.police 911 urn:service:sos.suicide 912 913 914 915 916 917 919 Figure 15: Example of response 921 11. Location Profiles 923 LoST uses location information in elements in requests and 924 elements in responses. Such location information 925 may be expressed in a variety of ways. This variety can cause 926 interoperability problems where a request or response contains 927 location information in a format not understood by the server or the 928 client, respectively. To achieve interoperability, this document 929 defines two mandatory-to-implement baseline location profiles to 930 define the manner in which location information is transmitted. It 931 possible to standardize other profiles in the future. The two 932 baseline profiles are: 934 geodetic-2d: 936 a simple profile for two-dimensional geodetic location 937 information, as described in Section 11.2; 939 civic: 941 a profile consisting of civic address location information, as 942 described in Section 11.3. 944 Requests and responses containing or 945 elements MUST contain location information in exactly one of the two 946 baseline profiles, in addition to zero or more additional profiles. 947 The ordering of location information indicates a preference on the 948 part of the sender. 950 Standards action is required for defining new profiles. A location 951 profile MUST define: 953 1. The token identifying it in the LoST location profile registry; 955 2. The formal definition of the XML to be used in requests, i.e., an 956 enumeration and definition of the XML child elements of the 957 element; 959 3. The formal definition of the XML to be used in responses, i.e., 960 an enumeration and definition of the XML child elements of the 961 element; 963 4. The declaration of whether geodetic-2d or civic is to be used as 964 the baseline profile. It is necessary to explicitly declare the 965 baseline profile as future profiles may be combinations of 966 geodetic and civic location information. 968 11.1. Location Profile Usage 970 A location profile is identified by a token in an IANA-maintained 971 registry (Section 16.5). Clients send location information compliant 972 with a location profile, and servers respond with location 973 information compliant with that same location profile. 975 When a LoST client sends a request that provides 976 location information, it includes one or more elements. A 977 element carries a mandatory 'profile' attribute that 978 indicates the location format of the child elements. The concept of 979 location profiles are described in Section 11. With the ability to 980 specify more than one element the client is able to convey 981 location information for multiple location profiles in the same 982 request. 984 When a LoST server sends a response that contains location 985 information, it uses the elements much like the 986 client uses the elements. Each element 987 contains location information conformant to the location profile 988 specified in the 'profile' attribute. When multiple 989 elements are included then it enables the server to send location 990 information compliant with multiple location profiles. 992 Using the location profiles defined in this document, the following 993 rules insure basic interoperatiblity between clients and servers: 995 1. A client MUST be capable of understanding the response for the 996 baseline profiles it used in the request. 998 2. If a client sends location information conformant to any location 999 profile other than geodetic-2d or civic, it MUST also send, in 1000 the same request, location information conformant to one of the 1001 baseline profiles. Otherwise, the server might not be able to 1002 understand the request. 1004 3. There can only be one instance of each location profile in a 1005 query. 1007 4. Servers MUST implement the geodetic-2d and civic profiles. 1009 5. A server uses the first-listed location profile that it 1010 understands and ignores the others. 1012 6. If a server receives a request that only contains location 1013 information using profiles it does not understand, the server 1014 responds with a (Section 12.1). 1016 7. The element MUST use the same location profile 1017 that was used to retrieve the answer and indicates which profile 1018 has been used with the 'profile' attribute. 1020 These rules enable the use of location profiles not yet specified, 1021 while ensuring baseline interoperability. Take, for example, this 1022 scenario. Client X has had its firmware upgraded to support the 1023 uber-complex-3D location profile. Client X sends location 1024 information to Server Y, which does not understand the 1025 uber-complex-3D location profile. If Client X also sends location 1026 information using the geodetic-2D baseline profile, then Server Y 1027 will still be able to understand the request and provide an 1028 understandable response, though with location information that might 1029 not be as precise or expressive as desired. This is possible because 1030 both Client X and Server Y understand the baseline profile. 1032 1033 1038 1039 1040 37.775 -122.422 1041 1042 1043 1044 1045 37.775 -122.4194 1046 37.555 -122.4194 1047 37.555 -122.4264 1048 37.775 -122.4264 1049 37.775 -122.4194 1050 1051 1052 1053 1054 -122.422 37.775 1055 1056 1057 1058 1059 37.775 -122.422 1060 1061 1062 urn:service:sos.police 1063 1065 Figure 16: Example of a query with baseline profile 1066 interoperability 1068 1069 1072 1078 1079 San Francisco Police Department 1080 1081 urn:service:sos.police 1082 1083 1084 1085 1086 37.775 -122.4194 1087 37.555 -122.4194 1088 37.555 -122.4264 1089 37.775 -122.4264 1090 37.775 -122.4194 1091 1092 1093 1094 1095 sip:nypd@example.com 1096 1097 1098 1099 1100 1101 1103 Figure 17: Example of a message with baseline 1104 profile interoperability 1106 11.2. Two Dimensional Geodetic Profile 1108 The geodetic-2d location profile is identified by geodetic-2d. 1109 Clients use this profile by placing a GML [13] element 1110 within the element. This is defined by the 'point2D' 1111 pattern in the LoST schema (see Section 14). 1113 Servers use this profile by placing a GML [13] element 1114 within the element. This is defined by the 1115 'polygon' pattern in the LoST schema (see Section 14). 1117 11.3. Basic Civic Profile 1119 The basic-civic location profile is identified by the token 'civic'. 1120 Clients use this profile by placing a element, defined 1121 in [11], within the element. 1123 Servers use this profile by placing a element, defined 1124 in [11], within the element. 1126 12. Errors, Warnings, and Redirects 1128 When a LoST server cannot fulfill a request completely, it can return 1129 either an error or a warning, depending on the severity of the 1130 problem. It returns an error element if no useful response can be 1131 returned for the query. It returns a element as part of 1132 another response element if it was able to respond in part, but the 1133 response may not be quite what the client had desired. For both 1134 elements, the 'source' attribute names the server that originally 1135 generated the error or warning, such as the authoritative server. 1136 Unless otherwise noted, all elements below can be either an error or 1137 a warning, depending on whether a default response, such as a 1138 mapping, is included. 1140 12.1. Errors 1142 LoST defines a pattern for errors, defined as elements in 1143 the Relax NG schema. This pattern defines a 'message' attribute 1144 containing human readable text and an 'xml:lang' attribute denoting 1145 the language of the human readable text. One or more such error 1146 elements are contained in the element. 1148 The following errors follow this basic pattern: 1150 badRequest 1152 The server could not parse or otherwise understand a request, 1153 e.g., because the XML was malformed. 1155 forbidden 1157 The server refused to send an answer. This generally only occurs 1158 for recursive queries, namely if the client tried to contact the 1159 authoritative server and was refused. (For HTTP as the underlying 1160 protocol, an HTTP 401 error would be returned.) 1162 internalError 1164 The server could not satisfy a request due to misconfiguration or 1165 other operational and non-protocol related reasons. 1167 locationProfileUnrecognized 1169 None of the profiles in the request were recognized by the server 1170 (see Section 11). 1172 loop 1174 During a recursive query, the server was about to visit a server 1175 that was already in the server list in the element, 1176 indicating a request loop. 1178 notFound 1180 The server could not find an answer to the query. 1182 serverError 1184 An answer was received from another LoST server, but it could not 1185 be parsed or otherwise understood. This error occurs only for 1186 recursive queries. 1188 serverTimeout 1190 A time out occurred before an answer was received. 1192 serviceNotImplemented 1194 The requested service URN is not implemented and no substitution 1195 was available. 1197 An example is below: 1199 1200 1202 1203 1205 Figure 18: Example of an error resonse 1207 12.2. Warnings 1209 A response MAY contain zero or more warnings. This pattern defines a 1210 'message' attribute containing human readable text and an 'xml:lang' 1211 attribute denoting the language of the human readable text. One or 1212 more such warning elements are contained in the element. 1214 This version of the specification does not define any warning 1215 elements. 1217 12.3. Redirects 1219 A LoST server can respond indicating that the querier should redirect 1220 the query to another server, using the element. The 1221 element includes a 'target' attribute indicating the LoST application 1222 unique string (see Section 4) that the client SHOULD be contacting 1223 next, as well as the 'source' attribute indicating the server that 1224 generated the redirect response and a 'message' attribute explaining 1225 the reason for the redirect response. During a recursive query, a 1226 server receiving a response can decide whether it wants to 1227 follow the redirection or simply return the response to its upstream 1228 querier. 1230 An example is below: 1232 1233 1238 Figure 19: Example of a redirect resonse 1240 13. LoST Transport 1242 LoST needs an underlying protocol transport mechanisms to carry 1243 requests and responses. This document defines the use of LoST over 1244 HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future 1245 documents. The available transport mechanisms are determined through 1246 the use of the LoST U-NAPTR application. In protocols that support 1247 content type indication, LoST uses the media type application/ 1248 lost+xml. 1250 When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP 1251 POST method. All HTTP responses are applicable. The HTTP URL is 1252 derived from the LoST server name via U-NAPTR application, as 1253 discussed above 1255 14. Relax NG Schema 1257 This section provides the Relax NG schema used by LoST protocol in 1258 the compact form. The verbose form is included in Appendix A. 1260 default namespace = "http://www.opengis.net/gml" 1261 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 1262 namespace ns1 = "urn:ietf:params:xml:ns:lost1" 1264 ## 1265 ## Location-to-Service Translation Protocol (LoST) 1266 ## 1267 ## A LoST XML instance has three request types, each with 1268 ## a cooresponding response type: find service, list services, 1269 ## and get service boundary. 1270 ## 1271 start = 1272 findService 1273 | listServices 1274 | listServicesByLocation 1275 | getServiceBoundary 1276 | findServiceResponse 1277 | listServicesResponse 1278 | listServicesByLocationResponse 1279 | getServiceBoundaryResponse 1280 | errors 1281 | redirect 1283 ## 1284 ## The queries. 1285 ## 1286 div { 1287 findService = 1288 element ns1:findService { 1289 element ns1:location { locationInformation }+, 1290 commonRequestPattern, 1291 attribute validateLocation { 1292 xsd:boolean >> a:defaultValue [ "false" ] 1293 }?, 1294 attribute serviceBoundary { 1295 ("reference" | "value") >> a:defaultValue [ "reference" ] 1296 }?, 1297 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 1298 } 1299 listServices = element ns1:listServices { commonRequestPattern } 1300 listServicesByLocation = 1301 element ns1:listServicesByLocation { 1302 element ns1:location { locationInformation }*, 1303 commonRequestPattern, 1304 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 1305 } 1306 getServiceBoundary = 1307 element ns1:getServiceBoundary { 1308 serviceBoundaryKey, extensionPoint 1309 } 1310 } 1312 ## 1313 ## The responses. 1314 ## 1315 div { 1316 findServiceResponse = 1317 element ns1:findServiceResponse { 1318 mapping+, locationValidation?, commonResponsePattern 1319 } 1320 listServicesResponse = 1321 element ns1:listServicesResponse { 1322 serviceList, commonResponsePattern 1323 } 1324 listServicesByLocationResponse = 1325 element ns1:listServicesByLocationResponse { 1326 serviceList, commonResponsePattern 1327 } 1328 getServiceBoundaryResponse = 1329 element ns1:getServiceBoundaryResponse { 1330 serviceBoundary, commonResponsePattern 1331 } 1332 } 1334 ## 1335 ## A pattern common to some of the queries. 1336 ## 1337 div { 1338 commonRequestPattern = service, extensionPoint 1339 } 1341 ## 1342 ## A pattern common to responses. 1343 ## 1344 div { 1345 commonResponsePattern = warnings*, path, extensionPoint 1346 } 1347 ## 1348 ## Location Information 1349 ## 1350 div { 1351 locationInformation = 1352 extensionPoint+, 1353 attribute profile { xsd:NMTOKEN } 1354 } 1356 ## 1357 ## Service Boundary 1358 ## 1359 div { 1360 serviceBoundary = element ns1:serviceBoundary { locationInformation }+ 1361 } 1363 ## 1364 ## Service Boundary Reference 1365 ## 1366 div { 1367 serviceBoundaryReference = 1368 element ns1:serviceBoundaryReference { 1369 source, serviceBoundaryKey, extensionPoint 1370 } 1371 serviceBoundaryKey = attribute key { xsd:token } 1372 } 1374 ## 1375 ## Path - 1376 ## Contains a list of via elements - 1377 ## places through which information flowed 1378 ## 1379 div { 1380 path = 1381 element ns1:path { 1382 element ns1:via { source, extensionPoint }* 1383 } 1384 } 1386 ## 1387 ## Expires pattern 1388 ## 1389 div { 1390 expires = attribute expires { xsd:dateTime } 1391 } 1393 ## 1394 ## A QName list 1395 ## 1396 div { 1397 qnameList = list { xsd:QName* } 1398 } 1400 ## 1401 ## A location-to-service mapping. 1402 ## 1403 div { 1404 mapping = 1405 element ns1:mapping { 1406 element ns1:displayName { 1407 xsd:string, 1408 attribute xml:lang { xsd:language } 1409 }*, 1410 service, 1411 (serviceBoundary | serviceBoundaryReference)?, 1412 element ns1:uri { xsd:anyURI }*, 1413 element ns1:serviceNumber { 1414 xsd:string { pattern = "[0-9*#]+" } 1415 }?, 1416 extensionPoint, 1417 expires, 1418 attribute lastUpdated { xsd:dateTime }, 1419 source, 1420 attribute sourceId { xsd:token }, 1421 attribute version { xsd:positiveInteger }, 1422 message 1423 } 1424 } 1426 ## 1427 ## Location validation 1428 ## 1429 div { 1430 locationValidation = 1431 element ns1:locationValidation { 1432 element ns1:valid { qnameList }?, 1433 element ns1:invalid { qnameList }?, 1434 element ns1:unchecked { qnameList }?, 1435 extensionPoint 1436 } 1437 } 1439 ## 1440 ## Errors and Warnings Container. 1441 ## 1442 div { 1443 errorContainer = 1444 (badRequest? 1445 & internalError? 1446 & serviceSubstitution? 1447 & forbidden? 1448 & notFound? 1449 & loop? 1450 & serviceNotImplemented? 1451 & serverTimeout? 1452 & serverError? 1453 & locationProfileUnrecognized?), 1454 extensionPoint, 1455 source 1456 errors = element ns1:errors { errorContainer } 1457 warnings = element ns1:warnings { errorContainer } 1458 } 1460 ## 1461 ## Basic Errors 1462 ## 1463 div { 1465 ## 1466 ## Error pattern. 1467 ## 1468 basicError = message, extensionPoint 1469 badRequest = element ns1:badRequest { basicError } 1470 internalError = element ns1:internalError { basicError } 1471 serviceSubstitution = element ns1:serviceSubstitution { basicError } 1472 forbidden = element ns1:forbidden { basicError } 1473 notFound = element ns1:notFound { basicError } 1474 loop = element ns1:loop { basicError } 1475 serviceNotImplemented = 1476 element ns1:serviceNotImplemented { basicError } 1477 serverTimeout = element ns1:serverTimeout { basicError } 1478 serverError = element ns1:serverError { basicError } 1479 locationProfileUnrecognized = 1480 element ns1:locationProfileUnrecognized { 1481 attribute unsupportedProfiles { xsd:NMTOKENS }, 1482 basicError 1483 } 1484 } 1486 ## 1487 ## Redirect. 1488 ## 1489 div { 1490 ## 1491 ## Redirect pattern 1492 ## 1493 redirect = 1494 element ns1:redirect { 1495 attribute target { appUniqueString }, 1496 source, 1497 message, 1498 extensionPoint 1499 } 1500 } 1502 ## 1503 ## Some common patterns. 1504 ## 1505 div { 1506 message = 1507 (attribute message { xsd:string }, 1508 attribute xml:lang { xsd:language })? 1509 service = element ns1:service { xsd:anyURI }? 1510 appUniqueString = 1511 xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } 1512 source = attribute source { appUniqueString } 1513 serviceList = 1514 element ns1:serviceList { 1515 list { xsd:anyURI* } 1516 } 1517 } 1519 ## 1520 ## Patterns for inclusion of elements from schemas in 1521 ## other namespaces. 1522 ## 1523 div { 1525 ## 1526 ## Any element not in the LoST namespace. 1527 ## 1528 notLost = element * - (ns1:* | ns1:*) { anyElement } 1530 ## 1531 ## A wildcard pattern for including any element 1532 ## from any other namespace. 1533 ## 1534 anyElement = 1535 (element * { anyElement } 1536 | attribute * { text } 1537 | text)* 1539 ## 1540 ## A point where future extensions 1541 ## (elements from other namespaces) 1542 ## can be added. 1543 ## 1544 extensionPoint = notLost* 1546 ## 1547 ## A 2D point from GML. 1548 ## 1549 point2d = 1550 element Point { 1551 attribute srsName { "urn:ogc:def:crs:EPSG::4326" }, 1552 pos 1553 } 1555 ## 1556 ## A GML position 1557 ## 1558 pos = 1559 element pos { 1560 list { xsd:double } 1561 } 1563 ## 1564 ## A Linear Ring from GML. 1565 ## 1566 linearRing = element LinearRing { pos, pos, pos, pos+ } 1568 ## 1569 ## A Polygon from GML. 1570 ## 1571 polygon = 1572 element Polygon { 1573 attribute srsName { "urn:ogc:def:crs:EPSG::4326" }, 1574 element exterior { linearRing }, 1575 element interior { linearRing }* 1576 } 1577 } 1579 Figure 20: RelaxNG schema 1581 15. Internationalization Considerations 1583 This mechanism is largely for passing protocol information from one 1584 subsystem to another; as such, most of its elements are tokens not 1585 meant for direct human consumption. If these tokens are presented to 1586 the end user, some localization may need to occur. The content of 1587 the element and the 'message' attributes may be 1588 displayed to the end user, and they are thus a complex types designed 1589 for this purpose. 1591 LoST exchanges information using XML. All XML processors are 1592 required to understand UTF-8 and UTF-16 encodings, and therefore all 1593 LoST clients and servers MUST understand UTF-8 and UTF-16 encoded 1594 XML. Additionally, LoST servers and clients MUST NOT encode XML with 1595 encodings other than UTF-8 or UTF-16. 1597 16. IANA Considerations 1599 16.1. U-NAPTR Registrations 1601 This document registers the following U-NAPTR application service 1602 tag: 1604 Application Service Tag: LoST 1606 Defining Publication: The specification contained within this 1607 document. 1609 This document registers the following U-NAPTR application protocol 1610 tags: 1612 o 1614 Application Protocol Tag: http 1616 Defining Publication: RFC 2616 [3] 1618 o 1620 Application Protocol Tag: https 1622 Defining Publication: RFC 2818 [4] 1624 16.2. Content-type registration for 'application/lost+xml' 1626 This specification requests the registration of a new MIME type 1627 according to the procedures of RFC 4288 [8] and guidelines in RFC 1628 3023 [5]. 1630 MIME media type name: application 1632 MIME subtype name: lost+xml 1634 Mandatory parameters: none 1636 Optional parameters: charset 1638 Indicates the character encoding of enclosed XML. 1640 Encoding considerations: 1642 Uses XML, which can employ 8-bit characters, depending on the 1643 character encoding used. See RFC 3023 [5], Section 3.2. 1645 Security considerations: 1647 This content type is designed to carry LoST protocol payloads. 1649 Interoperability considerations: None 1651 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 1652 replace XXXX with the RFC number of this specification.] this 1653 document 1655 Applications which use this media type: 1657 Emergency and Location-based Systems 1659 Additional information: 1661 Magic Number: None 1663 File Extension: .lostxml 1665 Macintosh file type code: 'TEXT' 1667 Personal and email address for further information: Hannes 1668 Tschofenig, Hannes.Tschofenig@siemens.com 1670 Intended usage: LIMITED USE 1672 Author: 1674 This specification is a work item of the IETF ECRIT working group, 1675 with mailing list address . 1677 Change controller: 1679 The IESG delegated to the IETF ECRIT working 1680 group, if it is still active. 1682 16.3. LoST Relax NG Schema Registration 1684 URI: urn:ietf:params:xml:ns:lost1 1686 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1687 (Hannes.Tschofenig@siemens.com). 1689 Relax NG Schema: The Relax NG schema to be registered is contained 1690 in Section 14. Its first line is 1692 default namespace = "urn:ietf:params:xml:ns:lost1" 1694 and its last line is 1696 } 1698 16.4. LoST Namespace Registration 1700 URI: urn:ietf:params:xml:ns:lost1 1702 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1703 (Hannes.Tschofenig@siemens.com). 1705 XML: 1707 BEGIN 1708 1709 1711 1712 1713 1715 LoST Namespace 1716 1717 1718

Namespace for LoST

1719

urn:ietf:params:xml:ns:lost1

1720

See RFCXXXX 1721 [NOTE TO IANA/RFC-EDITOR: 1722 Please replace XXXX with the RFC number of this 1723 specification.].

1724 1725 1726 END 1728 16.5. LoST Location Profile Registry 1730 This document seeks to create a registry of location profile names 1731 for the LoST protocol. Profile names are XML tokens. This registry 1732 will operate in accordance with RFC 2434 [2], Standards Action. 1734 geodetic-2d: 1736 Defined in Section 11.2 1738 civic: 1740 Defined in Section 11.3 1742 17. Security Considerations 1744 There are multiple threats to the overall system of which service 1745 mapping forms a part. An attacker that can obtain service contact 1746 URIs can use those URIs to attempt to disrupt those services. An 1747 attacker that can prevent the lookup of contact URIs can impair the 1748 reachability of such services. An attacker that can eavesdrop on the 1749 communication requesting this lookup can surmise the existence of an 1750 emergency and possibly its nature, and may be able to use this to 1751 launch a physical attack on the caller. 1753 To avoid that an attacker can modify the query or its result, the use 1754 of channel security, such as TLS, is RECOMMENDED. 1756 Generally, authentication and authorization is not required for 1757 mapping queries. If it is, authentication mechanism of the 1758 underlying transport mechanism, such as HTTP basic and digest 1759 authentication, MAY be used. (Basic authentication SHOULD only be 1760 used in combination with TLS.) 1762 A more detailed description of threats and security requirements are 1763 provided in [17]. 1765 18. Acknowledgments 1767 We would like to the thank the following working group members for 1768 the detailed review of previous LoST document versions: 1770 o Martin Thomson (Review July 2006) 1772 o Jonathan Rosenberg (Review July 2006) 1774 o Leslie Daigle (Review September 2006) 1776 o Shida Schubert (Review November 2006) 1778 o Martin Thomson (Review December 2006) 1780 o Barbara Stark (Review January 2007) 1782 o Patrik Faeltstroem (Review January 2007 1784 o Shida Schubert (Review January 2007 as a designated expert 1785 reviewer) 1787 We would also like to thank the following working group members for 1788 their input to selected design aspects of the LoST protocol: 1790 o Leslie Daigle and Martin Thomson (DNS-based LoST discovery 1791 procedure) 1793 o John Schnizlein (authoritive LoST answers) 1795 o Rohan Mahy (display names) 1797 o James Polk (error handling) 1799 o Ron Watro and Richard Barnes (expiry of cached data) 1801 o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James 1802 Winterbottom (Indication of PSAP Confidence Level) 1804 o Martin Thomson (service boundary references) 1806 o Martin Thomson (service URN in LoST response message) 1808 o Cullen Jennings (service boundaries) 1810 o Clive D.W. Feather, Martin Thomson (Validation Functionality) 1811 o Roger Marshall (PSAP Preference in LoST response) 1813 o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, 1814 Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. 1815 Feather, Richard Stastny, John Hearty, Roger Marshall, Jean- 1816 Francois Mule, Pierre Desjardins (Location Profiles) 1818 o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson, 1819 Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, 1820 Keith (List Services functionality) 1822 o Thomson, Martin, Michael Hammer (Mapping of Services) 1824 o Shida Schubert, James Winterbottom, Keith Drage (default service 1825 URN) 1827 o Otmar Lendl (LoST aggregation) 1829 Klaus Darilion and Marc Linsner provided miscellaneous input to the 1830 design of the protocol. Finally, we would like to thank Brian Rosen 1831 who participated in almost every discussion thread. 1833 19. Open Issues 1835 Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ 1837 20. References 1839 20.1. Normative References 1841 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1842 Levels", BCP 14, RFC 2119, March 1997. 1844 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1845 Considerations Section in RFCs", BCP 26, RFC 2434, 1846 October 1998. 1848 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1849 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1850 HTTP/1.1", RFC 2616, June 1999. 1852 [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1854 [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 1855 RFC 3023, January 2001. 1857 [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1858 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 1859 January 2005. 1861 [7] Peterson, J., "A Presence-based GEOPRIV Location Object 1862 Format", RFC 4119, December 2005. 1864 [8] Freed, N. and J. Klensin, "Media Type Specifications and 1865 Registration Procedures", BCP 13, RFC 4288, December 2005. 1867 [9] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 1868 Registration Procedures for New URI Schemes", BCP 115, 1869 RFC 4395, February 2006. 1871 [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", 1872 draft-ietf-ecrit-service-urn-05 (work in progress), 1873 August 2006. 1875 [11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 1876 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in 1877 progress), September 2006. 1879 [12] Daigle, L., "Domain-based Application Service Location Using 1880 URIs and the Dynamic Delegation Discovery Service (DDDS)", 1881 draft-daigle-unaptr-01 (work in progress), October 2006. 1883 [13] OpenGIS, "Open Geography Markup Language (GML) Implementation 1884 Specification", OGC OGC 02-023r4, January 2003. 1886 20.2. Informative References 1888 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1889 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1890 Session Initiation Protocol", RFC 3261, June 2002. 1892 [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1893 Protocol (XMPP): Instant Messaging and Presence", RFC 3921, 1894 October 2004. 1896 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 1897 December 2004. 1899 [17] Taylor, T., "Security Threats and Requirements for Emergency 1900 Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 1901 (work in progress), July 2006. 1903 [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 1904 Context Resolution with Internet Technologies", 1905 draft-ietf-ecrit-requirements-12 (work in progress), 1906 August 2006. 1908 [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1909 Framework", draft-ietf-ecrit-mapping-arch-01 (work in 1910 progress), December 2006. 1912 [20] Rosen, B. and J. Polk, "Best Current Practice for 1913 Communications Services in support of Emergency Calling", 1914 draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006. 1916 Appendix A. Non-Normative RELAX NG Schema in XML Syntax 1918 1919 1924 1925 1926 Location-to-Service Translation Protocol (LoST) 1928 A LoST XML instance has three request types, each with 1929 a cooresponding response type: find service, list services, 1930 and get service boundary. 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1946
1947 1948 The queries. 1949 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 false 1964 1965 1966 1967 1968 1969 reference 1970 value 1971 1972 reference 1973 1974 1975 1976 1977 1978 true 1979 1980 1981 1982 1984 1985 1986 1987 1988 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 true 2002 2003 2004 2005 2007 2008 2009 2010 2011 2013 2015
2017
2018 2019 The responses. 2020 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2034 2035 2036 2037 2038 2039 2041 2042 2043 2044 2045 2046 2048 2049 2050 2051 2052 2053 2055
2057
2058 2059 A pattern common to some of the queries. 2060 2062 2063 2064 2065 2066
2068
2069 2070 A pattern common to responses. 2071 2073 2074 2075 2076 2077 2078 2079 2080
2082
2083 2084 Location Information 2085 2087 2088 2089 2090 2091 2092 2093 2094 2095
2097
2098 2099 Service Boundary 2100 2102 2103 2104 2105 2107 2108 2109 2110
2112
2113 2114 Service Boundary Reference 2115 2117 2119 2120 2121 2122 2123 2124 2126 2127 2128 2129 2130 2132
2134
2135 2136 Path - 2137 Contains a list of via elements - 2138 places through which information flowed 2139 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151
2153
2154 2155 Expires pattern 2156 2158 2159 2160 2161 2162 2163
2165
2166 2167 A QName list 2168 2170 2171 2172 2173 2174 2175 2176 2177
2179
2180 2181 A location-to-service mapping. 2182 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 [0-9*#]+ 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2229
2231
2232 2233 Location validation 2234 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2252 2253 2254 2255 2256 2257
2259
2260 2261 Errors and Warnings Container. 2262 2264 2265 2266 2267 2268 2269 2270 2271 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 2306 2307 2308 2309 2310 2312
2314
2315 2316 Basic Errors 2317 2319 2320 2321 Error pattern. 2322 2323 2324 2325 2327 2328 2329 2330 2331 2333 2334 2335 2336 2337 2339 2340 2341 2342 2343 2345 2346 2347 2349 2350 2352 2353 2354 2355 2356 2358 2359 2360 2361 2362 2364 2365 2366 2367 2368 2370 2371 2372 2373 2374 2376 2377 2378 2379 2380 2382 2383 2384 2385 2386 2387 2388 2389 2391
2393
2394 2395 Redirect. 2396 2397 2398 2399 Redirect pattern 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2411
2413
2414 2415 Some common patterns. 2416 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2431 2432 2433 2434 2435 2436 2437 2439 2440 2441 ([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+ 2442 2443 2444 2445 2446 2447 2448 2450 2451 2452 2453 2454 2455 2456 2457 2458 2460
2462
2463 2464 Patterns for inclusion of elements from schemas in 2465 other namespaces. 2466 2468 2469 2470 Any element not in the LoST namespace. 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2483 2484 2485 A wildcard pattern for including any element 2486 from any other namespace. 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2502 2503 2504 A point where future extensions 2505 (elements from other namespaces) 2506 can be added. 2507 2508 2509 2510 2511 2513 2514 2515 A 2D point from GML. 2516 2517 2518 2519 urn:ogc:def:crs:EPSG::4326 2520 2521 2522 2523 2525 2526 2527 A GML position 2528 2529 2530 2531 2532 2533 2534 2536 2537 2538 A Linear Ring from GML. 2540 2541 2543 2544 2545 2546 2547 2548 2549 2550 2552 2553 2554 A Polygon from GML. 2555 2556 2558 2559 urn:ogc:def:crs:EPSG::4326 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2572
2574 2576 Figure 24 2578 Authors' Addresses 2580 Ted Hardie 2581 Qualcomm, Inc. 2583 Email: hardie@qualcomm.com 2585 Andrew Newton 2586 SunRocket 2587 8045 Leesburg Pike, Suite 300 2588 Vienna, VA 22182 2589 US 2591 Phone: +1 703 636 0852 2592 Email: andy@hxr.us 2594 Henning Schulzrinne 2595 Columbia University 2596 Department of Computer Science 2597 450 Computer Science Building 2598 New York, NY 10027 2599 US 2601 Phone: +1 212 939 7004 2602 Email: hgs+ecrit@cs.columbia.edu 2603 URI: http://www.cs.columbia.edu 2605 Hannes Tschofenig 2606 Siemens Networks GmbH & Co KG 2607 Otto-Hahn-Ring 6 2608 Munich, Bavaria 81739 2609 Germany 2611 Phone: +49 89 636 40390 2612 Email: Hannes.Tschofenig@siemens.com 2613 URI: http://www.tschofenig.com 2615 Full Copyright Statement 2617 Copyright (C) The IETF Trust (2007). 2619 This document is subject to the rights, licenses and restrictions 2620 contained in BCP 78, and except as set forth therein, the authors 2621 retain all their rights. 2623 This document and the information contained herein are provided on an 2624 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2625 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2626 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2627 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2628 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2629 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2631 Intellectual Property 2633 The IETF takes no position regarding the validity or scope of any 2634 Intellectual Property Rights or other rights that might be claimed to 2635 pertain to the implementation or use of the technology described in 2636 this document or the extent to which any license under such rights 2637 might or might not be available; nor does it represent that it has 2638 made any independent effort to identify any such rights. Information 2639 on the procedures with respect to rights in RFC documents can be 2640 found in BCP 78 and BCP 79. 2642 Copies of IPR disclosures made to the IETF Secretariat and any 2643 assurances of licenses to be made available, or the result of an 2644 attempt made to obtain a general license or permission for the use of 2645 such proprietary rights by implementers or users of this 2646 specification can be obtained from the IETF on-line IPR repository at 2647 http://www.ietf.org/ipr. 2649 The IETF invites any interested party to bring to its attention any 2650 copyrights, patents or patent applications, or other proprietary 2651 rights that may cover technology that may be required to implement 2652 this standard. Please address the information to the IETF at 2653 ietf-ipr@ietf.org. 2655 Acknowledgment 2657 Funding for the RFC Editor function is provided by the IETF 2658 Administrative Support Activity (IASA).