--- 1/draft-ietf-ecrit-lost-04.txt 2007-03-08 00:12:21.000000000 +0100 +++ 2/draft-ietf-ecrit-lost-05.txt 2007-03-08 00:12:21.000000000 +0100 @@ -1,23 +1,23 @@ ECRIT T. Hardie Internet-Draft Qualcomm, Inc. Intended status: Standards Track A. Newton -Expires: August 15, 2007 SunRocket +Expires: September 5, 2007 SunRocket H. Schulzrinne Columbia U. H. Tschofenig Siemens Networks GmbH & Co KG - February 11, 2007 + March 4, 2007 LoST: A Location-to-Service Translation Protocol - draft-ietf-ecrit-lost-04.txt + draft-ietf-ecrit-lost-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -28,104 +28,117 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 15, 2007. + This Internet-Draft will expire on September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Requirements Notation . . . . . . . . . . . . 6 3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7 - 4. LoST servers and Their Resolution . . . . . . . . . . . . . . 8 - 5. The Element . . . . . . . . . . . . . . . . . . . . 9 - 5.1. Data source and version: The 'source', 'sourceId' and - 'version' Attributes . . . . . . . . . . . . . . . . . . . 9 - 5.2. Time of Last Update: The 'lastUpdated' Attribute . . . . . 9 - 5.3. Validity: The 'expires' Attribute . . . . . . . . . . . . 9 - 5.4. Describing the Service with the Element . . 10 - 5.5. The Mapped Service: the Element . . . . . . . . 10 - 5.6. Defining the Service Region with the - Element . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5.7. Service Boundaries by Reference: the - Element . . . . . . . . . . . . 11 - 5.8. The Service Number Element . . . . . . . . . . . . . . . . 11 - 5.9. Service URLs: the Element . . . . . . . . . . . . . 12 - 6. Path of Request: Element . . . . . . . . . . . . . . . 13 - 7. Mapping a Location and Service to URLs: . . . . 14 - 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 14 - 7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 15 - 7.3. Components of the Request . . . . . . . . . 17 - 7.3.1. The Element . . . . . . . . . . . . . . . . 17 - 7.3.2. Identifying the Service: The Element . . . 18 - 7.3.3. Recursion . . . . . . . . . . . . . . . . . . . . . . 18 - 7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 18 - 7.3.5. Requesting Civic Location Validation . . . . . . . . . 18 + 4. LoST servers and Their Resolution . . . . . . . . . . . . . . 9 + 5. The Element . . . . . . . . . . . . . . . . . . . . 10 + 5.1. The Data Source: 'source', 'sourceId' and + 'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10 + 5.2. Validity: The 'expires' Attribute . . . . . . . . . . . . 10 + 5.3. Describing the Service with the Element . . 11 + 5.4. The Mapped Service: the Element . . . . . . . . 11 + 5.5. Defining the Service Region with the + Element . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.6. Service Boundaries by Reference: the + Element . . . . . . . . . . . . 12 + 5.7. The Service Number Element . . . . . . . . . . . . . . . . 13 + 5.8. Service URLs: the Element . . . . . . . . . . . . . 13 + 6. Path of a Request: Element . . . . . . . . . . . . . . 14 + 7. Mapping a Location and Service to URLs: . . . . 15 + 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 15 + 7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 16 + 7.3. Components of the Request . . . . . . . . . 18 + 7.3.1. The Element . . . . . . . . . . . . . . . . 18 + 7.3.2. Identifying the Service: The Element . . . 19 + 7.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 19 + 7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 19 + 7.3.5. Requesting Civic Location Validation . . . . . . . . . 19 7.4. Components of the Mapping Response - . . . . . . . . . . . . . . . . . . 20 - 7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 20 + . . . . . . . . . . . . . . . . . . 21 + 7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21 7.4.2. Civic Address Validation: the - Element . . . . . . . . . . . . . 21 - 8. Retrieving the Service Boundary via . . . 22 - 9. List Services: . . . . . . . . . . . . . . . . 25 - 10. List Services By Location: . . . . . 26 - 11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 28 - 11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 29 - 11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 32 - 11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 33 - 12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 34 - 12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 36 - 13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 37 - 14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 38 - 15. Internationalization Considerations . . . . . . . . . . . . . 45 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 - 16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 46 - 16.2. Content-type registration for 'application/lost+xml' . . . 46 - 16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 48 - 16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 48 - 16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 49 - 17. Security Considerations . . . . . . . . . . . . . . . . . . . 50 - 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 - 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 53 - 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 - 20.1. Normative References . . . . . . . . . . . . . . . . . . . 54 - 20.2. Informative References . . . . . . . . . . . . . . . . . . 55 - Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 56 + Element . . . . . . . . . . . . . 22 + 8. Retrieving the Service Boundary via . . . 23 + 9. List Services: . . . . . . . . . . . . . . . . 26 + 10. List Services By Location: . . . . . 27 + 11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 29 + 11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 30 + 11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 33 + 11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 34 + 12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 35 + 12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 37 + 13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 38 + 14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 39 + 15. Internationalization Considerations . . . . . . . . . . . . . 46 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 + 16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 47 + 16.2. Content-type registration for 'application/lost+xml' . . . 47 + 16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 49 + 16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 49 + 16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 50 + 17. Security Considerations . . . . . . . . . . . . . . . . . . . 51 + 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 + 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 54 + 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 20.1. Normative References . . . . . . . . . . . . . . . . . . . 55 + 20.2. Informative References . . . . . . . . . . . . . . . . . . 56 + Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 Intellectual Property and Copyright Statements . . . . . . . . . . 71 1. Introduction + Numerous techniques have been specified for the discovery of servers + for a particular service, including NAPTR records, SVRLOC and similar + protocols. However, there are an important class of services where + the specific service instance that is to be connected to depends on + the identity of the service and the location of the entity that needs + to reach it. An example of this is emergency telecommunications + services, where the service instance is a Public Safety Answering + Point (PSAP) that has jurisdiction over the location of the user + making the call. Here, the desired PSAP isn't necessarily the one + that is topologically or even line-of-sight closest to the caller; + rather, it is the one that serves the callers location based on + geopolitical boundaries. For this reason, the selected service + instance is a function of location and the desired service. + This document describes a protocol for mapping a service identifier - [10] and location information compatible with PIDF-LO [7], namely - revised civic location information [11] and GML [13]) to one or more + [9] and location information compatible with PIDF-LO [6], namely + revised civic location information [10] and GML [12]) to one or more service URL. Example service URL schemes include sip [14], xmpp [15], and tel [16]. While the initial focus is on providing mapping functions for emergency services, it is likely that the protocol is applicable to any service URN. For example, in the United States, the "2-1-1" and "3-1-1" service numbers follow a similar location-to- service behavior as emergency services. This document names this protocol "LoST", for Location-to-Service Translation. LoST Satisfies the requirements [18] for mapping protocols. LoST provides a number of operations, centered around @@ -133,283 +146,362 @@ information. LoST mapping queries can contain either civic or geodetic location information. For civic addresses, LoST can indicate which parts of the civic address are known to be valid or invalid, thus providing address validation (see Section 3.5 of [18] for a description of validation). LoST indicates errors in the location data to facilitate debugging and proper user feedback, but also provides best-effort answers. LoST queries can be resolved recursively or iteratively. To minimize round trips and to provide robustness against network failures, LoST - caches individual mappings and indicates the region for which the - same answer would be returned ("service region"). + supports caching of individual mappings and indicates the region for + which the same answer would be returned ("service region"). As defined in this document, LoST messages are carried in HTTP and HTTPS protocol exchanges, facilitating use of TLS for protecting the - integrity and confidentiality of requests and responses. Later - documents may describe how LoST messages could be carried over other - transports. + integrity and confidentiality of requests and responses. This document focuses on the description of the protocol between the - mapping client and the mapping server. The relationship between - other functions, such as discovery of mapping servers, data - replication and the overall mapping server architecture are described - in a separate document [19]. + mapping client and the mapping server. Other functions, such as + discovery of mapping servers, data replication and the overall + mapping server architecture are described in a separate document + [19]. The query message carries location information and a service - identifier encoded as a Uniform Resource Name (URN) (see [10]) from + identifier encoded as a Uniform Resource Name (URN) (see [9]) from the LoST client to the LoST server. The LoST server uses its database to map the input values to one or more Uniform Resource Identifiers (URI) and returns those URIs along with optional information, such as hints about the service boundary, in a response message to the LoST client. If the server cannot resolve the query itself, it may in turn query another server or return the address of another LoST server, identified by a LoST server name. In addition to the mapping function described in Section 7, the protocol also allows to retrieve the service boundary (see Section 8) and to list the services available for a particular location (see Section 10) or supported by a particular server (see Section 9). 2. Terminology and Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. - This document furthermore uses the terminology defined in [18]. + This document uses the following terms: + + Mapping: + + Mapping is a process that takes a location and a service + identifier as inputs and returns one or more URIs that point to a + host providing that service or acting as an intermediary to + establish communication with the serving entity. This definition + is a generalization of the term "mapping" as used in [18], because + of the potential for LoST to be used for non-emergency services. + + LoST Client and Server: + + "LoST client" is the role played by an entity that sends LoST + query messages and receives LoST response messages. "LoST server" + is the role played by an entity that receives LoST query messages + and sends LoST response messages. In recursive operation, the + same entity may play both roles. This document also uses the term + "authoritative server" to designate an entity that acts in the + LoST server role only and successfully resolves the input location + and service identifier to a URI or set of URIs. + + Service Boundary: + + A service boundary is the boundary or set of boundaries of a + geographic region, respectively set of geographic regions, within + which all locations will map to the same URI or set of URIs for a + given service. + + Validation: + + The term "validation" as used in this document is a concrete + realization of the term "location validation" as defined in + Section 3.5 of [18]. + + Additional emergency service terminology can be found in [18]. 3. Overview of Protocol Usage - The client may perform the mapping at any time. Among the common - triggers for mapping requests are: + The LoST protocol supports the following type of queries and + responses: + + and + + This message pattern allows to perform retrieve contact URIs based + on location information together with a service identifier. The + same query type may also ask for location validation and for + service numbers, either integrated into mapping request or + separately. The details can be found in Section 7 and + Section 7.4. + + and + + This message pattern allows query for a service boundary. The + details can be found in Section 8. + + and + + This message pattern enables a LoST client to ask a LoST server + for the services it supports. The details can be found in + Section 9. + + and + + This message pattern provides the LoST client with the services + that are available for a specific location region. The details + can be found in Section 10. + + LoST clients may initiate any of the above queries at any time. + Among the common triggers are: 1. When the client initially starts up or attaches to a network. 2. When the client detects that its location has changed - sufficiently that it is outside the bounds of the service region - returned in an earlier LoST query. + sufficiently that it is outside the bounds of the service region. - 3. When cached mapping information has expired. + 3. An incoming message at a SIP proxy in a location-based routing + scenario that requires a routing decision to be made. - 4. When invoking a particular service. At that time, a client may + 4. When cached mapping information has expired. + + 5. When invoking a particular service. At that time, a client may omit requests for service boundaries or other auxiliary information. A service-specific Best Current Practice (BCP) document, such as [20], governs whether a client is expected to invoke the mapping service just before needing the service or whether to rely on cached answers. Cache entries expire at their expiration time (see - Section 5.3), or they become invalid if the caller's device moves + Section 5.2), or they become invalid if the caller's device moves beyond the boundaries of the service region. 4. LoST servers and Their Resolution - A LoST server may be discovered using a U-NAPTR/DDDS [12] application - unique string (AUS), in the form of a DNS name. + LoST servers are identified by U-NAPTR/DDDS [11] application unique + strings, in the form of a DNS name. An example is 'lostserver.example.com' - Clients need to use the U-NAPTR [12] specification described below to + Clients need to use the U-NAPTR [11] specification described below to obtain a URI (indicating host and protocol) for the applicable LoST service. In this document, only the HTTP and HTTPS URL schemes are defined. Note that the HTTP URL can be any valid HTTP URL, including those containing path elements. - The following two DNS entries show the U-NAPTR resolution for the AUS + The following two DNS entries show the U-NAPTR resolution for "example.com" to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL http://lostserver.example.com, with the former being preferred. example.com. IN NAPTR 100 10 "u" "LoST:https" - "!*.!https://lostserver.example.com/secure!" "" + "!.*!https://lostserver.example.com/secure!" "" IN NAPTR 200 10 "u" "LoST:http" - "!*.!http://lostserver.example.com!" "" + "!.*!http://lostserver.example.com!" "" - Clients learn the LoST server's AUS by means beyond the scope of this - specification, such as SIP configuration and DHCP. + Clients learn the LoST server's host name by means beyond the scope + of this specification, such as SIP configuration and DHCP. 5. The Element The element is the core data element in LoST, describing a service region and the associated service URLs. Its attributes and elements are described in subsections below. -5.1. Data source and version: The 'source', 'sourceId' and 'version' - Attributes +5.1. The Data Source: 'source', 'sourceId' and 'lastUpdated' Attributes - The 'source', 'sourceId' and 'version' attributes uniquely identify a - particular mapping record. They are created by the authoritative - source for a mapping and never modified when a mapping is served from - a cache. All three attributes are REQUIRED for all - elements. A receiver can replace a mapping with another one having - the same 'source' and 'sourceId' and a higher version number. + The 'source', the 'sourceId' and the 'lastUpdated' attributes + uniquely identify a particular mapping record. They are created by + the authoritative source for a mapping and never modified when a + mapping is served from a cache. All three attributes are REQUIRED + for all elements. A receiver can replace a mapping with + another one having the same 'source' and 'sourceId' and a more recent + datum in 'lastUpdated'. The 'source' attribute contains a LoST application unique string identifying the authoritative generator of the mapping. See Section 4. The 'sourceId' attribute identifies a particular mapping and contains an opaque token that MUST be unique among all different mappings maintained by the authoritative source for that particular service. For example, a Universally Unique Identifier (UUID) is a suitable format. - The 'version' attribute is a positive integer that is incremented for - each change in the mapping. The XML data type does not specify an - upper bound for this attribute and thus, the value MUST NOT wrap - around. Thus, a higher version number refers to a more recent - mapping. A mapping maintains its sourceId value as long as it - remains logically the same, e.g., represents the same service - boundary or replaces an earlier service boundary. - -5.2. Time of Last Update: The 'lastUpdated' Attribute - - The 'lastUpdated' attribute describes when the mapping was last - changed. The contents of this attribute has the XML data type - dateTime in its timezoned form, using canonical UTC representation - with the letter 'Z' as the timezone indicator. The attribute is - REQUIRED. + The 'lastUpdated' attribute describes when a specific instance of + mapping, identified by the combination of 'source' and 'sourceId', + was last changed. The contents of this attribute has the XML data + type dateTime in its timezoned form, using canonical UTC + representation with the letter 'Z' as the timezone indicator. -5.3. Validity: The 'expires' Attribute +5.2. Validity: The 'expires' Attribute The 'expires' attribute contains the absolute time at which the mapping becomes invalid. The contents of this attribute is a timezoned XML type dateTime, in canonical representation. See Section 3 regarding how this value is to be utilized with a cache. - The 'expires' attribute is REQUIRED to be included in the element. + Optionally, this attribute may contain the values of 'NO-CACHE' and + 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is + an indication that the mapping should not be cached. The value of + 'NO-EXPIRATION' is an indication that the mapping does not expire. + On occasion, a server may be forced to return an expired mapping if it cannot reach the authoritative server or the server fails to return a usable answer. Clients and servers MAY cache the mapping so that they have at least some information available. Caching servers that have such stale information SHOULD re-attempt the query each - time a client requests a mapping. + time a client requests a mapping. Since the expired mapping will be + returned to the client as a non-error/non-warning response it is the + responsibility of the client to check the 'expires' attribute + associated with mapping data returned in a LoST response to detemine + whether the mapping is fresh. -5.4. Describing the Service with the Element +5.3. Describing the Service with the Element Zero or more elements describe the service with a string that is suitable for display to human users, each annotated with the 'xml:lang' attribute that contains a language tag to aid in the rendering of text. -5.5. The Mapped Service: the Element +5.4. The Mapped Service: the Element The element identifies the service for which this mapping applies. Two cases need to be distinguished when the LoST server sets the element in the response message: - 1. If the requested service, identified by the service URN [10] in + 1. If the requested service, identified by the service URN [9] in the element of the request, exists for the location indicated, then the LoST server puts the service URN from the request into the element. 2. If, however, the requested service, identified by the service URN - [10] in the element in the request, does not exist for + [9] in the element in the request, does not exist for the location indicated, the server can either return an (Section 12.1) error or can provide an alternate service that approximates the desired service for that location. In the latter case, the server MUST include a element with the alternative service URN. The choice of service URN is left to local policy, but the alternate service should be able to satisfy the original service request. The element is optional but may also be required if the mapping is to be digitally signed. -5.6. Defining the Service Region with the Element +5.5. Defining the Service Region with the Element A response MAY indicate the region for which the service URL returned would be the same as in the actual query, the so-called _service region_. The service region can be indicated by value or by - reference (see Section 5.7). If a client moves outside the service + reference (see Section 5.6). If a client moves outside the service area and wishes to obtain current service data, it sends a new query with its current location. The service region is described by value in one or more elements, each formatted according to a different location profile, identified by the 'profile' atribute - (see Section 11). The response MUST contain at least one service - boundary using the same profile as the request. The client only - processes the first element that it can understand according to its - list of supported location profiles. Thus, elements with geospatial - coordinates are alternative descriptions of the same service region, - not additive geometries. + (see Section 11). If included in a response, the + element MUST contain at least one service boundary that uses the same + profile as the request. The client only processes the first element + that it can understand according to its list of supported location + profiles. Thus, elements with geospatial coordinates are alternative + descriptions of the same service region, not additive geometries. + + A service boundary is requested by the client (using the + 'serviceBoundary' attribute in the request with the value set to + "value"). A response MAY contain more than one element with profile 'civic'. Each element describes a set of civic addresses that fall within the service boundary, namely all addresses that textually match the civic address elements provided, regardless of the value of other address elements. A location falls within the mapping's service boundary if it matches any of the elements. -5.7. Service Boundaries by Reference: the +5.6. Service Boundaries by Reference: the Element Since geodetic service boundaries may contain thousands of points and thus be quite large, clients may opt to conserve bandwidth and request a reference to the service boundary instead of the value - described in Section 5.6. The identifier of the service boundary is + described in Section 5.5. The identifier of the service boundary is returned as an attribute of the element, along with a LoST application unique string (see Section 4) identifying the server from where it can be retrieved. The actual value of the service boundary is then retrieved with the getServiceBoundary (Section 8) request. + A reference to a service boundary is requested by the client (using + the 'serviceBoundary' attribute in the request with the value set to + "reference"). A LoST server may decide, based on local policy, to + return the service boundary per value or to omit the + element in the response. + The identifier is a random token with at least 128 bits of entropy and can be assumed to be globally unique. It uniquely references a particular boundary. If the boundary changes, a new identifier MUST be chosen. Because of these properties, a client receiving a mapping response can simply check if it already has a copy of the boundary with that identifier. If so, it can skip checking with the server whether the boundary has been updated. Since service boundaries are likely to remain unchanged for extended periods of time, possibly exceeding the normal lifetime of the service URL, this approach avoids unnecessarily refreshing the boundary information just because the the remainder of the mapping has become invalid. -5.8. The Service Number Element +5.7. The Service Number Element The service number is returned in the optional element. It contains a string of digits, * and # that a user on a device with a 12-key dial pad could use to reach that particular service. -5.9. Service URLs: the Element +5.8. Service URLs: the Element The response returns the service URLs in one or more elements. The URLs MUST be absolute URLs. The ordering of the URLs has no particular significance. Each URL scheme MUST only appear at most once, but it is permissible to include both secured and regular versions of a protocol, such as both 'http' and 'https' or 'sip' and 'sips'. -6. Path of Request: Element +6. Path of a Request: Element To prevent loops and to allow tracing of request and response paths, all requests that allow recursion include a element that contains one or more elements, each possessing an attribute containing a LoST application unique string (see Section 4). The order of elements corresponds to the order of LoST servers, - i.e., the first element identifies the server that first - received the request from the client. The authoritative server - copies the element verbatim into the response. + i.e., the first element identifies the server that initially + received the request from the client issuing the request. The + element is inserted logically on receipt of the request, so that + every server in a recursive query operation is included in the + element. + + The server that answers the request instead of forwarding it, such as + the authoritative server, copies the element verbatim into the + response. The element is not modified in responses as the + responses traverses the server chain back to the querying client. If a query is answered iteratively, the querier includes all servers that it has already contacted. The example in Figure 5 indicates that the answer was given to the - responding server by the LoST server at esgw.ueber-110.de.example, - which got the answer from the LoST server at + client by the LoST server at esgw.ueber-110.de.example, which got the + answer from the (authoritative) LoST server at polizei.muenchen.de.example. 7. Mapping a Location and Service to URLs: 7.1. Overview The query constitutes the core of the LoST functionality, mapping civic or geodetic locations to URLs and associated data. After giving an example, we enumerate the elements of the query and response. @@ -437,55 +529,55 @@ urn:service:sos.police Figure 2: A geodetic query Given the query above, a server would respond with a service, and information related to that service. In the example below, the server has mapped the location given by the client for a police service to the New York City Police Deparment, instructing the client - that it may contact them via the URIs "sip:sfpd@example.com" and - "xmpp:sfpd@example.com". The server has also given the client a + that it may contact them via the URIs "sip:nypd@example.com" and + "xmpp:nypd@example.com". The server has also given the client a geodetic, two-dimensional boundary for this service. The mapping was last updated on November 1, 2006 and expires on January 1, 2007. If the client's location changes beyond the given service boundary or the expiration time has been reached, it may want to requery for this information, depending on the usage environment of LoST. - San Francisco Police Department + New York City Police Department urn:service:sos.police 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 - sip:sfpd@example.com - xmpp:sfpd@example.com + sip:nypd@example.com + xmpp:nypd@example.com 911 Figure 3: A geodetic answer @@ -561,67 +653,66 @@ Figure 5: A civic address answer 7.3. Components of the Request The request includes attributes that govern whether the request is handled iteratively or recursively, whether location - validation is performed and which elements must be contained in the + validation is performed and which elements may be contained in the response. 7.3.1. The Element The query communicates location information using one or more elements, which MUST conform to a location profile (see Section 11). There MUST NOT be more than one location element for each distinct location profile. The order of location objects is significant; the server uses the first location object where it understands the location profile. 7.3.2. Identifying the Service: The Element The type of service desired is specified by the element. - It contains service URNs from the registry established in [10]. + It contains service URNs from the registry established in [9]. -7.3.3. Recursion +7.3.3. Recursion and Iteration - LoST and queries can be - recursive, as indicated by the 'recursive' attribute. A value of - "true" indicates a recursive query, with the default being "false" - when the attribute is omitted. Regardless of the attribute, a server - MAY always answer a query by providing a LoST application unique - string (see Section 4), i.e., indirection, however, it MUST NOT - recurse if the attribute is "false". + LoST can operate in either recursive or iterative mode, on a request- + by-request basis. In recursive mode, the LoST server initiates + queries on behalf of the requester and returns the result to the + requester. - In recursive mode, the LoST server initiates queries on behalf of the - requester and returns the result to the requester, inserting a - element to track the response chain. The elements are appended - in responses in order of visit, i.e., the first element - contains the authoritative server and elements below indicate - servers that the response traversed on its way back to the original - querier. + In iterative mode, the server contacted returns a redirection + response indicating the next server to be queried. + + For the queries defined in this document, only LoST and + queries can be recursive, as indicated by + the 'recursive' attribute. A value of "true" indicates a recursive + query, with the default being "false" when the attribute is omitted. + Regardless of the attribute, a server MAY always answer a query by + providing a LoST application unique string (see Section 4), i.e., + indirection, however, it MUST NOT recurse if the attribute is + "false". 7.3.4. Service Boundary LoST elements can describe the service boundary either by value or by reference. Returning a service boundary reference is generally more space-efficient for geospatial (polygon) boundaries and if the boundaries change rarely, but does incur an additional request. The querier can express a preference for one or the other modality with the 'serviceBoundary' attribute in the request, but the server makes the final decision as - to whether to return a reference or a value. Servers SHOULD NOT - return a by-value service boundaries if the querier requested a - reference. + to whether to return a reference or a value. 7.3.5. Requesting Civic Location Validation Civic address validation is requested by setting the optional attribute 'validateLocation' to true. If the attribute is omitted, it is assumed to be false. The response is described in Section 7.4.2. The example in Figure 6 demonstrates address validation, omitting the standard response elements. @@ -689,23 +780,24 @@ Mapping responses consist of the element (Section 5) describing the mapping itself, possibly followed by warnings (Section 12.2), location validation information (Section 7.4.2), and an indication of the path (Section 6) the response has taken. 7.4.2. Civic Address Validation: the Element A server can indicate in its response which civic address elements it has recognized as valid, which ones it has ignored and which ones it - has checked and found to be invalid. The server MUST include this + has checked and found to be invalid. The server SHOULD include this information if the 'validateLocation' attribute in the request was - true. Each element contains a list of tokens separated by white + true but local policy at the server may allow this information to be + omitted. Each element contains a list of tokens separated by white space, enumerating the civic location lables used in child elements of the element. The element enumerates those civic address elements that have been recognized as valid by the LoST server and that have been used to determine the mapping. The elements enumerates the civic address elements that the server did not check and that were not used in determining the response. The element enumerate civic address elements that the server attempted to check, but that did not match the other civic address elements found in the list. @@ -715,66 +807,66 @@ the postal code or the city is considered valid. The mapping naturally corresponds to the valid elements. The example (Figure 6) indicates that the tokens 'country', 'A1', 'A3', and 'A6' have been validated by the LoST server. The server considered the postal code 81675 in the element as not valid for this location. 8. Retrieving the Service Boundary via - As discussed in Section 5.6, the can return a + As discussed in Section 5.5, the can return a globally unique identifier in the 'serviceBoundary' attribute that can be used to retrieve the service boundary, rather than returning the boundary by value. This is shown in the example in Figure 8. The client can then retrieve the boundary using the request and obtains the boundary in the , illustrated in the example in Figure 10. The client issues the request to the server identified in the 'server' attribute of the element. These requests are always directed to the authoritative server and do not recurse. - + 37.775 -122.422 urn:service:sos.police Figure 8: request and response with service boundary reference - San Francisco Police Department + New York City Police Department urn:service:sos.police - sip:sfpd@example.com - xmpp:sfpd@example.com + sip:nypd@example.com + xmpp:nypd@example.com 911 Figure 9: message with service boundary reference @@ -877,22 +969,22 @@ element, consisting of a whitespace-separated list of service URNs. The query and response are illustrated in Figure 14 and in Figure 15, respectively. - - 37:46:30N 122:25:10W + + -34.407 150.883 urn:service:sos Figure 14: Example of query @@ -991,33 +1083,41 @@ 1. A client MUST be capable of understanding the response for the baseline profiles it used in the request. 2. If a client sends location information conformant to any location profile other than geodetic-2d or civic, it MUST also send, in the same request, location information conformant to one of the baseline profiles. Otherwise, the server might not be able to understand the request. - 3. There can only be one instance of each location profile in a + 3. A client SHOULD NOT send multiple profiles of derived + from different baseline profiles. Or said another way, a client + should only send location profiles from the same baseline profile + in the same query. If a client has location information + primarily of geodetic nature and location information primarily + of a civic nature, it should send separate requests containing + each type of location information. + + 4. There can only be one instance of each location profile in a query. - 4. Servers MUST implement the geodetic-2d and civic profiles. + 5. Servers MUST implement the geodetic-2d and civic profiles. - 5. A server uses the first-listed location profile that it + 6. A server uses the first-listed location profile that it understands and ignores the others. - 6. If a server receives a request that only contains location + 7. If a server receives a request that only contains location information using profiles it does not understand, the server responds with a (Section 12.1). - 7. The element MUST use the same location profile + 8. The element MUST use the same location profile that was used to retrieve the answer and indicates which profile has been used with the 'profile' attribute. These rules enable the use of location profiles not yet specified, while ensuring baseline interoperability. Take, for example, this scenario. Client X has had its firmware upgraded to support the uber-complex-3D location profile. Client X sends location information to Server Y, which does not understand the uber-complex-3D location profile. If Client X also sends location information using the geodetic-2D baseline profile, then Server Y @@ -1026,60 +1126,60 @@ not be as precise or expressive as desired. This is possible because both Client X and Server Y understand the baseline profile. - + 37.775 -122.422 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 37.775 -122.4194 - + -122.422 37.775 - + 37.775 -122.422 urn:service:sos.police Figure 16: Example of a query with baseline profile interoperability - San Francisco Police Department + New York City Police Department urn:service:sos.police 37.775 -122.4194 37.555 -122.4194 37.555 -122.4264 37.775 -122.4264 @@ -1095,50 +1195,64 @@ Figure 17: Example of a message with baseline profile interoperability 11.2. Two Dimensional Geodetic Profile The geodetic-2d location profile is identified by geodetic-2d. - Clients use this profile by placing a GML [13] element - within the element. This is defined by the 'point2D' - pattern in the LoST schema (see Section 14). + Clients use this profile by placing a element, as described + in Section 7.2.1 of [13], within the element. Section + 7.2.1 of [13] describes the specification of a with either a + two dimensional position (latitude and longitude) or three + dimensional position (latitude, longitude, and altitude). A client + MAY use the three dimensional position, and servers MAY interpret a + three dimensional position as a two dimensional position by ignoring + altitude. - Servers use this profile by placing a GML [13] element - within the element. This is defined by the - 'polygon' pattern in the LoST schema (see Section 14). + Servers use this profile by placing a element, as described + in Section 7.2.2 of [13], within the element. This + is defined by the 'polygon' pattern in the LoST schema (see + Section 14). + + With respect to the description in Section 7.2.2 of [13] the + restriction to 16 points for a polygon is not applicable to this + document. With this profile servers MUST use WGS 84 (latitude, + longitude), i.e., the srsName set to 'urn:ogc:def:crs:EPSG::4326' + where altitude information is omitted. The orientation of the points + in the polygon is upward normal as described in Section 7.2.2 of + [13]. 11.3. Basic Civic Profile The basic-civic location profile is identified by the token 'civic'. Clients use this profile by placing a element, defined - in [11], within the element. + in [10], within the element. Servers use this profile by placing a element, defined - in [11], within the element. + in [10], within the element. 12. Errors, Warnings, and Redirects When a LoST server cannot fulfill a request completely, it can return either an error or a warning, depending on the severity of the problem. It returns an error element if no useful response can be returned for the query. It returns a element as part of another response element if it was able to respond in part, but the - response may not be quite what the client had desired. For both - elements, the 'source' attribute names the server that originally - generated the error or warning, such as the authoritative server. - Unless otherwise noted, all elements below can be either an error or - a warning, depending on whether a default response, such as a - mapping, is included. + response may not be quite what the client had desired. This document + does not define warnings. For both elements, the 'source' attribute + names the server that originally generated the error or warning, such + as the authoritative server. Unless otherwise noted, all elements + below can be either an error or a warning, depending on whether a + default response, such as a mapping, is included. 12.1. Errors LoST defines a pattern for errors, defined as elements in the Relax NG schema. This pattern defines a 'message' attribute containing human readable text and an 'xml:lang' attribute denoting the language of the human readable text. One or more such error elements are contained in the element. The following errors follow this basic pattern: @@ -1246,23 +1360,22 @@ When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP POST method. All HTTP responses are applicable. The HTTP URL is derived from the LoST server name via U-NAPTR application, as discussed above 14. Relax NG Schema This section provides the Relax NG schema used by LoST protocol in the compact form. The verbose form is included in Appendix A. -default namespace = "http://www.opengis.net/gml" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" -namespace ns1 = "urn:ietf:params:xml:ns:lost1" +default namespace ns1 = "urn:ietf:params:xml:ns:lost1" ## ## Location-to-Service Translation Protocol (LoST) ## ## A LoST XML instance has three request types, each with ## a cooresponding response type: find service, list services, ## and get service boundary. ## start = findService @@ -1274,71 +1387,67 @@ | listServicesByLocationResponse | getServiceBoundaryResponse | errors | redirect ## ## The queries. ## div { findService = - element ns1:findService { - element ns1:location { locationInformation }+, + element findService { + element location { locationInformation }+, commonRequestPattern, attribute validateLocation { xsd:boolean >> a:defaultValue [ "false" ] }?, attribute serviceBoundary { ("reference" | "value") >> a:defaultValue [ "reference" ] }?, - attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? + attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? } - listServices = element ns1:listServices { commonRequestPattern } + listServices = element listServices { commonRequestPattern } listServicesByLocation = - element ns1:listServicesByLocation { - element ns1:location { locationInformation }*, + element listServicesByLocation { + element location { locationInformation }*, commonRequestPattern, attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? } getServiceBoundary = - element ns1:getServiceBoundary { - serviceBoundaryKey, extensionPoint - } + element getServiceBoundary { serviceBoundaryKey, extensionPoint } } ## ## The responses. ## div { findServiceResponse = - element ns1:findServiceResponse { + element findServiceResponse { mapping+, locationValidation?, commonResponsePattern } listServicesResponse = - element ns1:listServicesResponse { - serviceList, commonResponsePattern - } + element listServicesResponse { serviceList, commonResponsePattern } listServicesByLocationResponse = - element ns1:listServicesByLocationResponse { + element listServicesByLocationResponse { serviceList, commonResponsePattern } getServiceBoundaryResponse = - element ns1:getServiceBoundaryResponse { + element getServiceBoundaryResponse { serviceBoundary, commonResponsePattern } } ## ## A pattern common to some of the queries. ## div { - commonRequestPattern = service, extensionPoint + commonRequestPattern = service, path?, extensionPoint } ## ## A pattern common to responses. ## div { commonResponsePattern = warnings*, path, extensionPoint } ## @@ -1347,56 +1456,56 @@ div { locationInformation = extensionPoint+, attribute profile { xsd:NMTOKEN } } ## ## Service Boundary ## div { - serviceBoundary = element ns1:serviceBoundary { locationInformation }+ + serviceBoundary = element serviceBoundary { locationInformation }+ } ## ## Service Boundary Reference ## div { serviceBoundaryReference = - element ns1:serviceBoundaryReference { + element serviceBoundaryReference { source, serviceBoundaryKey, extensionPoint } serviceBoundaryKey = attribute key { xsd:token } } ## ## Path - ## Contains a list of via elements - ## places through which information flowed ## div { path = - element ns1:path { - element ns1:via { source, extensionPoint }* + element path { + element via { source, extensionPoint }+ } } ## ## Expires pattern ## div { - expires = attribute expires { xsd:dateTime } + expires = + attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } } ## ## A QName list - ## div { qnameList = list { xsd:QName* } } ## ## A location-to-service mapping. ## div { mapping = @@ -1393,50 +1502,49 @@ ## div { qnameList = list { xsd:QName* } } ## ## A location-to-service mapping. ## div { mapping = - element ns1:mapping { - element ns1:displayName { + element mapping { + element displayName { xsd:string, attribute xml:lang { xsd:language } }*, service, (serviceBoundary | serviceBoundaryReference)?, - element ns1:uri { xsd:anyURI }*, - element ns1:serviceNumber { + element uri { xsd:anyURI }*, + element serviceNumber { xsd:string { pattern = "[0-9*#]+" } }?, extensionPoint, expires, attribute lastUpdated { xsd:dateTime }, source, attribute sourceId { xsd:token }, - attribute version { xsd:positiveInteger }, message } } ## ## Location validation ## div { locationValidation = - element ns1:locationValidation { - element ns1:valid { qnameList }?, - element ns1:invalid { qnameList }?, - element ns1:unchecked { qnameList }?, + element locationValidation { + element valid { qnameList }?, + element invalid { qnameList }?, + element unchecked { qnameList }?, extensionPoint } } ## ## Errors and Warnings Container. ## div { errorContainer = (badRequest? @@ -1444,79 +1552,79 @@ & serviceSubstitution? & forbidden? & notFound? & loop? & serviceNotImplemented? & serverTimeout? & serverError? & locationProfileUnrecognized?), extensionPoint, source - errors = element ns1:errors { errorContainer } - warnings = element ns1:warnings { errorContainer } + errors = element errors { errorContainer } + warnings = element warnings { errorContainer } } ## ## Basic Errors ## div { ## ## Error pattern. ## basicError = message, extensionPoint - badRequest = element ns1:badRequest { basicError } - internalError = element ns1:internalError { basicError } - serviceSubstitution = element ns1:serviceSubstitution { basicError } - forbidden = element ns1:forbidden { basicError } - notFound = element ns1:notFound { basicError } - loop = element ns1:loop { basicError } - serviceNotImplemented = - element ns1:serviceNotImplemented { basicError } - serverTimeout = element ns1:serverTimeout { basicError } - serverError = element ns1:serverError { basicError } + badRequest = element badRequest { basicError } + internalError = element internalError { basicError } + serviceSubstitution = element serviceSubstitution { basicError } + forbidden = element forbidden { basicError } + notFound = element notFound { basicError } + loop = element loop { basicError } + serviceNotImplemented = element serviceNotImplemented { basicError } + serverTimeout = element serverTimeout { basicError } + serverError = element serverError { basicError } locationProfileUnrecognized = - element ns1:locationProfileUnrecognized { + element locationProfileUnrecognized { attribute unsupportedProfiles { xsd:NMTOKENS }, basicError } } ## ## Redirect. ## div { + ## ## Redirect pattern ## redirect = - element ns1:redirect { + element redirect { attribute target { appUniqueString }, source, message, extensionPoint } } ## ## Some common patterns. ## div { message = (attribute message { xsd:string }, attribute xml:lang { xsd:language })? - service = element ns1:service { xsd:anyURI }? + service = element service { xsd:anyURI }? appUniqueString = xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } source = attribute source { appUniqueString } serviceList = - element ns1:serviceList { + element serviceList { list { xsd:anyURI* } } } ## ## Patterns for inclusion of elements from schemas in ## other namespaces. ## div { @@ -1526,58 +1634,28 @@ notLost = element * - (ns1:* | ns1:*) { anyElement } ## ## A wildcard pattern for including any element ## from any other namespace. ## anyElement = (element * { anyElement } | attribute * { text } | text)* + ## ## A point where future extensions ## (elements from other namespaces) ## can be added. ## extensionPoint = notLost* - ## - ## A 2D point from GML. - ## - point2d = - element Point { - attribute srsName { "urn:ogc:def:crs:EPSG::4326" }, - pos - } - - ## - ## A GML position - ## - pos = - element pos { - list { xsd:double } - } - - ## - ## A Linear Ring from GML. - ## - linearRing = element LinearRing { pos, pos, pos, pos+ } - - ## - ## A Polygon from GML. - ## - polygon = - element Polygon { - attribute srsName { "urn:ogc:def:crs:EPSG::4326" }, - element exterior { linearRing }, - element interior { linearRing }* - } } Figure 20: RelaxNG schema 15. Internationalization Considerations This mechanism is largely for passing protocol information from one subsystem to another; as such, most of its elements are tokens not meant for direct human consumption. If these tokens are presented to the end user, some localization may need to occur. The content of @@ -1614,21 +1692,21 @@ o Application Protocol Tag: https Defining Publication: RFC 2818 [4] 16.2. Content-type registration for 'application/lost+xml' This specification requests the registration of a new MIME type - according to the procedures of RFC 4288 [8] and guidelines in RFC + according to the procedures of RFC 4288 [7] and guidelines in RFC 3023 [5]. MIME media type name: application MIME subtype name: lost+xml Mandatory parameters: none Optional parameters: charset @@ -1666,22 +1744,21 @@ Intended usage: LIMITED USE Author: This specification is a work item of the IETF ECRIT working group, with mailing list address . Change controller: - The IESG delegated to the IETF ECRIT working - group, if it is still active. + The IESG 16.3. LoST Relax NG Schema Registration URI: urn:ietf:params:xml:ns:lost1 Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@siemens.com). Relax NG Schema: The Relax NG schema to be registered is contained in Section 14. Its first line is @@ -1774,20 +1851,28 @@ o Martin Thomson (Review December 2006) o Barbara Stark (Review January 2007) o Patrik Faeltstroem (Review January 2007 o Shida Schubert (Review January 2007 as a designated expert reviewer) + o Jonathan Rosenberg (Review February 2007) + + o Tom Taylor (Review February 2007) + + o Theresa Reese (Review February 2007) + + o Shida Schubert (Review February 2007) + We would also like to thank the following working group members for their input to selected design aspects of the LoST protocol: o Leslie Daigle and Martin Thomson (DNS-based LoST discovery procedure) o John Schnizlein (authoritive LoST answers) o Rohan Mahy (display names) @@ -1816,20 +1901,22 @@ Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, Keith (List Services functionality) o Thomson, Martin, Michael Hammer (Mapping of Services) o Shida Schubert, James Winterbottom, Keith Drage (default service URN) o Otmar Lendl (LoST aggregation) + o Tom Taylor (Terminology) + Klaus Darilion and Marc Linsner provided miscellaneous input to the design of the protocol. Finally, we would like to thank Brian Rosen who participated in almost every discussion thread. 19. Open Issues Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ 20. References @@ -1844,48 +1931,49 @@ [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. - [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, - January 2005. - - [7] Peterson, J., "A Presence-based GEOPRIV Location Object + [6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. - [8] Freed, N. and J. Klensin, "Media Type Specifications and + [7] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. - [9] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and + [8] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006. - [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", + [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", draft-ietf-ecrit-service-urn-05 (work in progress), August 2006. - [11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format - for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in - progress), September 2006. + [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format + for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in + progress), February 2007. - [12] Daigle, L., "Domain-based Application Service Location Using + [11] Daigle, L., "Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", - draft-daigle-unaptr-01 (work in progress), October 2006. + draft-daigle-unaptr-02 (work in progress), February 2007. - [13] OpenGIS, "Open Geography Markup Language (GML) Implementation - Specification", OGC OGC 02-023r4, January 2003. + [12] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, + "Geographic information - Geography Markup Language (GML)", OGC + Standard OpenGIS 03-105r1, April 2004. + + [13] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application + Schema for use by the Internet Engineering Task Force (IETF)", + Candidate OpenGIS Implementation Specification , December 2006. 20.2. Informative References [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004. @@ -1964,21 +2049,21 @@ reference value reference - true + false @@ -2046,23 +2130,25 @@
A pattern common to some of the queries. - + + +
A pattern common to responses. @@ -2127,38 +2213,42 @@
Path - Contains a list of via elements - places through which information flowed - + - +
Expires pattern + + NO-CACHE + NO-EXPIRATION +
A QName list @@ -2206,23 +2296,20 @@ - - -
Location validation @@ -2495,79 +2582,20 @@ A point where future extensions (elements from other namespaces) can be added. - - - A 2D point from GML. - - - - urn:ogc:def:crs:EPSG::4326 - - - - - - - - A GML position - - - - - - - - - - - A Linear Ring from GML. - - - - - - - - - - - - - - - A Polygon from GML. - - - - urn:ogc:def:crs:EPSG::4326 - - - - - - - - - - - -
Figure 24 Authors' Addresses Ted Hardie Qualcomm, Inc.