idnits 2.17.1 draft-ietf-ecrit-lost-09.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 2998. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3009. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3016. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3022. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 28, 2008) is 5873 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: September 29, 2008 American Registry for Internet 6 Numbers 7 H. Schulzrinne 8 Columbia University 9 H. Tschofenig 10 Nokia Siemens Networks 11 March 28, 2008 13 LoST: A Location-to-Service Translation Protocol 14 draft-ietf-ecrit-lost-09.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 September 29, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 59 109 20.1. Normative References . . . . . . . . . . . . . . . . . . . 59 110 20.2. Informative References . . . . . . . . . . . . . . . . . . 60 111 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 61 112 Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 75 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 114 Intellectual Property and Copyright Statements . . . . . . . . . . 77 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. 1315 When geodetic location information of this location profile is placed 1316 in the element then the elements with geospatial 1317 coordinates are alternative descriptions of the same service region, 1318 not additive geometries. 1320 12.3. Basic Civic Profile 1322 The basic-civic location profile is identified by the token 'civic'. 1323 Clients use this profile by placing a element, defined 1324 in [10], within the element. 1326 Servers use this profile by placing a element, defined 1327 in [10], within the element. 1329 A response MAY contain more than one element with 1330 profile 'civic'. Each element describes a set of 1331 civic addresses that fall within the service boundary, namely all 1332 addresses that textually match the civic address elements provided, 1333 regardless of the value of other address elements. A location falls 1334 within the mapping's service boundary if it matches any of the 1335 elements. Hence, a response may contain multiple 1336 elements with civic and/or geodetic location 1337 profiles. 1339 13. Errors, Warnings, and Redirects 1341 When a LoST server cannot fulfill a request completely, it can return 1342 either an error or a warning, depending on the severity of the 1343 problem. It returns an error element if no useful response can be 1344 returned for the query. It returns a element as part of 1345 another response element if it was able to respond in part, but the 1346 response may not be quite what the client had desired. For both 1347 elements, the 'source' attribute names the server that originally 1348 generated the error or warning, such as the authoritative server. 1349 Unless otherwise noted, all elements below can be either an error or 1350 a warning, depending on whether a default response, such as a 1351 mapping, is included. 1353 13.1. Errors 1355 LoST defines a pattern for errors, defined as elements in 1356 the Relax NG schema. This pattern defines a 'message' attribute 1357 containing human readable text and an 'xml:lang' attribute denoting 1358 the language of the human readable text. One or more such error 1359 elements are contained in the element. 1361 The following errors follow this basic pattern: 1363 badRequest 1365 The server could not parse or otherwise understand a request, 1366 e.g., because the XML was malformed. 1368 forbidden 1370 The server refused to send an answer. This generally only occurs 1371 for recursive queries, namely if the client tried to contact the 1372 authoritative server and was refused. 1374 internalError 1376 The server could not satisfy a request due to misconfiguration or 1377 other operational and non-protocol related reasons. 1379 locationProfileUnrecognized 1381 None of the profiles in the request were recognized by the server 1382 (see Section 12). 1384 locationInvalid 1386 The geodetic or civic location in the request was invalid. For 1387 example, the longitude or latitude values fall outside the 1388 acceptable ranges. 1390 SRSInvalid 1392 The spatial reference system (SRS) contained in the location 1393 element was not recognized or does not match the location profile. 1395 loop 1397 During a recursive query, the server was about to visit a server 1398 that was already in the server list in the element, 1399 indicating a request loop. 1401 notFound 1403 The server could not find an answer to the query. 1405 serverError 1407 An answer was received from another LoST server, but it could not 1408 be parsed or otherwise understood. This error occurs only for 1409 recursive queries. 1411 serverTimeout 1413 A time out occurred before an answer was received. 1415 serviceNotImplemented 1417 The requested service URN is not implemented and no substitution 1418 was available. 1420 An example is below: 1422 1423 1425 1426 1428 Figure 17: Example of an error resonse 1430 13.2. Warnings 1432 A response MAY contain zero or more warnings. This pattern defines a 1433 'message' attribute containing human readable text and an 'xml:lang' 1434 attribute denoting the language of the human readable text. One or 1435 more such warning elements are contained in the element. 1436 To provide human readable text in an appropriate language the HTTP 1437 content negotiation capabilities (see Section 14) MAY be utilized by 1438 a server. 1440 This version of the specification defines the following warnings: 1442 locationValidationUnavailable 1444 The element MAY be returned when a 1445 server wishes to notify a client that it cannot fulfill a location 1446 validation request. This warning allows a server to return 1447 mapping information while signalling this exception state. 1449 serviceSubstitution 1451 The element MAY be returned when a server 1452 was not able to fulfill a request for a given 1453 service URN. For example, a request with the 1454 'urn:service:sos.police' service URN for a location in Uruguay may 1455 cause the LoST service to return a mapping for the 1456 'urn:service:sos' service URN since Uruguay does not make use of 1457 the sub-services police, fire and ambulance. If this warning is 1458 returned then the element in the response provides 1459 information about the service URN that refers to the mapping. 1461 defaultMappingReturned 1463 The element MAY be returned when a server 1464 was not able to fulfill a request for a given 1465 location but is able to respond with a default URI. For example, 1466 a nearby PSAP may be returned. 1468 An example of a warning is shown below: 1470 1471 1473 1478 1479 New York City Police Department 1480 1481 urn:service:sos.police 1482 1483 1484 1485 1486 37.775 -122.4194 1487 37.555 -122.4194 1488 37.555 -122.4264 1489 37.775 -122.4264 1490 37.775 -122.4194 1491 1492 1493 1494 1495 sip:nypd@example.com 1496 1497 1498 1502 1503 1504 1505 1506 1507 1509 Figure 18: Example of an warning resonse 1511 13.3. Redirects 1513 A LoST server can respond indicating that the querier should redirect 1514 the query to another server, using the element. The 1515 element includes a 'target' attribute indicating the LoST application 1516 unique string (see Section 4) that the client SHOULD be contacting 1517 next, as well as the 'source' attribute indicating the server that 1518 generated the redirect response and a 'message' attribute explaining 1519 the reason for the redirect response. During a recursive query, a 1520 server receiving a response can decide whether it wants to 1521 follow the redirection or simply return the response to its upstream 1522 querier. The "expires" value in the response returned by the server 1523 handling the redirected query indicates the earliest time at which a 1524 new query might be needed (see section 5.2). The query for the same 1525 tuple of location and service SHOULD NOT be directed to the server 1526 which gave redirect prior to that time. 1528 An example is below: 1530 1531 1536 Figure 19: Example of a redirect response 1538 14. LoST Transport: HTTP 1540 LoST needs an underlying protocol transport mechanisms to carry 1541 requests and responses. This document defines the use of LoST over 1542 HTTP and LoST over HTTP-over-TLS. Client and server developers are 1543 reminded that full support of RFC 2616 HTTP facilities is expected. 1544 If LoST clients or servers re-implement HTTP, rather than using 1545 available servers or client code as a base, careful attention must be 1546 paid to full interoperability. Other transport mechanisms are left 1547 to future documents. The available transport mechanisms are 1548 determined through the use of the LoST U-NAPTR application. In 1549 protocols that support content type indication, LoST uses the media 1550 type application/lost+xml. 1552 When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP 1553 POST method. The HTTP request MUST use the Cache-Control response 1554 directive "no-cache" to HTTP-level caching even by caches that have 1555 been configured to return stale responses to client requests. 1557 All LoST responses, including those indicating a LoST warning or 1558 error, are carried in 2xx responses, typically 200 (OK). Other 2xx 1559 responses, in particular 203 (Non-authoritative information) may be 1560 returned by HTTP caches that disregard the caching instructions. 3xx, 1561 4xx and 5xx HTTP response codes indicates that the HTTP request 1562 itself failed or was redirected; these responses do not contain any 1563 LoST XML elements. The 3xx responses are distinct from the redirects 1564 which are described in Section 13.3; the 13.3 redirects occur after a 1565 LoST server processes the request. Where an HTTP-layer redirect will 1566 be general, a LoST server redirect as described in 13.3 might be 1567 specific to a specific service or be the result of other processing 1568 by the LoST server. 1570 The HTTP URL is derived from the LoST server name via U-NAPTR 1571 application, as discussed above. 1573 15. Relax NG Schema 1575 This section provides the Relax NG schema used by LoST protocol in 1576 the compact form. The verbose form is included in Appendix A. 1578 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 1579 default namespace ns1 = "urn:ietf:params:xml:ns:lost1" 1581 ## 1582 ## Location-to-Service Translation Protocol (LoST) 1583 ## 1584 ## A LoST XML instance has three request types, each with 1585 ## a cooresponding response type: find service, list services, 1586 ## and get service boundary. 1587 ## 1588 start = 1589 findService 1590 | listServices 1591 | listServicesByLocation 1592 | getServiceBoundary 1593 | findServiceResponse 1594 | listServicesResponse 1595 | listServicesByLocationResponse 1596 | getServiceBoundaryResponse 1597 | errors 1598 | redirect 1600 ## 1601 ## The queries. 1602 ## 1603 div { 1604 findService = 1605 element findService { 1606 requestLocation, 1607 commonRequestPattern, 1608 attribute validateLocation { 1609 xsd:boolean >> a:defaultValue [ "false" ] 1610 }?, 1611 attribute serviceBoundary { 1612 ("reference" | "value") >> a:defaultValue [ "reference" ] 1613 }?, 1614 attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? 1615 } 1616 listServices = element listServices { commonRequestPattern } 1617 listServicesByLocation = 1618 element listServicesByLocation { 1619 requestLocation, 1620 commonRequestPattern, 1621 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 1622 } 1623 getServiceBoundary = 1624 element getServiceBoundary { serviceBoundaryKey, extensionPoint } 1625 } 1627 ## 1628 ## The responses. 1629 ## 1630 div { 1631 findServiceResponse = 1632 element findServiceResponse { 1633 mapping+, locationValidation?, commonResponsePattern, locationUsed 1634 } 1635 listServicesResponse = 1636 element listServicesResponse { serviceList, commonResponsePattern } 1637 listServicesByLocationResponse = 1638 element listServicesByLocationResponse { 1639 serviceList, commonResponsePattern, locationUsed 1640 } 1641 getServiceBoundaryResponse = 1642 element getServiceBoundaryResponse { 1643 serviceBoundary, commonResponsePattern 1644 } 1645 } 1647 ## 1648 ## A pattern common to some of the queries. 1649 ## 1650 div { 1651 commonRequestPattern = service, path?, extensionPoint 1652 } 1654 ## 1655 ## A pattern common to responses. 1656 ## 1657 div { 1658 commonResponsePattern = warnings*, path, extensionPoint 1659 } 1661 ## 1662 ## Location in Requests 1663 ## 1664 div { 1665 requestLocation = 1666 element location { 1667 attribute id { xsd:token }, 1668 locationInformation 1669 }+ 1670 } 1672 ## 1673 ## Location Information 1674 ## 1675 div { 1676 locationInformation = 1677 extensionPoint+, 1678 attribute profile { xsd:NMTOKEN }? 1679 } 1681 ## 1682 ## Service Boundary 1683 ## 1684 div { 1685 serviceBoundary = element serviceBoundary { locationInformation }+ 1686 } 1688 ## 1689 ## Service Boundary Reference 1690 ## 1691 div { 1692 serviceBoundaryReference = 1693 element serviceBoundaryReference { 1694 source, serviceBoundaryKey, extensionPoint 1695 } 1696 serviceBoundaryKey = attribute key { xsd:token } 1697 } 1699 ## 1700 ## Path - 1701 ## Contains a list of via elements - 1702 ## places through which information flowed 1703 ## 1704 div { 1705 path = 1706 element path { 1707 element via { source, extensionPoint }+ 1708 } 1709 } 1711 ## 1712 ## Location Used 1713 ## 1714 div { 1715 locationUsed = 1716 element locationUsed { 1717 attribute id { xsd:token } 1718 }? 1719 } 1721 ## 1722 ## Expires pattern 1723 ## 1724 div { 1725 expires = 1726 attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } 1727 } 1729 ## 1730 ## A QName list 1731 ## 1732 div { 1733 qnameList = list { xsd:QName* } 1734 } 1736 ## 1737 ## A location-to-service mapping. 1738 ## 1739 div { 1740 mapping = 1741 element mapping { 1742 element displayName { 1743 xsd:string, 1744 attribute xml:lang { xsd:language } 1745 }*, 1746 service, 1747 (serviceBoundary | serviceBoundaryReference)?, 1748 element uri { xsd:anyURI }*, 1749 element serviceNumber { 1750 xsd:token { pattern = "[0-9*#]+" } 1751 }?, 1752 extensionPoint, 1753 expires, 1754 attribute lastUpdated { xsd:dateTime }, 1755 source, 1756 attribute sourceId { xsd:token }, 1757 message 1758 } 1759 } 1761 ## 1762 ## Location validation 1763 ## 1764 div { 1765 locationValidation = 1766 element locationValidation { 1767 element valid { qnameList }?, 1768 element invalid { qnameList }?, 1769 element unchecked { qnameList }?, 1770 extensionPoint 1771 } 1772 } 1774 ## 1775 ## Errors and Warnings Container. 1776 ## 1777 div { 1778 exceptionContainer = 1779 (badRequest? 1780 & internalError? 1781 & serviceSubstitution? 1782 & defaultMappingReturned? 1783 & forbidden? 1784 & notFound? 1785 & loop? 1786 & serviceNotImplemented? 1787 & serverTimeout? 1788 & serverError? 1789 & locationInvalid? 1790 & locationProfileUnrecognized?), 1791 extensionPoint, 1792 source 1793 errors = element errors { exceptionContainer } 1794 warnings = element warnings { exceptionContainer } 1795 } 1797 ## 1798 ## Basic Exceptions 1799 ## 1800 div { 1802 ## 1803 ## Exception pattern. 1804 ## 1805 basicException = message, extensionPoint 1806 badRequest = element badRequest { basicException } 1807 internalError = element internalError { basicException } 1808 serviceSubstitution = element serviceSubstitution { basicException } 1809 defaultMappingReturned = 1810 element defaultMappingReturned { basicException } 1811 forbidden = element forbidden { basicException } 1812 notFound = element notFound { basicException } 1813 loop = element loop { basicException } 1814 serviceNotImplemented = 1815 element serviceNotImplemented { basicException } 1816 serverTimeout = element serverTimeout { basicException } 1817 serverError = element serverError { basicException } 1818 locationInvalid = element locationInvalid { basicException } 1819 locationValidationUnavailable = 1820 element locationValidationUnavailable { basicException } 1821 locationProfileUnrecognized = 1822 element locationProfileUnrecognized { 1823 attribute unsupportedProfiles { xsd:NMTOKENS }, 1824 basicException 1825 } 1826 } 1828 ## 1829 ## Redirect. 1830 ## 1831 div { 1833 ## 1834 ## Redirect pattern 1835 ## 1836 redirect = 1837 element redirect { 1838 attribute target { appUniqueString }, 1839 source, 1840 message, 1841 extensionPoint 1842 } 1843 } 1845 ## 1846 ## Some common patterns. 1847 ## 1848 div { 1849 message = 1850 (attribute message { xsd:token }, 1851 attribute xml:lang { xsd:language })? 1852 service = element service { xsd:anyURI }? 1853 appUniqueString = 1854 xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } 1855 source = attribute source { appUniqueString } 1856 serviceList = 1857 element serviceList { 1858 list { xsd:anyURI* } 1859 } 1860 } 1862 ## 1863 ## Patterns for inclusion of elements from schemas in 1864 ## other namespaces. 1865 ## 1866 div { 1868 ## 1869 ## Any element not in the LoST namespace. 1870 ## 1871 notLost = element * - (ns1:* | ns1:*) { anyElement } 1873 ## 1874 ## A wildcard pattern for including any element 1875 ## from any other namespace. 1876 ## 1877 anyElement = 1878 (element * { anyElement } 1879 | attribute * { text } 1880 | text)* 1882 ## 1883 ## A point where future extensions 1884 ## (elements from other namespaces) 1885 ## can be added. 1886 ## 1887 extensionPoint = notLost* 1888 } 1890 Figure 20: RelaxNG schema 1892 16. Internationalization Considerations 1894 The LoST protocol is mostly meant for machine-to-machine 1895 communications; as such, most of its elements are tokens not meant 1896 for direct human consumption. If these tokens are presented to the 1897 end user, some localization may need to occur. The content of the 1898 element and the 'message' attributes may be displayed 1899 to the end user, and they are thus complex types designed for this 1900 purpose. 1902 LoST exchanges information using XML. All XML processors are 1903 required to understand UTF-8 and UTF-16 encodings, and therefore all 1904 LoST clients and servers MUST understand UTF-8 and UTF-16 encoded 1905 XML. Additionally, LoST servers and clients MUST NOT encode XML with 1906 encodings other than UTF-8 or UTF-16. 1908 17. IANA Considerations 1910 17.1. U-NAPTR Registrations 1912 This document registers the following U-NAPTR application service 1913 tag: 1915 Application Service Tag: LoST 1917 Defining Publication: The specification contained within this 1918 document. 1920 This document registers the following U-NAPTR application protocol 1921 tags: 1923 o 1925 Application Protocol Tag: http 1927 Defining Publication: RFC 2616 [3] 1929 o 1931 Application Protocol Tag: https 1933 Defining Publication: RFC 2818 [4] 1935 17.2. Content-type registration for 'application/lost+xml' 1937 This specification requests the registration of a new MIME type 1938 according to the procedures of RFC 4288 [7] and guidelines in RFC 1939 3023 [5]. 1941 MIME media type name: application 1943 MIME subtype name: lost+xml 1945 Mandatory parameters: none 1947 Optional parameters: charset 1949 Indicates the character encoding of enclosed XML. 1951 Encoding considerations: Uses XML, which can employ 8-bit 1952 characters, depending on the character encoding used. See RFC 1953 3023 [5], Section 3.2. 1955 Security considerations: This content type is designed to carry LoST 1956 protocol payloads. 1958 Interoperability considerations: None 1960 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 1961 replace XXXX with the RFC number of this specification.] 1963 Applications which use this media type: Emergency and Location-based 1964 Systems 1966 Additional information: 1968 Magic Number: None 1970 File Extension: .lostxml 1972 Macintosh file type code: 'TEXT' 1974 Personal and email address for further information: Hannes 1975 Tschofenig, Hannes.Tschofenig@nsn.com 1977 Intended usage: LIMITED USE 1979 Author: 1981 This specification is a work item of the IETF ECRIT working group, 1982 with mailing list address . 1984 Change controller: 1986 The IESG 1988 17.3. LoST Relax NG Schema Registration 1990 URI: urn:ietf:params:xml:schema:lost1 1992 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1993 (Hannes.Tschofenig@nsn.com). 1995 Relax NG Schema: The Relax NG schema to be registered is contained 1996 in Section 15. Its first line is 1998 default namespace = "urn:ietf:params:xml:ns:lost1" 2000 and its last line is 2002 } 2004 17.4. LoST Namespace Registration 2006 URI: urn:ietf:params:xml:ns:lost1 2008 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 2009 (Hannes.Tschofenig@nsn.com). 2011 XML: 2013 BEGIN 2014 2015 2017 2018 2019 2021 LoST Namespace 2022 2023 2024

Namespace for LoST

2025

urn:ietf:params:xml:ns:lost1

2026

See RFCXXXX 2027 [NOTE TO IANA/RFC-EDITOR: 2028 Please replace XXXX with the RFC number of this 2029 specification.].

2030 2031 2032 END 2034 17.5. LoST Location Profile Registry 2036 This document seeks to create a registry of location profile names 2037 for the LoST protocol. Profile names are XML tokens. This registry 2038 will operate in accordance with RFC 2434 [2], Standards Action. 2040 geodetic-2d: 2042 Defined in Section 12.2. 2044 civic: 2046 Defined in Section 12.3. 2048 18. Security Considerations 2050 There are several threats to the overall system of which service 2051 mapping forms a part. An attacker that can obtain service contact 2052 URIs can use those URIs to attempt to disrupt those services. An 2053 attacker that can prevent the lookup of contact URIs can impair the 2054 reachability of such services. An attacker that can eavesdrop on the 2055 communication requesting this lookup can surmise the existence of an 2056 emergency and possibly its nature, and may be able to use this to 2057 launch a physical attack on the caller. 2059 To avoid an attacker modifying the query or its result, TLS MUST be 2060 implemented and SHOULD be used. Use is RECOMMENDED both for clients' 2061 queries to servers and for queries among servers; this latter 2062 recommendation is to help avoid LoST cache poisoning attacks by 2063 replacing answers given to caching LoST servers. The use of server 2064 identity checks is also RECOMMENDED, as described in [4] . 2066 In emergency service use cases, it is likely that deployments will 2067 see a large number of inputs to the U-NAPTR algorithm resolving to a 2068 single server. This is because local organizations will likely be 2069 permitted or even encouraged to use LoST servers provided by the 2070 local emergency services authority. This makes the use of 2071 alternatives to server identity which would check the input to the 2072 U-NAPTR algorithm against the certificates provided by the LoST 2073 server impractical, as the list of organizations using it would be 2074 large, subject to rapid change, and unknown to the LoST server 2075 operator. The use of server identity does leave open the possibility 2076 of DNS cache poisoning attacks, as the NAPTR records may be altered 2077 by an attacker. U-NAPTR recommends DNSSEC [20] as protection. While 2078 DNSSEC is incompletely deployed, users should be aware of the risk, 2079 particularly when they are requesting NAPTR records for domains or 2080 from servers with which they have no previous trust relationship. 2082 Generally, LoST servers will not need to authenticate or authorize 2083 clients presenting mapping queries. If they do, an authentication of 2084 the underlying transport mechanism, such as HTTP basic and digest 2085 authentication MAY be used. Basic Authentication SHOULD only be used 2086 in combination with TLS. 2088 A more detailed description of threats and security requirements are 2089 provided in [17]. The threats and security requirements in non- 2090 emergency service uses of LoST may be considerably different from 2091 those described here. For example, an attacker might seek monetary 2092 benefit by returning service mapping information which directed users 2093 to specific service providers. Before deploying LoST in new 2094 contexts, a thorough analysis of the threats and requirements 2095 specific to that context should be undertaken and decisions made on 2096 the appropriate mitigations. 2098 19. Acknowledgments 2100 We would like to the thank the following working group members for 2101 the detailed review of previous LoST document versions: 2103 o Martin Thomson (Review July 2006) 2105 o Jonathan Rosenberg (Review July 2006) 2107 o Leslie Daigle (Review September 2006) 2109 o Shida Schubert (Review November 2006) 2111 o Martin Thomson (Review December 2006) 2113 o Barbara Stark (Review January 2007) 2115 o Patrik Faeltstroem (Review January 2007 2117 o Shida Schubert (Review January 2007 as a designated expert 2118 reviewer) 2120 o Jonathan Rosenberg (Review February 2007) 2122 o Tom Taylor (Review February 2007) 2124 o Theresa Reese (Review February 2007) 2126 o Shida Schubert (Review February 2007) 2128 o James Winterbottom (Review July 2007) 2130 We would also like to thank the following working group members for 2131 their input to selected design aspects of the LoST protocol: 2133 o Leslie Daigle and Martin Thomson (DNS-based LoST discovery 2134 procedure) 2136 o John Schnizlein (authoritive LoST answers) 2138 o Rohan Mahy (display names) 2140 o James Polk (error handling) 2142 o Ron Watro and Richard Barnes (expiry of cached data) 2144 o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James 2145 Winterbottom (Indication of PSAP Confidence Level) 2147 o Martin Thomson (service boundary references) 2149 o Martin Thomson (service URN in LoST response message) 2151 o Cullen Jennings (service boundaries) 2153 o Clive D.W. Feather, Martin Thomson (Validation Functionality) 2155 o Roger Marshall (PSAP Preference in LoST response) 2157 o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, 2158 Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. 2159 Feather, Richard Stastny, John Hearty, Roger Marshall, Jean- 2160 Francois Mule, Pierre Desjardins (Location Profiles) 2162 o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson, 2163 Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, 2164 Keith (List Services functionality) 2166 o Thomson, Martin, Michael Hammer (Mapping of Services) 2168 o Shida Schubert, James Winterbottom, Keith Drage (default service 2169 URN) 2171 o Otmar Lendl (LoST aggregation) 2173 o Tom Taylor (Terminology) 2175 Klaus Darilion and Marc Linsner provided miscellaneous input to the 2176 design of the protocol. Finally, we would like to thank Brian Rosen 2177 who participated in almost every discussion thread. 2179 Early implementation efforts lead to good feedback by two open source 2180 implementation groups. We would like to thank the implementers for 2181 their work and for helping us to improve the quality of the 2182 specification: 2184 o Wonsang Song 2186 o Jong-Yul Kim 2188 o Anna Makarowska 2190 o Krzysztof Rzecki 2192 o Blaszczyk Piotr 2194 We would like to thank Jon Peterson for his IESG review comments. 2196 20. References 2198 20.1. Normative References 2200 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2201 Levels", BCP 14, RFC 2119, March 1997. 2203 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2204 Considerations Section in RFCs", BCP 26, RFC 2434, 2205 October 1998. 2207 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2208 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2209 HTTP/1.1", RFC 2616, June 1999. 2211 [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2213 [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 2214 RFC 3023, January 2001. 2216 [6] Peterson, J., "A Presence-based GEOPRIV Location Object 2217 Format", RFC 4119, December 2005. 2219 [7] Freed, N. and J. Klensin, "Media Type Specifications and 2220 Registration Procedures", BCP 13, RFC 4288, December 2005. 2222 [8] Daigle, L., "Domain-Based Application Service Location Using 2223 URIs and the Dynamic Delegation Discovery Service (DDDS)", 2224 RFC 4848, April 2007. 2226 [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 2227 and Other Well-Known Services", draft-ietf-ecrit-service-urn-07 2228 (work in progress), August 2007. 2230 [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 2231 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in 2232 progress), December 2007. 2234 [11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, 2235 "Geographic information - Geography Markup Language (GML)", OGC 2236 Standard OpenGIS 03-105r1, April 2004. 2238 [12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application 2239 Schema for use by the Internet Engineering Task Force (IETF)", 2240 Candidate OpenGIS Implementation Specification , December 2006. 2242 20.2. Informative References 2244 [13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 2245 PIDF-LO Usage Clarification, Considerations and 2246 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work 2247 in progress), February 2008. 2249 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2250 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2251 Session Initiation Protocol", RFC 3261, June 2002. 2253 [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence 2254 Protocol (XMPP): Instant Messaging and Presence", RFC 3921, 2255 October 2004. 2257 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 2258 December 2004. 2260 [17] Taylor, T., "Security Threats and Requirements for Emergency 2261 Call Marking and Mapping", draft-ietf-ecrit-security-threats-05 2262 (work in progress), August 2007. 2264 [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 2265 Context Resolution with Internet Technologies", 2266 draft-ietf-ecrit-requirements-13 (work in progress), 2267 March 2007. 2269 [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and 2270 Framework", draft-ietf-ecrit-mapping-arch-03 (work in 2271 progress), September 2007. 2273 [20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 2274 "DNS Security Introduction and Requirements", RFC 4033, 2275 March 2005. 2277 [21] Rosen, B. and J. Polk, "Best Current Practice for 2278 Communications Services in support of Emergency Calling", 2279 draft-ietf-ecrit-phonebcp-04 (work in progress), February 2008. 2281 URIs 2283 [22] 2286 Appendix A. Non-Normative RELAX NG Schema in XML Syntax 2288 2289 2294 2295 2296 Location-to-Service Translation Protocol (LoST) 2298 A LoST XML instance has three request types, each with 2299 a cooresponding response type: find service, list services, 2300 and get service boundary. 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2316
2317 2318 The queries. 2319 2321 2322 2323 2324 2325 2326 2327 2328 false 2329 2330 2331 2332 2333 2334 reference 2335 value 2336 2337 reference 2338 2339 2340 2341 2342 2343 false 2344 2345 2346 2347 2349 2350 2351 2352 2353 2355 2356 2357 2358 2359 2360 2361 2362 true 2363 2364 2365 2366 2368 2369 2370 2371 2372 2373 2375
2377
2378 2379 The responses. 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2394 2395 2396 2397 2398 2399 2401 2402 2403 2404 2405 2406 2407 2409 2410 2411 2412 2413 2414 2416
2418
2419 2420 A pattern common to some of the queries. 2421 2423 2424 2425 2426 2428 2429 2430 2431
2433
2434 2435 A pattern common to responses. 2436 2438 2439 2440 2441 2442 2443 2444 2445
2447
2448 2449 Location in Requests 2450 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462
2464
2465 2466 Location Information 2467 2469 2470 2471 2472 2473 2474 2475 2477 2478 2479 2480
2482
2483 2484 Service Boundary 2485 2487 2488 2489 2490 2491 2492 2493 2494
2496
2497 2498 Service Boundary Reference 2499 2501 2503 2504 2505 2506 2507 2508 2510 2511 2512 2513 2514 2516
2518
2519 2520 Path - 2521 Contains a list of via elements - 2522 places through which information flowed 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534
2536
2537 2538 Location Used 2539 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550
2552
2553 2554 Expires pattern 2555 2557 2558 2559 2560 2561 NO-CACHE 2562 NO-EXPIRATION 2563 2564 2565 2566
2568
2569 2570 A QName list 2571 2572 2573 2574 2575 2576 2577 2578 2579
2581
2582 2583 A location-to-service mapping. 2584 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 [0-9*#]+ 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2628
2630
2631 2632 Location validation 2633 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655
2657
2658 2659 Errors and Warnings Container. 2660 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2705 2706 2707 2708 2709 2711 2712 2713 2714 2715 2717
2719
2720 2721 Basic Exceptions 2722 2724 2725 2726 Exception pattern. 2727 2728 2729 2730 2732 2733 2734 2735 2736 2738 2739 2740 2741 2742 2744 2745 2746 2747 2748 2750 2751 2752 2753 2754 2756 2757 2758 2759 2760 2762 2763 2764 2766 2767 2769 2770 2771 2772 2773 2775 2776 2777 2778 2779 2781 2782 2783 2784 2785 2787 2788 2789 2790 2791 2793 2794 2795 2796 2797 2799 2800 2801 2802 2803 2805 2806 2807 2808 2809 2810 2811 2812 2814
2816
2817 2818 Redirect. 2819 2821 2822 2823 Redirect pattern 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2835
2837
2838 2839 Some common patterns. 2840 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 ([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+ 2865 2866 2868 2869 2870 2871 2872 2874 2875 2876 2877 2878 2879 2880 2881 2882 2884
2886
2887 2888 Patterns for inclusion of elements from schemas in 2889 other namespaces. 2890 2892 2893 2894 Any element not in the LoST namespace. 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2907 2908 2909 A wildcard pattern for including any element 2910 from any other namespace. 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2926 2927 2928 A point where future extensions 2929 (elements from other namespaces) 2930 can be added. 2931 2932 2933 2934 2935 2937
2939 2941 Figure 21 2943 Appendix B. Examples On-line 2945 The XML examples and Relax NG schemas may be found on-line [22]. 2947 Authors' Addresses 2949 Ted Hardie 2950 Qualcomm, Inc. 2952 Email: hardie@qualcomm.com 2954 Andrew Newton 2955 American Registry for Internet Numbers 2956 3635 Concorde Parkway, Suite 200 2957 Chantilly, VA 20151 2958 US 2960 Phone: +1 703 227 9894 2961 Email: andy@hxr.us 2963 Henning Schulzrinne 2964 Columbia University 2965 Department of Computer Science 2966 450 Computer Science Building 2967 New York, NY 10027 2968 US 2970 Phone: +1 212 939 7004 2971 Email: hgs+ecrit@cs.columbia.edu 2972 URI: http://www.cs.columbia.edu 2974 Hannes Tschofenig 2975 Nokia Siemens Networks 2976 Linnoitustie 6 2977 Espoo 02600 2978 Finland 2980 Phone: +358 (50) 4871445 2981 Email: Hannes.Tschofenig@nsn.com 2982 URI: http://www.tschofenig.priv.at 2984 Full Copyright Statement 2986 Copyright (C) The IETF Trust (2008). 2988 This document is subject to the rights, licenses and restrictions 2989 contained in BCP 78, and except as set forth therein, the authors 2990 retain all their rights. 2992 This document and the information contained herein are provided on an 2993 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2994 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2995 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2996 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2997 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2998 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3000 Intellectual Property 3002 The IETF takes no position regarding the validity or scope of any 3003 Intellectual Property Rights or other rights that might be claimed to 3004 pertain to the implementation or use of the technology described in 3005 this document or the extent to which any license under such rights 3006 might or might not be available; nor does it represent that it has 3007 made any independent effort to identify any such rights. Information 3008 on the procedures with respect to rights in RFC documents can be 3009 found in BCP 78 and BCP 79. 3011 Copies of IPR disclosures made to the IETF Secretariat and any 3012 assurances of licenses to be made available, or the result of an 3013 attempt made to obtain a general license or permission for the use of 3014 such proprietary rights by implementers or users of this 3015 specification can be obtained from the IETF on-line IPR repository at 3016 http://www.ietf.org/ipr. 3018 The IETF invites any interested party to bring to its attention any 3019 copyrights, patents or patent applications, or other proprietary 3020 rights that may cover technology that may be required to implement 3021 this standard. Please address the information to the IETF at 3022 ietf-ipr@ietf.org.