Internet Draft Dinkar Tiwari Category: Standards Track IBM Corporation Document: draft-tiwari-appl-wxxx-forms-00.txt Expires: November 2000 May 2000 Application/w-xxx-forms Media Type Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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. Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. Abstract This document proposes to standardize application/w-xxx-forms, a media type for use in sending requests involving form-input from a browser to a http server. These requests are currently sent via the HyperText Transfer Protocol on the World Wide Web. 1 Introduction In order for efficient and accurate communication between a browser and a host, there must be a standard format used to exchange data. Currently, all related major applications conforming to HTTP standards (browsers and web servers) do use the same format. However, this format has not been made a formal standard. The media type, application/w-xxx-forms, is a standalone data transport format and is widely used by all major applications. As application/w-xxx-forms is an integral part of sending data over the internet and since such media types belong in the IETF tree, this media type should also belong in the IETF tree. 2 Notational Conventions 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 [RFC-2119]. 3 application/w-xxx-forms Media Type This document standardizes application/w-xxx-forms as the standalone data transport format for communication between a browser and a host. When used for HTTP 1.1 GET requests, it shall be identical to the query as described in [RFC 2068]. All the requests use only the ISO 8859_1 character set and are treated as plain text by the server. However, certain characters have to be encoded in a different manner for the host to interpret the request correctly. Registration information for this media type is described below. The hex value of each character listed is given in parenthesis following the character. Registration Information MIME media type name: application MIME subtype name: w-xxx-forms Mandatory parameters: none Optional parameters: none Encoding considerations: This media type uses only the ISO 8859_1 character set. Certain characters have special meaning. They are the ampersand ('&'), percent ('%'), and space (' ') characters. '&' (x'26') The ampersand is used as the delimiter between the name/value pairs in the query string. '%' (x'25') The percent is used to transmit hexadecimal values as part of the request. ' ' (x'20') The space is considered by some browsers as the end of the request. Therefore, if a space is incorporated in a request, it will be encoded appropriately. Certain characters need to be encoded prior to being transmitted to the server. '&' (x'26'); '%' (x'25'); '+' (x'2B') As these characters have special meaning, they shall be encoded before being transmitted. This will be done by preceding the ISO 8859_1 hexadecimal value of these characters with a '%' sign. Space (x'20') Some browsers/servers see a space as the end of the request of have trailing spaces suppressed. Depending on the browser/server, this can pose a potential problem when a query string containing spaces is sent along with the Universal Resource Locator (URL). To circumvent this situation, all spaces shall be encoded as '+' (x'2B') signs. Security Considerations: none Interoperability considerations: none Published specification: none Applications which use this media type: This media type shall be accepted by all major HTTP browsers and servers. Additional information: Magic number(s): none A basic request for a url conforms to HTTP standards and the format is http://url With interactive websites, the user-input is submitted in the form of a query string. The query string is preceded by a '?' and attached to the end of a url. The query string is sent as a list of name/value pairs. An '=' (x'3D') shall separate each name from its corresponding value. Each pair shall be separated by an '&' (ampersand). The format of a request consisting of a query string will be http://url?name1=value1&name2=value2&name3=value3 Person & email address for further information: Dinkar Tiwari Paul Wanish Intended usage: COMMON 4 Examples The examples below give the value of the Content-type MIME header and the Application/w-xxx-forms declaration. Note that other MIME headers may be present, and the entity may contain other data in addition to the media type declaration. 4.1 '&' to separate user input fields field1="value1", field2="value2" http://www.your-domain-here.com?field1=value1&field2=value2 4.2 '%' to send special characters field1="value1+value2" http://www.your-domain-here.com?field1=value1%2Bvalue2 field1="value1&value2" http://www.your-domain-here.com?field1=value1%26value2 field1="value1%value2" http://www.your-domain-here.com?field1=value1%25value2 4.3 ' ' field1="value1 value2" http://www.your-domain-here.com?field1=value1+value2 5 References [RFC-2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC-2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC-2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Ford, Andrew, Spinning the Web, International Thomson Publishing, 1995. 6 Acknowledgements Paul Wanish contributed much content and feedback for all sections. Discussions with Frank DeGilio, Hilon Potter, and Paul Wanish helped refine the author's understanding of this media type. Paul Wanish IBM Corporation Design Center for e-transaction Processing 2455 South Road MS/P390 Poughkeepsie, NY 12601 EMail: wanish@us.ibm.com 7 Addresses of Authors Dinkar Tiwari IBM Corporation 2455 South Road MS/P390 Poughkeepsie, NY 12601 EMail: tdinkar@us.ibm.com 8 Full Copyright Statement Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Internet Draft Standards Track May 2000 Tiwari [Page 2]