Network Working Group S. Harhalakis Internet-Draft TEI of Thessaloniki Intended status: Standards Track June 16, 2007 Expires: December 18, 2007 Timezone Information in HTTP draft-sharhalakis-httpinfo-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 18, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Harhalakis Expires December 18, 2007 [Page 1] Internet-Draft Timezone Information in HTTP June 2007 Abstract This document defines a set of information-exchanging HTTP headers as an optional improvement to HTTP dialogs. Server side application using those headers will be able to request additional information from HTTP clients. This way the HTTP protocol is extended to support optional on-demand additional headers that can be send from clients when requested. An extensible communications framework that can be used by future documents is described. The ABNF description of the corresponding headers is provided. Harhalakis Expires December 18, 2007 [Page 2] Internet-Draft Timezone Information in HTTP June 2007 Discussion Discussion about this document takes place in http-wg mailing list (ietf-http-wg@w3.org). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Protocol definition . . . . . . . . . . . . . . . . . . . 6 2.2. Header syntax . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Proxy considerations . . . . . . . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3.1. Client side . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Server side . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Harhalakis Expires December 18, 2007 [Page 3] Internet-Draft Timezone Information in HTTP June 2007 1. Introduction 1.1. Purpose Web based application are exploiting the HTTP protocol to achieve better results and provide additional capabilities. Every now and then, server side applications introduce additional needs from HTTP clients. Current HTTP behavior does not provide a basis for clients to offer additional information upon request (on-demand). The HTTP protocol could be further extended by providing such a framework. This document addresses this need by describing a method and a set of headers to be used in HTTP [RFC2616] so that server side application may request additional information from clients. By providing support for on-demand offering of information from clients, the HTTP protocol will be able to be further extended without adopting additional headers that will be always exchanged. This will result in smaller client requests. Apart from that, willing clients will be able to provide a central management facility for information that will be send to server-side. Using such a client, users will be able to have better (centralized) control of information that will be send to servers and may experience better server side services that will take advantage of the additionally provided information. 1.2. Requirements 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]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements is said to be "conditionally compliant". 1.3. Terminology This document uses the following terms: HTTP client Every client of the HTTP protocol. Commonly referred to as a web browser. Harhalakis Expires December 18, 2007 [Page 4] Internet-Draft Timezone Information in HTTP June 2007 HTTP header A HTTP header as described in [RFC2616]. Information element A title that identifies some information. Information request The full list of requested information elements. The HTTP header specifications of this document are presented in the augmented Backus-Naur Form that is described in [RFC2616]. Harhalakis Expires December 18, 2007 [Page 5] Internet-Draft Timezone Information in HTTP June 2007 2. Definition 2.1. Protocol definition Server side applications MAY use the Information Request (I-RQ) header to request additional information from HTTP clients. Those applications MUST NOT assume that clients will respond to their requests nor that clients support the I-R header. Client side applications MAY support the server side I-RQ. Those clients MAY respond to I-RQ with one or more Information Provide (I-PR) headers. This action will require an additional and almost identical HTTP request to be sent that will include the additional headers. Clients that respond to I-RQ MUST inform the server side application when they are denying one or more I-RQ with an Information Deny (I-DN) header. Clients MAY cache per domain/path I-RQ and automatically send I-PR headers without waiting for an I-RQ. Clients SHOULD update their cache upon receipt of an I-RQ. This will ensure that they will not send unneeded data for more than one requests. 2.2. Header syntax For the purposes of this document, the following HTTP headers are defined: information-request = "Information-Request" ":" i-rq i-param i-rq = i-element *( "," i-element ) i-element = ALPHA *ALNUM ; No LWS i-param = *( ";" i-param-av ) i-param-av = "Domain" "=" value / "Path" "=" value / "Secure" ; As in cookies ALNUM = ALPHA / DIGIT information-provide = "Information-Provide" ":" i-pr i-pr = i-pr-one *( "," i-pr-one ) i-pr-one = i-element "=" value information-deny = "Information-Deny" ":" i-dn i-dn = i-element *( "," i-element ) Where: Harhalakis Expires December 18, 2007 [Page 6] Internet-Draft Timezone Information in HTTP June 2007 value A value as defined in HTTP State Management Mechanism [RFC2109]. LWS Linear White Space as described in [RFC2616]. Usage of i-param is the same as in cookie-av described in [RFC2109]. Same grammar and semantics apply. 2.3. Proxy considerations HTTP proxy servers MUST NOT alter this information. Server side scripts that produce customized results based on the I-PR information MUST return an appropriate "Vary" header as specified in paragraph 14.44 of [RFC2616]. Harhalakis Expires December 18, 2007 [Page 7] Internet-Draft Timezone Information in HTTP June 2007 3. Security Considerations 3.1. Client side Part or all of the additional provided information may include personal information. Documents that define the provided information MUST provide security considerations that characterize the additional information. HTTP clients MUST NOT provide sensitive information to servers without letting the user prevent it. Clients MUST either ask for user permission or provide options for preventing them from providing the additional information. The latter is RECOMMENDED. HTTP clients MUST provide secure defaults that protect user privacy. 3.2. Server side Web based applications MUST treat all this information as user input that may be invalid. Maliciously formed headers MUST be expected and addressed as needed. Harhalakis Expires December 18, 2007 [Page 8] Internet-Draft Timezone Information in HTTP June 2007 4. IANA Considerations This specification requires registration of a set of Message Header Fields for HTTP [RFC3864]: Header field: Information-Request Applicable protocol: HTTP Status: Experimental Author/change controller: IETF (iesg@ietf.org) Internet Engineering Task Force Specification document: [ this document ] Header field: Information-Provide Applicable protocol: HTTP Status: Experimental Author/change controller: IETF (iesg@ietf.org) Internet Engineering Task Force Specification document: [ this document ] Header field: Information-Deny Applicable protocol: HTTP Status: Experimental Author/change controller: IETF (iesg@ietf.org) Internet Engineering Task Force Harhalakis Expires December 18, 2007 [Page 9] Internet-Draft Timezone Information in HTTP June 2007 Specification document: [ this document ] Harhalakis Expires December 18, 2007 [Page 10] Internet-Draft Timezone Information in HTTP June 2007 5. References 5.1. Normative [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. 5.2. Informative [I-D.rfc-editor-rfc2223bis] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08 (work in progress), July 2004. Harhalakis Expires December 18, 2007 [Page 11] Internet-Draft Timezone Information in HTTP June 2007 Author's Address Stefanos Harhalakis Technological Educational Institute of Thessaloniki Department of Information Technology Thessaloniki, Greece GR Email: v13@it.teithe.gr, v13@priest.com Harhalakis Expires December 18, 2007 [Page 12] Internet-Draft Timezone Information in HTTP 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). Harhalakis Expires December 18, 2007 [Page 13]