idnits 2.17.00 (12 Aug 2021) /tmp/idnits3311/draft-tschofenig-ecrit-rfc5222bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC5222, but the abstract doesn't seem to directly say this. It does mention RFC5222 though, so this could be OK. -- The draft header indicates that this document updates RFC5012, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5012, updated by this document, for RFC5378 checks: 2005-09-06) -- 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 (October 18, 2009) is 4591 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 5226 (ref. '3') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 2818 (ref. '5') ** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (ref. '8') (Obsoleted by RFC 6838) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. '16') (Obsoleted by RFC 6121) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT T. Hardie 3 Internet-Draft 4 Updates: RFC 5222, RFC 5012 A. Newton 5 (if approved) American Registry for Internet 6 Intended status: Standards Track Numbers 7 Expires: April 21, 2010 H. Schulzrinne 8 Columbia University 9 H. Tschofenig 10 Nokia Siemens Networks 11 October 18, 2009 13 LoST: A Location-to-Service Translation Protocol 14 draft-tschofenig-ecrit-rfc5222bis-00 16 Status of This Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 21, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 This document describes an XML-based protocol for mapping service 53 identifiers and geodetic or civic location information to service 54 contact URIs. In particular, it can be used to determine the 55 location-appropriate Public Safety Answering Point (PSAP) for 56 emergency services. 58 This document is a revision of the original LoST specification, 59 descrbed in RFC 5222. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Requirements Notation . . . . . . . . . . . . 5 65 3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 6 66 4. LoST Servers and Their Resolution . . . . . . . . . . . . . . 8 67 5. The Element . . . . . . . . . . . . . . . . . . . . 8 68 5.1. The Mapping Data Source: 'source', 'sourceId', and 69 'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 8 70 5.2. Mapping Validity: The 'expires' Attribute . . . . . . . . 9 71 5.3. Describing the Service with the Element . . 10 72 5.4. The Mapped Service: The Element . . . . . . . . 10 73 5.5. Defining the Service Region with the 74 Element . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.6. Service Boundaries by Reference: The 76 Element . . . . . . . . . . . . 11 77 5.7. The Service Number: The Element . . . . . 11 78 5.8. Service URLs: The Element . . . . . . . . . . . . . 11 79 6. Path of a Request: The Element . . . . . . . . . . . . 12 80 7. Identifying the Location Element Used for Mapping: 81 . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8. Mapping a Location and Service to URLs: . . . . 12 83 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 8.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 13 86 8.2.2. Civic Address Mapping Example . . . . . . . . . . . . 14 87 8.3. Components of the Request . . . . . . . . . 16 88 8.3.1. The Element . . . . . . . . . . . . . . . . 16 89 8.3.2. Identifying the Service: The Element . . . 17 90 8.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 17 91 8.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 17 92 8.3.5. Requesting Civic Location Validation . . . . . . . . . 17 93 8.4. Components of the Mapping Response 94 . . . . . . . . . . . . . . . . . . 19 95 8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 19 96 8.4.2. Civic Address Validation: The 97 Element . . . . . . . . . . . . . . . . . . . . . . . 20 99 9. Retrieving the Service Boundary via . . . 20 100 10. List Services: . . . . . . . . . . . . . . . . 22 101 11. List Services By Location: . . . . . 23 102 12. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 25 103 12.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 26 104 12.2. Two-Dimensional Geodetic Profile . . . . . . . . . . . . . 30 105 12.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 31 106 13. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 32 107 13.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 32 108 13.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 33 109 13.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 35 110 14. LoST Transport: HTTP . . . . . . . . . . . . . . . . . . . . . 36 111 15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 37 112 16. Internationalization Considerations . . . . . . . . . . . . . 44 113 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 114 17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 44 115 17.2. Content-Type Registration for 'application/lost+xml' . . . 44 116 17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 45 117 17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 46 118 17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 46 119 18. Security Considerations . . . . . . . . . . . . . . . . . . . 47 120 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 121 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 122 20.1. Normative References . . . . . . . . . . . . . . . . . . . 48 123 20.2. Informative References . . . . . . . . . . . . . . . . . . 49 124 Appendix A. Changes from RFC 5222 . . . . . . . . . . . . . . . . 50 125 Appendix B. Non-Normative RELAX NG Schema in XML Syntax . . . . . 52 126 Appendix C. Examples Online . . . . . . . . . . . . . . . . . . . 65 128 1. Introduction 130 Protocols such as Naming Authority Pointer (NAPTR) records and the 131 Service Location Protocol (SLP) can be used to discover servers 132 offering a particular service. However, for an important class of 133 services the appropriate specific service instance depends both on 134 the identity of the service and the geographic location of the entity 135 that needs to reach it. Emergency telecommunications services are an 136 important example; here, the service instance is a Public Safety 137 Answering Point (PSAP) that has jurisdiction over the location of the 138 user making the call. The desired PSAP isn't necessarily the one 139 that is topologically or even line-of-sight closest to the caller; 140 rather, it is the one that serves the caller's location based on 141 jurisdictional boundaries. 143 This document describes a protocol for mapping a service identifier 144 and location information compatible with the Presence Information 145 Data Format Location Object (PIDF-LO) [7] to one or more service 146 URIs. Service identifiers take the form of the service URNs 147 described in [10]. Location information here includes revised civic 148 location information [11] and a subset of the PIDF-LO profile [14], 149 which consequently includes the Geo-Shapes [13] defined for GML [12]. 150 Example service URI schemes include sip [15], xmpp [16], and tel 151 [17]. While the initial focus is on providing mapping functions for 152 emergency services, it is likely that the protocol is applicable to 153 other service URNs. For example, in the United States, the "2-1-1" 154 and "3-1-1" service numbers follow a similar location-to-service 155 behavior as emergency services. 157 This document names this protocol "LoST", for Location-to-Service 158 Translation. LoST satisfies the requirements [19] for mapping 159 protocols. LoST provides a number of operations, centered around 160 mapping locations and service URNs to service URLs and associated 161 information. LoST mapping queries can contain either civic or 162 geodetic location information. For civic addresses, LoST can 163 indicate which parts of the civic address are known to be valid or 164 invalid, thus providing address validation, as described in Section 165 3.5 of [19]. LoST indicates errors in the location data to 166 facilitate debugging and proper user feedback, but also provides 167 best-effort answers. 169 LoST queries can be resolved recursively or iteratively. To minimize 170 round trips and to provide robustness against network failures, LoST 171 supports caching of individual mappings and indicates the region for 172 which the same answer would be returned ("service region"). 174 As defined in this document, LoST messages are carried in HTTP and 175 HTTPS protocol exchanges, facilitating use of TLS for protecting the 176 integrity and confidentiality of requests and responses. 178 This document focuses on the description of the protocol between the 179 mapping client and the mapping server. Other functions, such as 180 discovery of mapping servers, data replication and the overall 181 mapping server architecture are described in a separate document 182 [20]. 184 The query message carries location information and a service 185 identifier encoded as a Uniform Resource Name (URN) (see [10]) from 186 the LoST client to the LoST server. The LoST server uses its 187 database to map the input values to one or more Uniform Resource 188 Identifiers (URIs) and returns those URIs along with optional 189 information, such as a service boundary, in a response message to the 190 LoST client. If the server cannot resolve the query itself, it may 191 in turn query another server or return the address of another LoST 192 server, identified by a LoST server name. In addition to the mapping 193 function described in Section 8, the protocol also allows to retrieve 194 the service boundary (see Section 9) and to list the services 195 available for a particular location (see Section 11) or supported by 196 a particular server (see Section 10). 198 2. Terminology and Requirements Notation 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [1]. 204 This document uses the following terms: 206 Mapping: 207 Mapping is a process that takes a location and a service 208 identifier as inputs and returns one or more URIs. Those URIs can 209 point either to a host providing that service or to a host that in 210 turn routes the request to the final destination. This definition 211 is a generalization of the term "mapping" as used in [19], because 212 LoST can be used for non-emergency services. 214 Mapping Data: 215 Mapping data refers to a data structure that is defined in 216 Section 5. 218 Service boundary: 219 A service boundary circumscribes the region within which all 220 locations map to the same service URI or set of URIs for a given 221 service. A service boundary may consist of several non-contiguous 222 geometric shapes. Note that service boundary is an artifical 223 construct when used in LoST as the described region may not 224 necessarily need to reflect the real world boundary. This 225 simplification is made to allow a person operating a LoST server 226 to balance the tradeoff between the size of a precise service 227 boundary description and the protocol performance gained by 228 returning any form of service boundary. 230 LoST client: 231 A host acts as a LoST client if it sends LoST query messages and 232 receives LoST response messages. 234 LoST server: 235 A host acts as a LoST server if it receives LoST query messages 236 and sends LoST response messages. In recursive operation, the 237 same entity may be both a client and a server. 239 Authoritative LoST server: 240 An authoritative server acts only as a server and successfully 241 resolves the input location and service identifier to a URI or set 242 of URIs. 244 Validation: 245 The term "validation" can be separated into two categories, namely 247 Routing Valid: 248 Location information is considered valid if the civic or 249 geographic location can be mapped to one or more PSAPs. 251 Dispatch Valid: 252 Location information is considered dispatch valid if a provided 253 civic address exists in a given reference database. Note that 254 the criteria for matching a given address with the reference 255 database may not require the comparison of every civic address 256 token in the provided address. 258 Additional emergency service terminology can be found in [19]. 260 3. Overview of Protocol Usage 262 The LoST protocol supports the following types of queries and 263 responses: 265 and 266 A LoST client retrieves contact URIs based on location information 267 and a service identifier with this request and response. The same 268 query type may also ask for location validation. The details can 269 be found in Section 8. 271 and 272 A LoST client obtains a service boundary with this request and 273 response, as described in Section 9. 275 and 276 With this request and response, a LoST client can find out which 277 services a LoST server supports, as described in Section 10. 279 and 280 A LoST client can determine with this request and response which 281 services are available for a specific location region. Section 11 282 describes the details. 284 LoST clients may initiate any of the above queries at any time. 285 Among the common triggers are: 287 1. when the client initially starts up or attaches to a network; 289 2. when the client detects that its location has changed 290 sufficiently that it is outside the bounds of the service region; 292 3. when a SIP message arrives at a SIP proxy performing location- 293 based call routing; 295 4. when cached mapping information has expired; and 297 5. when invoking a particular service. At that time, a client may 298 omit requests for service boundaries or other auxiliary 299 information. 301 A service-specific Best Current Practice (BCP) document, such as 302 [22], governs whether a client is expected to invoke the mapping 303 service just before needing the service or whether to rely on cached 304 answers. Cache entries expire at their expiration time (see 305 Section 5.2), or they become invalid if the caller's device moves 306 beyond the boundaries of the service region. Service-specific Best 307 Current Practice documents may also provide guidance on the contact 308 URI schemes most appropriate to the service. As a general set of 309 guidelines, URI schemes that do not provide mechanisms for actually 310 initiating a contact method should be avoided (examples include data, 311 info, cid, and tag) as transforming those references into contact 312 mechanisms requires a layer of indirection that makes the overall 313 mechanism more fragile. Provisionally registered URI schemes should 314 also be carefully considered before use, because they are subject to 315 change in core semantics. 317 4. LoST Servers and Their Resolution 319 LoST servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/ 320 Dynamic Delegation Discovery Service) [9] application unique strings, 321 in the form of a DNS name. An example is 'lostserver.example.com'. 323 Clients need to use the U-NAPTR [9] specification described below to 324 obtain a URI (indicating host and protocol) for the applicable LoST 325 service. In this document, only the HTTP and HTTPS URL schemes are 326 defined. Note that the HTTP URL can be any valid HTTP URL, including 327 those containing path elements. 329 The following two DNS entries show the U-NAPTR resolution for 330 "example.com" to the HTTPS URL https://lostserv.example.com/secure or 331 the HTTP URL http://lostserver.example.com, with the former being 332 preferred. 334 example.com. 336 IN NAPTR 100 10 "u" "LoST:https" 337 "!.*!https://lostserver.example.com/secure!" "" 339 IN NAPTR 200 10 "u" "LoST:http" 340 "!.*!http://lostserver.example.com!" "" 342 Clients learn the LoST server's host name by means beyond the scope 343 of this specification, such as SIP configuration and DHCP [26]. 345 5. The Element 347 The element is the core data element in LoST, describing a 348 service region and the associated service URLs. Its attributes and 349 elements are described in subsections below. 351 5.1. The Mapping Data Source: 'source', 'sourceId', and 'lastUpdated' 352 Attributes 354 The 'source', 'sourceId', and 'lastUpdated' attributes uniquely 355 identify a particular mapping record. They are created by the 356 authoritative source for a mapping and are never modified when a 357 mapping is served from a cache. All three attributes are REQUIRED 358 for all elements. A receiver can replace a mapping in it's 359 cache with another one having the same 'source' and 'sourceId' and a 360 more recent time in 'lastUpdated'. 362 The 'source' attribute contains a LoST application unique string 363 identifying the authoritative generator of the mapping (see 364 Section 4). 366 The 'sourceId' attribute identifies a particular mapping and contains 367 an opaque token that MUST be unique among all different mappings 368 maintained by the authoritative source for that particular service. 369 For example, a Universally Unique Identifier (UUID) is a suitable 370 format. 372 The 'lastUpdated' attribute describes when a specific instance of 373 mapping, identified by the combination of 'source' and 'sourceId', 374 was last changed. When any of the elements of the element 375 is modified, for example by changing the element or the service 376 boundary, then this mapping has to be treated as a new instance and 377 the value in the 'lastUpdated' attribute has to be re-computed. 378 Another way to judge the need for a re-created mapping is when a 379 digital signature covering that mapping would break because of a 380 modification. The contents of the 'lastUpdated' attribute has the 381 XML data type dateTime in its timezoned form, using the canonical UTC 382 representation with the letter 'Z' as the timezone indicator. 384 5.2. Mapping Validity: The 'expires' Attribute 386 The 'expires' attribute contains the absolute time at which the 387 mapping becomes invalid. The contents of this attribute is a 388 timezoned XML type dateTime, in canonical representation. The 389 element MUST include the 'expires' attribute. 391 Optionally, this attribute may contain the values of 'NO-CACHE' and 392 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is 393 an indication that the mapping should not be cached. The value of 394 'NO-EXPIRATION' is an indication that the mapping does not expire. 395 Please note that the value of 'NO-EXPIRATION' has to be used with 396 care and will typically only be used in a controlled environment 397 where additional mechanisms can be used to update mappings that were 398 initially thought to never change. 400 On occasion, a server may be forced to return an expired mapping if 401 it cannot reach the authoritative server or the server fails to 402 return a usable answer. Clients and servers MAY cache the mapping so 403 that they have at least some information available. Caching servers 404 that have such stale information SHOULD re-attempt the query each 405 time a client requests a mapping. Since the expired mapping will be 406 returned to the client as a non-error/non-warning response, the 407 client MUST check the 'expires' attribute; if the mapping has 408 expired, local policy at the client determines whether it discards 409 the answer and tries again later or uses the possibly stale response. 411 5.3. Describing the Service with the Element 413 Zero or more elements describe the service with a 414 string that is suitable for display to human users, each annotated 415 with the 'xml:lang' attribute that contains a language tag to aid in 416 the rendering of text. 418 5.4. The Mapped Service: The Element 420 The mandatory element identifies the service for which this 421 mapping applies. Two cases need to be distinguished when the LoST 422 server sets the element in the response message: 424 1. If the requested service, identified by the service URN [10] in 425 the element of the request, exists for the location 426 indicated, then the LoST server copies the service URN from the 427 request into the element. 429 2. If, however, the requested service, identified by the service URN 430 [10] in the element in the request, does not exist for 431 the location indicated, the server either can return a 432 (Section 13.1) error or can provide an 433 alternate service that approximates the desired service for that 434 location. In the latter case, the server MUST include a 435 element with the alternative service URN. The choice 436 of service URN is left to local policy, but the alternate service 437 should be able to satisfy the original service request. 439 5.5. Defining the Service Region with the Element 441 A response MAY indicate the region for which the service URL returned 442 would be the same as in the actual query, the so-called service 443 region. The service region can be indicated by value or by reference 444 (see Section 5.6). If a client moves outside the service area and 445 wishes to obtain current service data, it sends a new query with its 446 current location. The service region is described by value in one or 447 more elements, each formatted according to a 448 specific location profile, identified by the 'profile' attribute (see 449 Section 12). elements formatted according to 450 different location profiles are alternative representations of the 451 same area, not additive to one another; this allows a client 452 understanding only one of the profile types to be sure it has a 453 complete view of the serviceBoundary. Within a serviceBoundary 454 element there may, however, be multiple locations which are additive; 455 this is necessary because some areas could not be 456 easily expressed with a single shape or civic location. If included 457 in a response, the element MUST contain at least 458 one service boundary that uses the same profile as the request. 460 A service boundary is requested by the client, using the 461 'serviceBoundary' attribute in the request with the value set to 462 "value". 464 5.6. Service Boundaries by Reference: The 465 Element 467 Since geodetic service boundaries may contain thousands of points and 468 can thus be quite large, clients may wish to conserve bandwidth by 469 requesting a reference to the service boundary instead of the value 470 described in Section 5.5. The identifier of the service boundary is 471 returned as an attribute of the element, 472 along with a LoST application unique string (see Section 4) 473 identifying the server from where it can be retrieved. The actual 474 value of the service boundary is then retrieved with the 475 getServiceBoundary (Section 9) request. 477 A reference to a service boundary is requested by the client using 478 the 'serviceBoundary' attribute in the request with the value set to 479 "reference". A LoST server may decide, based on local policy, to 480 return the service boundary by value or to omit the 481 element in the response. 483 The identifier is a random token with at least 128 bits of entropy 484 and can be assumed to be globally unique. It uniquely references a 485 particular boundary. If the boundary changes, a new identifier MUST 486 be chosen. Because of these properties, a client receiving a mapping 487 response can simply check if it already has a copy of the boundary 488 with that identifier. If so, it can skip checking with the server 489 whether the boundary has been updated. Since service boundaries are 490 likely to remain unchanged for extended periods of time, possibly 491 exceeding the normal lifetime of the service URL, this approach 492 avoids unnecessarily refreshing the boundary information just because 493 the remainder of the mapping has become invalid. 495 5.7. The Service Number: The Element 497 The service number is returned in the optional 498 element. It contains a string of digits, * and # that a user on a 499 device with a 12-key dial pad could use to reach that particular 500 service. 502 5.8. Service URLs: The Element 504 The response returns the service URLs in one or more elements. 505 The URLs MUST be absolute URLs. The ordering of the URLs has no 506 particular significance. Each URL scheme MUST only appear at most 507 once, but it is permissible to include both secured and regular 508 versions of a protocol, such as both 'http' and 'https' or 'sip' and 509 'sips'. 511 6. Path of a Request: The Element 513 To prevent loops and to allow tracing of request and response paths, 514 all requests that allow recursion include a element that 515 contains one or more elements, each possessing an attribute 516 containing a LoST application unique string (see Section 4). The 517 order of elements corresponds to the order of LoST servers, 518 i.e., the first element identifies the server that initially 519 received the request from the client issuing the request. Every 520 server in a recursive query operation is included in the 521 element, including the first server to receive it. 523 The server that answers the request instead of forwarding it, such as 524 the authoritative server, copies the element verbatim into the 525 response. The element is not modified in responses as the 526 responses traverses the server chain back to the querying client. 528 If a query is answered iteratively, the querier includes all servers 529 that it has already contacted. 531 When a cached mapping is returned, then the element cached 532 together with the mapping is returned. 534 The example in Figure 4 indicates that the answer was given to the 535 client by the LoST server at esgw.ueber-110.de.example, which got the 536 answer from the (authoritative) LoST server at 537 polizei.muenchen.de.example. 539 7. Identifying the Location Element Used for Mapping: 541 Several of the requests can provide one or more elements, 542 among which the server gets to choose. It is useful for the client 543 to be able to determine which one was actually used in producing the 544 result. For that purpose, the tag MUST contain an 'id' 545 attribute that uniquely identifies the element. The 546 format of the identifier is left to the client; it could, for 547 example, use a hash of the location information. The server returns 548 the identifier for the element it used in the 549 tag. 551 8. Mapping a Location and Service to URLs: 552 8.1. Overview 554 The query constitutes the core of the LoST 555 functionality, mapping civic or geodetic locations to URLs and 556 associated data. After giving an example, we enumerate the elements 557 of the query and response. 559 8.2. Examples 561 8.2.1. Example Using Geodetic Coordinates 563 The following is an example of mapping a service to a location using 564 geodetic coordinates, for the service associated with the police 565 (urn:service:sos.police). 567 568 574 575 576 37.775 -122.422 577 578 579 urn:service:sos.police 581 583 Figure 1: A geodetic query 585 Given the query above, a server would respond with a service, and 586 information related to that service. In the example below, the 587 server has mapped the location given by the client for a police 588 service to the New York City Police Department, instructing the 589 client that it may contact them via the URIs "sip:nypd@example.com" 590 and "xmpp:nypd@example.com". The server has also given the client a 591 geodetic, two-dimensional boundary for this service. The mapping was 592 last updated on November 1, 2006 and expires on January 1, 2007. If 593 the client's location changes beyond the given service boundary or 594 the expiration time has been reached, it may want to requery for this 595 information, depending on the usage environment of LoST. 597 598 600 605 606 New York City Police Department 607 608 urn:service:sos.police 609 610 611 612 613 37.775 -122.4194 614 37.555 -122.4194 615 37.555 -122.4264 616 37.775 -122.4264 617 37.775 -122.4194 618 619 620 621 622 sip:nypd@example.com 623 xmpp:nypd@example.com 624 911 625 626 627 628 629 630 631 633 Figure 2: A geodetic answer 635 8.2.2. Civic Address Mapping Example 637 The example below shows how to map a service to a location much like 638 the example in Section 8.2.1, but using civic address location 639 information. In this example, the client requests the service 640 associated with police (urn:service:sos.police) along with a specific 641 civic address (house number 6 on a street named Otto-Hahn-Ring in 642 Munich, Germany). 644 645 647 648 650 DE 651 Bavaria 652 Munich 653 Otto-Hahn-Ring 654 6 655 81675 656 657 658 urn:service:sos.police 659 661 Figure 3: A civic address query 663 Given the query above, a server would respond with a service, and 664 information related to that service. In the example below, the 665 server has mapped the location given by the client for a police 666 service to the Muenchen Polizei-Abteilung, instructing the client 667 that it may contact them via the URIs sip:munich-police@example.com 668 and xmpp:munich-police@example.com. The server has also given the 669 client a civic address boundary (the city of Munich) for this 670 service. The mapping was last updated on November 1, 2006 by the 671 authoritative source "polizei.muenchen.de.example" and expires on 672 January 1, 2007. This instructs the client to requery for the 673 information if its location changes beyond the given service boundary 674 (i.e., beyond the indicated district of Munich) or after January 1, 675 2007. 677 678 679 684 685 Muenchen Polizei-Abteilung 686 687 urn:service:sos.police 688 690 692 DE 693 Bavaria 694 Munich 695 81675 696 697 698 sip:munich-police@example.com 699 xmpp:munich-police@example.com 700 110 701 702 703 704 705 706 707 709 Figure 4: A civic address answer 711 8.3. Components of the Request 713 The request includes attributes and elements that 714 govern whether the request is handled iteratively or recursively, 715 whether location validation is performed, and which elements may be 716 contained in the response. 718 8.3.1. The Element 720 The query communicates location information using one 721 or more elements, which MUST conform to a location profile 722 (see Section 12). There MUST NOT be more than one location element 723 for each distinct location profile. The order of location elements 724 is significant; the server uses the first location element where it 725 understands the location profile. 727 8.3.2. Identifying the Service: The Element 729 The type of service desired is specified by the element. 730 It contains service URNs from the registry established in [10]. 732 8.3.3. Recursion and Iteration 734 LoST can operate in either recursive or iterative mode, on a request- 735 by-request basis. In recursive mode, the LoST server initiates 736 queries on behalf of the requester and returns the result to the 737 requester. 739 In iterative mode, the server contacted returns a redirection 740 response indicating the next server to be queried if the server 741 contacted cannot provide an answer itself. 743 For the queries defined in this document, only the LoST 744 and queries can be recursive, as indicated 745 by the 'recursive' attribute. A value of "true" indicates a 746 recursive query, with the default being "false" when the attribute is 747 omitted. Regardless of the attribute, a server MAY always answer a 748 query by providing a LoST application unique string (see Section 4), 749 i.e., indirection; however, it MUST NOT recurse if the attribute is 750 "false". 752 8.3.4. Service Boundary 754 LoST elements can describe the service boundary either by 755 value or by reference. Returning a service boundary reference is 756 generally more space-efficient for geospatial (polygon) boundaries 757 and if the boundaries change rarely, but does incur an additional 758 request. The querier can express a preference 759 for one or the other modality with the 'serviceBoundary' attribute in 760 the request, but the server makes the final decision as 761 to whether to return a reference or a value. 763 8.3.5. Requesting Civic Location Validation 765 Civic address validation is requested by setting the optional 766 attribute 'validateLocation' to true. If the attribute is omitted, 767 it is assumed to be false. The response is described in 768 Section 8.4.2. The example in Figure 5 demonstrates address 769 validation. If the server chooses a geodetic location among the 770 locations provided in a request, the attribute is ignored. 772 773 778 779 781 DE 782 Bavaria 783 Munich 784 Otto-Hahn-Ring 785 6 786 81675 787 788 789 urn:service:sos.police 790 792 Figure 5: A query with address validation request 794 795 796 801 802 Muenchen Polizei-Abteilung 803 804 urn:service:sos.police 805 806 808 DE 809 Bavaria 810 Munich 811 81675 812 813 814 sip:munich-police@example.com 815 xmpp:munich-police@example.com 816 110 817 818 819 country A1 A3 A6 820 PC 821 HNO 822 823 824 825 826 827 828 830 Figure 6: A message with address validation 831 information 833 8.4. Components of the Mapping Response 835 8.4.1. Overview 837 Mapping responses consist of the element (Section 5) 838 describing the mapping itself, possibly followed by warnings 839 (Section 13.2), location validation information (Section 8.4.2), and 840 an indication of the path (Section 6) the response has taken. 842 8.4.2. Civic Address Validation: The Element 844 A server can indicate in its response which civic address elements it 845 has recognized as valid, which ones it has ignored, and which ones it 846 has checked and found to be invalid. The server SHOULD include this 847 information if the 'validateLocation' attribute in the request was 848 true, but local policy at the server may allow this information to be 849 omitted. Each element contains a list of tokens separated by 850 whitespace, enumerating the civic location labels used in child 851 elements of the element. The element 852 enumerates those civic address elements that have been recognized as 853 valid by the LoST server and that have been used to determine the 854 mapping. The elements enumerates the civic address 855 elements that the server did not check and that were not used in 856 determining the response. The element enumerate civic 857 address elements that the server attempted to check, but that did not 858 match the other civic address elements found in the list. 859 Civic location tokens that are not listed in either the , 860 , or element belong to the class of unchecked 861 tokens. 863 Note that the same address can yield different responses if parts of 864 the civic address contradict each other. For example, if the postal 865 code does not match the city, local server policy determines whether 866 the postal code or the city is considered valid. The mapping 867 naturally corresponds to the valid elements. 869 The example shown in Figure 5 and in Figure 6 indicates that the 870 tokens 'country', 'A1', 'A3', and 'A6' have been validated by the 871 LoST server. The server considered the postal code 81675 in the 872 element as not valid for this location. The 'HNO' token belongs to 873 the class of unchecked location tokens. 875 9. Retrieving the Service Boundary via 877 As discussed in Section 5.5, the can return a 878 globally unique identifier in the 'serviceBoundary' attribute that 879 can be used to retrieve the service boundary, rather than returning 880 the boundary by value. This is shown in the example in Figure 7 and 881 Figure 8. The client can then retrieve the boundary using the 882 request and obtains the boundary in the 883 , illustrated in the example in Figure 9 884 and Figure 10. The client issues the request to the server 885 identified in the 'server' attribute of the 886 element. These requests are always 887 directed to the authoritative server and do not recurse. 889 890 895 896 897 37.775 -122.422 898 899 900 urn:service:sos.police 901 903 Figure 7: request and response with service boundary 904 reference 906 907 909 914 915 New York City Police Department 916 917 urn:service:sos.police 918 921 sip:nypd@example.com 922 xmpp:nypd@example.com 923 911 924 925 926 927 928 929 930 932 Figure 8: message with service boundary 933 reference 935 936 939 Figure 9: Requesting a service boundary with 941 942 944 945 946 947 948 37.775 -122.4194 949 37.555 -122.4194 950 37.555 -122.4264 951 37.775 -122.4264 952 37.775 -122.4194 953 954 955 956 957 958 959 960 961 963 Figure 10: Geodetic service boundary response 965 10. List Services: 967 A LoST client can ask a LoST server for the list of services that it 968 understands, primarily for diagnostic purposes. The query does not 969 contain location information, as it simply provides an indication of 970 which services the server can look up, not whether a particular 971 service is offered for a particular area. Typically, only top-level 972 services are included in the answer, implying support for all sub- 973 services. Since the query is answered by the queried server, there 974 is no notion of recursion or indirection. The 975 (Section 11) query below can be used to find 976 out whether a particular service is offered for a specific location. 977 An example request and response are shown in Figure 11. 979 980 982 urn:service:sos 983 985 Figure 11: Example of query 987 988 990 991 urn:service:sos.ambulance 992 urn:service:sos.animal-control 993 urn:service:sos.fire 994 urn:service:sos.gas 995 urn:service:sos.mountain 996 urn:service:sos.marine 997 urn:service:sos.physician 998 urn:service:sos.poison 999 urn:service:sos.police 1000 1001 1002 1003 1004 1006 Figure 12: Example of 1008 11. List Services By Location: 1010 A LoST client can ask a LoST server for the list of services it knows 1011 about for a particular area. The query 1012 contains one or more elements, each from a different 1013 location profile (Section 12), and may contain the element. 1014 As for , the server selects the first location element 1015 that has a profile the server understands and it can operate either 1016 recursively or iteratively; elements track the progress of the 1017 request. The query indicates the services that the server can 1018 enumerate from within the forest structure of which it is a part. 1019 Because LoST does not presume a single, overarching organization of 1020 all potential service types, there may be services available within a 1021 geographic area that could be described by other LoST servers 1022 connected to other forest structures. As an example, the emergency 1023 services forest for a region may be distinct from the forests that 1024 locate commercial services within the same region. 1026 If the query contains the element, the LoST server returns 1027 only immediate child services of the queried service that are 1028 available for the provided location. If the element is 1029 absent, the LoST service returns all top-level services available for 1030 the provided location that it knows about. 1032 A server responds to this query with a 1033 response. This response contains 1034 elements (see Section 6) and MUST contain a 1035 element, consisting of a whitespace-separated list of service URNs. 1036 The query and response are illustrated in Figure 13 and in Figure 14, 1037 respectively. 1039 1040 1044 1045 1046 -34.407 150.883 1047 1048 1049 urn:service:sos 1050 1052 Figure 13: Example of query 1054 1055 1057 1058 urn:service:sos.ambulance 1059 urn:service:sos.animal-control 1060 urn:service:sos.fire 1061 urn:service:sos.gas 1062 urn:service:sos.mountain 1063 urn:service:sos.marine 1064 urn:service:sos.physician 1065 urn:service:sos.poison 1066 urn:service:sos.police 1067 1068 1069 1070 1071 1072 1073 1075 Figure 14: Example of response 1077 12. Location Profiles 1079 LoST uses location information in elements in requests and 1080 elements in responses. Such location information 1081 may be expressed in a variety of ways. This variety can cause 1082 interoperability problems where a request or response contains 1083 location information in a format not understood by the server or the 1084 client, respectively. To achieve interoperability, this document 1085 defines two mandatory-to-implement baseline location profiles to 1086 define the manner in which location information is transmitted. It 1087 is possible to standardize other profiles in the future. The 1088 baseline profiles are: 1090 geodetic-2d: 1091 a profile for two-dimensional geodetic location information, as 1092 described in Section 12.2;. 1094 civic: 1095 a profile consisting of civic address location information, as 1096 described in Section 12.3. 1098 Requests and responses containing or 1099 elements MUST contain location information in exactly one of the two 1100 baseline profiles, in addition to zero or more additional profiles. 1101 The ordering of location information indicates a preference on the 1102 part of the sender. 1104 Standards action is required for defining new profiles. A location 1105 profile MUST define: 1107 1. The token identifying it in the LoST location profile registry. 1109 2. The formal definition of the XML to be used in requests, i.e., an 1110 enumeration and definition of the XML child elements of the 1111 element. 1113 3. The formal definition of the XML to be used in responses, i.e., 1114 an enumeration and definition of the XML child elements of the 1115 element. 1117 4. The declaration of whether geodetic-2d or civic is to be used as 1118 the baseline profile. It is necessary to explicitly declare the 1119 baseline profile as future profiles may be combinations of 1120 geodetic and civic location information. 1122 12.1. Location Profile Usage 1124 A location profile is identified by a token in an IANA-maintained 1125 registry (Section 17.5). Clients send location information compliant 1126 with a location profile, and servers respond with location 1127 information compliant with that same location profile. 1129 When a LoST client sends a request that provides 1130 location information, it includes one or more elements. A 1131 element carries an optional 'profile' attribute that 1132 indicates the location format of the child elements. A client may 1133 obtain location information that does not conform to a profile it 1134 recognizes, or it may not have the capability to map XML to profiles. 1135 In that case, a client MAY omit the profile attribute and the server 1136 should interpret the XML location data to the best of its ability, 1137 returning a "locationProfileUnrecognized" error if it is unable to do 1138 so. 1140 The concept of location profiles is described in Section 12. With 1141 the ability to specify more than one element, the client 1142 is able to convey location information for multiple location profiles 1143 in the same request. 1145 When a LoST server sends a response that contains location 1146 information, it uses the elements much like the 1147 client uses the elements. Each element 1148 contains location information conforming to the location profile 1149 specified in the 'profile' attribute. A response MAY contain 1150 multiple mappings or boundaries for the different 1151 elements, subject to the restrictions below. 1153 Using the location profiles defined in this document, the following 1154 rules ensure interoperability between clients and servers: 1156 1. A client MUST be capable of understanding the response for the 1157 baseline profiles it used in the request. 1159 2. If a client sends location information conformant to any location 1160 profile other than the ones described in this document, it MUST 1161 also send, in the same request, location information conformant 1162 to one of the baseline profiles. Otherwise, the server might not 1163 be able to understand the request. 1165 3. A client MUST NOT send multiple objects that are 1166 derived from different baseline profiles. In other words, a 1167 client MUST only send location objects according to the same 1168 baseline profile in a query, but it MAY contain a location 1169 element following a baseline profile in addition to some other 1170 profile. 1172 4. If a client has both location information primarily of geodetic 1173 nature and location information primarily of a civic nature, it 1174 MUST send separate requests containing each type of location 1175 information. 1177 5. There can only be one instance of each location profile in a 1178 query. 1180 6. Servers MUST implement all profiles described in this document. 1182 7. A server uses the first-listed location profile that it 1183 understands and ignores the others. 1185 8. If a server receives a request that only contains location 1186 information using profiles it does not understand, the server 1187 responds with a (Section 13.1). 1189 9. The element MUST use the same location profile 1190 that was used to retrieve the answer and indicates which profile 1191 has been used with the 'profile' attribute. 1193 These rules enable the use of location profiles not yet specified, 1194 while ensuring baseline interoperability. Take, for example, this 1195 scenario illustrated in Figure 15 and 16. Client X has had its 1196 firmware upgraded to support the 'not-yet-standardized-prism-profile' 1197 location profile. Client X sends location information to Server Y, 1198 which does not understand the 'not-yet-standardized-prism-profile' 1199 location profile. If Client X also sends location information using 1200 the geodetic-2D baseline profile, then Server Y will still be able to 1201 understand the request and provide an understandable response, though 1202 with location information that might not be as precise or expressive 1203 as desired. This is possible because both Client X and Server Y 1204 understand the baseline profile. 1206 1207 1213 1215 1216 1217 1218 1219 1220 1221 42.556844 -73.248157 36.6 1222 42.656844 -73.248157 36.6 1223 42.656844 -73.348157 36.6 1224 42.556844 -73.348157 36.6 1225 42.556844 -73.248157 36.6 1226 1227 1228 1229 1230 1231 1232 2.4 1233 1234 1235 1236 1237 1238 42.656844 -73.348157 1239 1240 1241 urn:service:sos.police 1242 1243 Figure 15: Example of a query with baseline profile 1244 interoperability 1246 1247 1250 1255 1256 New York City Police Department 1257 1258 urn:service:sos.police 1259 1260 1261 1262 1263 37.775 -122.4194 1264 37.555 -122.4194 1265 37.555 -122.4264 1266 37.775 -122.4264 1267 37.775 -122.4194 1268 1269 1270 1271 1272 sip:nypd@example.com 1273 911 1274 1275 1276 1277 1278 1279 1280 1282 Figure 16: Example of a message with baseline 1283 profile interoperability 1285 12.2. Two-Dimensional Geodetic Profile 1287 The "geodetic-2d" location profile is identified by the token 1288 "geodetic-2d". Clients and servers use this profile by placing the 1289 following location shapes into the or into the 1290 element (unless indicated otherwise): 1292 Point: 1293 The element is described in Section 5.2.1 of [14]. 1294 Section 5.2.1 of [14] shows also the specification of a 1295 with either a two-dimensional position (latitude and longitude) or 1296 three-dimensional position (latitude, longitude, and altitude). A 1297 client MAY use the three-dimensional position, and servers MAY 1298 interpret a three-dimensional position as a two-dimensional 1299 position by ignoring the altitude value. A element is not 1300 placed into a element. 1302 Polygon: 1303 The element is described in Section 5.2.2 of [14]. The 1304 restriction to 16 points for a polygon contained in Section 7.2.2 1305 of [13] is not applicable to this document. 1307 Circle: 1308 The element is described in Section 5.2.3 of [14]. 1310 Ellipse: 1311 The element is described in Section 5.2.4 of [14]. 1313 ArcBand: 1314 The element is described in Section 5.2.5 of [14]. 1316 When a client uses a , , , or 1317 element within the element, it is indicating that it will 1318 be satisfied by query results appropriate to any portion of the 1319 shape. It is left to the server to select an appropriate matching 1320 algorithm. A server MAY return multiple elements if the 1321 shape extends across multiple service areas. Servers are not 1322 required to return all possible elements to avoid denial- 1323 of-service attacks in which clients present queries that span a very 1324 large number of service boundaries (e.g., presenting a shape covering 1325 all of the United States). 1327 In the case where the server does not return multiple 1328 elements, but the shape extends across a service boundary, it is 1329 possible that the matching algorithm selected by the LoST server will 1330 return results that match a portion of the shape but do not match 1331 those specific to a particular point. A client may always select a 1332 point from within the shape to avoid this condition. The cases where 1333 it does not are generally those where it knows its own position only 1334 within the shape given. In emergency service use cases, that may 1335 result in the PSAP contacted at the URI provided by LoST being 1336 required to forward a call to one of its neighbors; this is an 1337 expected part of the overall emergency response system. In non- 1338 emergency service use cases, the service deployment model should take 1339 into account this issue as part of the provisioning model, as the 1340 combination of the data in the LoST server and the algorithm used for 1341 mapping determine which contact URIs are returned when shapes are 1342 used that overlap multiple service areas. 1344 As a general guideline, any deployed matching algorithm should ensure 1345 that the algorithm used does not needlessly return no results if 1346 there are valid results for any portion of the shape. If an 1347 authoritative server receives a query for which the area in the query 1348 overlaps the area for which the server has mapping information, then 1349 it MUST return either a mapping whose coverage area intersects the 1350 query area or a redirect to another server whose coverage area is a 1351 subset of the server's coverage area. 1353 When geodetic location information of this location profile is placed 1354 in the element, then the elements with geospatial 1355 coordinates are alternative descriptions of the same service region, 1356 not additive geometries. 1358 12.3. Basic Civic Profile 1360 The basic civic location profile is identified by the token 'civic'. 1361 Clients use this profile by placing a element, defined 1362 in [11], within the element. 1364 Servers use this profile by placing a element, defined 1365 in [11], within the element. 1367 A response MAY contain more than one element with 1368 profile 'civic'. The purpose of allowing multiple 1369 elements is to be able to express more complex location shapes. Each 1370 element describes a set of civic addresses that 1371 fall within the service boundary, namely, all addresses that 1372 textually match the civic address elements provided, regardless of 1373 the value of other address elements. A location falls within the 1374 mapping's service boundary if it matches any of the 1375 elements. Hence, a response may contain multiple 1376 elements with civic and/or geodetic location profiles. 1378 13. Errors, Warnings, and Redirects 1380 When a LoST server cannot fulfill a request completely, it can return 1381 either an error or a warning, depending on the severity of the 1382 problem. It returns an element if no useful response can be 1383 returned for the query. It returns a element as part of 1384 another response element if it was able to respond in part, but the 1385 response may not be quite what the client had desired. For both 1386 elements, the 'source' attribute names the server that originally 1387 generated the error or warning, such as the authoritative server. 1388 Unless otherwise noted, all elements below can be either an error or 1389 a warning, depending on whether a default response, such as a 1390 mapping, is included. 1392 13.1. Errors 1394 LoST defines a pattern for errors, defined as elements in 1395 the Relax NG schema. This pattern defines a 'message' attribute 1396 containing human-readable text and an 'xml:lang' attribute denoting 1397 the language of the human-readable text. One or more such error 1398 elements are contained in the element. 1400 The following errors follow this basic pattern: 1402 badRequest 1403 The server could not parse or otherwise understand a request, 1404 e.g., because the XML was malformed. 1406 forbidden 1407 The server refused to send an answer. This generally only occurs 1408 for recursive queries, namely, if the client tried to contact the 1409 authoritative server and was refused. 1411 internalError 1412 The server could not satisfy a request due to misconfiguration or 1413 other operational and non-protocol-related reasons. 1415 locationProfileUnrecognized 1416 None of the profiles in the request were recognized by the server 1417 (see Section 12). 1419 locationInvalid 1420 The geodetic or civic location in the request was invalid. For 1421 example, the longitude or latitude values fall outside the 1422 acceptable ranges. 1424 SRSInvalid 1425 The spatial reference system (SRS) contained in the location 1426 element was not recognized or does not match the location profile. 1428 loop 1429 During a recursive query, the server was about to visit a server 1430 that was already in the server list in the element, 1431 indicating a request loop. 1433 notFound 1434 The server could not find an answer to the query. 1436 serverError 1437 An answer was received from another LoST server, but it could not 1438 be parsed or otherwise understood. This error occurs only for 1439 recursive queries. 1441 serverTimeout 1442 A time out occurred before an answer was received. 1444 serviceNotImplemented 1445 The requested service URN is not implemented and no substitution 1446 was available. 1448 An example is below: 1450 1451 1453 1454 1456 Figure 17: Example of an error response 1458 13.2. Warnings 1460 A response MAY contain zero or more warnings. This pattern defines a 1461 'message' attribute containing human-readable text and an 'xml:lang' 1462 attribute denoting the language of the human-readable text. One or 1463 more such warning elements are contained in the element. 1464 To provide human-readable text in an appropriate language, the HTTP 1465 content negotiation capabilities (see Section 14) MAY be utilized by 1466 a server. 1468 This version of the specification defines the following warnings: 1470 locationValidationUnavailable 1471 The element MAY be returned when a 1472 server wishes to notify a client that it cannot fulfill a location 1473 validation request. This warning allows a server to return 1474 mapping information while signaling this exception state. 1476 serviceSubstitution 1477 The element MAY be returned when a server 1478 was not able to fulfill a request for a given 1479 service URN. For example, a request with the 1480 'urn:service:sos.police' service URN for a location in Uruguay may 1481 cause the LoST service to return a mapping for the 1482 'urn:service:sos' service URN since Uruguay does not make use of 1483 the sub-services police, fire, and ambulance. If this warning is 1484 returned, then the element in the response provides 1485 information about the service URN that refers to the mapping. 1487 defaultMappingReturned 1488 The element MAY be returned when a server 1489 was not able to fulfill a request for a given 1490 location but is able to respond with a default URI. For example, 1491 a nearby PSAP may be returned. 1493 An example of a warning is shown below: 1495 1496 1498 1503 1504 New York City Police Department 1505 1506 urn:service:sos.police 1507 1508 1509 1510 1511 37.775 -122.4194 1512 37.555 -122.4194 1513 37.555 -122.4264 1514 37.775 -122.4264 1515 37.775 -122.4194 1516 1517 1518 1519 1520 sip:nypd@example.com 1521 911 1522 1523 1524 1528 1529 1530 1531 1532 1533 1535 Figure 18: Example of a warning response 1537 13.3. Redirects 1539 A LoST server can respond indicating that the querier should redirect 1540 the query to another server, using the element. The 1541 element includes a 'target' attribute indicating the LoST application 1542 unique string (see Section 4) that the client SHOULD be contacting 1543 next, as well as the 'source' attribute indicating the server that 1544 generated the redirect response and a 'message' attribute explaining 1545 the reason for the redirect response. During a recursive query, a 1546 server receiving a response can decide whether it wants to 1547 follow the redirection or simply return the response to its upstream 1548 querier. The "expires" value in the response returned by the server 1549 handling the redirected query indicates the earliest time at which a 1550 new query might be needed (see Section 5.2). The query for the same 1551 tuple of location and service SHOULD NOT be directed to the server 1552 that gave redirect prior to that time. 1554 An example is below: 1556 1557 1562 Figure 19: Example of a redirect response 1564 14. LoST Transport: HTTP 1566 LoST needs an underlying protocol transport mechanism to carry 1567 requests and responses. This document defines the use of LoST over 1568 HTTP and LoST over HTTP-over-TLS. Client and server developers are 1569 reminded that full support of RFC 2616 HTTP facilities is expected. 1570 If LoST clients or servers re-implement HTTP, rather than using 1571 available servers or client code as a base, careful attention must be 1572 paid to full interoperability. Other transport mechanisms are left 1573 to future documents. The available transport mechanisms are 1574 determined through the use of the LoST U-NAPTR application. In 1575 protocols that support content type indication, LoST uses the media 1576 type application/lost+xml. 1578 When using HTTP [4] and HTTP-over-TLS [5], LoST requests use the HTTP 1579 POST method. The HTTP request MUST use the Cache-Control response 1580 directive "no-cache" to disable HTTP-level caching even by caches 1581 that have been configured to return stale responses to client 1582 requests. 1584 All LoST responses, including those indicating a LoST warning or 1585 error, are carried in 2xx responses, typically 200 (OK). Other 2xx 1586 responses, in particular 203 (Non-authoritative information), may be 1587 returned by HTTP caches that disregard the caching instructions. 3xx, 1588 4xx, and 5xx HTTP response codes indicate that the HTTP request 1589 itself failed or was redirected; these responses do not contain any 1590 LoST XML elements. The 3xx responses are distinct from the redirects 1591 that are described in Section 13.3; the redirect operation in 1592 Section 13.3 occur after a LoST server processes the request. Where 1593 an HTTP-layer redirect will be general, a LoST server redirect as 1594 described in Section 13.3 might be specific to a specific service or 1595 be the result of other processing by the LoST server. 1597 The HTTP URL is derived from the LoST server name via U-NAPTR 1598 application, as discussed above. 1600 15. Relax NG Schema 1602 This section provides the Relax NG schema used by the LoST protocol 1603 in the compact form. The verbose form is included in Appendix B. 1605 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 1606 default namespace ns1 = "urn:ietf:params:xml:ns:lost1" 1608 ## 1609 ## Location-to-Service Translation (LoST) Protocol 1611 ## 1612 ## A LoST XML instance has three request types, each with 1613 ## a corresponding response type: find service, list services, 1614 ## and get service boundary. 1615 ## 1616 start = 1617 findService 1618 | listServices 1619 | listServicesByLocation 1620 | getServiceBoundary 1621 | findServiceResponse 1622 | listServicesResponse 1623 | listServicesByLocationResponse 1624 | getServiceBoundaryResponse 1625 | errors 1626 | redirect 1628 ## 1629 ## The queries. 1630 ## 1631 div { 1632 findService = 1633 element findService { 1634 requestLocation, 1635 commonRequestPattern, 1636 attribute validateLocation { 1637 xsd:boolean >> a:defaultValue [ "false" ] 1638 }?, 1639 attribute serviceBoundary { 1640 ("reference" | "value") >> a:defaultValue [ "reference" ] 1641 }?, 1642 attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? 1643 } 1644 listServices = element listServices { commonRequestPattern } 1645 listServicesByLocation = 1646 element listServicesByLocation { 1647 requestLocation, 1648 commonRequestPattern, 1649 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 1650 } 1651 getServiceBoundary = 1652 element getServiceBoundary { serviceBoundaryKey, extensionPoint } 1653 } 1655 ## 1656 ## The responses. 1657 ## 1658 div { 1659 findServiceResponse = 1660 element findServiceResponse { 1661 mapping+, locationValidation?, commonResponsePattern, locationUsed 1662 } 1663 listServicesResponse = 1664 element listServicesResponse { serviceList, commonResponsePattern } 1665 listServicesByLocationResponse = 1666 element listServicesByLocationResponse { 1667 serviceList, commonResponsePattern, locationUsed 1668 } 1669 getServiceBoundaryResponse = 1670 element getServiceBoundaryResponse { 1671 serviceBoundary, commonResponsePattern 1672 } 1673 } 1675 ## 1676 ## A pattern common to some of the queries. 1677 ## 1678 div { 1679 commonRequestPattern = service, path?, extensionPoint 1680 } 1682 ## 1683 ## A pattern common to responses. 1685 ## 1686 div { 1687 commonResponsePattern = warnings*, path, extensionPoint 1688 } 1690 ## 1691 ## Location in Requests 1692 ## 1693 div { 1694 requestLocation = 1695 element location { 1696 attribute id { xsd:token }, 1697 locationInformation 1698 }+ 1699 } 1701 ## 1702 ## Location Information 1703 ## 1704 div { 1705 locationInformation = 1706 extensionPoint+, 1707 attribute profile { xsd:NMTOKEN }? 1708 } 1710 ## 1711 ## Service Boundary 1712 ## 1713 div { 1714 serviceBoundary = element serviceBoundary { locationInformation }+ 1715 } 1717 ## 1718 ## Service Boundary Reference 1719 ## 1720 div { 1721 serviceBoundaryReference = 1722 element serviceBoundaryReference { 1723 source, serviceBoundaryKey, extensionPoint 1724 } 1725 serviceBoundaryKey = attribute key { xsd:token } 1726 } 1728 ## 1729 ## Path - 1730 ## Contains a list of via elements - 1731 ## places through which information flowed 1732 ## 1733 div { 1734 path = 1735 element path { 1736 element via { source, extensionPoint }+ 1737 } 1738 } 1740 ## 1741 ## Location Used 1742 ## 1743 div { 1744 locationUsed = 1745 element locationUsed { 1746 attribute id { xsd:token } 1747 }? 1748 } 1750 ## 1751 ## Expires pattern 1752 ## 1753 div { 1754 expires = 1755 attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } 1756 } 1758 ## 1759 ## A QName list 1760 ## 1761 div { 1762 qnameList = list { xsd:QName* } 1763 } 1765 ## 1766 ## A location-to-service mapping. 1767 ## 1768 div { 1769 mapping = 1770 element mapping { 1771 element displayName { 1772 xsd:string, 1773 attribute xml:lang { xsd:language } 1774 }*, 1775 service, 1776 (serviceBoundary | serviceBoundaryReference)?, 1777 element uri { xsd:anyURI }*, 1778 element serviceNumber { 1779 xsd:token { pattern = "[0-9*#]+" } 1780 }?, 1781 extensionPoint, 1782 expires, 1783 attribute lastUpdated { xsd:dateTime }, 1784 source, 1785 attribute sourceId { xsd:token }, 1786 message 1787 } 1788 } 1790 ## 1791 ## Location validation 1792 ## 1793 div { 1794 locationValidation = 1795 element locationValidation { 1796 element valid { qnameList }?, 1797 element invalid { qnameList }?, 1798 element unchecked { qnameList }?, 1799 extensionPoint 1800 } 1801 } 1803 ## 1804 ## Errors and Warnings Container. 1805 ## 1806 div { 1807 exceptionContainer = 1808 (badRequest? 1809 & internalError? 1810 & serviceSubstitution? 1811 & defaultMappingReturned? 1812 & forbidden? 1813 & notFound? 1814 & loop? 1815 & serviceNotImplemented? 1816 & serverTimeout? 1817 & serverError? 1818 & locationInvalid? 1819 & locationProfileUnrecognized?), 1820 extensionPoint, 1821 source 1822 errors = element errors { exceptionContainer } 1823 warnings = element warnings { exceptionContainer } 1824 } 1826 ## 1827 ## Basic Exceptions 1828 ## 1829 div { 1831 ## 1832 ## Exception pattern. 1833 ## 1834 basicException = message, extensionPoint 1835 badRequest = element badRequest { basicException } 1836 internalError = element internalError { basicException } 1837 serviceSubstitution = element serviceSubstitution { basicException } 1838 defaultMappingReturned = 1839 element defaultMappingReturned { basicException } 1840 forbidden = element forbidden { basicException } 1841 notFound = element notFound { basicException } 1842 loop = element loop { basicException } 1843 serviceNotImplemented = 1844 element serviceNotImplemented { basicException } 1845 serverTimeout = element serverTimeout { basicException } 1846 serverError = element serverError { basicException } 1847 locationInvalid = element locationInvalid { basicException } 1848 locationValidationUnavailable = 1849 element locationValidationUnavailable { basicException } 1850 locationProfileUnrecognized = 1851 element locationProfileUnrecognized { 1852 attribute unsupportedProfiles { xsd:NMTOKENS }, 1853 basicException 1854 } 1855 } 1857 ## 1858 ## Redirect. 1859 ## 1860 div { 1862 ## 1863 ## Redirect pattern 1864 ## 1865 redirect = 1866 element redirect { 1867 attribute target { appUniqueString }, 1868 source, 1869 message, 1870 extensionPoint 1871 } 1872 } 1874 ## 1875 ## Some common patterns. 1876 ## 1877 div { 1878 message = 1879 (attribute message { xsd:token }, 1880 attribute xml:lang { xsd:language })? 1881 service = element service { xsd:anyURI }? 1882 appUniqueString = 1883 xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } 1884 source = attribute source { appUniqueString } 1885 serviceList = 1886 element serviceList { 1887 list { xsd:anyURI* } 1888 } 1889 } 1891 ## 1892 ## Patterns for inclusion of elements from schemas in 1893 ## other namespaces. 1894 ## 1895 div { 1897 ## 1898 ## Any element not in the LoST namespace. 1899 ## 1900 notLost = element * - (ns1:* | ns1:*) { anyElement } 1902 ## 1903 ## A wildcard pattern for including any element 1904 ## from any other namespace. 1905 ## 1906 anyElement = 1907 (element * { anyElement } 1908 | attribute * { text } 1909 | text)* 1911 ## 1912 ## A point where future extensions 1913 ## (elements from other namespaces) 1914 ## can be added. 1915 ## 1916 extensionPoint = notLost* 1917 } 1919 Figure 20: RelaxNG schema 1921 16. Internationalization Considerations 1923 The LoST protocol is mostly meant for machine-to-machine 1924 communications; as such, most of its elements are tokens not meant 1925 for direct human consumption. If these tokens are presented to the 1926 end user, some localization may need to occur. The content of the 1927 element and the 'message' attributes may be displayed 1928 to the end user, and they are thus complex types designed for this 1929 purpose. 1931 LoST exchanges information using XML. All XML processors are 1932 required to understand UTF-8 and UTF-16 encodings, and therefore all 1933 LoST clients and servers MUST understand UTF-8 and UTF-16 encoded 1934 XML. Additionally, LoST servers and clients MUST NOT encode XML with 1935 encodings other than UTF-8 or UTF-16. 1937 17. IANA Considerations 1939 17.1. U-NAPTR Registrations 1941 This document registers the following U-NAPTR application service 1942 tag: 1944 Application Service Tag: LoST 1946 Defining Publication: The specification contained within this 1947 document. 1949 This document registers the following U-NAPTR application protocol 1950 tags: 1952 o Application Protocol Tag: http 1954 Defining Publication: RFC 2616 [4] 1956 o Application Protocol Tag: https 1958 Defining Publication: RFC 2818 [5] 1960 17.2. Content-Type Registration for 'application/lost+xml' 1962 This specification requests the registration of a new MIME type 1963 according to the procedures of RFC 4288 [8] and guidelines in RFC 1964 3023 [6]. 1966 MIME media type name: application 1968 MIME subtype name: lost+xml 1970 Mandatory parameters: none 1972 Optional parameters: charset 1973 Indicates the character encoding of enclosed XML. 1975 Encoding considerations: Uses XML, which can employ 8-bit 1976 characters, depending on the character encoding used. See RFC 1977 3023 [6], Section 3.2. 1979 Security considerations: This content type is designed to carry LoST 1980 protocol payloads. 1982 Interoperability considerations: None 1984 Published specification: RFC 5222 1986 Applications that use this media type: Emergency and location-based 1987 systems 1989 Additional information: 1991 Magic Number: None 1993 File Extension: .lostxml 1995 Macintosh file type code: 'TEXT' 1997 Personal and email address for further information: 1998 Hannes Tschofenig, Hannes.Tschofenig@nsn.com 2000 Intended usage: LIMITED USE 2002 Author: 2003 This specification is a work item of the IETF ECRIT working group, 2004 with mailing list address . 2006 Change controller: 2007 The IESG 2009 17.3. LoST Relax NG Schema Registration 2010 URI: urn:ietf:params:xml:schema:lost1 2012 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 2013 (Hannes.Tschofenig@nsn.com). 2015 Relax NG Schema: The Relax NG schema to be registered is contained 2016 in Section 15. Its first line is 2018 default namespace = "urn:ietf:params:xml:ns:lost1" 2020 and its last line is 2022 } 2024 17.4. LoST Namespace Registration 2026 URI: urn:ietf:params:xml:ns:lost1 2028 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 2029 (Hannes.Tschofenig@nsn.com). 2031 XML: 2033 BEGIN 2034 2035 2037 2038 2039 2041 LoST Namespace 2042 2043 2044

Namespace for LoST

2045

urn:ietf:params:xml:ns:lost1

2046

See RFC5222.

2047 2048 2049 END 2051 17.5. LoST Location Profile Registry 2053 This document creates a registry of location profile names for the 2054 LoST protocol. Profile names are XML tokens. This registry will 2055 operate in accordance with RFC 5226 [3], Standards Action. 2057 geodetic-2d: 2058 Defined in Section 12.2. 2060 civic: 2061 Defined in Section 12.3. 2063 18. Security Considerations 2065 There are several threats to the overall system of which service 2066 mapping forms a part. An attacker that can obtain service contact 2067 URIs can use those URIs to attempt to disrupt those services. An 2068 attacker that can prevent the lookup of contact URIs can impair the 2069 reachability of such services. An attacker that can eavesdrop on the 2070 communication requesting this lookup can surmise the existence of an 2071 emergency and possibly its nature, and may be able to use this to 2072 launch a physical attack on the caller. 2074 To avoid an attacker modifying the query or its result, Transport 2075 Layer Security (TLS) MUST be implemented and SHOULD be used. Use is 2076 RECOMMENDED both for clients' queries to servers and for queries 2077 among servers; this latter recommendation is to help avoid LoST cache 2078 poisoning attacks by replacing answers given to caching LoST servers. 2080 The use of server identity checks with TLS, as described in Section 2081 3.1 of [5], is also RECOMMENDED. Omitting the server identity check 2082 allows an attacker to masquerade as a LoST server, so this approach 2083 should be used only when getting any answer, even from a potentially 2084 malicious LoST server, is preferred over closing the connection (and 2085 thus not getting any answer at all). The host name compared against 2086 the server certificate is the host name in the URI, not the DNS name 2087 used as input to NAPTR resolution. 2089 Note that the security considerations in [23] recommend comparing the 2090 input of NAPTR resolution to the certificate, not the output (host 2091 name in the URI). This approach was not chosen because in emergency 2092 service use cases, it is likely that deployments will see a large 2093 number of inputs to the U-NAPTR algorithm resolving to a single 2094 server, typically run by a local emergency services authority. In 2095 this case, checking the input to the NAPTR resolution against the 2096 certificates provided by the LoST server would be impractical, as the 2097 list of organizations using it would be large, subject to rapid 2098 change, and unknown to the LoST server operator. 2100 The use of server identity does leave open the possibility of DNS- 2101 based attacks, as the NAPTR records may be altered by an attacker. 2102 The attacks include, for example, interception of DNS packets between 2103 the client and the recursive name server, DNS cache poisoning, and 2104 intentional modifications by the recursive name server; see [24] for 2105 more comprehensive discussion. 2107 DNS Security (DNSSEC) [21] can be used to protect against these 2108 threats. While DNSSEC is incompletely deployed, users should be 2109 aware of the risk, particularly when they are requesting NAPTR 2110 records in environments where the local recursive name server, or the 2111 network between the client and the local recursive name server, is 2112 not considered trustworthy. 2114 LoST deployments that are unable to use DNSSEC and unwilling to trust 2115 DNS resolution without DNSSEC cannot use the NATPR-based discovery of 2116 LoST servers as is. When suitable configuration mechanisms are 2117 available, one possibility is to configure the LoST server URIs 2118 (instead of the domain name to be used for NAPTR resolution) 2119 directly. Future specifications for applying LoST in non-emergency 2120 services may also specify additional discovery mechanisms and name 2121 matching semantics. 2123 Generally, LoST servers will not need to authenticate or authorize 2124 clients presenting mapping queries. If they do, an authentication of 2125 the underlying transport mechanism, such as HTTP basic and digest 2126 authentication, MAY be used. Basic authentication SHOULD only be 2127 used in combination with TLS. 2129 A more detailed description of threats and security requirements is 2130 provided in [18]. The threats and security requirements in non- 2131 emergency service uses of LoST may be considerably different from 2132 those described here. For example, an attacker might seek monetary 2133 benefit by returning service mapping information that directed users 2134 to specific service providers. Before deploying LoST in new 2135 contexts, a thorough analysis of the threats and requirements 2136 specific to that context should be undertaken and decisions made on 2137 the appropriate mitigations. 2139 19. Acknowledgments 2141 For the acknowledgments to the initial LoST version please refer to 2142 RFC 5222 [2]. 2144 We would like to thank the following persons for their review 2145 comments to this revised version of LoST: Avery Penniston. 2147 20. References 2149 20.1. Normative References 2151 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2152 Levels", BCP 14, RFC 2119, March 1997. 2154 [2] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, 2155 "LoST: A Location-to-Service Translation Protocol", RFC 5222, 2156 August 2008. 2158 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2159 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 2161 [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2162 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2163 HTTP/1.1", RFC 2616, June 1999. 2165 [5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2167 [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 2168 RFC 3023, January 2001. 2170 [7] Peterson, J., "A Presence-based GEOPRIV Location Object 2171 Format", RFC 4119, December 2005. 2173 [8] Freed, N. and J. Klensin, "Media Type Specifications and 2174 Registration Procedures", BCP 13, RFC 4288, December 2005. 2176 [9] Daigle, L., "Domain-Based Application Service Location Using 2177 URIs and the Dynamic Delegation Discovery Service (DDDS)", 2178 RFC 4848, April 2007. 2180 [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 2181 and Other Well-Known Services", RFC 5031, January 2008. 2183 [11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 2184 for Presence Information Data Format Location Object 2185 (PIDF-LO)", RFC 5139, February 2008. 2187 [12] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, 2188 "Geographic information - Geography Markup Language (GML)", OGC 2189 Standard OpenGIS 03-105r1, April 2004. 2191 [13] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application 2192 Schema for use by the Internet Engineering Task Force (IETF)", 2193 Candidate OpenGIS Implementation Specification , December 2006. 2195 20.2. Informative References 2197 [14] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 2198 PIDF-LO Usage Clarification, Considerations and 2199 Recommendations", Work in Progress, February 2008. 2201 [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2202 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2203 Session Initiation Protocol", RFC 3261, June 2002. 2205 [16] Saint-Andre, P., Ed., "Extensible Messaging and Presence 2206 Protocol (XMPP): Instant Messaging and Presence", RFC 3921, 2207 October 2004. 2209 [17] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 2210 December 2004. 2212 [18] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, 2213 "Security Threats and Requirements for Emergency Call Marking 2214 and Mapping", RFC 5069, January 2008. 2216 [19] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 2217 Context Resolution with Internet Technologies", RFC 5012, 2218 January 2008. 2220 [20] Schulzrinne, H., "Location-to-URL Mapping Architecture and 2221 Framework", Work in Progress, September 2007. 2223 [21] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 2224 "DNS Security Introduction and Requirements", RFC 4033, 2225 March 2005. 2227 [22] Rosen, B. and J. Polk, "Best Current Practice for 2228 Communications Services in support of Emergency Calling", Work 2229 in Progress, February 2008. 2231 [23] Daigle, L. and A. Newton, "Domain-Based Application Service 2232 Location Using SRV RRs and the Dynamic Delegation Discovery 2233 Service (DDDS)", RFC 3958, January 2005. 2235 [24] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 2236 System (DNS)", RFC 3833, August 2004. 2238 [25] "", . 2241 [26] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 2242 Location-to-Service Translation (LoST) Servers Using the 2243 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 2244 August 2008. 2246 Appendix A. Changes from RFC 5222 2247 -00: Based on RFC 5222 the following changes were made: 2249 * New terminology introduced for "location validation". Still 2250 necessary to double-check it with the latest terms used in 2251 NENA. 2253 * Editorial changes in Section 1 regarding service boundary 2254 hints. 2256 * Clarified in Section 3 that service numbers are provided in the 2257 a message rather than in a separate 2258 message. 2260 * Provided additional description in Section 5.1 regarding the 2261 'lastUpdated' attribute and when a new mapping is created. 2263 * Added a note about the usage of the NO-EXPIRATION value in 2264 Section 5.2. 2266 * Fixed a wrong statement in Section 11 saying that the 2267 elements are optional in the 2268 message. They are mandatory. 2270 * Included a clarification in Section 12.3 about why a response 2271 may contain more than one element. 2273 The following changes are pending and require discussion on the 2274 list: 2276 * Removal of the warning element since the 2277 functionality is already accomplished by including the 2278 element with the substituted service URN. 2280 * Allowing the element to contain location of 2281 profiles that were not included in the request. Example: 2282 Request with civic location information and response with 2283 geodetic service boundary. 2285 * Description of how load balancing / alternate routing is 2286 accomplished. 2288 * Inclusion of a contact info for error reporting in case there 2289 are failures. 2291 * Provide additional description regarding the service boundary 2292 matching when the civic location profile is used. 2294 Appendix B. Non-Normative RELAX NG Schema in XML Syntax 2296 2297 2302 2303 2304 Location-to-Service Translation (LoST) Protocol 2306 A LoST XML instance has three request types, each with 2307 a corresponding response type: find service, list services, 2308 and get service boundary. 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2324
2325 2326 The queries. 2327 2329 2330 2331 2332 2333 2334 2335 2336 false 2337 2338 2339 2340 2341 2342 reference 2343 value 2344 2345 reference 2346 2347 2348 2349 2350 2351 false 2352 2353 2354 2355 2357 2358 2359 2360 2361 2363 2364 2365 2366 2367 2368 2369 2370 true 2371 2372 2373 2374 2376 2377 2378 2379 2380 2381 2383
2385
2386 2387 The responses. 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2402 2403 2404 2405 2406 2407 2409 2410 2411 2412 2413 2414 2415 2417 2418 2419 2420 2421 2422 2424
2426
2427 2428 A pattern common to some of the queries. 2429 2431 2432 2433 2434 2436 2437 2438 2439
2441
2442 2443 A pattern common to responses. 2444 2446 2447 2448 2449 2450 2451 2452 2453
2455
2456 2457 Location in Requests 2458 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470
2472
2473 2474 Location Information 2475 2477 2478 2479 2480 2481 2482 2483 2485 2486 2487 2488
2490
2491 2492 Service Boundary 2493 2495 2496 2497 2498 2499 2500 2501 2502
2504
2505 2506 Service Boundary Reference 2507 2509 2511 2512 2513 2514 2515 2516 2518 2519 2520 2521 2522 2524
2526
2527 2528 Path - 2529 Contains a list of via elements - 2530 places through which information flowed 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542
2544
2545 2546 Location Used 2547 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558
2560
2561 2562 Expires pattern 2563 2565 2566 2567 2568 2569 NO-CACHE 2570 NO-EXPIRATION 2571 2572 2573 2574
2576
2577 2578 A QName list 2579 2580 2581 2582 2583 2584 2585 2586 2587
2589
2590 2591 A location-to-service mapping. 2592 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 [0-9*#]+ 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2636
2638
2639 2640 Location validation 2641 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663
2665
2666 2667 Errors and Warnings Container. 2668 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 2704 2705 2706 2707 2708 2709 2710 2711 2713 2714 2715 2716 2717 2719 2720 2721 2722 2723 2725
2727
2728 2729 Basic Exceptions 2730 2732 2733 2734 Exception pattern. 2735 2736 2737 2738 2740 2741 2742 2743 2744 2746 2747 2748 2749 2750 2752 2753 2754 2755 2756 2758 2759 2760 2761 2762 2764 2765 2766 2767 2768 2770 2771 2772 2774 2775 2777 2778 2779 2780 2781 2783 2784 2785 2786 2787 2789 2790 2791 2792 2793 2795 2796 2797 2798 2799 2801 2802 2803 2804 2805 2807 2808 2809 2810 2811 2813 2814 2815 2816 2817 2818 2819 2820 2822
2824
2825 2826 Redirect. 2827 2829 2830 2831 Redirect pattern 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2843
2845
2846 2847 Some common patterns. 2848 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 ([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+ 2873 2874 2876 2877 2878 2879 2880 2882 2883 2884 2885 2886 2887 2888 2889 2890 2892
2894
2895 2896 Patterns for inclusion of elements from schemas in 2897 other namespaces. 2898 2900 2901 2902 Any element not in the LoST namespace. 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2915 2916 2917 A wildcard pattern for including any element 2918 from any other namespace. 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2934 2935 2936 A point where future extensions 2937 (elements from other namespaces) 2938 can be added. 2939 2940 2941 2942 2943 2945
2947
2949 Figure 21 2951 Appendix C. Examples Online 2953 The XML examples and Relax NG schemas may be found online [25]. 2955 Authors' Addresses 2957 Ted Hardie 2959 EMail: ted.ietf@gmail.com 2960 Andrew Newton 2961 American Registry for Internet Numbers 2962 3635 Concorde Parkway, Suite 200 2963 Chantilly, VA 20151 2964 US 2966 Phone: +1 703 227 9894 2967 EMail: andy@hxr.us 2969 Henning Schulzrinne 2970 Columbia University 2971 Department of Computer Science 2972 450 Computer Science Building 2973 New York, NY 10027 2974 US 2976 Phone: +1 212 939 7004 2977 EMail: hgs+ecrit@cs.columbia.edu 2978 URI: http://www.cs.columbia.edu 2980 Hannes Tschofenig 2981 Nokia Siemens Networks 2982 Linnoitustie 6 2983 Espoo 02600 2984 Finland 2986 Phone: +358 (50) 4871445 2987 EMail: Hannes.Tschofenig@nsn.com 2988 URI: http://www.tschofenig.priv.at