--- 1/draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt 2010-03-08 00:11:05.000000000 +0100 +++ 2/draft-ietf-geopriv-dhcp-lbyr-uri-option-07.txt 2010-03-08 00:11:05.000000000 +0100 @@ -1,93 +1,75 @@ Geopriv WG James Polk Internet-Draft Cisco Systems -Intended status: Standards Track (PS) Sept 14, 2009 -Expires: March 14, 2010 +Intended status: Standards Track (PS) March 7, 2010 +Expires: Sept 7, 2010 Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI) - draft-ietf-geopriv-dhcp-lbyr-uri-option-06 + draft-ietf-geopriv-dhcp-lbyr-uri-option-07 + +Abstract + + This document creates a Dynamic Host Configuration Protocol (DHCP) + Option for transmitting a client's geolocation Uniform Resource + Identifier (URI) of a client, which can be dereferenced in a + separate transaction by the client or an entity the client sends + this URI to. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with - the provisions of BCP 78 and BCP 79. This document may contain - material from IETF Documents or IETF Contributions published or made - publicly available before November 10, 2008. The person(s) - controlling the copyright in some of this material may not have - granted the IETF Trust the right to allow modifications of such - material outside the IETF Standards Process. Without obtaining an - adequate license from the person(s) controlling the copyright in - such materials, this document may not be modified outside the IETF - Standards Process, and derivative works of it may not be created - outside the IETF Standards Process, except to format it for - publication as an RFC or to translate it into languages other than - English. + the provisions of BCP 78 and 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 March 14, 2010. + This Internet-Draft will expire on September 7, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your - rights and restrictions with respect to this document. - -Legal - - This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE - ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS - FOR A PARTICULAR PURPOSE. - -Abstract - - This document creates a Dynamic Host Configuration Protocol (DHCP) - Option for transmitting a client's geolocation Uniform Resource - Identifier (URI) of a client, which can be dereferenced in a - separate transaction by the client or an entity the client sends - this URI to. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with + respect to this document. Code Components extracted from this + document must include Simplified BSD License text as described in + Section 4.e of the Trust Legal Provisions and are provided without + warranty as described in the BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Format of the DHCP LuriElement Option . . . . . . . . . . . . 4 - 2.1. Overall Format of LuriElement Option in IPv4 . . . . . 5 + 2.1. Overall Format of LuriElement Option in IPv4 . . . . . 4 2.2. Overall Format of LuriElement Option in IPv6 . . . . . 5 - 2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 6 - 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 7 + 2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 5 + 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 6 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8 - 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 9 + 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -391,21 +373,21 @@ to view the PIDF-LO of the target whose location is indicated in a presence document. The dereference transaction will be, in many environments, challenged by the Location Server. The nature of this challenge is out of scope of this document. o This document does not prevent some environments from operating in a possession model, for example - tightly controlled enterprise networks, but this operation SHOULD NOT be assumed to exist as a matter of local policy. The costs associated with authorization vs. possession models are discussed in Section - 3.3.2 of [ID-GEO-RA]. + 3.3.2 of [RFC5606]. 3.2 Harmful URIs and URLs There are, in fact, some types of URIs that are not good to receive, due to security concerns. For example, any URLs that can have scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web pages that have scripts. Therefore, o URIs received via this Option SHOULD NOT be sent to a general-browser to connect to a web page, because they could have @@ -419,20 +401,32 @@ registers acceptable location URI schemes (or types). 3.3 Valid Location URI Schemes or Types This section specifies which URI types are acceptable as a location URI scheme (or type) for this DHCP Option: 1. sip: 2. sips: 3. pres: + 4. http: + 5. https: + + URIs using the "pres" scheme are dereferenced using the presence + event package for SIP [RFC3856], so they will reference a PIDF-LO + document when location is available. Responses to requests for URIs + with other schemes ("sip", "sips", "http", and "https") MUST have + MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS + URIs MAY refer to information with MIME type 'application/held+xml', + in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can + indicate which MIME types they support using the "Accept" header + field in SIP [RFC3261] or HTTP [RFC2616]. These location URI types are IANA registered in Section 4.2 of this document. 4. IANA Considerations 4.1 The IPv4 Option number for this Option This document IANA registers this IPv4 Option number XXX (to be assigned by IANA once this document becomes an RFC). @@ -449,20 +443,22 @@ 4.4 IANA Considerations for Acceptable Location URI Types IANA is requested to create a new registry for acceptable location URI types. The following 3 URI types are registered by this document: 1. sip: 2. sips: 3. pres: + 4. http: + 5. https: Any additional location URI types to be defined for use via this DHC Option need to be created and IANA registered with peer review and an RFC. 4.5 IANA Considerations for LuriTypes IANA is requested to create a new registry for acceptable location types defined in Section 3.2 of this document, arranged similar to this: @@ -522,23 +518,23 @@ When implementing a DHC server that will serve clients across an uncontrolled network, one should consider the potential security risks therein. 6. Acknowledgements Thanks to James Winterbottom, Marc Linsner, Roger Marshall and Robert Sparks for their useful comments. And to Lisa Dusseault for her concerns about the types of URIs that can cause harm. To Richard Barnes for inspiring a more robust Security Considerations - section. To Hannes Tschofenig and Ted Hardie for riding me to - comply with their concerns, including a good scrubbing of the nearly - final doc. + section, and for offering the text to incorporate HTTP URIs. To + Hannes Tschofenig and Ted Hardie for riding me to comply with their + concerns, including a good scrubbing of the nearly final doc. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. @@ -556,50 +552,57 @@ [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 + [RFC3856] J. Rosenberg, "A Presence Event Package for the Session + Initiation Protocol (SIP)", RFC 3856, August 2004 + 7.2. Informative References [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in - progress", July 2009 + progress", Feb 2010 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson, M. Dawson, "A Location Dereferencing Protocol Using - HELD", "work in progress", July 2009 + HELD", "work in progress", January 2010 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", RFC 4776, November 2006 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference - Mechanism", "work in progress", Feb 2009 + Mechanism", "work in progress", November 2009 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", "work in - progress", Feb 2009 + progress", July 2009 - [ID-GEO-RA] J. Peterson, T. Hardie, J. Morris, " Implications of + [RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of 'retransmission-allowed' for SIP Location Conveyance", - "work in progress", March 2009 + August 2009 + + [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., + Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer + Protocol - HTTP/1.1", RFC 2616, June 1999 Authors' Address James Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Email: jmpolk@cisco.com