idnits 2.17.1 draft-ietf-ecrit-lost-07.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 2931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2942. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2949. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2955. 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 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2008) is 5921 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-10 -- 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-03 Summary: 7 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: August 10, 2008 American Registry for Internet 6 Numbers 7 H. Schulzrinne 8 Columbia University 9 H. Tschofenig 10 Nokia Siemens Networks 11 February 7, 2008 13 LoST: A Location-to-Service Translation Protocol 14 draft-ietf-ecrit-lost-07.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 August 8, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 This document describes an XML-based protocol for mapping service 48 identifiers and geodetic or civic location information to service 49 contact URIs. In particular, it can be used to determine the 50 location-appropriate PSAP for emergency services. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology and Requirements Notation . . . . . . . . . . . . 6 56 3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7 57 4. LoST Servers and Their Resolution . . . . . . . . . . . . . . 9 58 5. The Element . . . . . . . . . . . . . . . . . . . . 10 59 5.1. The Mapping Data Source: 'source', 'sourceId' and 60 'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10 61 5.2. Mapping Validity: The 'expires' Attribute . . . . . . . . 10 62 5.3. Describing the Service with the Element . . 11 63 5.4. The Mapped Service: the Element . . . . . . . . 11 64 5.5. Defining the Service Region with the 65 Element . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.6. Service Boundaries by Reference: the 67 Element . . . . . . . . . . . . 12 68 5.7. The Service Number: the Element . . . . . 13 69 5.8. Service URLs: the Element . . . . . . . . . . . . . 13 70 6. Path of a Request: the Element . . . . . . . . . . . . 14 71 7. Identifying the Location Element Used for Mapping: 72 . . . . . . . . . . . . . . . . . . . . . . . . 15 73 8. Mapping a Location and Service to URLs: . . . . 16 74 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 8.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 16 77 8.2.2. Civic Address Mapping Example . . . . . . . . . . . . 17 78 8.3. Components of the Request . . . . . . . . . 19 79 8.3.1. The Element . . . . . . . . . . . . . . . . 19 80 8.3.2. Identifying the Service: The Element . . . 20 81 8.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 20 82 8.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 20 83 8.3.5. Requesting Civic Location Validation . . . . . . . . . 20 84 8.4. Components of the Mapping Response 85 . . . . . . . . . . . . . . . . . . 22 86 8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22 87 8.4.2. Civic Address Validation: the 88 Element . . . . . . . . . . . . . 23 89 9. Retrieving the Service Boundary via . . . 24 90 10. List Services: . . . . . . . . . . . . . . . . 27 91 11. List Services By Location: . . . . . 28 92 12. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 30 93 12.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 31 94 12.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 34 95 12.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 35 96 13. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 37 97 13.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 98 13.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 39 99 13.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 40 100 14. LoST Transport: HTTP . . . . . . . . . . . . . . . . . . . . . 42 101 15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43 102 16. Internationalization Considerations . . . . . . . . . . . . . 50 103 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 104 17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51 105 17.2. Content-type registration for 'application/lost+xml' . . . 51 106 17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53 107 17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53 108 17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54 109 18. Security Considerations . . . . . . . . . . . . . . . . . . . 55 110 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 111 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 112 20.1. Normative References . . . . . . . . . . . . . . . . . . . 58 113 20.2. Informative References . . . . . . . . . . . . . . . . . . 59 114 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 60 115 Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 74 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 117 Intellectual Property and Copyright Statements . . . . . . . . . . 76 119 1. Introduction 121 Protocols such as NAPTR records and the Service Location Protocol 122 (SLP) can be used to discover servers offering a particular service. 123 However, for an important class of services the appropriate specific 124 service instance depends both on the identity of the service and the 125 geographic location of the entity that needs to reach it. Emergency 126 telecommunications services are an important example; here, the 127 service instance is a Public Safety Answering Point (PSAP) that has 128 jurisdiction over the location of the user making the call. The 129 desired PSAP isn't necessarily the one that is topologically or even 130 line-of-sight closest to the caller; rather, it is the one that 131 serves the caller's location based on jurisdictional boundaries. 133 This document describes a protocol for mapping a service identifier 134 and location information compatible with PIDF-LO PIDF-LO [6] to one 135 or more service URIs. Service identifiers take the form of the 136 service URNs described in [9]. Location information here includes 137 revised civic location information [10] and a subset of the PIDL-LO 138 profile [13] which consequently includes the Geo-Shapes [12] defined 139 for GML [11]. Example service URI schemes include sip [14], xmpp 140 [15], and tel [16]. While the initial focus is on providing mapping 141 functions for emergency services, it is likely that the protocol is 142 applicable to other service URNs. For example, in the United States, 143 the "2-1-1" and "3-1-1" service numbers follow a similar location-to- 144 service behavior as emergency services. 146 This document names this protocol "LoST", for Location-to-Service 147 Translation. LoST Satisfies the requirements [18] for mapping 148 protocols. LoST provides a number of operations, centered around 149 mapping locations and service URNs to service URLs and associated 150 information. LoST mapping queries can contain either civic or 151 geodetic location information. For civic addresses, LoST can 152 indicate which parts of the civic address are known to be valid or 153 invalid, thus providing address validation, as described in Section 154 3.5 of [18]. LoST indicates errors in the location data to 155 facilitate debugging and proper user feedback, but also provides 156 best-effort answers. 158 LoST queries can be resolved recursively or iteratively. To minimize 159 round trips and to provide robustness against network failures, LoST 160 supports caching of individual mappings and indicates the region for 161 which the same answer would be returned ("service region"). 163 As defined in this document, LoST messages are carried in HTTP and 164 HTTPS protocol exchanges, facilitating use of TLS for protecting the 165 integrity and confidentiality of requests and responses. 167 This document focuses on the description of the protocol between the 168 mapping client and the mapping server. Other functions, such as 169 discovery of mapping servers, data replication and the overall 170 mapping server architecture are described in a separate document 171 [19]. 173 The query message carries location information and a service 174 identifier encoded as a Uniform Resource Name (URN) (see [9]) from 175 the LoST client to the LoST server. The LoST server uses its 176 database to map the input values to one or more Uniform Resource 177 Identifiers (URI) and returns those URIs along with optional 178 information, such as hints about the service boundary, in a response 179 message to the LoST client. If the server cannot resolve the query 180 itself, it may in turn query another server or return the address of 181 another LoST server, identified by a LoST server name. In addition 182 to the mapping function described in Section 8, the protocol also 183 allows to retrieve the service boundary (see Section 9) and to list 184 the services available for a particular location (see Section 11) or 185 supported by a particular server (see Section 10). 187 2. Terminology and Requirements Notation 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [1]. 193 This document uses the following terms: 195 Mapping: Mapping is a process that takes a location and a service 196 identifier as inputs and returns one or more URIs. Those URIs can 197 either point to a host providing that service or to a host that in 198 turn routes the request to the final destination. This definition 199 is a generalization of the term "mapping" as used in [18], because 200 LoST can be used for non-emergency services. 202 LoST client: A host acts as a LoST client if it sends LoST query 203 messages and receives LoST response messages. 205 LoST server: A host acts as a LoST server if it receives LoST query 206 messages and sends LoST response messages. In recursive 207 operation, the same entity may be both a client and a server. 209 Authoritative LoST server: An authoritative server acts only as a 210 server and successfully resolves the input location and service 211 identifier to a URI or set of URIs. 213 Service boundary: A service boundary circumscribes the region within 214 which all locations map to the same service URI or set of URIs for 215 a given service. A service boundary may consist of several non- 216 contiguous geometric shapes. 218 Validation: 220 The term "validation" describes the behavior defined as "location 221 validation" in Section 3.5 of [18]. 223 Additional emergency service terminology can be found in [18]. 225 3. Overview of Protocol Usage 227 The LoST protocol supports the following type of queries and 228 responses: 230 and 232 A LoST client retrieves contact URIs based on location information 233 and a service identifier with this request and response. The same 234 query type may also ask for location validation and for service 235 numbers, either combined with a mapping request or separately. 236 The details can be found in Section 8 and Section 8.4. 238 and 240 A LoST client obtains a service boundary with this request and 241 response, as described in Section 9. 243 and 245 With this request and response, a LoST client can find out which 246 services a LoST server supports, as described in Section 10. 248 and 250 A LoST client can determine with this request and response which 251 services are available for a specific location region. Section 11 252 describes the details. 254 LoST clients may initiate any of the above queries at any time. 255 Among the common triggers are: 257 1. When the client initially starts up or attaches to a network; 259 2. when the client detects that its location has changed 260 sufficiently that it is outside the bounds of the service region; 262 3. when a SIP message arrives at a SIP proxy performing location- 263 based call routing; 265 4. when cached mapping information has expired; 267 5. when invoking a particular service. At that time, a client may 268 omit requests for service boundaries or other auxiliary 269 information. 271 A service-specific Best Current Practice (BCP) document, such as 272 [20], governs whether a client is expected to invoke the mapping 273 service just before needing the service or whether to rely on cached 274 answers. Cache entries expire at their expiration time (see 275 Section 5.2), or they become invalid if the caller's device moves 276 beyond the boundaries of the service region. 278 4. LoST Servers and Their Resolution 280 LoST servers are identified by U-NAPTR/DDDS [8] application unique 281 strings, in the form of a DNS name. An example is 282 'lostserver.example.com'. 284 Clients need to use the U-NAPTR [8] specification described below to 285 obtain a URI (indicating host and protocol) for the applicable LoST 286 service. In this document, only the HTTP and HTTPS URL schemes are 287 defined. Note that the HTTP URL can be any valid HTTP URL, including 288 those containing path elements. 290 The following two DNS entries show the U-NAPTR resolution for 291 "example.com" to the HTTPS URL https://lostserv.example.com/secure or 292 the HTTP URL http://lostserver.example.com, with the former being 293 preferred. 295 example.com. 297 IN NAPTR 100 10 "u" "LoST:https" 298 "!.*!https://lostserver.example.com/secure!" "" 300 IN NAPTR 200 10 "u" "LoST:http" 301 "!.*!http://lostserver.example.com!" "" 303 Clients learn the LoST server's host name by means beyond the scope 304 of this specification, such as SIP configuration and DHCP. 306 5. The Element 308 The element is the core data element in LoST, describing a 309 service region and the associated service URLs. Its attributes and 310 elements are described in subsections below. 312 5.1. The Mapping Data Source: 'source', 'sourceId' and 'lastUpdated' 313 Attributes 315 The 'source', the 'sourceId' and the 'lastUpdated' attributes 316 uniquely identify a particular mapping record. They are created by 317 the authoritative source for a mapping and are never modified when a 318 mapping is served from a cache. All three attributes are REQUIRED 319 for all elements. A receiver can replace a mapping with 320 another one having the same 'source' and 'sourceId' and a more recent 321 time in 'lastUpdated'. 323 The 'source' attribute contains a LoST application unique string 324 identifying the authoritative generator of the mapping (Section 4). 326 The 'sourceId' attribute identifies a particular mapping and contains 327 an opaque token that MUST be unique among all different mappings 328 maintained by the authoritative source for that particular service. 329 For example, a Universally Unique Identifier (UUID) is a suitable 330 format. 332 The 'lastUpdated' attribute describes when a specific instance of 333 mapping, identified by the combination of 'source' and 'sourceId', 334 was last changed. The contents of this attribute has the XML data 335 type dateTime in its timezoned form, using canonical UTC 336 representation with the letter 'Z' as the timezone indicator. 338 5.2. Mapping Validity: The 'expires' Attribute 340 The 'expires' attribute contains the absolute time at which the 341 mapping becomes invalid. The contents of this attribute is a 342 timezoned XML type dateTime, in canonical representation. See 343 Section 3 regarding how this value is to be utilized with a cache. 344 The 'expires' attribute is REQUIRED to be included in the 345 element. 347 Optionally, this attribute may contain the values of 'NO-CACHE' and 348 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is 349 an indication that the mapping should not be cached. The value of 350 'NO-EXPIRATION' is an indication that the mapping does not expire. 352 On occasion, a server may be forced to return an expired mapping if 353 it cannot reach the authoritative server or the server fails to 354 return a usable answer. Clients and servers MAY cache the mapping so 355 that they have at least some information available. Caching servers 356 that have such stale information SHOULD re-attempt the query each 357 time a client requests a mapping. Since the expired mapping will be 358 returned to the client as a non-error/non-warning response ,the 359 client MUST check the 'expires' attribute; if the mapping has 360 expired, local policy at the client determines whether it discards 361 the answer and tries again later or uses the possibly stale response. 363 5.3. Describing the Service with the Element 365 Zero or more elements describe the service with a 366 string that is suitable for display to human users, each annotated 367 with the 'xml:lang' attribute that contains a language tag to aid in 368 the rendering of text. 370 5.4. The Mapped Service: the Element 372 The mandatory element identifies the service for which this 373 mapping applies. Two cases need to be distinguished when the LoST 374 server sets the element in the response message: 376 1. If the requested service, identified by the service URN [9] in 377 the element of the request, exists for the location 378 indicated, then the LoST server copies the service URN from the 379 request into the element. 381 2. If, however, the requested service, identified by the service URN 382 [9] in the element in the request, does not exist for 383 the location indicated, the server can either return an 384 (Section 13.1) error or can provide an 385 alternate service that approximates the desired service for that 386 location. In the latter case, the server MUST include a 387 element with the alternative service URN. The choice 388 of service URN is left to local policy, but the alternate service 389 should be able to satisfy the original service request. 391 5.5. Defining the Service Region with the Element 393 A response MAY indicate the region for which the service URL returned 394 would be the same as in the actual query, the so-called _service 395 region_. The service region can be indicated by value or by 396 reference (see Section 5.6). If a client moves outside the service 397 area and wishes to obtain current service data, it sends a new query 398 with its current location. The service region is described by value 399 in one or more elements, each formatted according 400 to a specific location profile, identified by the 'profile' attribute 401 (see Section 12). serviceBoundary elements formatted according to 402 different location profiles are alternative representations of the 403 same area, not additive to one another; this allows a client 404 understanding only one of the profile types to be sure it has a 405 complete view of the serviceBoundary. Within a serviceBoundary 406 element there may, however, be multiple locations which _are_ 407 additive; this is necessary because some serviceBoundary areas could 408 not be easily expressed with a single shape or civic location. If 409 included in a response, the element MUST contain at 410 least one service boundary that uses the same profile as the request. 412 A service boundary is requested by the client, using the 413 'serviceBoundary' attribute in the request with the value set to 414 "value". 416 5.6. Service Boundaries by Reference: the 417 Element 419 Since geodetic service boundaries may contain thousands of points and 420 can thus be quite large, clients may wish to conserve bandwidth by 421 requesting a reference to the service boundary instead of the value 422 described in Section 5.5. The identifier of the service boundary is 423 returned as an attribute of the element, 424 along with a LoST application unique string (see Section 4) 425 identifying the server from where it can be retrieved. The actual 426 value of the service boundary is then retrieved with the 427 getServiceBoundary (Section 9) request. 429 A reference to a service boundary is requested by the client (using 430 the 'serviceBoundary' attribute in the request with the value set to 431 "reference"). A LoST server may decide, based on local policy, to 432 return the service boundary per value or to omit the 433 element in the response. 435 The identifier is a random token with at least 128 bits of entropy 436 and can be assumed to be globally unique. It uniquely references a 437 particular boundary. If the boundary changes, a new identifier MUST 438 be chosen. Because of these properties, a client receiving a mapping 439 response can simply check if it already has a copy of the boundary 440 with that identifier. If so, it can skip checking with the server 441 whether the boundary has been updated. Since service boundaries are 442 likely to remain unchanged for extended periods of time, possibly 443 exceeding the normal lifetime of the service URL, this approach 444 avoids unnecessarily refreshing the boundary information just because 445 the remainder of the mapping has become invalid. 447 5.7. The Service Number: the Element 449 The service number is returned in the optional 450 element. It contains a string of digits, * and # that a user on a 451 device with a 12-key dial pad could use to reach that particular 452 service. 454 5.8. Service URLs: the Element 456 The response returns the service URLs in one or more elements. 457 The URLs MUST be absolute URLs. The ordering of the URLs has no 458 particular significance. Each URL scheme MUST only appear at most 459 once, but it is permissible to include both secured and regular 460 versions of a protocol, such as both 'http' and 'https' or 'sip' and 461 'sips'. 463 6. Path of a Request: the Element 465 To prevent loops and to allow tracing of request and response paths, 466 all requests that allow recursion include a element that 467 contains one or more elements, each possessing an attribute 468 containing a LoST application unique string (see Section 4). The 469 order of elements corresponds to the order of LoST servers, 470 i.e., the first element identifies the server that initially 471 received the request from the client issuing the request. Every 472 server in a recursive query operation is included in the 473 elelment, including the first server to receive it. 475 The server that answers the request instead of forwarding it, such as 476 the authoritative server, copies the element verbatim into the 477 response. The element is not modified in responses as the 478 responses traverses the server chain back to the querying client. 480 If a query is answered iteratively, the querier includes all servers 481 that it has already contacted. 483 When a cached mapping is returned then the element cached 484 together with the mapping is returned. 486 The example in Figure 5 indicates that the answer was given to the 487 client by the LoST server at esgw.ueber-110.de.example, which got the 488 answer from the (authoritative) LoST server at 489 polizei.muenchen.de.example. 491 7. Identifying the Location Element Used for Mapping: 493 Several of the requests can provide one or more elements, 494 among which the server gets to choose. It is useful for the client 495 to be able to determine which one was actually used in producing the 496 result. For that purpose, the tag MUST contain an 'id' 497 attribute that uniquely identifies the element. The 498 format of the identifier is left to the client; it could, for 499 example, use a hash of the location information. The server returns 500 the identifier for the element it used in the 501 tag. See Section 8.3.1 for more details. 503 8. Mapping a Location and Service to URLs: 505 8.1. Overview 507 The query constitutes the core of the LoST 508 functionality, mapping civic or geodetic locations to URLs and 509 associated data. After giving an example, we enumerate the elements 510 of the query and response. 512 8.2. Examples 514 8.2.1. Example Using Geodetic Coordinates 516 The following is an example of mapping a service to a location using 517 geodetic coordinates, for the service associated with the police 518 (urn:service:sos.police). 520 521 527 528 529 37.775 -122.422 530 531 532 urn:service:sos.police 534 536 Figure 2: A geodetic query 538 Given the query above, a server would respond with a service, and 539 information related to that service. In the example below, the 540 server has mapped the location given by the client for a police 541 service to the New York City Police Department, instructing the 542 client that it may contact them via the URIs "sip:nypd@example.com" 543 and "xmpp:nypd@example.com". The server has also given the client a 544 geodetic, two-dimensional boundary for this service. The mapping was 545 last updated on November 1, 2006 and expires on January 1, 2007. If 546 the client's location changes beyond the given service boundary or 547 the expiration time has been reached, it may want to requery for this 548 information, depending on the usage environment of LoST. 550 551 553 558 559 New York City Police Department 560 561 urn:service:sos.police 562 563 564 565 566 37.775 -122.4194 567 37.555 -122.4194 568 37.555 -122.4264 569 37.775 -122.4264 570 37.775 -122.4194 571 572 573 574 575 sip:nypd@example.com 576 xmpp:nypd@example.com 577 911 578 579 580 581 582 583 584 586 Figure 3: A geodetic answer 588 8.2.2. Civic Address Mapping Example 590 The example below shows how to map a service to a location much like 591 the example in Section 8.2.1, but using civic address location 592 information. In this example, the client requests the service 593 associated with police (urn:service:sos.police) along with a specific 594 civic address (house number 6 on a street named Otto-Hahn-Ring in 595 Munich, Germany). 597 598 600 601 603 Germany 604 Bavaria 605 Munich 606 Otto-Hahn-Ring 607 6 608 81675 609 610 611 urn:service:sos.police 612 614 Figure 4: A civic address query 616 Given the query above, a server would respond with a service, and 617 information related to that service. In the example below, the 618 server has mapped the location given by the client for a police 619 service to the Muenchen Polizei-Abteilung, instructing the client 620 that it may contact them via the URIs sip:munich-police@example.com 621 and xmpp:munich-police@example.com. The server has also given the 622 client a civic address boundary (the city of Munich) for this 623 service. The mapping was last updated on November 1, 2006 by the 624 authoritative source "polizei.muenchen.de.example" and expires on 625 January 1, 2007. This instructs the client to requery for the 626 information if its location changes beyond the given service boundary 627 (i.e., beyond the city of Munich) or after January 1, 2007. 629 630 631 636 637 Muenchen Polizei-Abteilung 638 639 urn:service:sos.police 640 642 644 Germany 645 Bavaria 646 Munich 647 81675 648 649 650 sip:munich-police@example.com 651 xmpp:munich-police@example.com 652 110 653 654 655 656 657 658 659 661 Figure 5: A civic address answer 663 8.3. Components of the Request 665 The request includes attributes and elements that 666 govern whether the request is handled iteratively or recursively, 667 whether location validation is performed and which elements may be 668 contained in the response. 670 8.3.1. The Element 672 The query communicates location information using one 673 or more elements, which MUST conform to a location profile 674 (see Section 12). There MUST NOT be more than one location element 675 for each distinct location profile. The order of location elements 676 is significant; the server uses the first location element where it 677 understands the location profile. 679 8.3.2. Identifying the Service: The Element 681 The type of service desired is specified by the element. 682 It contains service URNs from the registry established in [9]. 684 8.3.3. Recursion and Iteration 686 LoST can operate in either recursive or iterative mode, on a request- 687 by-request basis. In recursive mode, the LoST server initiates 688 queries on behalf of the requester and returns the result to the 689 requester. 691 In iterative mode, the server contacted returns a redirection 692 response indicating the next server to be queried if the server 693 contacted cannot provide an answer itself. 695 For the queries defined in this document, only LoST and 696 queries can be recursive, as indicated by 697 the 'recursive' attribute. A value of "true" indicates a recursive 698 query, with the default being "false" when the attribute is omitted. 699 Regardless of the attribute, a server MAY always answer a query by 700 providing a LoST application unique string (see Section 4), i.e., 701 indirection, however, it MUST NOT recurse if the attribute is 702 "false". 704 8.3.4. Service Boundary 706 LoST elements can describe the service boundary either by 707 value or by reference. Returning a service boundary reference is 708 generally more space-efficient for geospatial (polygon) boundaries 709 and if the boundaries change rarely, but does incur an additional 710 request. The querier can express a preference 711 for one or the other modality with the 'serviceBoundary' attribute in 712 the request, but the server makes the final decision as 713 to whether to return a reference or a value. 715 8.3.5. Requesting Civic Location Validation 717 Civic address validation is requested by setting the optional 718 attribute 'validateLocation' to true. If the attribute is omitted, 719 it is assumed to be false. The response is described in 720 Section 8.4.2. The example in Figure 6 demonstrates address 721 validation. If the server chooses a geodetic location among the 722 locations provided in a request, the attribute is ignored. 724 725 730 731 733 DE 734 Bavaria 735 Munich 736 Otto-Hahn-Ring 737 6 738 81675 739 740 741 urn:service:sos.police 742 744 Figure 6: A query with address validation request 746 747 748 753 754 Muenchen Polizei-Abteilung 755 756 urn:service:sos.police 757 758 760 Germany 761 Bavaria 762 Munich 763 81675 764 765 766 sip:munich-police@example.com 767 xmpp:munich-police@example.com 768 110 769 770 771 country A1 A3 A6 772 PC 773 HNO 774 775 776 777 778 779 780 782 Figure 7: A message with address validation 783 information 785 8.4. Components of the Mapping Response 787 8.4.1. Overview 789 Mapping responses consist of the element (Section 5) 790 describing the mapping itself, possibly followed by warnings 791 (Section 13.2), location validation information (Section 8.4.2), and 792 an indication of the path (Section 6) the response has taken. 794 8.4.2. Civic Address Validation: the Element 796 A server can indicate in its response which civic address elements it 797 has recognized as valid, which ones it has ignored and which ones it 798 has checked and found to be invalid. The server SHOULD include this 799 information if the 'validateLocation' attribute in the request was 800 true but local policy at the server may allow this information to be 801 omitted. Each element contains a list of tokens separated by white 802 space, enumerating the civic location labels used in child elements 803 of the element. The element enumerates those 804 civic address elements that have been recognized as valid by the LoST 805 server and that have been used to determine the mapping. The 806 elements enumerates the civic address elements that the 807 server did not check and that were not used in determining the 808 response. The element enumerate civic address elements 809 that the server attempted to check, but that did not match the other 810 civic address elements found in the list. Civic location 811 tokens that are neither listed in the , the and the 812 element belong to the class of unchecked tokens. 814 Note that the same address can yield different responses if parts of 815 the civic address contradict each other. For example, if the postal 816 code does not match the city, local server policy determines whether 817 the postal code or the city is considered valid. The mapping 818 naturally corresponds to the valid elements. 820 The example shown in Figure 6 and in Figure 7 indicates that the 821 tokens 'country', 'A1', 'A3', and 'A6' have been validated by the 822 LoST server. The server considered the postal code 81675 in the 823 element as not valid for this location. The 'HNO' token belongs to 824 the class of unchecked location tokens. 826 9. Retrieving the Service Boundary via 828 As discussed in Section 5.5, the can return a 829 globally unique identifier in the 'serviceBoundary' attribute that 830 can be used to retrieve the service boundary, rather than returning 831 the boundary by value. This is shown in the example in Figure 8 and 832 Figure 9. The client can then retrieve the boundary using the 833 request and obtains the boundary in the 834 , illustrated in the example in 835 Figure 10. The client issues the request to the server identified in 836 the 'server' attribute of the element. 837 These requests are always directed to the authoritative server and do 838 not recurse. 840 841 846 847 848 37.775 -122.422 849 850 851 urn:service:sos.police 852 854 Figure 8: request and response with service boundary 855 reference 857 858 860 865 866 New York City Police Department 867 868 urn:service:sos.police 869 872 sip:nypd@example.com 873 xmpp:nypd@example.com 874 911 875 876 877 878 879 880 881 883 Figure 9: message with service boundary 884 reference 886 887 890 Figure 10: Requesting a service boundary with 892 The request may also be used to retrieve service 893 boundaries that are expressed as civic addresses, as illustrated in 894 Figure 11. 896 897 899 900 902 US 903 New York 904 New York 905 906 907 908 909 910 911 913 Figure 11: Civic Address Service Boundary Response 915 10. List Services: 917 A LoST client can ask a LoST server for the list of services that it 918 understands, primarily for diagnostic purposes. The query does not 919 contain location information, as it simply provides an indication of 920 which services the server can look up, not whether a particular 921 service is offered for a particular area. Typically, only top-level 922 services are included in the answer, implying support for all sub- 923 services. Since the query is answered by the queried server, there 924 is no notion of recursion or indirection and no path indication. The 925 (Section 11) query below can be used to find 926 out whether a particular service is offered for a specific location. 927 An example request and response are shown in Figure 12. 929 930 932 urn:service:sos 933 935 Figure 12: Example of query 937 938 940 941 urn:service:sos.ambulance 942 urn:service:sos.animal-control 943 urn:service:sos.fire 944 urn:service:sos.gas 945 urn:service:sos.mountain 946 urn:service:sos.marine 947 urn:service:sos.physician 948 urn:service:sos.poison 949 urn:service:sos.police 950 urn:service:sos.suicide 951 952 953 954 955 956 958 Figure 13: Example of 960 11. List Services By Location: 962 A LoST client can ask a LoST server for the list of services it knows 963 about for a particular area. The query 964 contains one or more elements, each from a different 965 location profile (Section 12), and may contain the element. 966 As for , the server selects the first location element 967 that has a profile the server understands and it can operate either 968 recursively or iteratively; elements track the progress of the 969 request. The query indicates the services that the server can 970 enumerate from within the forest structure of which it is a part. 971 Because LoST does not presume a single, overarching organization of 972 all potential service types, there may be services available within a 973 geographic area which could be described by other LoST servers 974 connected to other forest structures. As an example, the emergency 975 services forest for a region may be distinct from the forests that 976 locate commercial services within the same region 978 If the query contains the element, the LoST server returns 979 only immediate child services of the queried service that are 980 available for the provided location. If the element is 981 absent, the LoST service returns all top-level services available for 982 the provided location that it knows about. 984 A server responds to this query with a 985 response. This response MAY contain 986 elements (see Section 6) and MUST contain a 987 element, consisting of a whitespace-separated list of service URNs. 988 The query and response are illustrated in Figure 14 and in Figure 15, 989 respectively. 991 992 996 997 998 -34.407 150.883 999 1000 1001 urn:service:sos 1002 1004 Figure 14: Example of query 1006 1007 1009 1010 urn:service:sos.ambulance 1011 urn:service:sos.animal-control 1012 urn:service:sos.fire 1013 urn:service:sos.gas 1014 urn:service:sos.mountain 1015 urn:service:sos.marine 1016 urn:service:sos.physician 1017 urn:service:sos.poison 1018 urn:service:sos.police 1019 urn:service:sos.suicide 1020 1021 1022 1023 1024 1025 1026 1028 Figure 15: Example of response 1030 12. Location Profiles 1032 LoST uses location information in elements in requests and 1033 elements in responses. Such location information 1034 may be expressed in a variety of ways. This variety can cause 1035 interoperability problems where a request or response contains 1036 location information in a format not understood by the server or the 1037 client, respectively. To achieve interoperability, this document 1038 defines two mandatory-to-implement baseline location profiles to 1039 define the manner in which location information is transmitted. It 1040 is possible to standardize other profiles in the future. The 1041 baseline profiles are: 1043 geodetic-2d: 1045 a profile for two-dimensional geodetic location information, as 1046 described in Section 12.2; 1048 civic: 1050 a profile consisting of civic address location information, as 1051 described in Section 12.3. 1053 Requests and responses containing or 1054 elements MUST contain location information in exactly one of the two 1055 baseline profiles, in addition to zero or more additional profiles. 1056 The ordering of location information indicates a preference on the 1057 part of the sender. 1059 Standards action is required for defining new profiles. A location 1060 profile MUST define: 1062 1. The token identifying it in the LoST location profile registry; 1064 2. The formal definition of the XML to be used in requests, i.e., an 1065 enumeration and definition of the XML child elements of the 1066 element; 1068 3. The formal definition of the XML to be used in responses, i.e., 1069 an enumeration and definition of the XML child elements of the 1070 element; 1072 4. The declaration of whether geodetic-2d or civic is to be used as 1073 the baseline profile. It is necessary to explicitly declare the 1074 baseline profile as future profiles may be combinations of 1075 geodetic and civic location information. 1077 12.1. Location Profile Usage 1079 A location profile is identified by a token in an IANA-maintained 1080 registry (Section 17.5). Clients send location information compliant 1081 with a location profile, and servers respond with location 1082 information compliant with that same location profile. 1084 When a LoST client sends a request that provides 1085 location information, it includes one or more elements. A 1086 element carries an optional 'profile' attribute that 1087 indicates the location format of the child elements. A client may 1088 obtain location information that does not conform to a profile it 1089 recognizes or it may not have the capability to map XML to profiles. 1090 In that case, a client MAY omit the profile attribute and the server 1091 should interpret the XML location data to the best of its ability, 1092 returning a "locationProfileUnrecognized" error if it is unable to do 1093 so. 1095 The concept of location profiles are described in Section 12. With 1096 the ability to specify more than one element the client is 1097 able to convey location information for multiple location profiles in 1098 the same request. 1100 When a LoST server sends a response that contains location 1101 information, it uses the elements much like the 1102 client uses the elements. Each element 1103 contains location information conforming to the location profile 1104 specified in the 'profile' attribute. A response MAY contain 1105 multiple mappings or boundaries for the different 1106 elements, subject to the restrictions below. 1108 Using the location profiles defined in this document, the following 1109 rules ensure interoperability between clients and servers: 1111 1. A client MUST be capable of understanding the response for the 1112 baseline profiles it used in the request. 1114 2. If a client sends location information conformant to any location 1115 profile other than the ones described in this document, it MUST 1116 also send, in the same request, location information conformant 1117 to one of the baseline profiles. Otherwise, the server might not 1118 be able to understand the request. 1120 3. A client MUST NOT send multiple objects that are 1121 derived from different baseline profiles. In other words, a 1122 client MUST only send location objects according to the same 1123 baseline profile in a query, but it MAY contain a location 1124 element following a baseline profile in addition to some other 1125 profile. 1127 4. If a client has both location information primarily of geodetic 1128 nature and location information primarily of a civic nature, it 1129 MUST send separate requests containing each type of location 1130 information. 1132 5. There can only be one instance of each location profile in a 1133 query. 1135 6. Servers MUST implement all profiles described in this document. 1137 7. A server uses the first-listed location profile that it 1138 understands and ignores the others. 1140 8. If a server receives a request that only contains location 1141 information using profiles it does not understand, the server 1142 responds with a (Section 13.1). 1144 9. The element MUST use the same location profile 1145 that was used to retrieve the answer and indicates which profile 1146 has been used with the 'profile' attribute. 1148 These rules enable the use of location profiles not yet specified, 1149 while ensuring baseline interoperability. Take, for example, this 1150 scenario. Client X has had its firmware upgraded to support the 1151 'not-yet-standardized-prism-profile' location profile. Client X 1152 sends location information to Server Y, which does not understand the 1153 'not-yet-standardized-prism-profile' location profile. If Client X 1154 also sends location information using the geodetic-2D baseline 1155 profile, then Server Y will still be able to understand the request 1156 and provide an understandable response, though with location 1157 information that might not be as precise or expressive as desired. 1158 This is possible because both Client X and Server Y understand the 1159 baseline profile. 1161 1162 1168 1170 1171 1172 1173 1174 1175 1176 42.556844 -73.248157 36.6 1177 42.656844 -73.248157 36.6 1178 42.656844 -73.348157 36.6 1179 42.556844 -73.348157 36.6 1180 42.556844 -73.248157 36.6 1181 1182 1183 1184 1185 1186 1187 2.4 1188 1189 1190 1191 1192 1193 42.656844 -73.348157 1194 1195 1196 urn:service:sos.police 1197 1199 Figure 16: Example of a query with baseline profile 1200 interoperability 1202 1203 1206 1211 1212 New York City Police Department 1213 1214 urn:service:sos.police 1215 1216 1217 1218 1219 37.775 -122.4194 1220 37.555 -122.4194 1221 37.555 -122.4264 1222 37.775 -122.4264 1223 37.775 -122.4194 1224 1225 1226 1227 1228 sip:nypd@example.com 1229 911 1230 1231 1232 1233 1234 1235 1236 1238 Figure 17: Example of a message with baseline 1239 profile interoperability 1241 12.2. Two Dimensional Geodetic Profile 1243 The "geodetic-2d" location profile is identified by "geodetic-2d". 1244 Clients and servers use this profile by placing the following 1245 location shapes into the or into the 1246 element (unless indicated otherwise): 1248 Point: 1250 The element is described in Section 5.2.1 of [13]. 1251 Section 5.2.1 of [13] shows also the specification of a 1252 with either a two dimensional position (latitude and longitude) or 1253 three dimensional position (latitude, longitude, and altitude). A 1254 client MAY use the three dimensional position, and servers MAY 1255 interpret a three dimensional position as a two dimensional 1256 position by ignoring the altitude value. A element is not 1257 placed into a element. 1259 Polygon: 1261 The element is described in Section 5.2.2 of [13]. The 1262 restriction to 16 points for a polygon contained in Section 7.2.2 1263 of [12] is not applicable to this document. 1265 Circle: 1267 The element is described in Section 5.2.3 of [13]. 1269 Ellipse: 1271 The element is described in Section 5.2.4 of [13]. 1273 ArcBand: 1275 The element is described in Section 5.2.5 of [13]. 1277 When clients place a , , or 1278 element within the element then it indicates that the 1279 query is about any point contained in the given area; it is left to 1280 the server to select an appropriate matching algorithm, such as using 1281 computing the centroid. A server MAY return multiple 1282 elements if the polygon extends across multiple service areas. 1284 When geodetic location information of this location profile is placed 1285 in the element then the elements with geospatial 1286 coordinates are alternative descriptions of the same service region, 1287 not additive geometries. 1289 12.3. Basic Civic Profile 1291 The basic-civic location profile is identified by the token 'civic'. 1292 Clients use this profile by placing a element, defined 1293 in [10], within the element. 1295 Servers use this profile by placing a element, defined 1296 in [10], within the element. 1298 A response MAY contain more than one element with 1299 profile 'civic'. Each element describes a set of 1300 civic addresses that fall within the service boundary, namely all 1301 addresses that textually match the civic address elements provided, 1302 regardless of the value of other address elements. A location falls 1303 within the mapping's service boundary if it matches any of the 1304 elements. Hence, a response may contain multiple 1305 elements with civic and/or geodetic location 1306 profiles. 1308 13. Errors, Warnings, and Redirects 1310 When a LoST server cannot fulfill a request completely, it can return 1311 either an error or a warning, depending on the severity of the 1312 problem. It returns an error element if no useful response can be 1313 returned for the query. It returns a element as part of 1314 another response element if it was able to respond in part, but the 1315 response may not be quite what the client had desired. For both 1316 elements, the 'source' attribute names the server that originally 1317 generated the error or warning, such as the authoritative server. 1318 Unless otherwise noted, all elements below can be either an error or 1319 a warning, depending on whether a default response, such as a 1320 mapping, is included. 1322 13.1. Errors 1324 LoST defines a pattern for errors, defined as elements in 1325 the Relax NG schema. This pattern defines a 'message' attribute 1326 containing human readable text and an 'xml:lang' attribute denoting 1327 the language of the human readable text. One or more such error 1328 elements are contained in the element. 1330 The following errors follow this basic pattern: 1332 badRequest 1334 The server could not parse or otherwise understand a request, 1335 e.g., because the XML was malformed. 1337 forbidden 1339 The server refused to send an answer. This generally only occurs 1340 for recursive queries, namely if the client tried to contact the 1341 authoritative server and was refused. 1343 internalError 1345 The server could not satisfy a request due to misconfiguration or 1346 other operational and non-protocol related reasons. 1348 locationProfileUnrecognized 1350 None of the profiles in the request were recognized by the server 1351 (see Section 12). 1353 locationInvalid 1355 The geodetic or civic location in the request was invalid. For 1356 example, the longitude or latitude values fall outside the 1357 acceptable ranges. 1359 SRSInvalid 1361 The spatial reference system (SRS) contained in the location 1362 element was not recognized or does not match the location profile. 1364 loop 1366 During a recursive query, the server was about to visit a server 1367 that was already in the server list in the element, 1368 indicating a request loop. 1370 notFound 1372 The server could not find an answer to the query. 1374 serverError 1376 An answer was received from another LoST server, but it could not 1377 be parsed or otherwise understood. This error occurs only for 1378 recursive queries. 1380 serverTimeout 1382 A time out occurred before an answer was received. 1384 serviceNotImplemented 1386 The requested service URN is not implemented and no substitution 1387 was available. 1389 An example is below: 1391 1392 1394 1395 1397 Figure 18: Example of an error resonse 1399 13.2. Warnings 1401 A response MAY contain zero or more warnings. This pattern defines a 1402 'message' attribute containing human readable text and an 'xml:lang' 1403 attribute denoting the language of the human readable text. One or 1404 more such warning elements are contained in the element. 1405 To provide human readable text in an appropriate language the HTTP 1406 content negotiation capabilities (see Section 14) MAY be utilized by 1407 a server. 1409 This version of the specification defines the following warnings: 1411 locationValidationUnavailable 1413 The element MAY be returned when a 1414 server wishes to notify a client that it cannot fulfill a location 1415 validation request. This warning allows a server to return 1416 mapping information while signalling this exception state. 1418 serviceSubstitution 1420 The element MAY be returned when a server 1421 was not able to fulfill a request for a given 1422 service URN. For example, a request with the 1423 'urn:service:sos.police' service URN for a location in Uruguay may 1424 cause the LoST service to return a mapping for the 1425 'urn:service:sos' service URN since Uruguay does not make use of 1426 the sub-services police, fire and ambulance. If this warning is 1427 returned then the element in the response provides 1428 information about the service URN that refers to the mapping. 1430 defaultMappingReturned 1432 The element MAY be returned when a server 1433 was not able to fulfill a request for a given 1434 location but is able to respond with a default URI. For example, 1435 a nearby PSAP may be returned. 1437 An example of a warning is shown below: 1439 1440 1442 1447 1448 New York City Police Department 1449 1450 urn:service:sos.police 1451 1452 1453 1454 1455 37.775 -122.4194 1456 37.555 -122.4194 1457 37.555 -122.4264 1458 37.775 -122.4264 1459 37.775 -122.4194 1460 1461 1462 1463 1464 sip:nypd@example.com 1465 1466 1467 1471 1472 1473 1474 1475 1476 1478 Figure 19: Example of an warning resonse 1480 13.3. Redirects 1482 A LoST server can respond indicating that the querier should redirect 1483 the query to another server, using the element. The 1484 element includes a 'target' attribute indicating the LoST application 1485 unique string (see Section 4) that the client SHOULD be contacting 1486 next, as well as the 'source' attribute indicating the server that 1487 generated the redirect response and a 'message' attribute explaining 1488 the reason for the redirect response. During a recursive query, a 1489 server receiving a response can decide whether it wants to 1490 follow the redirection or simply return the response to its upstream 1491 querier. 1493 An example is below: 1495 1496 1501 Figure 20: Example of a redirect response 1503 14. LoST Transport: HTTP 1505 LoST needs an underlying protocol transport mechanisms to carry 1506 requests and responses. This document defines the use of LoST over 1507 HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future 1508 documents. The available transport mechanisms are determined through 1509 the use of the LoST U-NAPTR application. In protocols that support 1510 content type indication, LoST uses the media type application/ 1511 lost+xml. 1513 When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP 1514 POST method. The HTTP request MUST use the Cache-Control response 1515 directive "no-cache" to HTTP-level "caching even by caches that have 1516 been configured to return stale responses to client requests." 1518 All LoST responses, including those indicating a LoST warning or 1519 error, are carried in 2xx responses, typically 200 (OK). Other 2xx 1520 responses, in particular 203 (Non-authoritative information) may be 1521 returned by HTTP caches that disregard the caching instructions. 3xx, 1522 4xx and 5xx HTTP response codes indicates that the HTTP request 1523 itself failed or was redirected; these responses do not contain any 1524 LoST XML elements. The 3xx responses are distinct from the redirects 1525 which are described in Section 13.3; the 13.3 redirects occur after a 1526 LoST server processes the request. Where an HTTP-layer redirect will 1527 be general, a LoST server redirect as described in 13.3 might be 1528 specific to a specific service or be the result of other processing 1529 by the LoST server. 1531 The HTTP URL is derived from the LoST server name via U-NAPTR 1532 application, as discussed above. 1534 15. Relax NG Schema 1536 This section provides the Relax NG schema used by LoST protocol in 1537 the compact form. The verbose form is included in Appendix A. 1539 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 1540 default namespace ns1 = "urn:ietf:params:xml:ns:lost1" 1542 ## 1543 ## Location-to-Service Translation Protocol (LoST) 1544 ## 1545 ## A LoST XML instance has three request types, each with 1546 ## a cooresponding response type: find service, list services, 1547 ## and get service boundary. 1548 ## 1549 start = 1550 findService 1551 | listServices 1552 | listServicesByLocation 1553 | getServiceBoundary 1554 | findServiceResponse 1555 | listServicesResponse 1556 | listServicesByLocationResponse 1557 | getServiceBoundaryResponse 1558 | errors 1559 | redirect 1561 ## 1562 ## The queries. 1563 ## 1564 div { 1565 findService = 1566 element findService { 1567 requestLocation, 1568 commonRequestPattern, 1569 attribute validateLocation { 1570 xsd:boolean >> a:defaultValue [ "false" ] 1571 }?, 1572 attribute serviceBoundary { 1573 ("reference" | "value") >> a:defaultValue [ "reference" ] 1574 }?, 1575 attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? 1576 } 1577 listServices = element listServices { commonRequestPattern } 1578 listServicesByLocation = 1579 element listServicesByLocation { 1580 requestLocation, 1581 commonRequestPattern, 1582 attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? 1583 } 1584 getServiceBoundary = 1585 element getServiceBoundary { serviceBoundaryKey, extensionPoint } 1586 } 1588 ## 1589 ## The responses. 1590 ## 1591 div { 1592 findServiceResponse = 1593 element findServiceResponse { 1594 mapping+, locationValidation?, commonResponsePattern, locationUsed 1595 } 1596 listServicesResponse = 1597 element listServicesResponse { serviceList, commonResponsePattern } 1598 listServicesByLocationResponse = 1599 element listServicesByLocationResponse { 1600 serviceList, commonResponsePattern, locationUsed 1601 } 1602 getServiceBoundaryResponse = 1603 element getServiceBoundaryResponse { 1604 serviceBoundary, commonResponsePattern 1605 } 1606 } 1608 ## 1609 ## A pattern common to some of the queries. 1610 ## 1611 div { 1612 commonRequestPattern = service, path?, extensionPoint 1613 } 1615 ## 1616 ## A pattern common to responses. 1617 ## 1618 div { 1619 commonResponsePattern = warnings*, path, extensionPoint 1620 } 1622 ## 1623 ## Location in Requests 1624 ## 1625 div { 1626 requestLocation = 1627 element location { 1628 attribute id { xsd:token }, 1629 locationInformation 1630 }+ 1631 } 1633 ## 1634 ## Location Information 1635 ## 1636 div { 1637 locationInformation = 1638 extensionPoint+, 1639 attribute profile { xsd:NMTOKEN }? 1640 } 1642 ## 1643 ## Service Boundary 1644 ## 1645 div { 1646 serviceBoundary = element serviceBoundary { locationInformation }+ 1647 } 1649 ## 1650 ## Service Boundary Reference 1651 ## 1652 div { 1653 serviceBoundaryReference = 1654 element serviceBoundaryReference { 1655 source, serviceBoundaryKey, extensionPoint 1656 } 1657 serviceBoundaryKey = attribute key { xsd:token } 1658 } 1660 ## 1661 ## Path - 1662 ## Contains a list of via elements - 1663 ## places through which information flowed 1664 ## 1665 div { 1666 path = 1667 element path { 1668 element via { source, extensionPoint }+ 1669 } 1670 } 1672 ## 1673 ## Location Used 1674 ## 1675 div { 1676 locationUsed = 1677 element locationUsed { 1678 attribute id { xsd:token } 1679 }? 1680 } 1682 ## 1683 ## Expires pattern 1684 ## 1685 div { 1686 expires = 1687 attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } 1688 } 1690 ## 1691 ## A QName list 1692 ## 1693 div { 1694 qnameList = list { xsd:QName* } 1695 } 1697 ## 1698 ## A location-to-service mapping. 1699 ## 1700 div { 1701 mapping = 1702 element mapping { 1703 element displayName { 1704 xsd:string, 1705 attribute xml:lang { xsd:language } 1706 }*, 1707 service, 1708 (serviceBoundary | serviceBoundaryReference)?, 1709 element uri { xsd:anyURI }*, 1710 element serviceNumber { 1711 xsd:token { pattern = "[0-9*#]+" } 1712 }?, 1713 extensionPoint, 1714 expires, 1715 attribute lastUpdated { xsd:dateTime }, 1716 source, 1717 attribute sourceId { xsd:token }, 1718 message 1719 } 1720 } 1722 ## 1723 ## Location validation 1724 ## 1725 div { 1726 locationValidation = 1727 element locationValidation { 1728 element valid { qnameList }?, 1729 element invalid { qnameList }?, 1730 element unchecked { qnameList }?, 1731 extensionPoint 1732 } 1733 } 1735 ## 1736 ## Errors and Warnings Container. 1737 ## 1738 div { 1739 exceptionContainer = 1740 (badRequest? 1741 & internalError? 1742 & serviceSubstitution? 1743 & defaultMappingReturned? 1744 & forbidden? 1745 & notFound? 1746 & loop? 1747 & serviceNotImplemented? 1748 & serverTimeout? 1749 & serverError? 1750 & locationInvalid? 1751 & locationProfileUnrecognized?), 1752 extensionPoint, 1753 source 1754 errors = element errors { exceptionContainer } 1755 warnings = element warnings { exceptionContainer } 1756 } 1758 ## 1759 ## Basic Exceptions 1760 ## 1761 div { 1763 ## 1764 ## Exception pattern. 1765 ## 1766 basicException = message, extensionPoint 1767 badRequest = element badRequest { basicException } 1768 internalError = element internalError { basicException } 1769 serviceSubstitution = element serviceSubstitution { basicException } 1770 defaultMappingReturned = 1771 element defaultMappingReturned { basicException } 1772 forbidden = element forbidden { basicException } 1773 notFound = element notFound { basicException } 1774 loop = element loop { basicException } 1775 serviceNotImplemented = 1776 element serviceNotImplemented { basicException } 1777 serverTimeout = element serverTimeout { basicException } 1778 serverError = element serverError { basicException } 1779 locationInvalid = element locationInvalid { basicException } 1780 locationValidationUnavailable = 1781 element locationValidationUnavailable { basicException } 1782 locationProfileUnrecognized = 1783 element locationProfileUnrecognized { 1784 attribute unsupportedProfiles { xsd:NMTOKENS }, 1785 basicException 1786 } 1787 } 1789 ## 1790 ## Redirect. 1791 ## 1792 div { 1794 ## 1795 ## Redirect pattern 1796 ## 1797 redirect = 1798 element redirect { 1799 attribute target { appUniqueString }, 1800 source, 1801 message, 1802 extensionPoint 1803 } 1804 } 1806 ## 1807 ## Some common patterns. 1808 ## 1809 div { 1810 message = 1811 (attribute message { xsd:token }, 1812 attribute xml:lang { xsd:language })? 1813 service = element service { xsd:anyURI }? 1814 appUniqueString = 1815 xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } 1816 source = attribute source { appUniqueString } 1817 serviceList = 1818 element serviceList { 1819 list { xsd:anyURI* } 1820 } 1821 } 1823 ## 1824 ## Patterns for inclusion of elements from schemas in 1825 ## other namespaces. 1826 ## 1827 div { 1829 ## 1830 ## Any element not in the LoST namespace. 1831 ## 1832 notLost = element * - (ns1:* | ns1:*) { anyElement } 1834 ## 1835 ## A wildcard pattern for including any element 1836 ## from any other namespace. 1837 ## 1838 anyElement = 1839 (element * { anyElement } 1840 | attribute * { text } 1841 | text)* 1843 ## 1844 ## A point where future extensions 1845 ## (elements from other namespaces) 1846 ## can be added. 1847 ## 1848 extensionPoint = notLost* 1849 } 1851 Figure 21: RelaxNG schema 1853 16. Internationalization Considerations 1855 The LoST protocol is mostly meant for machine-to-machine 1856 communications; as such, most of its elements are tokens not meant 1857 for direct human consumption. If these tokens are presented to the 1858 end user, some localization may need to occur. The content of the 1859 element and the 'message' attributes may be displayed 1860 to the end user, and they are thus complex types designed for this 1861 purpose. 1863 LoST exchanges information using XML. All XML processors are 1864 required to understand UTF-8 and UTF-16 encodings, and therefore all 1865 LoST clients and servers MUST understand UTF-8 and UTF-16 encoded 1866 XML. Additionally, LoST servers and clients MUST NOT encode XML with 1867 encodings other than UTF-8 or UTF-16. 1869 17. IANA Considerations 1871 17.1. U-NAPTR Registrations 1873 This document registers the following U-NAPTR application service 1874 tag: 1876 Application Service Tag: LoST 1878 Defining Publication: The specification contained within this 1879 document. 1881 This document registers the following U-NAPTR application protocol 1882 tags: 1884 o 1886 Application Protocol Tag: http 1888 Defining Publication: RFC 2616 [3] 1890 o 1892 Application Protocol Tag: https 1894 Defining Publication: RFC 2818 [4] 1896 17.2. Content-type registration for 'application/lost+xml' 1898 This specification requests the registration of a new MIME type 1899 according to the procedures of RFC 4288 [7] and guidelines in RFC 1900 3023 [5]. 1902 MIME media type name: application 1904 MIME subtype name: lost+xml 1906 Mandatory parameters: none 1908 Optional parameters: charset 1910 Indicates the character encoding of enclosed XML. 1912 Encoding considerations: Uses XML, which can employ 8-bit 1913 characters, depending on the character encoding used. See RFC 1914 3023 [5], Section 3.2. 1916 Security considerations: This content type is designed to carry LoST 1917 protocol payloads. 1919 Interoperability considerations: None 1921 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 1922 replace XXXX with the RFC number of this specification.] 1924 Applications which use this media type: Emergency and Location-based 1925 Systems 1927 Additional information: 1929 Magic Number: None 1931 File Extension: .lostxml 1933 Macintosh file type code: 'TEXT' 1935 Personal and email address for further information: Hannes 1936 Tschofenig, Hannes.Tschofenig@nsn.com 1938 Intended usage: LIMITED USE 1940 Author: 1942 This specification is a work item of the IETF ECRIT working group, 1943 with mailing list address . 1945 Change controller: 1947 The IESG 1949 17.3. LoST Relax NG Schema Registration 1951 URI: urn:ietf:params:xml:schema:lost1 1953 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1954 (Hannes.Tschofenig@nsn.com). 1956 Relax NG Schema: The Relax NG schema to be registered is contained 1957 in Section 15. Its first line is 1959 default namespace = "urn:ietf:params:xml:ns:lost1" 1961 and its last line is 1963 } 1965 17.4. LoST Namespace Registration 1967 URI: urn:ietf:params:xml:ns:lost1 1969 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig 1970 (Hannes.Tschofenig@nsn.com). 1972 XML: 1974 BEGIN 1975 1976 1978 1979 1980 1982 LoST Namespace 1983 1984 1985

Namespace for LoST

1986

urn:ietf:params:xml:ns:lost1

1987

See RFCXXXX 1988 [NOTE TO IANA/RFC-EDITOR: 1989 Please replace XXXX with the RFC number of this 1990 specification.].

1991 1992 1993 END 1995 17.5. LoST Location Profile Registry 1997 This document seeks to create a registry of location profile names 1998 for the LoST protocol. Profile names are XML tokens. This registry 1999 will operate in accordance with RFC 2434 [2], Standards Action. 2001 geodetic-2d: 2003 Defined in Section 12.2. 2005 civic: 2007 Defined in Section 12.3. 2009 18. Security Considerations 2011 There are several threats to the overall system of which service 2012 mapping forms a part. An attacker that can obtain service contact 2013 URIs can use those URIs to attempt to disrupt those services. An 2014 attacker that can prevent the lookup of contact URIs can impair the 2015 reachability of such services. An attacker that can eavesdrop on the 2016 communication requesting this lookup can surmise the existence of an 2017 emergency and possibly its nature, and may be able to use this to 2018 launch a physical attack on the caller. 2020 To avoid that an attacker can modify the query or its result, TLS 2021 MUST be implemented and SHOULD be used. Use is RECOMMENDED both for 2022 clients' queries to servers and for queries among servers; this 2023 latter recommendation is to help avoid cache poisoning attacks by 2024 replacing answers given to caching servers. The use of server 2025 identity checks is also RECOMMENDED, as described in [4] 2027 Generally, authentication and authorization is not required for 2028 mapping queries. If it is, authentication mechanism of the 2029 underlying transport mechanism, such as HTTP basic and digest 2030 authentication, MAY be used. (Basic authentication SHOULD only be 2031 used in combination with TLS.) 2033 A more detailed description of threats and security requirements are 2034 provided in [17]. 2036 19. Acknowledgments 2038 We would like to the thank the following working group members for 2039 the detailed review of previous LoST document versions: 2041 o Martin Thomson (Review July 2006) 2043 o Jonathan Rosenberg (Review July 2006) 2045 o Leslie Daigle (Review September 2006) 2047 o Shida Schubert (Review November 2006) 2049 o Martin Thomson (Review December 2006) 2051 o Barbara Stark (Review January 2007) 2053 o Patrik Faeltstroem (Review January 2007 2055 o Shida Schubert (Review January 2007 as a designated expert 2056 reviewer) 2058 o Jonathan Rosenberg (Review February 2007) 2060 o Tom Taylor (Review February 2007) 2062 o Theresa Reese (Review February 2007) 2064 o Shida Schubert (Review February 2007) 2066 o James Winterbottom (Review July 2007) 2068 We would also like to thank the following working group members for 2069 their input to selected design aspects of the LoST protocol: 2071 o Leslie Daigle and Martin Thomson (DNS-based LoST discovery 2072 procedure) 2074 o John Schnizlein (authoritive LoST answers) 2076 o Rohan Mahy (display names) 2078 o James Polk (error handling) 2080 o Ron Watro and Richard Barnes (expiry of cached data) 2082 o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James 2083 Winterbottom (Indication of PSAP Confidence Level) 2085 o Martin Thomson (service boundary references) 2087 o Martin Thomson (service URN in LoST response message) 2089 o Cullen Jennings (service boundaries) 2091 o Clive D.W. Feather, Martin Thomson (Validation Functionality) 2093 o Roger Marshall (PSAP Preference in LoST response) 2095 o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, 2096 Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. 2097 Feather, Richard Stastny, John Hearty, Roger Marshall, Jean- 2098 Francois Mule, Pierre Desjardins (Location Profiles) 2100 o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson, 2101 Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, 2102 Keith (List Services functionality) 2104 o Thomson, Martin, Michael Hammer (Mapping of Services) 2106 o Shida Schubert, James Winterbottom, Keith Drage (default service 2107 URN) 2109 o Otmar Lendl (LoST aggregation) 2111 o Tom Taylor (Terminology) 2113 Klaus Darilion and Marc Linsner provided miscellaneous input to the 2114 design of the protocol. Finally, we would like to thank Brian Rosen 2115 who participated in almost every discussion thread. 2117 Early implementation efforts lead to good feedback by two open source 2118 implementation groups. We would like to thank the implementers for 2119 their work and for helping us to improve the quality of the 2120 specification: 2122 o Wonsang Song 2124 o Jong-Yul Kim 2126 o Anna Makarowska 2128 o Krzysztof Rzecki 2130 o Blaszczyk Piotr 2132 We would like to thank Jon Peterson for his IESG review comments. 2134 20. References 2136 20.1. Normative References 2138 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2139 Levels", BCP 14, RFC 2119, March 1997. 2141 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2142 Considerations Section in RFCs", BCP 26, RFC 2434, 2143 October 1998. 2145 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 2146 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 2147 HTTP/1.1", RFC 2616, June 1999. 2149 [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2151 [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 2152 RFC 3023, January 2001. 2154 [6] Peterson, J., "A Presence-based GEOPRIV Location Object 2155 Format", RFC 4119, December 2005. 2157 [7] Freed, N. and J. Klensin, "Media Type Specifications and 2158 Registration Procedures", BCP 13, RFC 4288, December 2005. 2160 [8] Daigle, L., "Domain-Based Application Service Location Using 2161 URIs and the Dynamic Delegation Discovery Service (DDDS)", 2162 RFC 4848, April 2007. 2164 [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 2165 and Other Well-Known Services", draft-ietf-ecrit-service-urn-07 2166 (work in progress), August 2007. 2168 [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format 2169 for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in 2170 progress), December 2007. 2172 [11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, 2173 "Geographic information - Geography Markup Language (GML)", OGC 2174 Standard OpenGIS 03-105r1, April 2004. 2176 [12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application 2177 Schema for use by the Internet Engineering Task Force (IETF)", 2178 Candidate OpenGIS Implementation Specification , December 2006. 2180 20.2. Informative References 2182 [13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 2183 PIDF-LO Usage Clarification, Considerations and 2184 Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work 2185 in progress), October 2007. 2187 [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2188 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2189 Session Initiation Protocol", RFC 3261, June 2002. 2191 [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence 2192 Protocol (XMPP): Instant Messaging and Presence", RFC 3921, 2193 October 2004. 2195 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 2196 December 2004. 2198 [17] Taylor, T., "Security Threats and Requirements for Emergency 2199 Call Marking and Mapping", draft-ietf-ecrit-security-threats-05 2200 (work in progress), August 2007. 2202 [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 2203 Context Resolution with Internet Technologies", 2204 draft-ietf-ecrit-requirements-13 (work in progress), 2205 March 2007. 2207 [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and 2208 Framework", draft-ietf-ecrit-mapping-arch-03 (work in 2209 progress), September 2007. 2211 [20] Rosen, B. and J. Polk, "Best Current Practice for 2212 Communications Services in support of Emergency Calling", 2213 draft-ietf-ecrit-phonebcp-03 (work in progress), November 2007. 2215 URIs 2217 [21] 2219 Appendix A. Non-Normative RELAX NG Schema in XML Syntax 2221 2222 2227 2228 2229 Location-to-Service Translation Protocol (LoST) 2231 A LoST XML instance has three request types, each with 2232 a cooresponding response type: find service, list services, 2233 and get service boundary. 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2249
2250 2251 The queries. 2252 2254 2255 2256 2257 2258 2259 2260 2261 false 2262 2263 2264 2265 2266 2267 reference 2268 value 2269 2270 reference 2271 2272 2273 2274 2275 2276 false 2277 2278 2279 2280 2282 2283 2284 2285 2286 2288 2289 2290 2291 2292 2293 2294 2295 true 2296 2297 2298 2299 2301 2302 2303 2304 2305 2306 2308
2310
2311 2312 The responses. 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2327 2328 2329 2330 2331 2332 2334 2335 2336 2337 2338 2339 2340 2342 2343 2344 2345 2346 2347 2349
2351
2352 2353 A pattern common to some of the queries. 2354 2356 2357 2358 2359 2361 2362 2363 2364
2366
2367 2368 A pattern common to responses. 2369 2371 2372 2373 2374 2375 2376 2377 2378
2380
2381 2382 Location in Requests 2383 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395
2397
2398 2399 Location Information 2400 2402 2403 2404 2405 2406 2407 2408 2410 2411 2412 2413
2415
2416 2417 Service Boundary 2418 2420 2421 2422 2423 2424 2425 2426 2427
2429
2430 2431 Service Boundary Reference 2432 2434 2436 2437 2438 2439 2440 2441 2443 2444 2445 2446 2447 2449
2451
2452 2453 Path - 2454 Contains a list of via elements - 2455 places through which information flowed 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467
2469
2470 2471 Location Used 2472 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483
2485
2486 2487 Expires pattern 2488 2490 2491 2492 2493 2494 NO-CACHE 2495 NO-EXPIRATION 2496 2497 2498 2499
2501
2502 2503 A QName list 2504 2505 2506 2507 2508 2509 2510 2511 2512
2514
2515 2516 A location-to-service mapping. 2517 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 [0-9*#]+ 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2561
2563
2564 2565 Location validation 2566 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588
2590
2591 2592 Errors and Warnings Container. 2593 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 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2638 2639 2640 2641 2642 2644 2645 2646 2647 2648 2650
2652
2653 2654 Basic Exceptions 2655 2657 2658 2659 Exception pattern. 2660 2661 2662 2663 2665 2666 2667 2668 2669 2671 2672 2673 2674 2675 2677 2678 2679 2680 2681 2683 2684 2685 2686 2687 2689 2690 2691 2692 2693 2695 2696 2697 2699 2700 2702 2703 2704 2705 2706 2708 2709 2710 2711 2712 2714 2715 2716 2717 2718 2720 2721 2722 2723 2724 2726 2727 2728 2729 2730 2732 2733 2734 2735 2736 2738 2739 2740 2741 2742 2743 2744 2745 2747
2749
2750 2751 Redirect. 2752 2754 2755 2756 Redirect pattern 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2768
2770
2771 2772 Some common patterns. 2773 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 ([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+ 2798 2799 2801 2802 2803 2804 2805 2807 2808 2809 2810 2811 2812 2813 2814 2815 2817
2819
2820 2821 Patterns for inclusion of elements from schemas in 2822 other namespaces. 2823 2825 2826 2827 Any element not in the LoST namespace. 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2840 2841 2842 A wildcard pattern for including any element 2843 from any other namespace. 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2859 2860 2861 A point where future extensions 2862 (elements from other namespaces) 2863 can be added. 2864 2865 2866 2867 2868 2870
2872 2874 Figure 25 2876 Appendix B. Examples On-line 2878 The XML examples and Relax NG schemas may be found on-line [21]. 2880 Authors' Addresses 2882 Ted Hardie 2883 Qualcomm, Inc. 2885 Email: hardie@qualcomm.com 2887 Andrew Newton 2888 American Registry for Internet Numbers 2889 3635 Concorde Parkway, Suite 200 2890 Chantilly, VA 20151 2891 US 2893 Phone: +1 703 227 9894 2894 Email: andy@hxr.us 2896 Henning Schulzrinne 2897 Columbia University 2898 Department of Computer Science 2899 450 Computer Science Building 2900 New York, NY 10027 2901 US 2903 Phone: +1 212 939 7004 2904 Email: hgs+ecrit@cs.columbia.edu 2905 URI: http://www.cs.columbia.edu 2907 Hannes Tschofenig 2908 Nokia Siemens Networks 2909 Linnoitustie 6 2910 Espoo 02600 2911 Finland 2913 Phone: +358 (50) 4871445 2914 Email: Hannes.Tschofenig@nsn.com 2915 URI: http://www.tschofenig.com 2917 Full Copyright Statement 2919 Copyright (C) The IETF Trust (2008). 2921 This document is subject to the rights, licenses and restrictions 2922 contained in BCP 78, and except as set forth therein, the authors 2923 retain all their rights. 2925 This document and the information contained herein are provided on an 2926 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2927 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2928 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2929 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2930 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2931 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2933 Intellectual Property 2935 The IETF takes no position regarding the validity or scope of any 2936 Intellectual Property Rights or other rights that might be claimed to 2937 pertain to the implementation or use of the technology described in 2938 this document or the extent to which any license under such rights 2939 might or might not be available; nor does it represent that it has 2940 made any independent effort to identify any such rights. Information 2941 on the procedures with respect to rights in RFC documents can be 2942 found in BCP 78 and BCP 79. 2944 Copies of IPR disclosures made to the IETF Secretariat and any 2945 assurances of licenses to be made available, or the result of an 2946 attempt made to obtain a general license or permission for the use of 2947 such proprietary rights by implementers or users of this 2948 specification can be obtained from the IETF on-line IPR repository at 2949 http://www.ietf.org/ipr. 2951 The IETF invites any interested party to bring to its attention any 2952 copyrights, patents or patent applications, or other proprietary 2953 rights that may cover technology that may be required to implement 2954 this standard. Please address the information to the IETF at 2955 ietf-ipr@ietf.org. 2957 Acknowledgment 2959 Funding for the RFC Editor function is provided by the IETF 2960 Administrative Support Activity (IASA).