idnits 2.17.1 draft-ietf-ecrit-lost-10.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3051. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3064. 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 (May 27, 2008) is 5775 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (ref. '4') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3023 (ref. '5') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (ref. '7') (Obsoleted by RFC 6838) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-11 -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. '15') (Obsoleted by RFC 6121) == Outdated reference: A later version (-04) exists of draft-ietf-ecrit-mapping-arch-03 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-04 Summary: 6 errors (**), 0 flaws (~~), 4 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: November 28, 2008 American Registry for Internet 6 Numbers 7 H. Schulzrinne 8 Columbia University 9 H. Tschofenig 10 Nokia Siemens Networks 11 May 27, 2008 13 LoST: A Location-to-Service Translation Protocol 14 draft-ietf-ecrit-lost-10.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on November 28, 2008. 41 Abstract 43 This document describes an XML-based protocol for mapping service 44 identifiers and geodetic or civic location information to service 45 contact URIs. In particular, it can be used to determine the 46 location-appropriate Public Safety Answering Point (PSAP) for 47 emergency services. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Terminology and Requirements Notation . . . . . . . . . . . . 6 53 3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7 54 4. LoST Servers and Their Resolution . . . . . . . . . . . . . . 9 55 5. The Element . . . . . . . . . . . . . . . . . . . . 10 56 5.1. The Mapping Data Source: 'source', 'sourceId' and 57 'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10 58 5.2. Mapping Validity: The 'expires' Attribute . . . . . . . . 10 59 5.3. Describing the Service with the Element . . 11 60 5.4. The Mapped Service: the Element . . . . . . . . 11 61 5.5. Defining the Service Region with the 62 Element . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5.6. Service Boundaries by Reference: the 64 Element . . . . . . . . . . . . 12 65 5.7. The Service Number: the Element . . . . . 13 66 5.8. Service URLs: the Element . . . . . . . . . . . . . 13 67 6. Path of a Request: the Element . . . . . . . . . . . . 14 68 7. Identifying the Location Element Used for Mapping: 69 . . . . . . . . . . . . . . . . . . . . . . . . 15 70 8. Mapping a Location and Service to URLs: . . . . 16 71 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 8.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 16 74 8.2.2. Civic Address Mapping Example . . . . . . . . . . . . 17 75 8.3. Components of the Request . . . . . . . . . 19 76 8.3.1. The Element . . . . . . . . . . . . . . . . 19 77 8.3.2. Identifying the Service: The Element . . . 20 78 8.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 20 79 8.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 20 80 8.3.5. Requesting Civic Location Validation . . . . . . . . . 20 81 8.4. Components of the Mapping Response 82 . . . . . . . . . . . . . . . . . . 22 83 8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22 84 8.4.2. Civic Address Validation: the 85 Element . . . . . . . . . . . . . 23 86 9. Retrieving the Service Boundary via . . . 24 87 10. List Services: . . . . . . . . . . . . . . . . 27 88 11. List Services By Location: . . . . . 28 89 12. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 30 90 12.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 31 91 12.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 34 92 12.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 36 93 13. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 37 94 13.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 95 13.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 39 96 13.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 40 97 14. LoST Transport: HTTP . . . . . . . . . . . . . . . . . . . . . 42 98 15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43 99 16. Internationalization Considerations . . . . . . . . . . . . . 50 100 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 101 17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51 102 17.2. Content-type registration for 'application/lost+xml' . . . 51 103 17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53 104 17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53 105 17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54 106 18. Security Considerations . . . . . . . . . . . . . . . . . . . 55 107 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 108 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 109 20.1. Normative References . . . . . . . . . . . . . . . . . . . 60 110 20.2. Informative References . . . . . . . . . . . . . . . . . . 61 111 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 62 112 Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 76 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 114 Intellectual Property and Copyright Statements . . . . . . . . . . 78 116 1. Introduction 118 Protocols such as NAPTR records and the Service Location Protocol 119 (SLP) can be used to discover servers offering a particular service. 120 However, for an important class of services the appropriate specific 121 service instance depends both on the identity of the service and the 122 geographic location of the entity that needs to reach it. Emergency 123 telecommunications services are an important example; here, the 124 service instance is a Public Safety Answering Point (PSAP) that has 125 jurisdiction over the location of the user making the call. The 126 desired PSAP isn't necessarily the one that is topologically or even 127 line-of-sight closest to the caller; rather, it is the one that 128 serves the caller's location based on jurisdictional boundaries. 130 This document describes a protocol for mapping a service identifier 131 and location information compatible with PIDF-LO [6] to one or more 132 service URIs. Service identifiers take the form of the service URNs 133 described in [9]. Location information here includes revised civic 134 location information [10] and a subset of the PIDL-LO profile [13] 135 which consequently includes the Geo-Shapes [12] defined for GML [11]. 136 Example service URI schemes include sip [14], xmpp [15], and tel 137 [16]. While the initial focus is on providing mapping functions for 138 emergency services, it is likely that the protocol is applicable to 139 other service URNs. For example, in the United States, the "2-1-1" 140 and "3-1-1" service numbers follow a similar location-to-service 141 behavior as emergency services. 143 This document names this protocol "LoST", for Location-to-Service 144 Translation. LoST Satisfies the requirements [18] for mapping 145 protocols. LoST provides a number of operations, centered around 146 mapping locations and service URNs to service URLs and associated 147 information. LoST mapping queries can contain either civic or 148 geodetic location information. For civic addresses, LoST can 149 indicate which parts of the civic address are known to be valid or 150 invalid, thus providing address validation, as described in Section 151 3.5 of [18]. LoST indicates errors in the location data to 152 facilitate debugging and proper user feedback, but also provides 153 best-effort answers. 155 LoST queries can be resolved recursively or iteratively. To minimize 156 round trips and to provide robustness against network failures, LoST 157 supports caching of individual mappings and indicates the region for 158 which the same answer would be returned ("service region"). 160 As defined in this document, LoST messages are carried in HTTP and 161 HTTPS protocol exchanges, facilitating use of TLS for protecting the 162 integrity and confidentiality of requests and responses. 164 This document focuses on the description of the protocol between the 165 mapping client and the mapping server. Other functions, such as 166 discovery of mapping servers, data replication and the overall 167 mapping server architecture are described in a separate document 168 [19]. 170 The query message carries location information and a service 171 identifier encoded as a Uniform Resource Name (URN) (see [9]) from 172 the LoST client to the LoST server. The LoST server uses its 173 database to map the input values to one or more Uniform Resource 174 Identifiers (URI) and returns those URIs along with optional 175 information, such as hints about the service boundary, in a response 176 message to the LoST client. If the server cannot resolve the query 177 itself, it may in turn query another server or return the address of 178 another LoST server, identified by a LoST server name. In addition 179 to the mapping function described in Section 8, the protocol also 180 allows to retrieve the service boundary (see Section 9) and to list 181 the services available for a particular location (see Section 11) or 182 supported by a particular server (see Section 10). 184 2. Terminology and Requirements Notation 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [1]. 190 This document uses the following terms: 192 Mapping: Mapping is a process that takes a location and a service 193 identifier as inputs and returns one or more URIs. Those URIs can 194 either point to a host providing that service or to a host that in 195 turn routes the request to the final destination. This definition 196 is a generalization of the term "mapping" as used in [18], because 197 LoST can be used for non-emergency services. 199 LoST client: A host acts as a LoST client if it sends LoST query 200 messages and receives LoST response messages. 202 LoST server: A host acts as a LoST server if it receives LoST query 203 messages and sends LoST response messages. In recursive 204 operation, the same entity may be both a client and a server. 206 Authoritative LoST server: An authoritative server acts only as a 207 server and successfully resolves the input location and service 208 identifier to a URI or set of URIs. 210 Service boundary: A service boundary circumscribes the region within 211 which all locations map to the same service URI or set of URIs for 212 a given service. A service boundary may consist of several non- 213 contiguous geometric shapes. 215 Validation: 217 The term "validation" describes the behavior defined as "location 218 validation" in Section 3.5 of [18]. 220 Additional emergency service terminology can be found in [18]. 222 3. Overview of Protocol Usage 224 The LoST protocol supports the following type of queries and 225 responses: 227 and 229 A LoST client retrieves contact URIs based on location information 230 and a service identifier with this request and response. The same 231 query type may also ask for location validation and for service 232 numbers, either combined with a mapping request or separately. 233 The details can be found in Section 8 and Section 8.4. 235 and 237 A LoST client obtains a service boundary with this request and 238 response, as described in Section 9. 240 and 242 With this request and response, a LoST client can find out which 243 services a LoST server supports, as described in Section 10. 245 and 247 A LoST client can determine with this request and response which 248 services are available for a specific location region. Section 11 249 describes the details. 251 LoST clients may initiate any of the above queries at any time. 252 Among the common triggers are: 254 1. When the client initially starts up or attaches to a network; 256 2. when the client detects that its location has changed 257 sufficiently that it is outside the bounds of the service region; 259 3. when a SIP message arrives at a SIP proxy performing location- 260 based call routing; 262 4. when cached mapping information has expired; 264 5. when invoking a particular service. At that time, a client may 265 omit requests for service boundaries or other auxiliary 266 information. 268 A service-specific Best Current Practice (BCP) document, such as 269 [21], governs whether a client is expected to invoke the mapping 270 service just before needing the service or whether to rely on cached 271 answers. Cache entries expire at their expiration time (see 272 Section 5.2), or they become invalid if the caller's device moves 273 beyond the boundaries of the service region. Service-specific Best 274 Curent Practice documents may also provide guidance on the contact 275 URI schemes most appropriate to the service. As a general set of 276 guidelines, URI schemes that do not provide mechanisms for actually 277 initiating a contact method should be avoided (examples include data, 278 info, cid, and tag) as transforming those references into contact 279 mechanisms requires a layer of indirection that makes the overall 280 mechanism more fragile. Provisionally registered URI schemes should 281 also be carefully considered before use, because they are subject to 282 change in core semantics. 284 4. LoST Servers and Their Resolution 286 LoST servers are identified by U-NAPTR/DDDS [8] application unique 287 strings, in the form of a DNS name. An example is 288 'lostserver.example.com'. 290 Clients need to use the U-NAPTR [8] specification described below to 291 obtain a URI (indicating host and protocol) for the applicable LoST 292 service. In this document, only the HTTP and HTTPS URL schemes are 293 defined. Note that the HTTP URL can be any valid HTTP URL, including 294 those containing path elements. 296 The following two DNS entries show the U-NAPTR resolution for 297 "example.com" to the HTTPS URL https://lostserv.example.com/secure or 298 the HTTP URL http://lostserver.example.com, with the former being 299 preferred. 301 example.com. 303 IN NAPTR 100 10 "u" "LoST:https" 304 "!.*!https://lostserver.example.com/secure!" "" 306 IN NAPTR 200 10 "u" "LoST:http" 307 "!.*!http://lostserver.example.com!" "" 309 Clients learn the LoST server's host name by means beyond the scope 310 of this specification, such as SIP configuration and DHCP. 312 5. The Element 314 The element is the core data element in LoST, describing a 315 service region and the associated service URLs. Its attributes and 316 elements are described in subsections below. 318 5.1. The Mapping Data Source: 'source', 'sourceId' and 'lastUpdated' 319 Attributes 321 The 'source', the 'sourceId' and the 'lastUpdated' attributes 322 uniquely identify a particular mapping record. They are created by 323 the authoritative source for a mapping and are never modified when a 324 mapping is served from a cache. All three attributes are REQUIRED 325 for all elements. A receiver can replace a mapping with 326 another one having the same 'source' and 'sourceId' and a more recent 327 time in 'lastUpdated'. 329 The 'source' attribute contains a LoST application unique string 330 identifying the authoritative generator of the mapping (Section 4). 332 The 'sourceId' attribute identifies a particular mapping and contains 333 an opaque token that MUST be unique among all different mappings 334 maintained by the authoritative source for that particular service. 335 For example, a Universally Unique Identifier (UUID) is a suitable 336 format. 338 The 'lastUpdated' attribute describes when a specific instance of 339 mapping, identified by the combination of 'source' and 'sourceId', 340 was last changed. The contents of this attribute has the XML data 341 type dateTime in its timezoned form, using canonical UTC 342 representation with the letter 'Z' as the timezone indicator. 344 5.2. Mapping Validity: The 'expires' Attribute 346 The 'expires' attribute contains the absolute time at which the 347 mapping becomes invalid. The contents of this attribute is a 348 timezoned XML type dateTime, in canonical representation. See 349 Section 3 regarding how this value is to be utilized with a cache. 350 The 'expires' attribute is REQUIRED to be included in the 351 element. 353 Optionally, this attribute may contain the values of 'NO-CACHE' and 354 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is 355 an indication that the mapping should not be cached. The value of 356 'NO-EXPIRATION' is an indication that the mapping does not expire. 358 On occasion, a server may be forced to return an expired mapping if 359 it cannot reach the authoritative server or the server fails to 360 return a usable answer. Clients and servers MAY cache the mapping so 361 that they have at least some information available. Caching servers 362 that have such stale information SHOULD re-attempt the query each 363 time a client requests a mapping. Since the expired mapping will be 364 returned to the client as a non-error/non-warning response ,the 365 client MUST check the 'expires' attribute; if the mapping has 366 expired, local policy at the client determines whether it discards 367 the answer and tries again later or uses the possibly stale response. 369 5.3. Describing the Service with the Element 371 Zero or more elements describe the service with a 372 string that is suitable for display to human users, each annotated 373 with the 'xml:lang' attribute that contains a language tag to aid in 374 the rendering of text. 376 5.4. The Mapped Service: the Element 378 The mandatory element identifies the service for which this 379 mapping applies. Two cases need to be distinguished when the LoST 380 server sets the element in the response message: 382 1. If the requested service, identified by the service URN [9] in 383 the element of the request, exists for the location 384 indicated, then the LoST server copies the service URN from the 385 request into the element. 387 2. If, however, the requested service, identified by the service URN 388 [9] in the element in the request, does not exist for 389 the location indicated, the server can either return an 390 (Section 13.1) error or can provide an 391 alternate service that approximates the desired service for that 392 location. In the latter case, the server MUST include a 393 element with the alternative service URN. The choice 394 of service URN is left to local policy, but the alternate service 395 should be able to satisfy the original service request. 397 5.5. Defining the Service Region with the Element 399 A response MAY indicate the region for which the service URL returned 400 would be the same as in the actual query, the so-called _service 401 region_. The service region can be indicated by value or by 402 reference (see Section 5.6). If a client moves outside the service 403 area and wishes to obtain current service data, it sends a new query 404 with its current location. The service region is described by value 405 in one or more elements, each formatted according 406 to a specific location profile, identified by the 'profile' attribute 407 (see Section 12). serviceBoundary elements formatted according to 408 different location profiles are alternative representations of the 409 same area, not additive to one another; this allows a client 410 understanding only one of the profile types to be sure it has a 411 complete view of the serviceBoundary. Within a serviceBoundary 412 element there may, however, be multiple locations which _are_ 413 additive; this is necessary because some serviceBoundary areas could 414 not be easily expressed with a single shape or civic location. If 415 included in a response, the element MUST contain at 416 least one service boundary that uses the same profile as the request. 418 A service boundary is requested by the client, using the 419 'serviceBoundary' attribute in the request with the value set to 420 "value". 422 5.6. Service Boundaries by Reference: the 423 Element 425 Since geodetic service boundaries may contain thousands of points and 426 can thus be quite large, clients may wish to conserve bandwidth by 427 requesting a reference to the service boundary instead of the value 428 described in Section 5.5. The identifier of the service boundary is 429 returned as an attribute of the element, 430 along with a LoST application unique string (see Section 4) 431 identifying the server from where it can be retrieved. The actual 432 value of the service boundary is then retrieved with the 433 getServiceBoundary (Section 9) request. 435 A reference to a service boundary is requested by the client (using 436 the 'serviceBoundary' attribute in the request with the value set to 437 "reference"). A LoST server may decide, based on local policy, to 438 return the service boundary per value or to omit the 439 element in the response. 441 The identifier is a random token with at least 128 bits of entropy 442 and can be assumed to be globally unique. It uniquely references a 443 particular boundary. If the boundary changes, a new identifier MUST 444 be chosen. Because of these properties, a client receiving a mapping 445 response can simply check if it already has a copy of the boundary 446 with that identifier. If so, it can skip checking with the server 447 whether the boundary has been updated. Since service boundaries are 448 likely to remain unchanged for extended periods of time, possibly 449 exceeding the normal lifetime of the service URL, this approach 450 avoids unnecessarily refreshing the boundary information just because 451 the remainder of the mapping has become invalid. 453 5.7. The Service Number: the Element 455 The service number is returned in the optional 456 element. It contains a string of digits, * and # that a user on a 457 device with a 12-key dial pad could use to reach that particular 458 service. 460 5.8. Service URLs: the Element 462 The response returns the service URLs in one or more elements. 463 The URLs MUST be absolute URLs. The ordering of the URLs has no 464 particular significance. Each URL scheme MUST only appear at most 465 once, but it is permissible to include both secured and regular 466 versions of a protocol, such as both 'http' and 'https' or 'sip' and 467 'sips'. 469 6. Path of a Request: the Element 471 To prevent loops and to allow tracing of request and response paths, 472 all requests that allow recursion include a element that 473 contains one or more elements, each possessing an attribute 474 containing a LoST application unique string (see Section 4). The 475 order of elements corresponds to the order of LoST servers, 476 i.e., the first element identifies the server that initially 477 received the request from the client issuing the request. Every 478 server in a recursive query operation is included in the 479 element, including the first server to receive it. 481 The server that answers the request instead of forwarding it, such as 482 the authoritative server, copies the element verbatim into the 483 response. The element is not modified in responses as the 484 responses traverses the server chain back to the querying client. 486 If a query is answered iteratively, the querier includes all servers 487 that it has already contacted. 489 When a cached mapping is returned then the element cached 490 together with the mapping is returned. 492 The example in Figure 4 indicates that the answer was given to the 493 client by the LoST server at esgw.ueber-110.de.example, which got the 494 answer from the (authoritative) LoST server at 495 polizei.muenchen.de.example. 497 7. Identifying the Location Element Used for Mapping: 499 Several of the requests can provide one or more elements, 500 among which the server gets to choose. It is useful for the client 501 to be able to determine which one was actually used in producing the 502 result. For that purpose, the tag MUST contain an 'id' 503 attribute that uniquely identifies the element. The 504 format of the identifier is left to the client; it could, for 505 example, use a hash of the location information. The server returns 506 the identifier for the element it used in the 507 tag. See Section 8.3.1 for more details. 509 8. Mapping a Location and Service to URLs: 511 8.1. Overview 513 The query constitutes the core of the LoST 514 functionality, mapping civic or geodetic locations to URLs and 515 associated data. After giving an example, we enumerate the elements 516 of the query and response. 518 8.2. Examples 520 8.2.1. Example Using Geodetic Coordinates 522 The following is an example of mapping a service to a location using 523 geodetic coordinates, for the service associated with the police 524 (urn:service:sos.police). 526 527 533 534 535 37.775 -122.422 536 537 538 urn:service:sos.police 540 542 Figure 1: A geodetic query 544 Given the query above, a server would respond with a service, and 545 information related to that service. In the example below, the 546 server has mapped the location given by the client for a police 547 service to the New York City Police Department, instructing the 548 client that it may contact them via the URIs "sip:nypd@example.com" 549 and "xmpp:nypd@example.com". The server has also given the client a 550 geodetic, two-dimensional boundary for this service. The mapping was 551 last updated on November 1, 2006 and expires on January 1, 2007. If 552 the client's location changes beyond the given service boundary or 553 the expiration time has been reached, it may want to requery for this 554 information, depending on the usage environment of LoST. 556 557 559 564 565 New York City Police Department 566 567 urn:service:sos.police 568 569 570 571 572 37.775 -122.4194 573 37.555 -122.4194 574 37.555 -122.4264 575 37.775 -122.4264 576 37.775 -122.4194 577 578 579 580 581 sip:nypd@example.com 582 xmpp:nypd@example.com 583 911 584 585 586 587 588 589 590 592 Figure 2: A geodetic answer 594 8.2.2. Civic Address Mapping Example 596 The example below shows how to map a service to a location much like 597 the example in Section 8.2.1, but using civic address location 598 information. In this example, the client requests the service 599 associated with police (urn:service:sos.police) along with a specific 600 civic address (house number 6 on a street named Otto-Hahn-Ring in 601 Munich, Germany). 603 604 606 607 609 Germany 610 Bavaria 611 Munich 612 Otto-Hahn-Ring 613 6 614 81675 615 616 617 urn:service:sos.police 618 620 Figure 3: A civic address query 622 Given the query above, a server would respond with a service, and 623 information related to that service. In the example below, the 624 server has mapped the location given by the client for a police 625 service to the Muenchen Polizei-Abteilung, instructing the client 626 that it may contact them via the URIs sip:munich-police@example.com 627 and xmpp:munich-police@example.com. The server has also given the 628 client a civic address boundary (the city of Munich) for this 629 service. The mapping was last updated on November 1, 2006 by the 630 authoritative source "polizei.muenchen.de.example" and expires on 631 January 1, 2007. This instructs the client to requery for the 632 information if its location changes beyond the given service boundary 633 (i.e., beyond the city of Munich) or after January 1, 2007. 635 636 637 642 643 Muenchen Polizei-Abteilung 644 645 urn:service:sos.police 646 648 650 Germany 651 Bavaria 652 Munich 653 81675 654 655 656 sip:munich-police@example.com 657 xmpp:munich-police@example.com 658 110 659 660 661 662 663 664 665 667 Figure 4: A civic address answer 669 8.3. Components of the Request 671 The request includes attributes and elements that 672 govern whether the request is handled iteratively or recursively, 673 whether location validation is performed and which elements may be 674 contained in the response. 676 8.3.1. The Element 678 The query communicates location information using one 679 or more elements, which MUST conform to a location profile 680 (see Section 12). There MUST NOT be more than one location element 681 for each distinct location profile. The order of location elements 682 is significant; the server uses the first location element where it 683 understands the location profile. 685 8.3.2. Identifying the Service: The Element 687 The type of service desired is specified by the element. 688 It contains service URNs from the registry established in [9]. 690 8.3.3. Recursion and Iteration 692 LoST can operate in either recursive or iterative mode, on a request- 693 by-request basis. In recursive mode, the LoST server initiates 694 queries on behalf of the requester and returns the result to the 695 requester. 697 In iterative mode, the server contacted returns a redirection 698 response indicating the next server to be queried if the server 699 contacted cannot provide an answer itself. 701 For the queries defined in this document, only LoST and 702 queries can be recursive, as indicated by 703 the 'recursive' attribute. A value of "true" indicates a recursive 704 query, with the default being "false" when the attribute is omitted. 705 Regardless of the attribute, a server MAY always answer a query by 706 providing a LoST application unique string (see Section 4), i.e., 707 indirection, however, it MUST NOT recurse if the attribute is 708 "false". 710 8.3.4. Service Boundary 712 LoST elements can describe the service boundary either by 713 value or by reference. Returning a service boundary reference is 714 generally more space-efficient for geospatial (polygon) boundaries 715 and if the boundaries change rarely, but does incur an additional 716 request. The querier can express a preference 717 for one or the other modality with the 'serviceBoundary' attribute in 718 the request, but the server makes the final decision as 719 to whether to return a reference or a value. 721 8.3.5. Requesting Civic Location Validation 723 Civic address validation is requested by setting the optional 724 attribute 'validateLocation' to true. If the attribute is omitted, 725 it is assumed to be false. The response is described in 726 Section 8.4.2. The example in Figure 5 demonstrates address 727 validation. If the server chooses a geodetic location among the 728 locations provided in a request, the attribute is ignored. 730 731 736 737 739 DE 740 Bavaria 741 Munich 742 Otto-Hahn-Ring 743 6 744 81675 745 746 747 urn:service:sos.police 748 750 Figure 5: A query with address validation request 752 753 754 759 760 Muenchen Polizei-Abteilung 761 762 urn:service:sos.police 763 764 766 Germany 767 Bavaria 768 Munich 769 81675 770 771 772 sip:munich-police@example.com 773 xmpp:munich-police@example.com 774 110 775 776 777 country A1 A3 A6 778 PC 779 HNO 780 781 782 783 784 785 786 788 Figure 6: A message with address validation 789 information 791 8.4. Components of the Mapping Response 793 8.4.1. Overview 795 Mapping responses consist of the element (Section 5) 796 describing the mapping itself, possibly followed by warnings 797 (Section 13.2), location validation information (Section 8.4.2), and 798 an indication of the path (Section 6) the response has taken. 800 8.4.2. Civic Address Validation: the Element 802 A server can indicate in its response which civic address elements it 803 has recognized as valid, which ones it has ignored and which ones it 804 has checked and found to be invalid. The server SHOULD include this 805 information if the 'validateLocation' attribute in the request was 806 true but local policy at the server may allow this information to be 807 omitted. Each element contains a list of tokens separated by white 808 space, enumerating the civic location labels used in child elements 809 of the element. The element enumerates those 810 civic address elements that have been recognized as valid by the LoST 811 server and that have been used to determine the mapping. The 812 elements enumerates the civic address elements that the 813 server did not check and that were not used in determining the 814 response. The element enumerate civic address elements 815 that the server attempted to check, but that did not match the other 816 civic address elements found in the list. Civic location 817 tokens that are neither listed in the , the and the 818 element belong to the class of unchecked tokens. 820 Note that the same address can yield different responses if parts of 821 the civic address contradict each other. For example, if the postal 822 code does not match the city, local server policy determines whether 823 the postal code or the city is considered valid. The mapping 824 naturally corresponds to the valid elements. 826 The example shown in Figure 5 and in Figure 6 indicates that the 827 tokens 'country', 'A1', 'A3', and 'A6' have been validated by the 828 LoST server. The server considered the postal code 81675 in the 829 element as not valid for this location. The 'HNO' token belongs to 830 the class of unchecked location tokens. 832 9. Retrieving the Service Boundary via 834 As discussed in Section 5.5, the can return a 835 globally unique identifier in the 'serviceBoundary' attribute that 836 can be used to retrieve the service boundary, rather than returning 837 the boundary by value. This is shown in the example in Figure 7 and 838 Figure 8. The client can then retrieve the boundary using the 839 request and obtains the boundary in the 840 , illustrated in the example in Figure 9. 841 The client issues the request to the server identified in the 842 'server' attribute of the element. These 843 requests are always directed to the authoritative server and do not 844 recurse. 846 847 852 853 854 37.775 -122.422 855 856 857 urn:service:sos.police 858 860 Figure 7: request and response with service boundary 861 reference 863 864 866 871 872 New York City Police Department 873 874 urn:service:sos.police 875 878 sip:nypd@example.com 879 xmpp:nypd@example.com 880 911 881 882 883 884 885 886 887 889 Figure 8: message with service boundary 890 reference 892 893 896 Figure 9: Requesting a service boundary with 898 The request may also be used to retrieve service 899 boundaries that are expressed as civic addresses, as illustrated in 900 Figure 10. 902 903 905 906 908 US 909 New York 910 New York 911 912 913 914 915 916 917 919 Figure 10: Civic Address Service Boundary Response 921 10. List Services: 923 A LoST client can ask a LoST server for the list of services that it 924 understands, primarily for diagnostic purposes. The query does not 925 contain location information, as it simply provides an indication of 926 which services the server can look up, not whether a particular 927 service is offered for a particular area. Typically, only top-level 928 services are included in the answer, implying support for all sub- 929 services. Since the query is answered by the queried server, there 930 is no notion of recursion or indirection and no path indication. The 931 (Section 11) query below can be used to find 932 out whether a particular service is offered for a specific location. 933 An example request and response are shown in Figure 11. 935 936 938 urn:service:sos 939 941 Figure 11: Example of query 943 944 946 947 urn:service:sos.ambulance 948 urn:service:sos.animal-control 949 urn:service:sos.fire 950 urn:service:sos.gas 951 urn:service:sos.mountain 952 urn:service:sos.marine 953 urn:service:sos.physician 954 urn:service:sos.poison 955 urn:service:sos.police 956 urn:service:sos.suicide 957 958 959 960 961 962 964 Figure 12: Example of 966 11. List Services By Location: 968 A LoST client can ask a LoST server for the list of services it knows 969 about for a particular area. The query 970 contains one or more elements, each from a different 971 location profile (Section 12), and may contain the element. 972 As for , the server selects the first location element 973 that has a profile the server understands and it can operate either 974 recursively or iteratively; elements track the progress of the 975 request. The query indicates the services that the server can 976 enumerate from within the forest structure of which it is a part. 977 Because LoST does not presume a single, overarching organization of 978 all potential service types, there may be services available within a 979 geographic area which could be described by other LoST servers 980 connected to other forest structures. As an example, the emergency 981 services forest for a region may be distinct from the forests that 982 locate commercial services within the same region 984 If the query contains the element, the LoST server returns 985 only immediate child services of the queried service that are 986 available for the provided location. If the element is 987 absent, the LoST service returns all top-level services available for 988 the provided location that it knows about. 990 A server responds to this query with a 991 response. This response MAY contain 992 elements (see Section 6) and MUST contain a 993 element, consisting of a whitespace-separated list of service URNs. 994 The query and response are illustrated in Figure 13 and in Figure 14, 995 respectively. 997 998 1002 1003 1004 -34.407 150.883 1005 1006 1007 urn:service:sos 1008 1010 Figure 13: Example of query 1012 1013 1015 1016 urn:service:sos.ambulance 1017 urn:service:sos.animal-control 1018 urn:service:sos.fire 1019 urn:service:sos.gas 1020 urn:service:sos.mountain 1021 urn:service:sos.marine 1022 urn:service:sos.physician 1023 urn:service:sos.poison 1024 urn:service:sos.police 1025 urn:service:sos.suicide 1026 1027 1028 1029 1030 1031 1032 1034 Figure 14: Example of response 1036 12. Location Profiles 1038 LoST uses location information in elements in requests and 1039 elements in responses. Such location information 1040 may be expressed in a variety of ways. This variety can cause 1041 interoperability problems where a request or response contains 1042 location information in a format not understood by the server or the 1043 client, respectively. To achieve interoperability, this document 1044 defines two mandatory-to-implement baseline location profiles to 1045 define the manner in which location information is transmitted. It 1046 is possible to standardize other profiles in the future. The 1047 baseline profiles are: 1049 geodetic-2d: 1051 a profile for two-dimensional geodetic location information, as 1052 described in Section 12.2; 1054 civic: 1056 a profile consisting of civic address location information, as 1057 described in Section 12.3. 1059 Requests and responses containing or 1060 elements MUST contain location information in exactly one of the two 1061 baseline profiles, in addition to zero or more additional profiles. 1062 The ordering of location information indicates a preference on the 1063 part of the sender. 1065 Standards action is required for defining new profiles. A location 1066 profile MUST define: 1068 1. The token identifying it in the LoST location profile registry; 1070 2. The formal definition of the XML to be used in requests, i.e., an 1071 enumeration and definition of the XML child elements of the 1072 element; 1074 3. The formal definition of the XML to be used in responses, i.e., 1075 an enumeration and definition of the XML child elements of the 1076 element; 1078 4. The declaration of whether geodetic-2d or civic is to be used as 1079 the baseline profile. It is necessary to explicitly declare the 1080 baseline profile as future profiles may be combinations of 1081 geodetic and civic location information. 1083 12.1. Location Profile Usage 1085 A location profile is identified by a token in an IANA-maintained 1086 registry (Section 17.5). Clients send location information compliant 1087 with a location profile, and servers respond with location 1088 information compliant with that same location profile. 1090 When a LoST client sends a request that provides 1091 location information, it includes one or more elements. A 1092 element carries an optional 'profile' attribute that 1093 indicates the location format of the child elements. A client may 1094 obtain location information that does not conform to a profile it 1095 recognizes or it may not have the capability to map XML to profiles. 1096 In that case, a client MAY omit the profile attribute and the server 1097 should interpret the XML location data to the best of its ability, 1098 returning a "locationProfileUnrecognized" error if it is unable to do 1099 so. 1101 The concept of location profiles are described in Section 12. With 1102 the ability to specify more than one element the client is 1103 able to convey location information for multiple location profiles in 1104 the same request. 1106 When a LoST server sends a response that contains location 1107 information, it uses the elements much like the 1108 client uses the elements. Each element 1109 contains location information conforming to the location profile 1110 specified in the 'profile' attribute. A response MAY contain 1111 multiple mappings or boundaries for the different 1112 elements, subject to the restrictions below. 1114 Using the location profiles defined in this document, the following 1115 rules ensure interoperability between clients and servers: 1117 1. A client MUST be capable of understanding the response for the 1118 baseline profiles it used in the request. 1120 2. If a client sends location information conformant to any location 1121 profile other than the ones described in this document, it MUST 1122 also send, in the same request, location information conformant 1123 to one of the baseline profiles. Otherwise, the server might not 1124 be able to understand the request. 1126 3. A client MUST NOT send multiple objects that are 1127 derived from different baseline profiles. In other words, a 1128 client MUST only send location objects according to the same 1129 baseline profile in a query, but it MAY contain a location 1130 element following a baseline profile in addition to some other 1131 profile. 1133 4. If a client has both location information primarily of geodetic 1134 nature and location information primarily of a civic nature, it 1135 MUST send separate requests containing each type of location 1136 information. 1138 5. There can only be one instance of each location profile in a 1139 query. 1141 6. Servers MUST implement all profiles described in this document. 1143 7. A server uses the first-listed location profile that it 1144 understands and ignores the others. 1146 8. If a server receives a request that only contains location 1147 information using profiles it does not understand, the server 1148 responds with a (Section 13.1). 1150 9. The element MUST use the same location profile 1151 that was used to retrieve the answer and indicates which profile 1152 has been used with the 'profile' attribute. 1154 These rules enable the use of location profiles not yet specified, 1155 while ensuring baseline interoperability. Take, for example, this 1156 scenario. Client X has had its firmware upgraded to support the 1157 'not-yet-standardized-prism-profile' location profile. Client X 1158 sends location information to Server Y, which does not understand the 1159 'not-yet-standardized-prism-profile' location profile. If Client X 1160 also sends location information using the geodetic-2D baseline 1161 profile, then Server Y will still be able to understand the request 1162 and provide an understandable response, though with location 1163 information that might not be as precise or expressive as desired. 1164 This is possible because both Client X and Server Y understand the 1165 baseline profile. 1167 1168 1174 1176 1177 1178 1179 1180 1181 1182 42.556844 -73.248157 36.6 1183 42.656844 -73.248157 36.6 1184 42.656844 -73.348157 36.6 1185 42.556844 -73.348157 36.6 1186 42.556844 -73.248157 36.6 1187 1188 1189 1190 1191 1192 1193 2.4 1194 1195 1196 1197 1198 1199 42.656844 -73.348157 1200 1201 1202 urn:service:sos.police 1203 1205 Figure 15: Example of a query with baseline profile 1206 interoperability 1208 1209 1212 1217 1218 New York City Police Department 1219 1220 urn:service:sos.police 1221 1222 1223 1224 1225 37.775 -122.4194 1226 37.555 -122.4194 1227 37.555 -122.4264 1228 37.775 -122.4264 1229 37.775 -122.4194 1230 1231 1232 1233 1234 sip:nypd@example.com 1235 911 1236 1237 1238 1239 1240 1241 1242 1244 Figure 16: Example of a message with baseline 1245 profile interoperability 1247 12.2. Two Dimensional Geodetic Profile 1249 The "geodetic-2d" location profile is identified by "geodetic-2d". 1250 Clients and servers use this profile by placing the following 1251 location shapes into the or into the 1252 element (unless indicated otherwise): 1254 Point: 1256 The element is described in Section 5.2.1 of [13]. 1257 Section 5.2.1 of [13] shows also the specification of a 1258 with either a two dimensional position (latitude and longitude) or 1259 three dimensional position (latitude, longitude, and altitude). A 1260 client MAY use the three dimensional position, and servers MAY 1261 interpret a three dimensional position as a two dimensional 1262 position by ignoring the altitude value. A element is not 1263 placed into a element. 1265 Polygon: 1267 The element is described in Section 5.2.2 of [13]. The 1268 restriction to 16 points for a polygon contained in Section 7.2.2 1269 of [12] is not applicable to this document. 1271 Circle: 1273 The element is described in Section 5.2.3 of [13]. 1275 Ellipse: 1277 The element is described in Section 5.2.4 of [13]. 1279 ArcBand: 1281 The element is described in Section 5.2.5 of [13]. 1283 When a client uses a , , or 1284 element within the element, it is indicating that it will 1285 be satisfied by query results appropriate to any portion of the 1286 shape. It is left to the server to select an appropriate matching 1287 algorithm. A server MAY return multiple elements if the 1288 shape extends across multiple service areas. Servers are not 1289 required to return all possible elements to avoid denial of 1290 service attacks in which clients present queries that span a very 1291 large number service boundaries (e.g. presenting a shape covering all 1292 of the United States). 1294 In the case where the server does not return multiple 1295 elements, but the shape extends across a service boundary, it is 1296 possible that the matching algorithm selected by the LoST server will 1297 return results that match a portion of the shape but do not match 1298 those specific to a particular point. A client may always select a 1299 point from within the shape to avoid this condition. The cases where 1300 it does not are generally those where it knows its own position only 1301 within the shape given. In emergency service use cases, that may 1302 result in the PSAP contacted at the URI provided by LoST being 1303 required to forward a call to one of its neighbors; this is an 1304 expected part of the overall emergency response system. In non- 1305 emergency service use cases, the service deployment model should take 1306 into account this issue as part of the provisioning model, as the 1307 combination of the data in the LoST server and the algorithm used for 1308 mapping determine which contact URIs are returned when shapes are 1309 used which overlap multiple service areas. 1311 As a general guideline, any deployed matching algorithm should ensure 1312 that the algorithm used does not needlessly return NULL results if 1313 there are valid results for any portion of the shape. If an 1314 authoritative server receives a query for which the area in the query 1315 overlaps the area for which the server has mapping information, then 1316 it MUST return either a mapping whose coverage area intersects the 1317 query area or a redirect to another server whose coverage area is a 1318 subset of the server's coverage area. 1320 When geodetic location information of this location profile is placed 1321 in the element then the elements with geospatial 1322 coordinates are alternative descriptions of the same service region, 1323 not additive geometries. 1325 12.3. Basic Civic Profile 1327 The basic-civic location profile is identified by the token 'civic'. 1328 Clients use this profile by placing a element, defined 1329 in [10], within the element. 1331 Servers use this profile by placing a element, defined 1332 in [10], within the element. 1334 A response MAY contain more than one element with 1335 profile 'civic'. Each element describes a set of 1336 civic addresses that fall within the service boundary, namely all 1337 addresses that textually match the civic address elements provided, 1338 regardless of the value of other address elements. A location falls 1339 within the mapping's service boundary if it matches any of the 1340 elements. Hence, a response may contain multiple 1341 elements with civic and/or geodetic location 1342 profiles. 1344 13. Errors, Warnings, and Redirects 1346 When a LoST server cannot fulfill a request completely, it can return 1347 either an error or a warning, depending on the severity of the 1348 problem. It returns an error element if no useful response can be 1349 returned for the query. It returns a element as part of 1350 another response element if it was able to respond in part, but the 1351 response may not be quite what the client had desired. For both 1352 elements, the 'source' attribute names the server that originally 1353 generated the error or warning, such as the authoritative server. 1354 Unless otherwise noted, all elements below can be either an error or 1355 a warning, depending on whether a default response, such as a 1356 mapping, is included. 1358 13.1. Errors 1360 LoST defines a pattern for errors, defined as elements in 1361 the Relax NG schema. This pattern defines a 'message' attribute 1362 containing human readable text and an 'xml:lang' attribute denoting 1363 the language of the human readable text. One or more such error 1364 elements are contained in the element. 1366 The following errors follow this basic pattern: 1368 badRequest 1370 The server could not parse or otherwise understand a request, 1371 e.g., because the XML was malformed. 1373 forbidden 1375 The server refused to send an answer. This generally only occurs 1376 for recursive queries, namely if the client tried to contact the 1377 authoritative server and was refused. 1379 internalError 1381 The server could not satisfy a request due to misconfiguration or 1382 other operational and non-protocol related reasons. 1384 locationProfileUnrecognized 1386 None of the profiles in the request were recognized by the server 1387 (see Section 12). 1389 locationInvalid 1391 The geodetic or civic location in the request was invalid. For 1392 example, the longitude or latitude values fall outside the 1393 acceptable ranges. 1395 SRSInvalid 1397 The spatial reference system (SRS) contained in the location 1398 element was not recognized or does not match the location profile. 1400 loop 1402 During a recursive query, the server was about to visit a server 1403 that was already in the server list in the element, 1404 indicating a request loop. 1406 notFound 1408 The server could not find an answer to the query. 1410 serverError 1412 An answer was received from another LoST server, but it could not 1413 be parsed or otherwise understood. This error occurs only for 1414 recursive queries. 1416 serverTimeout 1418 A time out occurred before an answer was received. 1420 serviceNotImplemented 1422 The requested service URN is not implemented and no substitution 1423 was available. 1425 An example is below: 1427 1428 1430 1431 1433 Figure 17: Example of an error resonse 1435 13.2. Warnings 1437 A response MAY contain zero or more warnings. This pattern defines a 1438 'message' attribute containing human readable text and an 'xml:lang' 1439 attribute denoting the language of the human readable text. One or 1440 more such warning elements are contained in the element. 1441 To provide human readable text in an appropriate language the HTTP 1442 content negotiation capabilities (see Section 14) MAY be utilized by 1443 a server. 1445 This version of the specification defines the following warnings: 1447 locationValidationUnavailable 1449 The element MAY be returned when a 1450 server wishes to notify a client that it cannot fulfill a location 1451 validation request. This warning allows a server to return 1452 mapping information while signalling this exception state. 1454 serviceSubstitution 1456 The element MAY be returned when a server 1457 was not able to fulfill a request for a given 1458 service URN. For example, a request with the 1459 'urn:service:sos.police' service URN for a location in Uruguay may 1460 cause the LoST service to return a mapping for the 1461 'urn:service:sos' service URN since Uruguay does not make use of 1462 the sub-services police, fire and ambulance. If this warning is 1463 returned then the element in the response provides 1464 information about the service URN that refers to the mapping. 1466 defaultMappingReturned 1468 The element MAY be returned when a server 1469 was not able to fulfill a request for a given 1470 location but is able to respond with a default URI. For example, 1471 a nearby PSAP may be returned. 1473 An example of a warning is shown below: 1475 1476 1478 1483 1484 New York City Police Department 1485 1486 urn:service:sos.police 1487 1488 1489 1490 1491 37.775 -122.4194 1492 37.555 -122.4194 1493 37.555 -122.4264 1494 37.775 -122.4264 1495 37.775 -122.4194 1496 1497 1498 1499 1500 sip:nypd@example.com 1501 1502 1503 1507 1508 1509 1510 1511 1512 1514 Figure 18: Example of an warning resonse 1516 13.3. Redirects 1518 A LoST server can respond indicating that the querier should redirect 1519 the query to another server, using the element. The 1520 element includes a 'target' attribute indicating the LoST application 1521 unique string (see Section 4) that the client SHOULD be contacting 1522 next, as well as the 'source' attribute indicating the server that 1523 generated the redirect response and a 'message' attribute explaining 1524 the reason for the redirect response. During a recursive query, a 1525 server receiving a response can decide whether it wants to 1526 follow the redirection or simply return the response to its upstream 1527 querier. The "expires" value in the response returned by the server 1528 handling the redirected query indicates the earliest time at which a 1529 new query might be needed (see section 5.2). The query for the same 1530 tuple of location and service SHOULD NOT be directed to the server 1531 which gave redirect prior to that time. 1533 An example is below: 1535 1536 1541 Figure 19: Example of a redirect response 1543 14. LoST Transport: HTTP 1545 LoST needs an underlying protocol transport mechanisms to carry 1546 requests and responses. This document defines the use of LoST over 1547 HTTP and LoST over HTTP-over-TLS. Client and server developers are 1548 reminded that full support of RFC 2616 HTTP facilities is expected. 1549 If LoST clients or servers re-implement HTTP, rather than using 1550 available servers or client code as a base, careful attention must be 1551 paid to full interoperability. Other transport mechanisms are left 1552 to future documents. The available transport mechanisms are 1553 determined through the use of the LoST U-NAPTR application. In 1554 protocols that support content type indication, LoST uses the media 1555 type application/lost+xml. 1557 When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP 1558 POST method. The HTTP request MUST use the Cache-Control response 1559 directive "no-cache" to HTTP-level caching even by caches that have 1560 been configured to return stale responses to client requests. 1562 All LoST responses, including those indicating a LoST warning or 1563 error, are carried in 2xx responses, typically 200 (OK). Other 2xx 1564 responses, in particular 203 (Non-authoritative information) may be 1565 returned by HTTP caches that disregard the caching instructions. 3xx, 1566 4xx and 5xx HTTP response codes indicates that the HTTP request 1567 itself failed or was redirected; these responses do not contain any 1568 LoST XML elements. The 3xx responses are distinct from the redirects 1569 which are described in Section 13.3; the 13.3 redirects occur after a 1570 LoST server processes the request. Where an HTTP-layer redirect will 1571 be general, a LoST server redirect as described in 13.3 might be 1572 specific to a specific service or be the result of other processing 1573 by the LoST server. 1575 The HTTP URL is derived from the LoST server name via U-NAPTR 1576 application, as discussed above. 1578 15. Relax NG Schema 1580 This section provides the Relax NG schema used by LoST protocol in 1581 the compact form. The verbose form is included in Appendix A. 1583 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 1584 default namespace ns1 = "urn:ietf:params:xml:ns:lost1" 1586 ## 1587 ## Location-to-Service Translation Protocol (LoST) 1588 ## 1589 ## A LoST XML instance has three request types, each with 1590 ## a cooresponding response type: find service, list services, 1591 ## and get service boundary. 1592 ## 1593 start = 1594 findService 1595 | listServices 1596 | listServicesByLocation 1597 | getServiceBoundary 1598 | findServiceResponse 1599 | listServicesResponse 1600 | listServicesByLocationResponse 1601 | getServiceBoundaryResponse 1602 | errors 1603 | redirect 1605 ## 1606 ## The queries. 1607 ## 1608 div { 1609 findService = 1610 element findService { 1611 requestLocation, 1612 commonRequestPattern, 1613 attribute validateLocation { 1614 xsd:boolean >> a:defaultValue [ "false" ] 1615 }?, 1616 attribute serviceBoundary { 1617 ("reference" | "value") >> a:defaultValue [ "reference" ] 1618 }?, 1619 attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? 1620 } 1621 listServices = element listServices { commonRequestPattern } 1622 listServicesByLocation = 1623 element listServicesByLocation { 1624 requestLocation, 1625 commonRequestPattern, 1626 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 1627 } 1628 getServiceBoundary = 1629 element getServiceBoundary { serviceBoundaryKey, extensionPoint } 1630 } 1632 ## 1633 ## The responses. 1634 ## 1635 div { 1636 findServiceResponse = 1637 element findServiceResponse { 1638 mapping+, locationValidation?, commonResponsePattern, locationUsed 1639 } 1640 listServicesResponse = 1641 element listServicesResponse { serviceList, commonResponsePattern } 1642 listServicesByLocationResponse = 1643 element listServicesByLocationResponse { 1644 serviceList, commonResponsePattern, locationUsed 1645 } 1646 getServiceBoundaryResponse = 1647 element getServiceBoundaryResponse { 1648 serviceBoundary, commonResponsePattern 1649 } 1650 } 1652 ## 1653 ## A pattern common to some of the queries. 1654 ## 1655 div { 1656 commonRequestPattern = service, path?, extensionPoint 1657 } 1659 ## 1660 ## A pattern common to responses. 1661 ## 1662 div { 1663 commonResponsePattern = warnings*, path, extensionPoint 1664 } 1666 ## 1667 ## Location in Requests 1668 ## 1669 div { 1670 requestLocation = 1671 element location { 1672 attribute id { xsd:token }, 1673 locationInformation 1674 }+ 1675 } 1677 ## 1678 ## Location Information 1679 ## 1680 div { 1681 locationInformation = 1682 extensionPoint+, 1683 attribute profile { xsd:NMTOKEN }? 1684 } 1686 ## 1687 ## Service Boundary 1688 ## 1689 div { 1690 serviceBoundary = element serviceBoundary { locationInformation }+ 1691 } 1693 ## 1694 ## Service Boundary Reference 1695 ## 1696 div { 1697 serviceBoundaryReference = 1698 element serviceBoundaryReference { 1699 source, serviceBoundaryKey, extensionPoint 1700 } 1701 serviceBoundaryKey = attribute key { xsd:token } 1702 } 1704 ## 1705 ## Path - 1706 ## Contains a list of via elements - 1707 ## places through which information flowed 1708 ## 1709 div { 1710 path = 1711 element path { 1712 element via { source, extensionPoint }+ 1713 } 1714 } 1716 ## 1717 ## Location Used 1718 ## 1719 div { 1720 locationUsed = 1721 element locationUsed { 1722 attribute id { xsd:token } 1723 }? 1724 } 1726 ## 1727 ## Expires pattern 1728 ## 1729 div { 1730 expires = 1731 attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } 1732 } 1734 ## 1735 ## A QName list 1736 ## 1737 div { 1738 qnameList = list { xsd:QName* } 1739 } 1741 ## 1742 ## A location-to-service mapping. 1743 ## 1744 div { 1745 mapping = 1746 element mapping { 1747 element displayName { 1748 xsd:string, 1749 attribute xml:lang { xsd:language } 1750 }*, 1751 service, 1752 (serviceBoundary | serviceBoundaryReference)?, 1753 element uri { xsd:anyURI }*, 1754 element serviceNumber { 1755 xsd:token { pattern = "[0-9*#]+" } 1756 }?, 1757 extensionPoint, 1758 expires, 1759 attribute lastUpdated { xsd:dateTime }, 1760 source, 1761 attribute sourceId { xsd:token }, 1762 message 1763 } 1764 } 1766 ## 1767 ## Location validation 1768 ## 1769 div { 1770 locationValidation = 1771 element locationValidation { 1772 element valid { qnameList }?, 1773 element invalid { qnameList }?, 1774 element unchecked { qnameList }?, 1775 extensionPoint 1776 } 1777 } 1779 ## 1780 ## Errors and Warnings Container. 1781 ## 1782 div { 1783 exceptionContainer = 1784 (badRequest? 1785 & internalError? 1786 & serviceSubstitution? 1787 & defaultMappingReturned? 1788 & forbidden? 1789 & notFound? 1790 & loop? 1791 & serviceNotImplemented? 1792 & serverTimeout? 1793 & serverError? 1794 & locationInvalid? 1795 & locationProfileUnrecognized?), 1796 extensionPoint, 1797 source 1798 errors = element errors { exceptionContainer } 1799 warnings = element warnings { exceptionContainer } 1800 } 1802 ## 1803 ## Basic Exceptions 1804 ## 1805 div { 1807 ## 1808 ## Exception pattern. 1809 ## 1810 basicException = message, extensionPoint 1811 badRequest = element badRequest { basicException } 1812 internalError = element internalError { basicException } 1813 serviceSubstitution = element serviceSubstitution { basicException } 1814 defaultMappingReturned = 1815 element defaultMappingReturned { basicException } 1816 forbidden = element forbidden { basicException } 1817 notFound = element notFound { basicException } 1818 loop = element loop { basicException } 1819 serviceNotImplemented = 1820 element serviceNotImplemented { basicException } 1821 serverTimeout = element serverTimeout { basicException } 1822 serverError = element serverError { basicException } 1823 locationInvalid = element locationInvalid { basicException } 1824 locationValidationUnavailable = 1825 element locationValidationUnavailable { basicException } 1826 locationProfileUnrecognized = 1827 element locationProfileUnrecognized { 1828 attribute unsupportedProfiles { xsd:NMTOKENS }, 1829 basicException 1830 } 1831 } 1833 ## 1834 ## Redirect. 1835 ## 1836 div { 1838 ## 1839 ## Redirect pattern 1840 ## 1841 redirect = 1842 element redirect { 1843 attribute target { appUniqueString }, 1844 source, 1845 message, 1846 extensionPoint 1847 } 1848 } 1850 ## 1851 ## Some common patterns. 1852 ## 1853 div { 1854 message = 1855 (attribute message { xsd:token }, 1856 attribute xml:lang { xsd:language })? 1857 service = element service { xsd:anyURI }? 1858 appUniqueString = 1859 xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } 1860 source = attribute source { appUniqueString } 1861 serviceList = 1862 element serviceList { 1863 list { xsd:anyURI* } 1864 } 1865 } 1867 ## 1868 ## Patterns for inclusion of elements from schemas in 1869 ## other namespaces. 1870 ## 1871 div { 1873 ## 1874 ## Any element not in the LoST namespace. 1875 ## 1876 notLost = element * - (ns1:* | ns1:*) { anyElement } 1878 ## 1879 ## A wildcard pattern for including any element 1880 ## from any other namespace. 1881 ## 1882 anyElement = 1883 (element * { anyElement } 1884 | attribute * { text } 1885 | text)* 1887 ## 1888 ## A point where future extensions 1889 ## (elements from other namespaces) 1890 ## can be added. 1891 ## 1892 extensionPoint = notLost* 1893 } 1895 Figure 20: RelaxNG schema 1897 16. Internationalization Considerations 1899 The LoST protocol is mostly meant for machine-to-machine 1900 communications; as such, most of its elements are tokens not meant 1901 for direct human consumption. If these tokens are presented to the 1902 end user, some localization may need to occur. The content of the 1903 element and the 'message' attributes may be displayed 1904 to the end user, and they are thus complex types designed for this 1905 purpose. 1907 LoST exchanges information using XML. All XML processors are 1908 required to understand UTF-8 and UTF-16 encodings, and therefore all 1909 LoST clients and servers MUST understand UTF-8 and UTF-16 encoded 1910 XML. Additionally, LoST servers and clients MUST NOT encode XML with 1911 encodings other than UTF-8 or UTF-16. 1913 17. IANA Considerations 1915 17.1. U-NAPTR Registrations 1917 This document registers the following U-NAPTR application service 1918 tag: 1920 Application Service Tag: LoST 1922 Defining Publication: The specification contained within this 1923 document. 1925 This document registers the following U-NAPTR application protocol 1926 tags: 1928 o 1930 Application Protocol Tag: http 1932 Defining Publication: RFC 2616 [3] 1934 o 1936 Application Protocol Tag: https 1938 Defining Publication: RFC 2818 [4] 1940 17.2. Content-type registration for 'application/lost+xml' 1942 This specification requests the registration of a new MIME type 1943 according to the procedures of RFC 4288 [7] and guidelines in RFC 1944 3023 [5]. 1946 MIME media type name: application 1948 MIME subtype name: lost+xml 1950 Mandatory parameters: none 1952 Optional parameters: charset 1954 Indicates the character encoding of enclosed XML. 1956 Encoding considerations: Uses XML, which can employ 8-bit 1957 characters, depending on the character encoding used. See RFC 1958 3023 [5], Section 3.2. 1960 Security considerations: This content type is designed to carry LoST 1961 protocol payloads. 1963 Interoperability considerations: None 1965 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 1966 replace XXXX with the RFC number of this specification.] 1968 Applications which use this media type: Emergency and Location-based 1969 Systems 1971 Additional information: 1973 Magic Number: None 1975 File Extension: .lostxml 1977 Macintosh file type code: 'TEXT' 1979 Personal and email address for further information: Hannes 1980 Tschofenig, Hannes.Tschofenig@nsn.com 1982 Intended usage: LIMITED USE 1984 Author: 1986 This specification is a work item of the IETF ECRIT working group, 1987 with mailing list address . 1989 Change controller: 1991 The IESG 1993 17.3. LoST Relax NG Schema Registration 1995 URI: urn:ietf:params:xml:schema:lost1 1997 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1998 (Hannes.Tschofenig@nsn.com). 2000 Relax NG Schema: The Relax NG schema to be registered is contained 2001 in Section 15. Its first line is 2003 default namespace = "urn:ietf:params:xml:ns:lost1" 2005 and its last line is 2007 } 2009 17.4. LoST Namespace Registration 2011 URI: urn:ietf:params:xml:ns:lost1 2013 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 2014 (Hannes.Tschofenig@nsn.com). 2016 XML: 2018 BEGIN 2019 2020 2022 2023 2024 2026 LoST Namespace 2027 2028 2029

Namespace for LoST

2030

urn:ietf:params:xml:ns:lost1

2031

See RFCXXXX 2032 [NOTE TO IANA/RFC-EDITOR: 2033 Please replace XXXX with the RFC number of this 2034 specification.].

2035 2036 2037 END 2039 17.5. LoST Location Profile Registry 2041 This document seeks to create a registry of location profile names 2042 for the LoST protocol. Profile names are XML tokens. This registry 2043 will operate in accordance with RFC 2434 [2], Standards Action. 2045 geodetic-2d: 2047 Defined in Section 12.2. 2049 civic: 2051 Defined in Section 12.3. 2053 18. Security Considerations 2055 There are several threats to the overall system of which service 2056 mapping forms a part. An attacker that can obtain service contact 2057 URIs can use those URIs to attempt to disrupt those services. An 2058 attacker that can prevent the lookup of contact URIs can impair the 2059 reachability of such services. An attacker that can eavesdrop on the 2060 communication requesting this lookup can surmise the existence of an 2061 emergency and possibly its nature, and may be able to use this to 2062 launch a physical attack on the caller. 2064 To avoid an attacker modifying the query or its result, TLS MUST be 2065 implemented and SHOULD be used. Use is RECOMMENDED both for clients' 2066 queries to servers and for queries among servers; this latter 2067 recommendation is to help avoid LoST cache poisoning attacks by 2068 replacing answers given to caching LoST servers. 2070 The use of server identity checks with TLS, as described in Section 2071 3.1 of [4] is also RECOMMENDED. Omitting the server identity check 2072 allows an attacker to masquerade as a LoST server, so this approach 2073 should be used only when getting any answer, even from a potentially 2074 malicious LoST server, is preferred over closing the connection (and 2075 thus not getting any answer at all). The host name compared against 2076 the server certificate is the host name in the URI, not the DNS name 2077 used as input to NAPTR resolution. 2079 Note that the security considerations in [22] recommend comparing the 2080 input of NAPTR resolution to the certificate, not the output (host 2081 name in the URI). This approach was not chosen because in emergency 2082 service use cases, it is likely that deployments will see a large 2083 number of inputs to the U-NAPTR algorithm resolving to a single 2084 server, typically run by a local emergency services authority. In 2085 this case, checking the input to the NAPTR resolution against the 2086 certificates provided by the LoST server would be impractical, as the 2087 list of organizations using it would be large, subject to rapid 2088 change, and unknown to the LoST server operator. 2090 The use of server identity does leave open the possibility of DNS 2091 based attacks, as the NAPTR records may be altered by an attacker. he 2092 attacks include, for example, interception of DNS packets between the 2093 client and the recursive name server, DNS cache poisoning, and 2094 intentional modifications by the recursive name server; see [23] for 2095 more comprehensive discussion. 2097 DNSSEC [20] can be used to protect against these threats. While 2098 DNSSEC is incompletely deployed, users should be aware of the risk, 2099 particularly when they are requesting NAPTR records in environments 2100 where the local recursive name server, or the network between the 2101 client and the local recursive name server, is not considered 2102 trustworthy. 2104 LoST deployments which are unable to use DNSSEC and unwilling to 2105 trust DNS resolution without DNSSEC, cannot use the NATPR-based 2106 discovery of LoST servers as-is. When suitable configuration 2107 mechanisms are available, one possibility is to configure the LoST 2108 server URIs (instead of the domain name to be used for NAPTR 2109 resolution) directly. Future specifications for applying LoST in 2110 non-emergency services may also specify additional discovery 2111 mechanisms and name matching semantics. 2113 Generally, LoST servers will not need to authenticate or authorize 2114 clients presenting mapping queries. If they do, an authentication of 2115 the underlying transport mechanism, such as HTTP basic and digest 2116 authentication MAY be used. Basic Authentication SHOULD only be used 2117 in combination with TLS. 2119 A more detailed description of threats and security requirements are 2120 provided in [17]. The threats and security requirements in non- 2121 emergency service uses of LoST may be considerably different from 2122 those described here. For example, an attacker might seek monetary 2123 benefit by returning service mapping information which directed users 2124 to specific service providers. Before deploying LoST in new 2125 contexts, a thorough analysis of the threats and requirements 2126 specific to that context should be undertaken and decisions made on 2127 the appropriate mitigations. 2129 19. Acknowledgments 2131 We would like to the thank the following working group members for 2132 the detailed review of previous LoST document versions: 2134 o Martin Thomson (Review July 2006) 2136 o Jonathan Rosenberg (Review July 2006) 2138 o Leslie Daigle (Review September 2006) 2140 o Shida Schubert (Review November 2006) 2142 o Martin Thomson (Review December 2006) 2144 o Barbara Stark (Review January 2007) 2146 o Patrik Faeltstroem (Review January 2007 2148 o Shida Schubert (Review January 2007 as a designated expert 2149 reviewer) 2151 o Jonathan Rosenberg (Review February 2007) 2153 o Tom Taylor (Review February 2007) 2155 o Theresa Reese (Review February 2007) 2157 o Shida Schubert (Review February 2007) 2159 o James Winterbottom (Review July 2007) 2161 We would also like to thank the following working group members for 2162 their input to selected design aspects of the LoST protocol: 2164 o Leslie Daigle and Martin Thomson (DNS-based LoST discovery 2165 procedure) 2167 o John Schnizlein (authoritive LoST answers) 2169 o Rohan Mahy (display names) 2171 o James Polk (error handling) 2173 o Ron Watro and Richard Barnes (expiry of cached data) 2175 o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James 2176 Winterbottom (Indication of PSAP Confidence Level) 2178 o Martin Thomson (service boundary references) 2180 o Martin Thomson (service URN in LoST response message) 2182 o Clive D.W. Feather, Martin Thomson (Validation Functionality) 2184 o Roger Marshall (PSAP Preference in LoST response) 2186 o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, 2187 Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. 2188 Feather, Richard Stastny, John Hearty, Roger Marshall, Jean- 2189 Francois Mule, Pierre Desjardins (Location Profiles) 2191 o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson, 2192 Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, 2193 Keith (List Services functionality) 2195 o Thomson, Martin, Michael Hammer (Mapping of Services) 2197 o Shida Schubert, James Winterbottom, Keith Drage (default service 2198 URN) 2200 o Otmar Lendl (LoST aggregation) 2202 o Tom Taylor (Terminology) 2204 Klaus Darilion and Marc Linsner provided miscellaneous input to the 2205 design of the protocol. Finally, we would like to thank Brian Rosen 2206 who participated in almost every discussion thread. 2208 Early implementation efforts lead to good feedback by two open source 2209 implementation groups. We would like to thank the implementers for 2210 their work and for helping us to improve the quality of the 2211 specification: 2213 o Wonsang Song 2215 o Jong-Yul Kim 2217 o Anna Makarowska 2219 o Krzysztof Rzecki 2221 o Blaszczyk Piotr 2223 We would like to thank Jon Peterson, Dan Romascanu, Lisa Dusseault, 2224 and Tim Polk for their IESG review comments. Blocking IESG comments 2225 were also received from Pasi Eronen (succeeding Sam Hartman's review) 2226 and Cullen Jennings. Adjustments have been made to several pieces of 2227 text to satisfy these requests for changes, most notably in the 2228 Security Considerations and in the discussion of redirection in the 2229 presence of overlapping coverage areas. 2231 20. References 2233 20.1. Normative References 2235 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2236 Levels", BCP 14, RFC 2119, March 1997. 2238 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2239 Considerations Section in RFCs", BCP 26, RFC 2434, 2240 October 1998. 2242 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2243 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2244 HTTP/1.1", RFC 2616, June 1999. 2246 [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2248 [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 2249 RFC 3023, January 2001. 2251 [6] Peterson, J., "A Presence-based GEOPRIV Location Object 2252 Format", RFC 4119, December 2005. 2254 [7] Freed, N. and J. Klensin, "Media Type Specifications and 2255 Registration Procedures", BCP 13, RFC 4288, December 2005. 2257 [8] Daigle, L., "Domain-Based Application Service Location Using 2258 URIs and the Dynamic Delegation Discovery Service (DDDS)", 2259 RFC 4848, April 2007. 2261 [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 2262 and Other Well-Known Services", draft-ietf-ecrit-service-urn-07 2263 (work in progress), August 2007. 2265 [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 2266 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in 2267 progress), December 2007. 2269 [11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, 2270 "Geographic information - Geography Markup Language (GML)", OGC 2271 Standard OpenGIS 03-105r1, April 2004. 2273 [12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application 2274 Schema for use by the Internet Engineering Task Force (IETF)", 2275 Candidate OpenGIS Implementation Specification , December 2006. 2277 20.2. Informative References 2279 [13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 2280 PIDF-LO Usage Clarification, Considerations and 2281 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work 2282 in progress), February 2008. 2284 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2285 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2286 Session Initiation Protocol", RFC 3261, June 2002. 2288 [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence 2289 Protocol (XMPP): Instant Messaging and Presence", RFC 3921, 2290 October 2004. 2292 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 2293 December 2004. 2295 [17] Taylor, T., "Security Threats and Requirements for Emergency 2296 Call Marking and Mapping", draft-ietf-ecrit-security-threats-05 2297 (work in progress), August 2007. 2299 [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 2300 Context Resolution with Internet Technologies", 2301 draft-ietf-ecrit-requirements-13 (work in progress), 2302 March 2007. 2304 [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and 2305 Framework", draft-ietf-ecrit-mapping-arch-03 (work in 2306 progress), September 2007. 2308 [20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 2309 "DNS Security Introduction and Requirements", RFC 4033, 2310 March 2005. 2312 [21] Rosen, B. and J. Polk, "Best Current Practice for 2313 Communications Services in support of Emergency Calling", 2314 draft-ietf-ecrit-phonebcp-04 (work in progress), February 2008. 2316 [22] Daigle, L. and A. Newton, "Domain-Based Application Service 2317 Location Using SRV RRs and the Dynamic Delegation Discovery 2318 Service (DDDS)", RFC 3958, January 2005. 2320 [23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 2321 System (DNS)", RFC 3833, August 2004. 2323 URIs 2325 [24] 2328 Appendix A. Non-Normative RELAX NG Schema in XML Syntax 2330 2331 2336 2337 2338 Location-to-Service Translation Protocol (LoST) 2340 A LoST XML instance has three request types, each with 2341 a cooresponding response type: find service, list services, 2342 and get service boundary. 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2358
2359 2360 The queries. 2361 2363 2364 2365 2366 2367 2368 2369 2370 false 2371 2372 2373 2374 2375 2376 reference 2377 value 2378 2379 reference 2380 2381 2382 2383 2384 2385 false 2386 2387 2388 2389 2391 2392 2393 2394 2395 2397 2398 2399 2400 2401 2402 2403 2404 true 2405 2406 2407 2408 2410 2411 2412 2413 2414 2415 2417
2419
2420 2421 The responses. 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2436 2437 2438 2439 2440 2441 2443 2444 2445 2446 2447 2448 2449 2451 2452 2453 2454 2455 2456 2458
2460
2461 2462 A pattern common to some of the queries. 2463 2465 2466 2467 2468 2470 2471 2472 2473
2475
2476 2477 A pattern common to responses. 2478 2480 2481 2482 2483 2484 2485 2486 2487
2489
2490 2491 Location in Requests 2492 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504
2506
2507 2508 Location Information 2509 2511 2512 2513 2514 2515 2516 2517 2519 2520 2521 2522
2524
2525 2526 Service Boundary 2527 2529 2530 2531 2532 2533 2534 2535 2536
2538
2539 2540 Service Boundary Reference 2541 2543 2545 2546 2547 2548 2549 2550 2552 2553 2554 2555 2556 2558
2560
2561 2562 Path - 2563 Contains a list of via elements - 2564 places through which information flowed 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576
2578
2579 2580 Location Used 2581 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592
2594
2595 2596 Expires pattern 2597 2599 2600 2601 2602 2603 NO-CACHE 2604 NO-EXPIRATION 2605 2606 2607 2608
2610
2611 2612 A QName list 2613 2614 2615 2616 2617 2618 2619 2620 2621
2623
2624 2625 A location-to-service mapping. 2626 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 [0-9*#]+ 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2670
2672
2673 2674 Location validation 2675 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697
2699
2700 2701 Errors and Warnings Container. 2702 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2747 2748 2749 2750 2751 2753 2754 2755 2756 2757 2759
2761
2762 2763 Basic Exceptions 2764 2766 2767 2768 Exception pattern. 2769 2770 2771 2772 2774 2775 2776 2777 2778 2780 2781 2782 2783 2784 2786 2787 2788 2789 2790 2792 2793 2794 2795 2796 2798 2799 2800 2801 2802 2804 2805 2806 2808 2809 2811 2812 2813 2814 2815 2817 2818 2819 2820 2821 2823 2824 2825 2826 2827 2829 2830 2831 2832 2833 2835 2836 2837 2838 2839 2841 2842 2843 2844 2845 2847 2848 2849 2850 2851 2852 2853 2854 2856
2858
2859 2860 Redirect. 2861 2863 2864 2865 Redirect pattern 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2877
2879
2880 2881 Some common patterns. 2882 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 ([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+ 2907 2908 2910 2911 2912 2913 2914 2916 2917 2918 2919 2920 2921 2922 2923 2924 2926
2928
2929 2930 Patterns for inclusion of elements from schemas in 2931 other namespaces. 2932 2934 2935 2936 Any element not in the LoST namespace. 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2949 2950 2951 A wildcard pattern for including any element 2952 from any other namespace. 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2968 2969 2970 A point where future extensions 2971 (elements from other namespaces) 2972 can be added. 2973 2974 2975 2976 2977 2979
2981
2983 Figure 21 2985 Appendix B. Examples On-line 2987 The XML examples and Relax NG schemas may be found on-line [24]. 2989 Authors' Addresses 2991 Ted Hardie 2992 Qualcomm, Inc. 2994 Email: hardie@qualcomm.com 2996 Andrew Newton 2997 American Registry for Internet Numbers 2998 3635 Concorde Parkway, Suite 200 2999 Chantilly, VA 20151 3000 US 3002 Phone: +1 703 227 9894 3003 Email: andy@hxr.us 3005 Henning Schulzrinne 3006 Columbia University 3007 Department of Computer Science 3008 450 Computer Science Building 3009 New York, NY 10027 3010 US 3012 Phone: +1 212 939 7004 3013 Email: hgs+ecrit@cs.columbia.edu 3014 URI: http://www.cs.columbia.edu 3016 Hannes Tschofenig 3017 Nokia Siemens Networks 3018 Linnoitustie 6 3019 Espoo 02600 3020 Finland 3022 Phone: +358 (50) 4871445 3023 Email: Hannes.Tschofenig@nsn.com 3024 URI: http://www.tschofenig.priv.at 3026 Full Copyright Statement 3028 Copyright (C) The IETF Trust (2008). 3030 This document is subject to the rights, licenses and restrictions 3031 contained in BCP 78, and except as set forth therein, the authors 3032 retain all their rights. 3034 This document and the information contained herein are provided on an 3035 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3036 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3037 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3038 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3039 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3040 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3042 Intellectual Property 3044 The IETF takes no position regarding the validity or scope of any 3045 Intellectual Property Rights or other rights that might be claimed to 3046 pertain to the implementation or use of the technology described in 3047 this document or the extent to which any license under such rights 3048 might or might not be available; nor does it represent that it has 3049 made any independent effort to identify any such rights. Information 3050 on the procedures with respect to rights in RFC documents can be 3051 found in BCP 78 and BCP 79. 3053 Copies of IPR disclosures made to the IETF Secretariat and any 3054 assurances of licenses to be made available, or the result of an 3055 attempt made to obtain a general license or permission for the use of 3056 such proprietary rights by implementers or users of this 3057 specification can be obtained from the IETF on-line IPR repository at 3058 http://www.ietf.org/ipr. 3060 The IETF invites any interested party to bring to its attention any 3061 copyrights, patents or patent applications, or other proprietary 3062 rights that may cover technology that may be required to implement 3063 this standard. Please address the information to the IETF at 3064 ietf-ipr@ietf.org.