Geopriv J. Winterbottom Internet-Draft M. Thomson Intended status: Best Current M. Dawson Practice Andrew Corporation Expires: December 16, 2007 June 14, 2007 Using HELD as a Location URI Dereference Protocol draft-winterbottom-geopriv-held-deref-bcp-00.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 December 16, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Winterbottom, et al. Expires December 16, 2007 [Page 1] Internet-Draft HELD Deref June 2007 Abstract This document describes how HELD can be used by a third-party to deference an HTTP location URI. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative references . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Winterbottom, et al. Expires December 16, 2007 [Page 2] Internet-Draft HELD Deref June 2007 1. Introduction The HELD specification [I-D.ietf-geopriv-http-location-delivery] provides a set of features that can be used by an end-point to retrieve location information from an LCS. HELD is desgined for an end-point to query its own location from an LCS, but can also be the protocol to retrieve location from an LCS where a third-party application possesses a location reference in the form of an HTTP location URI. This document describes best common practice (BCP) on how HELD is used as a dereference protocol for HTTP location URIs. Winterbottom, et al. Expires December 16, 2007 [Page 3] Internet-Draft HELD Deref June 2007 2. Terminology The key conventions and terminology used in this document are defined as follows: This document reuses the terms Target, as defined in [RFC3693]. This document uses the term Location Configuration Server, LCS, as the node in the access network providing location information to an end-point. This term is also used in [I-D.ietf-geopriv-l7-lcp-ps]. Basic terms from the HELD specification [I-D.ietf-geopriv-http-location-delivery] are also reused. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Winterbottom, et al. Expires December 16, 2007 [Page 4] Internet-Draft HELD Deref June 2007 3. Overview HELD provides a specification for obtaining location information from a Location Configuration Server (LCS), either by value, as a PIDF-LO, and/or as a set of location URIs that can be used by third-parties to retrieve the location the location of the Target. The benefits and requirements for location by reference (LbyR) are provided in [I-D.marshall-geopriv-lbyr-requirements], along with characteristics of different kinds of location reference. This document addresses HTTP location URIs. Other URI forms, the required permissions, and the need for authentication by any specific recipient is deemed to be in the application domain and therefore out of scope for this document. Resuing HELD in this manner reduces the number of protocols that need to be supported on the LIS, simplfies development, reduces complexity and improves interoperability by ensuring consistency between the form of location available at the end-point and the dereferencer interfaces. The location recipient in this document is in possession of an HTTP location URI which, when successfully de-referenced, will yield the location of the Target. How the recipient obtained the location URI is not in scope for this document, however mechanisms such as [I-D.ietf-sip-location-conveyance] support this functionality. Winterbottom, et al. Expires December 16, 2007 [Page 5] Internet-Draft HELD Deref June 2007 4. Detailed Description HELD has explicit support for providing location URIs to an end- point. The URI type returned over HELD can, in principle be any valid URI, in practice it will be limited to URI types for which a location acquisition function exists or can be defined. This document describes a best common practice for using HELD as a dereference protocol with HTTP location URIs. Only a subset of HELD is required to support the needs of an external dereference protocol, these needs can be summarized as follows: 1: The ability to identify the Target for which location is required. 2: The ability to request location in the form required by the application. 3: The ability to indicate how long to wait for location information. Item 1 is addressed by the location URI itself and the remaining two requirements can be satisfied by parameters in the HELD locationRequest message. The following locationRequest parameters represent the valid set that can be used when HELD is used as a dereference protocol: locationType: The type of location being requested. exact: indicates that the recipient is not prepared to accept an alternative location form if the requested form is not available. responseTime: The period of time that the recipient is prepared to wait for a response. If any other parameters are received in a locationRequest message where HELD is being used as the dereference protocol for a location URI, the LCS MUST respond with a 400 "Request Error" message to the requesting entity. Where HELD is being used as the derefernce protocol the LCS MUST return location as a PIDF-LO [RFC4119] in the corresponding heldResponse message, and the PIDF-LO MUST comply with [I-D.ietf-geopriv-pdif-lo-profile]. Where the LCS is unable to process the location recipient's request, it SHOULD return the appropriate error from the existing HELD error set defined in [I-D.ietf-geopriv-http-location-delivery]. Winterbottom, et al. Expires December 16, 2007 [Page 6] Internet-Draft HELD Deref June 2007 5. Security Considerations Depending on the application, dereferencing a location URI may require the recipient to authenticate with the LCS. How the recipient knows when to do this and under what circumstances this behaviour is required is out of scope for this document. It is expected that common HTTP authentication techniques will be used, including: 1: Basic HTTP authentication [RFC2617] 2: HTTP Digest authentication [RFC2617] 3: Client-side X.509 certifcates [RFC2818] The LCS MUST use server authentication methods described in HTTP on TLS [RFC2818]. Any Target provided access rules MUST be adhered to by the LCS where these do not contravene local jurisdictional obligations. Winterbottom, et al. Expires December 16, 2007 [Page 7] Internet-Draft HELD Deref June 2007 6. IANA Considerations There are no specific IANA considerations for this document. Winterbottom, et al. Expires December 16, 2007 [Page 8] Internet-Draft HELD Deref June 2007 7. Acknowledgements Thanks to Barbara Stark and Guy Caron for providing early comments. Winterbottom, et al. Expires December 16, 2007 [Page 9] Internet-Draft HELD Deref June 2007 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [I-D.ietf-geopriv-pdif-lo-profile] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", draft-ietf-geopriv-pdif-lo-profile-07 (work in progress), April 2007. [I-D.ietf-geopriv-http-location-delivery] Barnes, M., "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-00 (work in progress), June 2007. [I-D.marshall-geopriv-lbyr-requirements] Marshall, R., "Requirements for a Location-by-Reference Mechanism used in Location Configuration and Conveyance", draft-marshall-geopriv-lbyr-requirements-01 (work in progress), March 2007. 8.2. Informative references [I-D.ietf-sip-location-conveyance] Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", draft-ietf-sip-location-conveyance-07 (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 Winterbottom, et al. Expires December 16, 2007 [Page 10] Internet-Draft HELD Deref June 2007 Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007. Winterbottom, et al. Expires December 16, 2007 [Page 11] Internet-Draft HELD Deref June 2007 Authors' Addresses James Winterbottom Andrew Corporation PO Box U40 University of Wollongong, NSW 2500 AU Email: james.winterbottom@andrew.com Martin Thomson Andrew Corporation PO Box U40 University of Wollongong, NSW 2500 AU Email: martin.thomson@andrew.com Martin Dawson Andrew Corporation PO Box U40 University of Wollongong, NSW 2500 AU Email: martin.dawson@andrew.com Winterbottom, et al. Expires December 16, 2007 [Page 12] Internet-Draft HELD Deref June 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 December 16, 2007 [Page 13]