GEOPRIV WG J. Winterbottom Internet-Draft M. Thomson Intended status: Standards Track Andrew Expires: September 3, 2007 B. Stark BellSouth March 2, 2007 HTTP Enabled Location Delivery (HELD) draft-winterbottom-http-location-delivery-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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 September 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Winterbottom, et al. Expires September 3, 2007 [Page 1] Internet-Draft HELD March 2007 Abstract A Geopriv using protocol is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information either by-value or by-reference. The protocol supports mobile and nomadic devices through Location URIs. The protocol is an application-layer protocol that is independent of session-layer; an HTTP, web services binding is specified. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Exclusions . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Device or Target . . . . . . . . . . . . . . . . . . . . . 6 1.3. The Bigger Picture . . . . . . . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 8 2.1. GEOPRIV Terminology . . . . . . . . . . . . . . . . . . . 8 3. HELD Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Requesting Location Information Directly . . . . . . . . . 10 3.1.1. Shaping the PIDF-LO . . . . . . . . . . . . . . . . . 11 3.2. Requesting a Location URI . . . . . . . . . . . . . . . . 11 3.2.1. Establishing a Location Server Context . . . . . . . . 12 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 14 4.1. Protocol Binding . . . . . . . . . . . . . . . . . . . . . 15 4.2. Location Request . . . . . . . . . . . . . . . . . . . . . 15 4.3. Contexts . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.1. Creating Contexts . . . . . . . . . . . . . . . . . . 16 4.3.2. Updating Contexts . . . . . . . . . . . . . . . . . . 17 4.3.3. Terminating Contexts . . . . . . . . . . . . . . . . . 17 4.4. Combined Context and Location Requests . . . . . . . . . . 18 4.5. Indicating Errors . . . . . . . . . . . . . . . . . . . . 18 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 19 5.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 20 5.2. "assert" Parameter . . . . . . . . . . . . . . . . . . . . 20 5.2.1. "method" Parameter . . . . . . . . . . . . . . . . . . 20 5.2.2. "timestamp" Parameter . . . . . . . . . . . . . . . . 20 5.2.3. "expires" Parameter . . . . . . . . . . . . . . . . . 21 5.2.4. "exact" Parameter . . . . . . . . . . . . . . . . . . 21 5.3. "locationType" Parameter . . . . . . . . . . . . . . . . . 21 5.3.1. "exact" Parameter . . . . . . . . . . . . . . . . . . 22 5.4. "profile" Parameter . . . . . . . . . . . . . . . . . . . 22 5.4.1. "presentity" Parameter . . . . . . . . . . . . . . . . 23 5.4.2. "retentionExpiry" Parameter . . . . . . . . . . . . . 23 5.4.3. "retentionInterval" Parameter . . . . . . . . . . . . 23 5.4.4. "retransmission" Parameter . . . . . . . . . . . . . . 24 5.4.5. "rulesetURI" Parameter . . . . . . . . . . . . . . . . 24 Winterbottom, et al. Expires September 3, 2007 [Page 2] Internet-Draft HELD March 2007 5.5. "signed" Parameter . . . . . . . . . . . . . . . . . . . . 24 5.6. "lifetime" Parameter . . . . . . . . . . . . . . . . . . . 24 5.7. "rules" Parameter . . . . . . . . . . . . . . . . . . . . 24 5.7.1. "rulesetURI" Parameter . . . . . . . . . . . . . . . . 25 5.7.2. Common Policy "ruleset" Parameter . . . . . . . . . . 25 5.8. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 25 5.9. "message" Parameter . . . . . . . . . . . . . . . . . . . 27 5.10. "context" Parameter . . . . . . . . . . . . . . . . . . . 27 5.10.1. "locationURI" Parameter . . . . . . . . . . . . . . . 27 5.10.2. "password" Parameter . . . . . . . . . . . . . . . . . 27 5.10.3. "expires" Parameter . . . . . . . . . . . . . . . . . 28 5.11. "location" Parameter . . . . . . . . . . . . . . . . . . . 28 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.1. HTTP Binding WSDL . . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 8.1. Return Routability . . . . . . . . . . . . . . . . . . . . 38 8.2. Transaction Layer Security . . . . . . . . . . . . . . . . 39 8.3. Veracity of Asserted LI . . . . . . . . . . . . . . . . . 39 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.1. Simple HTTP Binding Example Messages . . . . . . . . . . . 40 9.2. Location Request Examples . . . . . . . . . . . . . . . . 42 9.3. Context Creation and Update Examples . . . . . . . . . . . 44 9.4. Sample LG WSDL Document . . . . . . . . . . . . . . . . . 48 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 10.1. IANA Registry for HELD Result Codes . . . . . . . . . . . 49 10.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 49 10.3. XML Schema Registration . . . . . . . . . . . . . . . . . 50 10.4. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:http . . . . . . . . . 50 10.5. MIME Media Type Registration for 'application/held+xml' . 51 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 12.1. Normative References . . . . . . . . . . . . . . . . . . . 54 12.2. Informative References . . . . . . . . . . . . . . . . . . 55 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 58 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 58 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 58 A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship . . . . 59 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 59 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 60 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 60 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 60 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 61 Appendix B. HELD Compliance to NENA Location Acqusition Requirements . . . . . . . . . . . . . . . . . . . . 62 B.1. DA1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Winterbottom, et al. Expires September 3, 2007 [Page 3] Internet-Draft HELD March 2007 B.2. DA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 B.3. DA3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 B.4. DA4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 B.5. DA5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 B.6. DA6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 B.7. DA7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 B.8. DA8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 B.9. DA9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 B.10. DA10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 B.11. DA11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 B.12. DA12 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 B.13. Rep1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 B.14. Rep2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 B.15. Rep3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 B.16. Rep4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 B.17. LocSec1 . . . . . . . . . . . . . . . . . . . . . . . . . 66 B.18. LocSec2 . . . . . . . . . . . . . . . . . . . . . . . . . 67 B.19. LocSec3 . . . . . . . . . . . . . . . . . . . . . . . . . 67 B.20. LocSec4 . . . . . . . . . . . . . . . . . . . . . . . . . 67 B.21. LocSec5 . . . . . . . . . . . . . . . . . . . . . . . . . 68 B.22. LocSec6 . . . . . . . . . . . . . . . . . . . . . . . . . 68 B.23. LocSec7 . . . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 Intellectual Property and Copyright Statements . . . . . . . . . . 70 Winterbottom, et al. Expires September 3, 2007 [Page 4] Internet-Draft HELD March 2007 1. Introduction The location of a Device is information that is useful for a number of applications. A Device might be able to determine this information using its own resources, but more often than not, the Device must rely on its access network to provide this information. This document describes a protocol that can be used to acquire Location Information (LI) from a service within an access network. This specification identifies two methods for acquiring LI. Location may be retrieved from a Location Generator (LG) by-value, that is, the Device may acquire LI directly. Alternatively, the Device may request that the LG provide a location URI so that LI can be distributed by-reference. Both of these methods are compatible, and both can be provided concurrently from the same LG so that application needs can be addressed individually. This specification defines an XML-based protocol that enables the retrieval of LI from a LG. This protocol can be bound to any session-layer protocol, particularly those capable of MIME transport; an HTTP binding is included as a minimum requirement. 1.1. Exclusions This document defines a protocol for configuration purposes; that is, a protocol for requesting (and receiving) the information necessary to use LI. This document does not define a Geopriv Using Protocol. The LG is assumed to be present within the same administrative domain as the Device (the access network), which limits the security threats that this protocol is exposed to. This document does not specify how LI is derived. Determination of the physical location of a network termination point is dependent on the type of access network and the capabilities of networking equipment. The specific methods that could be used are innumerable, therefore this is left to individual network and equipment implementations. Providing LI by-reference implies that a server is able to provide the Device with a public, globally-routable URI. How this URI is provided is not covered by this specification. This includes any interactions between the LG and LS necessary to facilitate the provision of a Location URI. This document does not define how an LG is discovered or configured. Service discovery techniques are described in [I-D.thomson-geopriv-lis-discovery]. Winterbottom, et al. Expires September 3, 2007 [Page 5] Internet-Draft HELD March 2007 1.2. Device or Target LI provided for the Device is often represented as the location of a user. However, in this document LI is attributed to a Device and not a person. Primarily, this is because location determination technologies are generally designed to locate a Device and not a person. In addition to this, unless the Device requires active user authentication, there is no guarantee that any particular individual is using the Device at that instant. Thus, if any claim of veracity is to be made for LI, the distinction between Target and Device must be made explicit. This distinction should not lead to the impression that the location of the Device does not impact the privacy constraints required by this protocol. Revealing the location of the Device almost invariably reveals some information about the location of the user of the Device, therefore the same level of privacy protection demanded by a user is required for the Device. It is expected that, for most applications, this distinction will be unnecessary: LI for the Device will be used as an adequate substitute for the user's LI. This requires either some additional assurances about the link between Device and Target, or an acceptance of the aforementioned limitations. This document assumes that the Device is responsible for the protocol interactions described and that it does so with the authority of the Target and Rule Maker (RM). 1.3. The Bigger Picture This document describes an interface between a Device and a Location Generator (LG). Detailing the interactions between these two entities requires a wider understanding of other interested parties. For the Device, the most important consideration is the Target. In some cases, this is the same as the Device, but it is more likely to be a human user. The foundation of this protocol is that the Target is able to direct the dissemination of LI, that is, the Target provides authorization policies and otherwise controls how LI is granted to Location Recipients (LRs). This extends to when a Location Server (LS) is employed to provide a Location URI; the LS cannot provide LI to an LR without express permission from the Target. The LG exists as an access network service. An Access Provider (AP) operates this service so that Devices (and Targets) can retrieve LI. The LG exists because not all Devices are capable of determining LI, Winterbottom, et al. Expires September 3, 2007 [Page 6] Internet-Draft HELD March 2007 and because, even if a Device is able to determine its own LI, it may be more efficient with assistance. The following diagram shows one possible configuration of the roles identified in [RFC3693] and where this protocol applies. +-----------+ +-----------+ | Location | | Location | | Generator | - - - - | Server | | | | | +-----------+ +-----------+ | | HELD | | | Rule Maker - _ +-----------+ +-----------+ o - - | Device | | Location | | (Target) |----Object--->| Recipient | | | | (LS, RH) | | | +-----------+ +----------+ +-----------+ Figure 2: Simple Location Request Model In this model, the Device in this scenario acts as a Location Server (LS) and Rule Holder (RH); it is responsible for making authorization decisions about which Location Recipients are given LOs. The LG needs to uniquely identify the Device within the access network. The source address of the request message is sufficient in most cases. Once the Device is identified, the LG uses network domain-specific information to determine the location of the Device. An LI request does not need to include any identification information other than return addressing. In fact, the HTTP binding (Section 7) includes the option for a GET request. Return routability also addresses a number of security concerns, see Section 8. The response from the LG is a PIDF-LO document [RFC4119], unless there were errors in processing the request. The interface between Device (acting as LS) and Location Recipient (LR) is application-specific and outside the scope of this specification. Winterbottom, et al. Expires September 3, 2007 [Page 10] Internet-Draft HELD March 2007 3.1.1. Shaping the PIDF-LO A Device can include additional information in an LI request that controls how the LG populates the fields in a PIDF-LO document. Related to privacy, a presentity URI and usage rules can be specified. The Device can also include a location estimate, or request a specific type of location information, including a request for a signed PIDF-LO. When requesting LI, the Device can include a presentity URI for the Target and a ruleset reference. The LG incorporates this information in the PIDF-LO document, or modifies the document accordingly. LI contained within a PIDF-LO document can be either geodetic (coordinates using latitude and longitude or some other coordinate system) or civic (street or postal addresses). The Device can request that the LG provide a specific type of LI, including whether a jurisdictional or postal civic address is required. If a Device is capable of providing its own location it can include this in a request. The LG is then able to include this LI in the returned PIDF-LO. The type of LI is inferred from the request when LI is provided. The PIDF-LO document generated by an LG MUST follow the rules in [I-D.ietf-geopriv-pdif-lo-profile]. The LI sent in a request MUST follow the subset of those rules relating to the construction of the "location-info" element. 3.2. Requesting a Location URI Requesting LI directly does not always address the requirements of an application. A Location URI is a URI [RFC3986] of any scheme, which a Location Recipient (LR) can use to retrieve LI. A Device can request a Location URI instead of LI. Figure 3 illustrates how this usage of HELD fits within the model presented in [RFC3693]. The first aspect of the diagram shows how the Device acts as an agent for the Target and retrieves a Location URI, which it then provides to the Location Recipient. The second aspect has the Device acting as an agent for the Rule Maker; the Device forwards rules to the LG, which forwards them to the LS. Winterbottom, et al. Expires September 3, 2007 [Page 11] Internet-Draft HELD March 2007 +-----------+ Location +--------------+ | Location |------URI------>| Device | | Generator | | (Target) | | |<-----Rules-----| (Rule Maker) | +-----------+ +--------------+ | | LO & Rules Location URI | | V V +----------+ +------------+ | Location | Location | Location | | Server |------Object----->| Recipient | | | | | +----------+ +------------+ Figure 3: Location URI Usage Model Note that the Location Server takes the role of a (Private) Rule Holder when the rules are provided by-value. The rules may also be provided to the LG and LS by-reference, in which case, a Public Rule Holder is required; the Public Rule Holder is not shown in this diagram. The interface between Device (acting as LS) and Location Recipient (LR) is application-specific and outside the scope of this specification. Also, any interface between Device (acting as RM) and a Public Rule Holder is not relevant to this specification. The merits and drawbacks of using a Location URI approach are discussed in [I-D.marshall-geopriv-lbyr-requirements]. 3.2.1. Establishing a Location Server Context A Location URI is allocated for a Device by the LS. If the LS is to be able to service queries for location directed at the Location URI, it must maintain certain information. When the LG receives a request for a Location URI, it requests that the LS allocate a URI for a particular Device. As a part of providing a Location URI, the LS also creates a _context_, which contains the information that it requires to properly service requests to the URI. This document does not make any normative statements about the interface between the LG and LS. Any assumptions that are made about the nature of this interface are stated where necessary. A context contains sufficient information for the LS to identify the Device to the LG, so that LI can be generated as required, which could be on a per-request basis. The context also includes Winterbottom, et al. Expires September 3, 2007 [Page 12] Internet-Draft HELD March 2007 instructions from the Device on how the PIDF-LO is to be generated, as described in Section 3.1.1. The context contains an authorization policy that describes to whom, and how, LI is granted. This is a common-policy document [I-D.ietf-geopriv-common-policy] that is provided by the Device in the context creation request, either directly, or by reference. Winterbottom, et al. Expires September 3, 2007 [Page 13] Internet-Draft HELD March 2007 4. Protocol Description As discussed in Section 3, this protocol provides two basic functions: LI request and Location URI request. Messages are defined as XML documents. The Location Request message is described in Section 4.2. A Location Request from a Device results in a PIDF-LO document in case of success, or an error message. In requesting a Location URI, the Device requests that a context be created on the LS. The parameters for the create context request are described in Section 4.3.1. The response to a context creation request includes Location URIs and a password that can be used to update the information contained in the context. The details stored by the LS can be updated at any time after creation using the update context request, described in Section 4.3.2. Table 1 shows the basic set of messages supported by this protocol and their respective responses, successful or otherwise. +------------+------------------+-------------------+---------------+ | Operation | Request Message | Successful | Error | | | | Response | Response | +------------+------------------+-------------------+---------------+ | Request | locationRequest | PIDF-LO document | error | | Location | (Section 4.2) | [RFC4119] | (Section 4.5) | | | | | | | Create | createContext | contextResponse | error | | Context | (Section 4.3.1) | | (Section 4.5) | | | | | | | Update | updateContext | contextResponse | error | | Context | (Section 4.3.2) | | (Section 4.5) | +------------+------------------+-------------------+---------------+ Table 1: HELD Operations A MIME type "application/held+xml" is registered in Section 10.5 to distinguish HELD messages from other XML document bodies. This specification follows the recommendations and conventions described in [RFC3023], including the naming convention of the type ('+xml' suffix) and the usage of the 'charset' parameter. Section 5 contains a more thorough description of the protocol parameters, valid values, and how each should be handled. Section 6 contains a more specific definition of the structure of these messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028]. Winterbottom, et al. Expires September 3, 2007 [Page 14] Internet-Draft HELD March 2007 4.1. Protocol Binding The HELD protocol is an application-layer protocol that is defined independently of any lower layers. This means that any protocol can be used to transport this protocol providing that it can provide a few basic features: o The protocol must have acknowledged delivery. o The protocol must be able to correlate a response with a request. o The protocol must provide authentication, privacy and protection against modification. Candidate protocols that could be used to address these purposes include: TCP [RFC0793], TLS [RFC2246], SASL [RFC2222], HTTP [RFC2616], SIP [RFC3261], BEEP [RFC3080] and SOAP [W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part2-20030624]. This document includes a binding that uses a combination of HTTP, TLS and TCP in Section 7. 4.2. Location Request A location request is sent from the Device to the LG when it requires LI. This request can be very simple, including no parameters; in fact, the HTTP binding includes a GET request that does not include a message body. A Device MAY make an assertion about its own location as part of a location request. Devices that have some means of acquiring LI, either from embedded technology like Global Positioning System (GPS) receivers or from user input, can use this to convey that information to the LG. The "assert" element can be used to convey this information. The type of LI that a Device requests is determined by the type of LI that is included in the "assert" element. When asserted LI is not provided, the Device MAY specify the type of location requested using the "locationType" element. LI provided by the Device is potentially more precise than that provided by the LG, therefore the LG MAY use this information to create a response. The LG SHOULD validate the LI provided for accuracy and precision before using this information. The Device MAY specify a "profile" element that instructs the LG on how to construct the LO. Alternatively, if the Device has created a profile in an LS context, the Device can provide a "context" element Winterbottom, et al. Expires September 3, 2007 [Page 15] Internet-Draft HELD March 2007 so that the LG can retrieve the profile from the LS. The location request is made by sending a document formed of a "locationRequest" element. The successful response to a location request is a PIDF-LO document, unless the request fails, in which case the LG SHOULD provide an error indication document. 4.3. Contexts A context is established by the LS in order to provide a Location URI. The context includes information necessary to identify the Device and determine its location when an LR requests an LO using the Location URI. 4.3.1. Creating Contexts The Device uses the "createContext" message to request that the LG, and the LS, assign a Location URI. This establishes a context at the LS. The LS MUST maintain the information provided in the create context request. The create context request includes a time limit, which sets the maximum time that this context can be maintained. The response to a create context request contains information that the Device can use to identify a context. A set of Location URIs are included, each one MUST uniquely identify the context; that is, the LS MUST be able to identify a context based on a single Location URI. A Device can distribute a Location URI to an LR to allow it retrieve LI from the LS. A Location URI MUST NOT contain any information that could be used to identify the Device or Target. It is RECOMMENDED that a Location URI contain a public address for the LS and a random sequence of characters that the LS can use to identify a particular context. The presentity identifier included in a PIDF-LO document SHOULD NOT be used for either part or the entirety of a Location URI. The response to a create context request MUST include the time when the LS will terminate the context. The LS MUST NOT respond to any queries to the context beyond this time. A response to a context creation also includes a password that the Device uses to identify itself when updating the context at any time before the context expiry time. Winterbottom, et al. Expires September 3, 2007 [Page 16] Internet-Draft HELD March 2007 4.3.2. Updating Contexts A Device can update any of the information it has provided for a context at any time. The update context request includes the same information as the create context request with the addition of information that identifies an existing context. A Device uses any one of the Location URIs provided to uniquely identify a context when updating context information. The context password MUST be provided when updating context information. If a Device includes an authorization policy (or ruleset) in an update context request, the LS MUST refresh any stored copy of the authorization policy. This is especially important for authorization policies that are provided by-reference; the LS MUST update the authorization policy, even if the URI has not changed. Updated authorization policies MUST be processed by the LG and LS before any subsequent requests from LRs are accepted; the LG and LS MAY defer processing of the authorization policy until after a response is sent to the Device. The update context request is constructed using the "updateContext" element. A successful response is the "contextResponse" element, which is the same as the response to a create context response. The update context request can also indicate that data can be removed by the context by specifying a _nil_ value for any of the parameters, using the "xsi:nil" attribute. This applies to the profile (Section 5.4) element. The response to an update context request is identical in form to the create context response, with updated information about the context. The Location URIs MUST be the same as those in the response to the initial create context request, but the password and expiry time MAY be changed. 4.3.3. Terminating Contexts The update context request can be used to instruct the LS to terminate a context. The "lifetime" element in the request is set to a zero duration. Once the context has been terminated, or it has expired, Location URIs that reference that context can no longer be used and the Device MUST NOT use the Location URIs or password relating to that context. The LS MAY terminate a context without notifying the Device. The LS SHOULD terminate contexts if it, or the LG, detect that any information relating to the Device changes in a way that invalidates Winterbottom, et al. Expires September 3, 2007 [Page 17] Internet-Draft HELD March 2007 the context. When the Device requests that a context be terminated, the LG responds with a "contextResponse" message that does not include any context information; this message MUST include the HELD "201" response code. 4.4. Combined Context and Location Requests HELD supports an optimization that allows for the creation or update of a context while simultaneously requesting location information. The optional "location" attribute on the "createContext" or "updateContext" request can be used to request that the LG include a PIDF-LO in the "contextResponse". This PIDF-LO is formed according to the profile details associated with the context. 4.5. Indicating Errors In the event of an error, the LG SHOULD respond to the Device with an error document. The error response applies to all request types and SHOULD also be sent in response to any unrecognized request. An error indication document consists of an "error" element. The "error" element MUST include a "code" attribute that indicates the type of error. A set of predefined error codes are included in Section 5.8. Error responses MAY also include a "message" attribute that can include additional information. This information SHOULD be for diagnostic purposes only, and MAY be in any language. The language of the message SHOULD be indicated with an "xml:lang" attribute. Winterbottom, et al. Expires September 3, 2007 [Page 18] Internet-Draft HELD March 2007 5. Protocol Parameters This section describes, in detail the parameters that are used for this protocol. Table 2 lists the top-level components used within the protocol and where they are used. +------------------------+-------------+-------------+--------------+ | Parameter | Location | Create | Update | | | Request | Context | Context | +------------------------+-------------+-------------+--------------+ | responseTime | Request | Request | Request | | (Section 5.1) | | | | | | | | | | assert (Section 5.2) | Request | | | | | | | | | exact (assert) | Request | | | | (Section 5.2.4) | | | | | | | | | | locationType | Request | | | | (Section 5.3) | | | | | | | | | | exact (locationType) | Request | | | | (Section 5.3.1) | | | | | | | | | | profile (Section 5.4) | Request | Request | Request | | | | | | | signed (Section 5.5) | Request | | | | | | | | | lifetime (Section 5.6) | | Request | Request | | | | | | | rules (Section 5.7) | | Request | Request | | | | | | | code (Section 5.8) | Error | Error & | Error & | | | | Response | Response | | | | | | | message (Section 5.9) | Error | Error & | Error & | | | | Response | Response | | | | | | | context (Section 5.10) | Request | Response | Request & | | | | | Response | | | | | | | location | | Request | Request | | (Section 5.11) | | | | +------------------------+-------------+-------------+--------------+ Table 2: Message Parameter Usage Winterbottom, et al. Expires September 3, 2007 [Page 19] Internet-Draft HELD March 2007 5.1. "responseTime" Parameter The "responseTime" attribute indicates to the LG how long the Device is prepared to wait for a response. This attribute MAY be added to any request message, although it is primarily used with the location request. The value of this attribute is indicative only, the LG is under no obligation to strictly adhere to the time limit implied; any enforcement of the time limit is left to the Device. This attribute MAY be either a duration value as defined in XML Schema [W3C.REC-xmlschema-2-20041028], or a decimal seconds value, which may include a decimal point. It is RECOMMENDED that systems support millisecond precision for this parameter. The LG SHOULD provide the most accurate LI that can be determined within the specified interval. This parameter could be used as input when selecting the method of location determination, where multiple such methods exist. If this parameter is absent, then the LG SHOULD return the most precise LI it is capable of determining. 5.2. "assert" Parameter The "assert" element allows a Device to provide LI to the LG as part of a location request. Two types of content are allowed: a geodetic structure made up of a Geography Markup Language (GML) geometry object, "_Geometry" as defined by [OGC.GML-3.1.1]; and a civic address structure, "civicAddress" as defined by [I-D.ietf-geopriv-revised-civic-lo]. The contents of this element SHOULD follow the rules in [I-D.ietf-geopriv-pdif-lo-profile]. When used in combination with the "context" element, this LI MAY be used by the LS for requests to Location URIs for that context. This element is mutually exclusive with the "locationType" parameter, defined in Section 5.3. The type of LI requested is implied by the types included in the assertion. 5.2.1. "method" Parameter The "method" attribute SHOULD be attached to the "assert" element to indicate the means by which the LI was derived. This attribute follows the rules of the similarly named method element of the PIDF-LO. 5.2.2. "timestamp" Parameter The "timestamp" attribute SHOULD be attached to the "assert" element to indicate when the LI was generated. Winterbottom, et al. Expires September 3, 2007 [Page 20] Internet-Draft HELD March 2007 5.2.3. "expires" Parameter The "expires" attribute MAY be attached to the "assert" element to indicate when the included LI is no longer valid. The LG SHOULD set the "retention-expires" element in the returned PIDF-LO to no later than this time if it uses the LI. This attribute SHOULD NOT be included unless this time is definite. 5.2.4. "exact" Parameter When the "exact" attribute is set to "true", it indicates to the LG that the contents of the "assert" parameter MUST be strictly followed. The default value of "false" allows the LG the option of ignoring these values. This attribute indicates that the asserted LI MUST be included in the PIDF-LO response. If the LG cannot do this for any reason, which is usually because it determines that the LI was inaccurate or insufficiently precise, the LG MUST indicate an error. 5.3. "locationType" Parameter The "locationType" element is included in a location request. It contains a list of LI types that are requested by the Device. The following list describes the possible values: any: The LG SHOULD attempt to provide LI in all forms available to it. This value MUST be assumed as the default if no "locationType" is specified. The LG SHOULD return location information in a form that is suited for routing and responding to an emergency call in its jurisdiction. geodetic: The LG SHOULD return a geodetic location for the Target. civic: The LG SHOULD return a civic address for the Target. Any type of civic address may be returned. The LG SHOULD ignore this value if a request for jurisdictional or postal civic address has been made and can be satisfied. jurisdictionalCivic: The LG SHOULD return a jurisdictional civic address for the Target. postalCivic: The LG SHOULD return a postal civic address for the Target. The "locationType" element is mutually exclusive with the "assert" element, defined in Section 5.2. Winterbottom, et al. Expires September 3, 2007 [Page 21] Internet-Draft HELD March 2007 The LG SHOULD return the requested location type or types. The LG MAY provide additional location types, or it MAY provide alternative types if the request cannot be satisfied for a requested location type. If the "exact" attribute is present and set to "true" in a location request, then a successful LG response MUST provide the requested location type only, with no additional location information. The "exact" attribute has no effect when this element is set to "any". The "SHOULD"-strength requirement on this parameter is included to allow for soft-failover. This enables a fixed client configuration that prefers a specific location type without causing location requests to fail when that location type is unavailable. Unless the "exact" attribute is set, the LG MUST provide LI in any available form if it is unable to comply with the request. For example, a notebook computer could be configured to retrieve civic addresses, which is usually available from typical home or work situations. However, when using a wireless modem, the LG might be unable to provide a civic address. 5.3.1. "exact" Parameter When the "exact" attribute is set to "true", it indicates to the LG that the contents of the "locationType" parameter MUST be strictly followed. The default value of "false" allows the LG the option of ignoring these values. A value of "true" indicates that the LG MUST provide a PIDF-LO that includes LI of the requested type or types. The LG MUST provide the requested types only and these types SHOULD be specified in the same order as they were requested. The LG SHOULD handle an exact request that includes a "locationType" element set to "any" as if the "exact" attribute were set to "false". 5.4. "profile" Parameter The "profile" element contains a presentity identifier [RFC2778] and GEOPRIV usage rules [RFC4119] information. All fields are optional within this element, but when these fields are included, the LG MUST use these parameters when constructing the PIDF-LO document. This element MAY be included in location requests, create context requests and update context requests. When included in a location request, the profile is used immediately; when used in create context or update context requests, the profile is stored on the LS and is provided to the LG when the LS responds to requests from LRs. Winterbottom, et al. Expires September 3, 2007 [Page 22] Internet-Draft HELD March 2007 5.4.1. "presentity" Parameter The "presentity" element contains a presentity identifier that the LG SHOULD include in the "pres" attribute of the PIDF-LO document. The LG MAY require authentication of the presentity through any means; the LG SHOULD ignore this parameter if authentication information is not present or authentication information cannot be verified. 5.4.2. "retentionExpiry" Parameter The "retentionExpiry" element contains an absolute "dateTime" [W3C.REC-xmlschema-2-20041028] value for the "retention-expires" element of the PIDF-LO usage rules. This element is mutually exclusive with the "retentionInterval" element. The LG MAY use a different value than that specified (or the suggested default) as circumstances dictate, but MUST NOT use a value later than specified. If this value indicates a time that has already passed, the request MUST be rejected with an error. See retentionInterval (Section 5.4.3) for more details. 5.4.3. "retentionInterval" Parameter The "retentionInterval" element contains a time duration value that is specified in the same fashion as the responseTime attribute (Section 5.1). This value MUST be added to the time at which the PIDF-LO document is created to set the value of the "retention-expires" element. This element enables the Target to set an interval over which a LR can retain a LO, rather than an absolute time. This element is mutually exclusive with the "retentionExpires" element. If neither "retentionExpiry" nor "retentionInterval" are specified, the LG SHOULD provide a default value for the "retention-expires" element of the generated PIDF-LO document. The default for this value SHOULD be 24 hours from the receipt of the location request as defined in [RFC4119]. The LG MAY use a different value than that specified (or the suggested default) as circumstances dictate, but MUST NOT use a value larger than specified. Winterbottom, et al. Expires September 3, 2007 [Page 23] Internet-Draft HELD March 2007 5.4.4. "retransmission" Parameter The "retransmission" element contains a boolean value that MUST be included in the "retransmission-allowed" element of the generated PIDF-LO usage rules. When this element is not provided, the LG MUST set the "retransmission-allowed" element to "false". 5.4.5. "rulesetURI" Parameter The "rulesetURI" element contains a URI value that MUST be included in the "ruleset-reference" element of the generated PIDF-LO usage rules. This datum is only used to construct the usage rules in the PIDF-LO document. Within the context of a profile, this ruleset is not applied by either LG or LS, and the LS does not apply the rules found at the URI. 5.5. "signed" Parameter The "signed" attribute indicates whether the Device requires a digitally signed PIDF-LO. When present and set to "true", the LG MUST provide a PIDF-LO document that is signed according to [I-D.thomson-geopriv-location-dependability]. 5.6. "lifetime" Parameter The "lifetime" element specifies the maximum time that a context should be maintained by the LS. This parameter MUST be included in the context creation request to indicate to the LS the latest time that the context is allowed to be retained. The parameter MAY be included in context update requests to modify this time; when included in an update request with a zero value, it indicates that the context MUST be removed immediately. The "lifetime" element is a duration value that is specified in the same fashion as the "responseTime" attribute. This value MUST be added to the current time when received by the LS to determine the time at which the context expires. An LS MAY use any value less than or equal to this value, but MUST NOT use a longer value. The actual expiry time of the context MUST be indicated in the context response. 5.7. "rules" Parameter The "rules" element contains the authorization policy of the Target that dictates how and to whom LI is provided by the LS. This policy Winterbottom, et al. Expires September 3, 2007 [Page 24] Internet-Draft HELD March 2007 MUST be applied by the LS when providing LI to LRs. Authorization policies MUST conform to [I-D.ietf-geopriv-common-policy]. If the authorization policy is invalid, cannot be retrieved, or is otherwise not understood by the LS, the LG SHOULD fail the request. Note that this implies that the LS SHOULD attempt to retrieve an authorization policy that is provided by-reference at the time of a create context request; however, an LS MAY choose to do this later, if the requested response time might be exceeded. In the absence of an authorization policy, the LS MUST NOT provide LI to any LR. Note that in certain jurisdictions an LS might be required to provide LI to specific parties irrespective of the authorization policy, as mandated by legislation; for example, emergency services in some countries. 5.7.1. "rulesetURI" Parameter The "rulesetURI" element contains a URI that references the Target's authorization policy. This URI should reference a document of type "application/auth-policy+xml" as defined in [I-D.ietf-geopriv-common-policy]. It is RECOMMENDED that a ruleset URI use the "https" scheme. It is anticipated that, to improve responsiveness and reduce network usage, an LS could cache an authorization policy, consistent with the rules specified by the Rule Holder. For instance, the Rule Holder could specified retention times using the "Expires" header in HTTP [RFC2616]. The impact of changes to authorization policies are discussed in Section 4.3.2. 5.7.2. Common Policy "ruleset" Parameter The "ruleset" element, which is in the "urn:ietf:params:xml:ns:common-policy" namespace [I-D.ietf-geopriv-common-policy], allows for providing an authorization policy directly as part of a request. 5.8. "code" Parameter All responses, except a PIDF-LO document, MUST contain a response code. The "code" attribute applies to the "error" and "contextResponse" messages. The following response codes follow a three decimal form similar to that in HTTP [RFC2616] and SIP [RFC3261]: Winterbottom, et al. Expires September 3, 2007 [Page 25] Internet-Draft HELD March 2007 200 (Success): This code indicates that the request was successful. This code MUST not be used for an error response. 201 (Context Terminated): This code indicates that the request to terminate a context was successful. 400 (Request Error): This code indicates that the request was badly formed in some fashion. 401 (XML Error): This code indicates that the XML content of the request was either badly formed or invalid. 402 (Authentication Error): This code indicates that the request either did not contain authentication information, or the authentication provided was not accepted. 403 (Asserted Location Error): This code indicates that the LI that was asserted in the request was not acceptable to the LG. This code is used when the "exact" attribute on the "assert" parameter is set to "true". 404 (Context Not Found): This code indicates that the context identified in the request was not found. This code MAY also be used if the password provided was incorrect. 500 (General LG Error): This code indicates that an unspecified error occurred at the LG. 501 (Location Unknown): This code indicates that the LG could not determine the location of the Device. 502 (Unsupported Message): This code indicates that the request was not supported or understood by the LG. 503 (Timeout): This code indicates that the LG could not satisfy the request within the time specified in the "requestTime" parameter. 504 (Cannot Provide LI Type): This code indicates that the LG was unable to provide LI of the type or types requested. This code is used when the "exact" attribute on the "locationType" parameter is set to "true". Additional response codes within the x00 to x79 range MUST be specified in published RFCs; the range from x80 to x99 is reserved for private usage. Winterbottom, et al. Expires September 3, 2007 [Page 26] Internet-Draft HELD March 2007 5.9. "message" Parameter The "contextResponse" and "error" messages MAY include a "message" attribute to convey some additional, human-readable information about the result of the request. This message MAY be included in any language, which SHOULD be indicated by the "xml:lang", attribute. 5.10. "context" Parameter The "context" element includes information that is used to identify a context and control access to it. The context is identified by one or more Location URIs and a Device is granted a password which MUST be provided when accessing the context to update the information contained. When a context is created, the LG provides a "contextResponse" message that contains the "context" element. This element contains all of the Location URIs that can be used for the context, a password, and an expiry time. To update the details in a context, or reuse profile information stored in the context, the Device provides a "context" element. When identifying a context in this manner, the Device MUST provide only one Location URI and the password. 5.10.1. "locationURI" Parameter The "locationURI" element includes a single Location URI. Each Location URI is allocated by the LS so that it is able to uniquely identify the context. A "contextResponse" message contains any number of "locationURI" elements. It is RECOMMENDED that the LS allocate a Location URI for all schemes that it supports and that no scheme is present twice. All "updateContext" request messages MUST contain only one "locationURI" element, which is all that is necessary to uniquely identify a context. The Device MAY select any of the Location URIs provided by the LS. Location URIs do not change over the lifetime of a context. 5.10.2. "password" Parameter The "password" element carries a password that is used to access the context after it has been created. The LS generates this value when creating a context and the Device MUST use the exact same value when it wishes to access the context. This value acts as a shared secret between Device and LS. Winterbottom, et al. Expires September 3, 2007 [Page 27] Internet-Draft HELD March 2007 The value of the password MAY be updated in the response to any "updateContext" message. This element MAY contain any valid XML character data, within the constraints of the XML Schema "token" type. 5.10.3. "expires" Parameter The "expires" attribute indicates the time at which the context created by the LS will expire. This attribute is included in the "contextResponse" message only. Responses to create and update context requests MUST include the expiry time of the context. If the LS has expired a context in response to an update context request, this value SHOULD include a time in the past to avoid problems that could be caused by a slow clock in the Device. 5.11. "location" Parameter The "location" parameter is a boolean attribute associated with the "createContext" or "updateContext" message. The default for this attribute is "false". This parameter, when present and set to "true" indicates that the LG SHOULD include a PIDF-LO document in the "contextResponse" message. The success of any request that includes this parameter MUST NOT be affected by any error in providing a location; thus, if the LG is unable to include a PIDF-LO, it is only omitted from the response. If a "contextResponse" does not include a PIDF-LO, the Device can determine the reasons for failure by sending a separate "locationRequest". Note: The schema does not include an explicit particle for the "presence" element. This is because the "any" construct used to allow for extensions would conflict with any optional element, due to the Unique Particle Attribution schema rule. Winterbottom, et al. Expires September 3, 2007 [Page 28] Internet-Draft HELD March 2007 6. XML Schema This section gives the XML Schema Definition [W3C.REC-xmlschema-1-20041028] of the "application/held+xml" format. This is presented as a formal definition of the "application/ held+xml" format. Note that the XML Schema definition is not intended to be used with on-the-fly validation of the presence XML document. This document defines HELD messages. Winterbottom, et al. Expires September 3, 2007 [Page 29] Internet-Draft HELD March 2007 Winterbottom, et al. Expires September 3, 2007 [Page 30] Internet-Draft HELD March 2007 Winterbottom, et al. Expires September 3, 2007 [Page 31] Internet-Draft HELD March 2007 Winterbottom, et al. Expires September 3, 2007 [Page 32] Internet-Draft HELD March 2007 Winterbottom, et al. Expires September 3, 2007 [Page 33] Internet-Draft HELD March 2007 Winterbottom, et al. Expires September 3, 2007 [Page 34] Internet-Draft HELD March 2007 7. HTTP Binding This section defines an HTTP [RFC2616] binding for this protocol, which all conforming implementations MUST support. This binding takes the form of a Web Service (WS) that can be described by the Web Services Description Language (WSDL) document in Section 7.1. The three request messages are carried in this binding as the body of an HTTP POST request. The MIME type of both request and response bodies should be "application/held+xml", except that a PIDF-LO document SHOULD have the MIME type "application/pidf+xml". The LG populates the HTTP headers so that they are consistent with the contents of the message. In particular, the "Expires" and cache control headers are used to control the caching of any PIDF-LO document. The HTTP status code SHOULD have the same first digit as any "contextResponse" or "error" body included, and it SHOULD indicate a 2xx series response when a PIDF-LO document is included. This binding also includes a default behaviour, which is triggered by a GET request, or a POST with no request body. If either of these queries are received, the LG MUST attempt to provide a PIDF-LO document, as if the request was a location request. This binding MUST use TLS as described in [RFC2818]. TLS provides message integrity and privacy between Device and LG. The LG MUST use the server authentication method described in [RFC2818]; the Device MUST fail a request if server authentication fails, except in the event of an emergency. 7.1. HTTP Binding WSDL The following WSDL 2.0 [W3C.CR-wsdl20-20060106] document describes the HTTP binding for this protocol. Actual service instances MUST provide a "service" with at least one "endpoint" that implements the "heldHTTP" binding. A service description document MAY include this schema directly or by using the "import" or "include" directives. Winterbottom, et al. Expires September 3, 2007 [Page 35] Internet-Draft HELD March 2007 This document describes the basic HELD web service. Please refer to RFCXXXX for details. [[NOTE TO RFC-EDITOR: Please replace XXXX with the RFC number for this specification and remove this note.]] Winterbottom, et al. Expires September 3, 2007 [Page 37] Internet-Draft HELD March 2007 8. Security Considerations The threat model for this protocol assumes that the LG exists within the same administrative domain as the Device. The LG requires access to network information so that it can determine LI. Therefore, the LG can use network information to protect against a number of the possible attacks. Specific requirements and security considerations ofr location acquisition protocols provided in [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security considerations applicable to the use of Location URIs and by-reference provision of LI is included in [I-D.marshall-geopriv-lbyr-requirements]. 8.1. Return Routability It is RECOMMENDED that Location Generators use return routability rather than requiring Device authentication. Device authentication SHOULD NOT be required due to the administrative challenge of issuing and managing of client credentials, particularly when networks allow visiting users to attach devices. However, the LG MAY require any form of authentication as long as these factors are considered. Addressing information used in a request to the LG is used to determine the identity of the Device, and to address a response. This ensures that a Device can only request its own LI. A temporary spoofing of IP address could mean that a device could request a Location URI that would result in another Device's location. One or more of the follow approaches are RECOMMENDED to limit this exposure: o Location URIs SHOULD have a limited lifetime, that is, the LG SHOULD enforce a maximum value for the lifetime element (Section 5.6). o The network SHOULD have mechanisms that protect against IP address spoofing. o The LG SHOULD ensure that requests can only originate from within its administrative domain. o The LG and network SHOULD be configured so that the LG is made aware of Device movement within the network and addressing changes. If the LG and LS detect a change in the network that invalidates a context, the context MUST be terminated. Winterbottom, et al. Expires September 3, 2007 [Page 38] Internet-Draft HELD March 2007 The above measures are dependent on network configuration and SHOULD be considered with circumstances in mind. For instance, in a fixed internet access providers may be able to restriction the allocation of IP addresses to a single physical line, ensuring that spoofing is not possible; in such an environment, the other measures are not necessary. 8.2. Transaction Layer Security All bindings for this protocol MUST ensure that messages are adequately protected against eavesdropping and modification. Bindings MUST also provide a means of authenticating the LG. It is RECOMMENDED that all bindings also use TLS [RFC2246]. For the HTTP binding, TLS MUST be used. TLS provides protection against eavesdropping and modification. The server authentication methods described in HTTP on TLS [RFC2818] MUST be used. 8.3. Veracity of Asserted LI The assert element (Section 5.2) allows a Device the ability to provide LI. However, if an LG uses asserted LI, it is the LG that becomes responsible for the veracity of that information. Therefore, when the Device provides LI in a request, the LG MUST NOT use this information unless it can ensure its accuracy. This prevents the fraudulent provision of LI that could be caused by the LG accepting LI without any checks. It is unlikely that an LG is able to verify Device-provided LI beyond any uncertainty. The ability of an LG to verify LI is limited by its own capacity to determine the location of the Device. The LG SHOULD indicate the source of LI using the PIDF-LO "method" parameter so that users of LI can make appropriate judgments on its veracity. Winterbottom, et al. Expires September 3, 2007 [Page 39] Internet-Draft HELD March 2007 9. Examples 9.1. Simple HTTP Binding Example Messages The examples in this section show a complete HTTP message that includes the HELD request or response document. This example shows the most basic request for a LO. This uses the GET feature described by the HTTP binding. This example assumes that the LG service exists at the URL "https://lg.example.com/location". GET /location HTTP/1.1 Host: lg.example.com Accept: application/pidf+xml,application/held+xml,application/xml;q=0.8, text/xml;q=0.7 Accept-Charset: UTF-8,* The GET request is exactly identical to a minimal POST request that includes an empty "locationRequest" element. POST /location HTTP/1.1 Host: lg.example.com Accept: application/pidf+xml,application/held+xml,application/xml;q=0.8, text/xml;q=0.7 Accept-Charset: UTF-8,* Content-Type: application/held+xml Content-Length: 87 Winterbottom, et al. Expires September 3, 2007 [Page 40] Internet-Draft HELD March 2007 The successful response to either of these requests is a PIDF-LO document. The following response shows a minimal PIDF-LO response. HTTP/1.x 200 OK Server: Example LG Date: Tue, 10 Jan 2006 03:42:29 GMT Expires: Tue, 10 Jan 2006 03:42:29 GMT Cache-control: private Content-Type: application/pidf+xml Content-Length: 594 -34.407 150.88001 2006-01-11T03:42:28+00:00 2006-01-10T03:42:28+00:00 The error response to either of these requests is an error document. The following response shows an example error response. HTTP/1.x 500 Server Error Server: Example LG Date: Tue, 10 Jan 2006 03:49:20 GMT Expires: Tue, 10 Jan 2006 03:49:20 GMT Cache-control: private Content-Type: application/held+xml Content-Length: 135 Winterbottom, et al. Expires September 3, 2007 [Page 41] Internet-Draft HELD March 2007 Note: To focus on important portions of messages, all examples following this note do not show HTTP headers or the XML prologue. In addition, sections of XML not relevant to the example are replaced with comments. 9.2. Location Request Examples The location request shown below specifies location types and provides a profile that the LG applies to the PIDF-LO document. The request specifies that a response is desired within 10.5 seconds. jurisdictionalCivic geodetic pres:user@example.com 1800 false https://example.com/~user/ruleset.xml Winterbottom, et al. Expires September 3, 2007 [Page 42] Internet-Draft HELD March 2007 The response to this location request is the following PIDF-LO document, which shows how the profile values are applied. false 2006-01-11T03:42:28+00:00 https://example.com/~user/ruleset.xml 2006-01-10T03:42:28+00:00 Winterbottom, et al. Expires September 3, 2007 [Page 43] Internet-Draft HELD March 2007 The following location request includes a location assertion that includes a user-provided civic address. This message also requests that the LG retrieve profile information from a context that exists on an LS. https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o vs76e8cae9873a079888p9y4txwa Since this request includes the "exact" parameter set to "true", any successful response MUST include the provided LI. 9.3. Context Creation and Update Examples The following create context request shows the simplest form of this message, which sets a two hour lifetime on the context and includes a "rulesetURI" element for the LS. PT2H https://www.example.com/~user/privacy/ruleset.xml Winterbottom, et al. Expires September 3, 2007 [Page 44] Internet-Draft HELD March 2007 The following more complex create context request includes additional information. This includes a profile that sets the presentity and some of the "usage-rules" components in the PIDF-LO that the LS serves. PT2H pres:user@example.com 2006-01-13T12:00:00+00:00 false https://www.example.com/~user/privacy/ruleset.xml A typical successful response to this message provides several Location URIs in different schemes (in this case: "https" and "sips"), the exact context expiry time, and a password that can be used to update the context. https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o sips://ls.example.com:9769/357yc6s64ceyoiuy5ax3o 38cdj38mjcd-0-=54821kj28mp1qms.1 If any aspect of the data stored in a context changes, a "contextUpdate" request is sent to the LG to request that it update the information. This request includes the information necessary to access a context (the location URI and password) and only the information that has changed. Winterbottom, et al. Expires September 3, 2007 [Page 45] Internet-Draft HELD March 2007 The following request demonstrates how information stored in a context could be updated. For the context previously created, this provides the "retentionInterval" element, which overrides a previously configured "retentionExpiry" value. https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 38cdj38mjcd-0-=54821kj28mp1qms.1 600 To indicate success, the LG provides a "contextResponse" identical in form to the original request. The following request shows that a context lifetime can be extended or shortened by the Device by updating a context with a new "lifetime" element. The following message requests that the LS maintain the context for two hours beyond the current time. https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 38cdj38mjcd-0-=54821kj28mp1qms.1 PT2H Winterbottom, et al. Expires September 3, 2007 [Page 46] Internet-Draft HELD March 2007 The response to a request to extend the context includes the new expiry time of the context, if it has changed. https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o sips://ls.example.com:9769/357yc6s64ceyoiuy5ax3o 38cdj38mjcd-0-=54821kj28mp1qms.1 A zero value for the "lifetime" element terminates the context. The following request terminates the context. https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 38cdj38mjcd-0-=54821kj28mp1qms.1 PT0S The response to a message that requests the termination of a context appears as follows. Winterbottom, et al. Expires September 3, 2007 [Page 47] Internet-Draft HELD March 2007 9.4. Sample LG WSDL Document The following WSDL document demonstrates how a WSDL document can be created for a specific service, in this case, a service at the URI "https://lg.example.com/location". Winterbottom, et al. Expires September 3, 2007 [Page 48] Internet-Draft HELD March 2007 10. IANA Considerations According to the guidelines in [RFC3688], this document calls for an IANA registry for result codes and registers an XML namespace and schema. It also registers the "application/held+xml" MIME type. 10.1. IANA Registry for HELD Result Codes IANA will establish and maintain a registry of HELD result codes. Additional values are registered based on the "specification required" option in [RFC3688]. Specifications MUST specify the following information when registering new values in this registry: Code Value: A three-digit value from 000 to 679. The last 20 codes in each block of 100 (from x80 to x99) are reserved for private or experimental use and cannot be registered. Short Message: A brief message that describes the general reason for the code. Publication: A reference to any relevant publication or specification. Description and Usage: A longer description of the code and the circumstances where it applies. This description does not need to be exhaustive. The values in Section 5.8 are pre-registered in this registry. 10.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held", as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:geopriv:held Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). XML: Winterbottom, et al. Expires September 3, 2007 [Page 49] Internet-Draft HELD March 2007 BEGIN HELD Messages

Namespace for HELD Messages

urn:ietf:params:xml:ns:geopriv:held

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 10.3. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:geopriv:held Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). Schema: The XML for this schema can be found as the entirety of Section 6 of this document. 10.4. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:http This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held:http", as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:geopriv:held:http Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). XML: Winterbottom, et al. Expires September 3, 2007 [Page 50] Internet-Draft HELD March 2007 BEGIN HELD HTTP Binding WS

Namespace for HELD HTTP Binding WS

urn:ietf:params:xml:ns:geopriv:held:http

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 10.5. MIME Media Type Registration for 'application/held+xml' This section registers the "application/held+xml" MIME type. To: ietf-types@iana.org Subject: Registration of MIME media type application/held+xml MIME media type name: application MIME subtype name: held+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], section 3.2. Security considerations: This content type is designed to carry protocol data related to the location of an entity, which could include information that is considered private. Appropriate precautions should be taken to limit disclosure of this information. Winterbottom, et al. Expires September 3, 2007 [Page 51] Internet-Draft HELD March 2007 Interoperability considerations: This content type provides a basis for a protocol Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]] Applications which use this media type: Location information providers and consumers. Additional Information: Magic Number(s): (none) File extension(s): .xml Macintosh File Type Code(s): (none) Person & email address to contact for further information: Martin Thomson Intended usage: LIMITED USE Author/Change controller: This specification is TBD Other information: This media type is a specialization of application/xml [RFC3023], and many of the considerations described there also apply to application/held+xml. Winterbottom, et al. Expires September 3, 2007 [Page 52] Internet-Draft HELD March 2007 11. Acknowledgements The authors would like to thank the following people for their contribution to this document (in alphabetical order): Nadine Abbott, Guy Caron, Martin Dawson, Jerome Grenier, Neil Justusson, Tat Lam, Patti McCalmont, Perry Prozeniuk, John Schnizlein, Henning Schulzrinne, Ed Shrum, and Hannes Tschofenig. Winterbottom, et al. Expires September 3, 2007 [Page 53] Internet-Draft HELD March 2007 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2616] 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. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [I-D.ietf-geopriv-revised-civic-lo] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in progress), February 2007. [I-D.ietf-geopriv-pdif-lo-profile] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", draft-ietf-geopriv-pdif-lo-profile-05 (work in progress), October 2006. [I-D.thomson-geopriv-lis-discovery] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", draft-thomson-geopriv-lis-discovery-00 (work in progress), February 2007. [I-D.marshall-geopriv-lbyr-requirements] Winterbottom, et al. Expires September 3, 2007 [Page 54] Internet-Draft HELD March 2007 Marshall, R., "Requirements for a Location-by-Reference Mechanism used in Location Configuration and Conveyance", draft-marshall-geopriv-lbyr-requirements-00 (work in progress), February 2007. [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf-geopriv-l7-lcp-ps-00 (work in progress), January 2007. [I-D.ietf-geopriv-common-policy] Schulzrinne, H., "Common Policy: A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-11 (work in progress), August 2006. [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, . [OGC.GML-3.1.1] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, "Geographic information - Geography Markup Language (GML)", OpenGIS 03-105r1, April 2004, . [NENA_TID] National Emergency Number Association (NENA), "NENA Recommended Method(s) for Location Determination to Support IP-Based Emergency Services Technical Information Document", NENA VoIP Location Working Group 08-505 Issue 1, December 2006, . [I-D.thomson-geopriv-location-dependability] Thomson, M. and J. Winterbottom, "Digital Signature Methods for Location Dependability", February 2007. 12.2. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2222] Myers, J., "Simple Authentication and Security Layer Winterbottom, et al. Expires September 3, 2007 [Page 55] Internet-Draft HELD March 2007 (SASL)", RFC 2222, October 1997. [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [RFC3261] 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. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [W3C.REC-xmlschema-1-20041028] Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, . [W3C.REC-soap12-part1-20030624] Mendelsohn, N., Gudgin, M., Moreau, J., Hadley, M., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium Recommendation REC-soap12-part1- 20030624, June 2003, . [W3C.REC-soap12-part2-20030624] Gudgin, M., Hadley, M., Nielsen, H., Moreau, J., and N. Mendelsohn, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Web Consortium Recommendation REC-soap12-part2- 20030624, June 2003, . [W3C.CR-wsdl20-20060106] Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language", W3C CR CR-wsdl20-20060106, January 2006. [I-D.winterbottom-geopriv-held-identity-extensions] Winterbottom, et al. Expires September 3, 2007 [Page 56] Internet-Draft HELD March 2007 Winterbottom, J. and M. Thomson, "HELD End-Point identity Extensions", draft-winterbottom-geopriv-held-identity-extensions-00 (work in progress), October 2006. [I-D.thomson-geopriv-held-capabilities] Thomson, M. and J. Winterbottom, "Device Capability Negotiation for Device-Based Location Determination and Location Measurements in HELD", draft-thomson-geopriv-held-capabilities-01 (work in progress), February 2007. [I-D.thomson-geopriv-held-beep] Thomson, M. and J. Winterbottom, "A BEEP Binding for the HELD Protocol", February 2007. Winterbottom, et al. Expires September 3, 2007 [Page 57] Internet-Draft HELD March 2007 Appendix A. HELD Compliance to IETF LCP requirements This appendix describes HELD's compliance to the requirements specified in the [I-D.ietf-geopriv-l7-lcp-ps]. In addition to the LCP requirements specified by the IETF, HELD has independently been assessed against and found to comply with all the NENA requirements for a location acqusition protocol defined in [NENA_TID]. A.1. L7-1: Identifier Choice "The LIS MUST be presented with a unique identifier of its own addressing realm associated in some way with the physical location of the end host." COMPLY The identifier used may be the source address of the request packet and/or additional client identifier values relevant to the scope of the access network provided within the request. Mapping an IP address into lower-level attachment data is access network dependent and is the responsibility the LIS. HELD can however be used to provide assistence to the LIS through the inclusion of identity extensions such as those defined in [I-D.winterbottom-geopriv-held-identity-extensions]. A.2. L7-2: Mobility Support "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a broad range of mobility from devices that can only move between reboots, to devices that can change attachment points with the impact that their IP address is changed, to devices that do not change their IP address while roaming, to devices that continuously move by being attached to the same network attachment point." COMPLY Mobility support is inherently a characteristic of the access network technology and HELD is designed to be access network agnostic. Consequently HELD complies with this requirement. In addition HELD provides specific support for mobile environments by providing an optional responseTime attribute in location request messages. Wireless networks often have several different mechanisms at their disposal for position determination (e.g. Assisted GPS versus location based on serving base station identity), each providing different degrees of accuracy and taking different amounts of time to yield a result. The responseTime parameter provides the LIS with a criterion which it can use to select a location determination technique. Winterbottom, et al. Expires September 3, 2007 [Page 58] Internet-Draft HELD March 2007 HELD also supports an extension mechanism that allows location measurement capabilities to be exchanged between the end-point and the LIS. This mechanism allows for a greater number of location determination techniques to be used by both the end-point and the LIS. The specification describing this capability is provided in [I-D.thomson-geopriv-held-capabilities]. A.3. L7-3: Layer 7 and Layer 2/3 Provider Relationship "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST NOT assume a business or trust relationship between the provider of application layer (e.g., SIP, XMPP, H.323) provider and the access network provider operating the LIS." COMPLY HELD describes a location acquisition protocol and has no dependencies on how location is used once it has been acquired. Location acquisition using HELD is subject to the restrictions described in Section 8. A.4. L7-4: Layer 2 and Layer 3 Provider Relationship "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST assume that there is a trust and business relationship between the L2 and the L3 provider. The L3 provider operates the LIS and needs to obtain location information from the L2 provider since this one is closest to the end host. If the L2 and L3 provider for the same host are different entities, they cooperate for the purposes needed to determine end system locations." COMPLY HELD was specifically designed with this model in mind and readily allows itself to chaining requests between operators without a change in protocol being required. Examples of how HELD can be used in this manner are provided in detail in [NENA_TID]. HELD is a webservices protocol it can be bound to transports other than HTTP, for example a BEEP binding for HELD, [I-D.thomson-geopriv-held-beep]. Using a transport like BEEP for HELD offers the option of high request throughput over a dedicated connection between an L3 provider and an L2 provider without incurring the serial restriction imposed by HTTP. This is less easy to do with protocols that do not decouple themselves from the transport. Winterbottom, et al. Expires September 3, 2007 [Page 59] Internet-Draft HELD March 2007 A.5. L7-5: Legacy Device Considerations "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST consider legacy residential NAT devices and NTEs in an DSL environment that cannot be upgraded to support additional protocols, for example to pass additional information through DHCP." COMPLY HELD is an application protocol and operates on top of IP. A HELD request from a host behind a residential NAT will traverse the NAT acquiring the external address of the home router. The location provided to the host therefore will be the address of the home router in this circumstance. No changes are required to the home router in order to support this function, HELD was designed specifically to address this deployment scenario. Examples of how HELD can be used in this type of network environment are provided in [NENA_TID]. A.6. L7-6: VPN Awareness "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST assume that at least one end of a VPN is aware of the VPN functionality. In an enterprise scenario, the enterprise side will provide the LIS used by the client and can thereby detect whether the LIS request was initiated through a VPN tunnel." COMPLY HELD does not preclude a LIS on the far end of a VPN tunnel being aware that the client request is occurring over that tunnel. It also does not preclude a client device from accessing a LIS serving the local physical network and subsequently using the location information with an application that is accessed over a VPN tunnel. A.7. L7-7: Network Access Authentication "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST NOT assume prior network access authentication." COMPLY HELD makes no assumptions about prior network access authentication. HELD strongly recommends the use of TLS with server-side certificates for communication between the end-point and the LIS. There is no requirement for the end-point to authenticate with the LIS. Winterbottom, et al. Expires September 3, 2007 [Page 60] Internet-Draft HELD March 2007 A.8. L7-8: Network Topology Unawareness "The design of the GEOPRIV Layer 7 Location Configuration Protocol MUST NOT assume end systems being aware of the access network topology. End systems are, however, able to determine their public IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." COMPLY HELD makes no assumption about the network topology. HELD doesn't require that the device know its external IP address, except where that is required for discovery of the LIS. LIS disocvery techniques available to a HELD client are described in [I-D.thomson-geopriv-lis-discovery]. In certain network environments an end-point maybe able to ascertain information about the topology of the access network which may assist the LIS in location determination. HELD provides support for extensions that allow this information to be communicated to the LIS when it is available. Winterbottom, et al. Expires September 3, 2007 [Page 61] Internet-Draft HELD March 2007 Appendix B. HELD Compliance to NENA Location Acqusition Requirements This section details how HELD complies to each of the requirements provided in section 4 of [NENA_TID]. B.1. DA1 "The access network shall provide a mechanism for determination and acquisition of location information, and support queries for location." COMPLY HELD provides location acqusition functionality. A LIS may use any means to obtain measurements from the network to assist with location determination. B.2. DA2 "The location estimate used shall be that associated with the physically (wire, fiber, air) connected network." COMPLY HELD is designed to support the acquisition of location information determined on the basis of the physical access network with which the device is associated. HELD does not preclude any specific technology used by that access. B.3. DA3 "Location may be requested at any time. Location information must be associated with the device at the time the location is requested." COMPLY HELD location requests can be made at any time to the identified LIS serving the access network. It is the responsibility of the LIS to use the IP address and/or other identifiers included in the location request and determine the current location of the Target. Where more than one determination technology is available, the requesting entity may specify a response time to assist the LIS in selecting the appropriate location determination technology to use. The HELD protocol does not impose any physical constraints that prevent the LIS from reassessing the location at the time of each request. Winterbottom, et al. Expires September 3, 2007 [Page 62] Internet-Draft HELD March 2007 B.4. DA4 "Location acquisition should be provided by a consistent method across all network configurations." COMPLY HELD requires an end-point to be able to discover the LIS in the local access network. Once the LIS is known HELD is access network agnostic and can be used in the same way in any network topology. B.5. DA5 "Location determination and acquisition mechanisms must be applicable to emergency calling, and may also be applicable to a wide range of value-added location-based services." COMPLY HELD has specific semantics defined for obtaining locations suitable for routing emergency calls. In particular, HELD provides a rich set of location request options so that an application can retrieve location information in the form most suitable for its purpose. B.6. DA6 "Location determination and acquisition techniques shall support both NENA i2 and i3 network architectures." COMPLY HELD provides all of the functions necessary to support emergency calling applications. HELD has a specific semantic for requesting location information suitable to inclusion in emergency calling applications. Location information acquired using HELD is contained in a PIDF-LO the form required by both the NENA i2 and i3 architectures. It also supports location by reference mechanisms for out-of-band mid-call location updates as required, for example, for mobile wireless networks. B.7. DA7 "When measurement based-location determination mechanisms fail, the most accurate location information available should be provided. Examples include: For mobile, the Wireless Service Provider might provide tower or Access Point location, last known fix, etc. For wireline, a LIS might provide a civic location that defines the serving area of an access point, e.g., the State of Texas." Winterbottom, et al. Expires September 3, 2007 [Page 63] Internet-Draft HELD March 2007 Not Applicable HELD is a location acqusition protocol and will return the location determined by the LIS. HELD does not preclude the LIS from applying any arbitrarily sophisticated set of location determination techniques and associated fallback policy appropriate to the access technology it supports. B.8. DA8 "Location determination and acquisition must provide minimal impact to call setup time in the event that location is not known ahead of time." COMPLY HELD allows a location to be requested at any time, including prior to or during a call. Where time is of the essence the requesting entity can provide a response time indicating to the LIS that location is needed in the period specified. This allows the LIS to select the most accurate location determination technology available to it that can yield a location in the allotted time. This is of particular importance in wireless networks where the most accurate location determination techniques may take 10s of seconds. B.9. DA9 "Where a device is not location aware the IP Access network should have the ability to provide a location estimate on behalf of the device." COMPLY In order to support this functionality the requesting node must have a pre-existing trust relationship with the LIS, and HELD identity extensions as described in [I-D.winterbottom-geopriv-held-identity-extensions]. Where these requirements are satisfied, the LIS may provide a HELD response to the requesting device that has the same form as if the target device had been the requestor. If the traffic volume between the trusted node and the LIS is likely to be high, the HELD BEEP binding [I-D.thomson-geopriv-held-beep] may be used. B.10. DA10 "Location acquisition methods should not require modification of hardware/firmware in home-routers or modems." Winterbottom, et al. Expires September 3, 2007 [Page 64] Internet-Draft HELD March 2007 COMPLY This requirement is essentially the same as Appendix A.5. HELD is an application protocol and operates on top of IP. A HELD request from a host behind a residential NAT will traverse the NAT acquiring the external address of the home router. The location provided to the host therefore will be the address of the home router in this circumstance. No changes are required to the home router in order to support this function, HELD was designed specifically to address this deployment scenario. B.11. DA11 "A location determination method must exist that does not require network hardware replacement." Not Applicable HELD is a location acquisition protocol and does not directly specify how location is determined in the network. However, HELD does not require additions to or replacement of existing network server implementations because it is not defined as an extension to any existing non-location service protocol. B.12. DA12 "The location acquisition protocol shall allow the requesting device to specify a response time requirement to the LIS when requesting location information. The response time is expressed as the maximum time that the requesting node is prepared to wait for location information. The LIS is required to provide the most accurate location fix it can within the specified response time." COMPLY HELD has an explicit "responseTime" parameter that can be used with any request to the LIS. This parameter provides an indication to the LIS of how long the requesting node is prepared to wait for location, allowing the LIS to select the appropriate location determination technology to invoke particularly where it may need to trade off the accuracy of the result to meet the time constraint. B.13. Rep1 "Location information may be provided as location-by-value or location-by-reference and the form is subject to the nature of the request." Winterbottom, et al. Expires September 3, 2007 [Page 65] Internet-Draft HELD March 2007 COMPLY HELD supports requesting either a location reference in the form a location URI and/or a literal location. Literal locations are provided as a PIDF-LO. B.14. Rep2 "Location determination and acquisition mechanisms must support all location information fields defined within a PIDF-LO." COMPLY HELD provides location information in the form of a PIDF-LO, consequently all PIDF-LO fields are implicitly supported. B.15. Rep3 "Location acquisition mechanisms must allow for easy backwards compatibility as the representation of location information evolves." COMPLY HELD provides location as a PIDF-LO, any changes made to the PIDF-LO definition are made independently and without impact to the HELD definition. B.16. Rep4 "All representations of location shall include the ability to carry altitude and/or floor designation. This requirement does not imply altitude and/or floor designation is always used or supplied." COMPLY The PIDF-LO has explicit support for both civic and geodtic location types and consequently provides support for encoding both altitude and building floor values. Since HELD provides location as a PIDF-LO, any location that can be expressed in a PIDF-LO is compatible with HELD. HELD recommends that PIDF-LOs be constructed in accordance with the rules laid out in [I-D.ietf-geopriv-pdif-lo-profile]. B.17. LocSec1 "Location information shall only be provided to authenticated and authorized network devices. The degree of authentication and authorization required may vary depending on the network." Winterbottom, et al. Expires September 3, 2007 [Page 66] Internet-Draft HELD March 2007 COMPLY A LIS generally authenticates a Target using HELD to request its own location implicitly. Authentication is based on the IP address of the source request packet, inband indentifiers, and return routability. Where this level of authentication is not deemed sufficient other authentications mechanisms can be used, such as client-side certificates, shared-secret keys and HTTP digest. B.18. LocSec2 "Location determination and acquisition methods should preserve privacy of location information, subject to local laws and regulations." COMPLY This requirement is of particular significance where the acqusition protocol is also being used as a dereference protocol for a location URI. HELD supports this function by allowing a Target to provide access rules to the LIS. The Target may provide either an explicit set of rules defined using common policy syntax as described in [I-D.ietf-geopriv-common-policy], or the Target may provide a ruleset URI allowing the LIS to retrieve the ruleset from a third-party. LIS operators are also able to provide a default set of overiding policies to support, for example, emergency services. How these additional rules are provisioned and applied is a matter of LIS implementation and is outside the scope of any location acquisition protocol. B.19. LocSec3 "The location or location estimate of a caller should be dependable." COMPLY HELD supports this through two mechanisms. The first is a "signed" attribute that can be included with a location request. This allows the user to explicitly request a signed location object. The second is through location assertion. This allows an end-point to proffer a location to the LIS, and for the LIS to assert this location against the location that the LIS would provide. The assert function is described in more detail in Section 5.2. B.20. LocSec4 "The location acquisition protocol must support authentication of the Location Information Server, integrity protection of the Location Winterbottom, et al. Expires September 3, 2007 [Page 67] Internet-Draft HELD March 2007 Information, and protection against replay." COMPLY HELD recommends the use of TLS with server-side certificates for LIS authentication to requesting nodes where considered necessary. TLS when used in this fashion mitigates the risks of impersonation of the LIS. TLS also provides confidentiality and replay protection for requests and location information. B.21. LocSec5 "The location source shall be identified and should be authenticated. This includes manually entered location." COMPLY HELD provides a "signed" attribute that can be used to request a signed location object as described in Section 5.5. For Target provided locations, be for manually entered or device-determined location, HELD provides the location assertion function, which when combined with the "signed" attribute provides location source identification and authentication. B.22. LocSec6 "Where a location is acquired and cached prior to an emergency call, it should be refreshed at regular intervals to ensure that it is as current as possible, in the event location information cannot be obtained in real time." COMPLY HELD supports the ability to request location at any time. B.23. LocSec7 "Where location by-reference is used the appropriate privacy policies must be implemented and enforced by the LIS operator." COMPLY HELD allows a Target to provide access rules ot the LIS. The Target may provide either an explicit set of rules defined using common policy syntax as described in [I-D.ietf-geopriv-common-policy], or the Target may provide a ruleset URI allowing the LIS to retrieve the ruleset from a third-party. Winterbottom, et al. Expires September 3, 2007 [Page 68] Internet-Draft HELD March 2007 Authors' Addresses James Winterbottom Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2938 Email: james.winterbottom@andrew.com URI: http://www.andrew.com/ Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2915 Email: martin.thomson@andrew.com URI: http://www.andrew.com/ Barbara Stark BellSouth Room 7A41 725 W Peachtree St. Atlanta, GA 30308 US Email: barbara.stark@bellsouth.com Winterbottom, et al. Expires September 3, 2007 [Page 69] Internet-Draft HELD March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Winterbottom, et al. Expires September 3, 2007 [Page 70]