[gmime] Updated README
- From: Jeffrey Stedfast <fejj src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gmime] Updated README
- Date: Thu, 20 Feb 2014 15:11:48 +0000 (UTC)
commit b09920cbaccbf16aa719874969b92574b55f9695
Author: Jeffrey Stedfast <fejj gnome org>
Date: Thu Feb 20 10:11:31 2014 -0500
Updated README
README | 29 ++--
rfc/rfc2388.txt | 507 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 520 insertions(+), 16 deletions(-)
---
diff --git a/README b/README
index 18f02a2..45f4f2a 100644
--- a/README
+++ b/README
@@ -39,9 +39,20 @@ following RFCs:
Sets, Languages, and Continuations
* 2231: MIME Parameter Value and Encoded Word Extensions: Character
Sets, Languages, and Continuations (Obsoletes rfc2184)
+ * 2311: S/MIME Version 2 Message Specification
+ * 2312: S/MIME Version 2 Certificate Handling
+ * 2315: PKCS #7: Cryptographic Message Syntax
+ * 2630: Cryptographic Message Syntax
+ * 2632: S/MIME Version 3 Certificate Handling (Obsoletes rfc2311)
+ * 2633: S/MIME Version 3 Message Specification (Obsoletes rfc2312)
+ * 2634: Enhanced Security Services for S/MIME
* 2822: Internet Message Format (Obsoletes rfc822)
* 3156: MIME Security with OpenPGP (Updates rfc2015)
+ * 3850: S/MIME Version 3.1 Certificate Handling (Obsoletes rfc2632)
+ * 3851: S/MIME Version 3.1 Message Specification (Obsoletes rfc2633)
* 5322: Internet Message Format (Obsoletes rfc2822)
+ * 5750: S/MIME Version 3.2 Certificate Handling (Obsoletes rfc3850)
+ * 5751: S/MIME Version 3.2 Message Specification (Obsoletes rfc3851)
Other RFCs of interest:
@@ -49,38 +60,24 @@ Other RFCs of interest:
* 1927: Suggested Additional MIME Types for Associating Documents
* 2110: MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
* 2111: Content-ID and Message-ID Uniform Resource Locators
- * 2311: S/MIME Version 2 Message Specification
- * 2312: S/MIME Version 2 Certificate Handling
* 2387: The Multipart/Related Content-Type.
+ * 2388: Returning Values from Forms: multipart/form-data
* 2424: Content Duration MIME Header Definition
- * 2630: Cryptographic Message Syntax
- * 2632: S/MIME Version 3 Certificate Handling
- * 2633: S/MIME Version 3 Message Specification
- * 2634: Enhanced Security Services for S/MIME
* 3280: Internet X.509 Public Key Infrastructure certificate and
Certificate Revocation List (CRL) Profile
- * 3850: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
- Certificate Handling (Obsoletes rfc2632)
- * 3851: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
- Message Specification (Obsoletes rfc2633)
- * 5750: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
- Certificate Handling (Obsoletes rfc3850)
- * 5751: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
- Message Specification (Obsoletes rfc3851)
Cryptography related RFCs:
* 2268: A Description of the RC2(r) Encryption Algorithm
* 2313: PKCS #1: RSA Encryption
* 2314: PKCS #10: Certification Request Syntax
- * 2315: PKCS #7: Cryptographic Message Syntax
* 2631: Diffie-Hellman Key Agreement Method
LICENSE INFORMATION
-------------------
-The GMime library is Copyright (C) 2000-2013 Jeffrey Stedfast.
+The GMime library is Copyright (C) 2000-2014 Jeffrey Stedfast.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
diff --git a/rfc/rfc2388.txt b/rfc/rfc2388.txt
new file mode 100644
index 0000000..ffb9b6c
--- /dev/null
+++ b/rfc/rfc2388.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group L. Masinter
+Request for Comments: 2388 Xerox Corporation
+Category: Standards Track August 1998
+
+
+ Returning Values from Forms: multipart/form-data
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+1. Abstract
+
+ This specification defines an Internet Media Type, multipart/form-
+ data, which can be used by a wide variety of applications and
+ transported by a wide variety of protocols as a way of returning a
+ set of values as the result of a user filling out a form.
+
+2. Introduction
+
+ In many applications, it is possible for a user to be presented with
+ a form. The user will fill out the form, including information that
+ is typed, generated by user input, or included from files that the
+ user has selected. When the form is filled out, the data from the
+ form is sent from the user to the receiving application.
+
+ The definition of MultiPart/Form-Data is derived from one of those
+ applications, originally set out in [RFC1867] and subsequently
+ incorporated into [HTML40], where forms are expressed in HTML, and in
+ which the form values are sent via HTTP or electronic mail. This
+ representation is widely implemented in numerous web browsers and web
+ servers.
+
+ However, multipart/form-data can be used for forms that are presented
+ using representations other than HTML (spreadsheets, Portable
+ Document Format, etc), and for transport using other means than
+ electronic mail or HTTP. This document defines the representation of
+ form values independently of the application for which it is used.
+
+
+
+
+
+Masinter Standards Track [Page 1]
+
+RFC 2388 multipart/form-data August 1998
+
+
+3. Definition of multipart/form-data
+
+ The media-type multipart/form-data follows the rules of all multipart
+ MIME data streams as outlined in [RFC 2046]. In forms, there are a
+ series of fields to be supplied by the user who fills out the form.
+ Each field has a name. Within a given form, the names are unique.
+
+ "multipart/form-data" contains a series of parts. Each part is
+ expected to contain a content-disposition header [RFC 2183] where the
+ disposition type is "form-data", and where the disposition contains
+ an (additional) parameter of "name", where the value of that
+ parameter is the original field name in the form. For example, a part
+ might contain a header:
+
+ Content-Disposition: form-data; name="user"
+
+ with the value corresponding to the entry of the "user" field.
+
+ Field names originally in non-ASCII character sets may be encoded
+ within the value of the "name" parameter using the standard method
+ described in RFC 2047.
+
+ As with all multipart MIME types, each part has an optional
+ "Content-Type", which defaults to text/plain. If the contents of a
+ file are returned via filling out a form, then the file input is
+ identified as the appropriate media type, if known, or
+ "application/octet-stream". If multiple files are to be returned as
+ the result of a single form entry, they should be represented as a
+ "multipart/mixed" part embedded within the "multipart/form-data".
+
+ Each part may be encoded and the "content-transfer-encoding" header
+ supplied if the value of that part does not conform to the default
+ encoding.
+
+4. Use of multipart/form-data
+
+4.1 Boundary
+
+ As with other multipart types, a boundary is selected that does not
+ occur in any of the data. Each field of the form is sent, in the
+ order defined by the sending appliction and form, as a part of the
+ multipart stream. Each part identifies the INPUT name within the
+ original form. Each part should be labelled with an appropriate
+ content-type if the media type is known (e.g., inferred from the file
+ extension or operating system typing information) or as
+ "application/octet-stream".
+
+
+
+
+
+Masinter Standards Track [Page 2]
+
+RFC 2388 multipart/form-data August 1998
+
+
+4.2 Sets of files
+
+ If the value of a form field is a set of files rather than a single
+ file, that value can be transferred together using the
+ "multipart/mixed" format.
+
+4.3 Encoding
+
+ While the HTTP protocol can transport arbitrary binary data, the
+ default for mail transport is the 7BIT encoding. The value supplied
+ for a part may need to be encoded and the "content-transfer-encoding"
+ header supplied if the value does not conform to the default
+ encoding. [See section 5 of RFC 2046 for more details.]
+
+4.4 Other attributes
+
+ Forms may request file inputs from the user; the form software may
+ include the file name and other file attributes, as specified in [RFC
+ 2184].
+
+ The original local file name may be supplied as well, either as a
+ "filename" parameter either of the "content-disposition: form-data"
+ header or, in the case of multiple files, in a "content-disposition:
+ file" header of the subpart. The sending application MAY supply a
+ file name; if the file name of the sender's operating system is not
+ in US-ASCII, the file name might be approximated, or encoded using
+ the method of RFC 2231.
+
+ This is a convenience for those cases where the files supplied by the
+ form might contain references to each other, e.g., a TeX file and its
+ .sty auxiliary style description.
+
+4.5 Charset of text in form data
+
+ Each part of a multipart/form-data is supposed to have a content-
+ type. In the case where a field element is text, the charset
+ parameter for the text indicates the character encoding used.
+
+ For example, a form with a text field in which a user typed 'Joe owes
+ <eu>100' where <eu> is the Euro symbol might have form data returned
+ as:
+
+ --AaB03x
+ content-disposition: form-data; name="field1"
+ content-type: text/plain;charset=windows-1250
+ content-transfer-encoding: quoted-printable
+
+
+
+
+
+Masinter Standards Track [Page 3]
+
+RFC 2388 multipart/form-data August 1998
+
+
+ Joe owes =80100.
+ --AaB03x
+
+5. Operability considerations
+
+5.1 Compression, encryption
+
+ Some of the data in forms may be compressed or encrypted, using other
+ MIME mechanisms. This is a function of the application that is
+ generating the form-data.
+
+5.2 Other data encodings rather than multipart
+
+ Various people have suggested using new mime top-level type
+ "aggregate", e.g., aggregate/mixed or a content-transfer-encoding of
+ "packet" to express indeterminate-length binary data, rather than
+ relying on the multipart-style boundaries. While this would be
+ useful, the "multipart" mechanisms are well established, simple to
+ implement on both the sending client and receiving server, and as
+ efficient as other methods of dealing with multiple combinations of
+ binary data.
+
+ The multipart/form-data encoding has a high overhead and performance
+ impact if there are many fields with short values. However, in
+ practice, for the forms in use, for example, in HTML, the average
+ overhead is not significant.
+
+5.3 Remote files with third-party transfer
+
+ In some scenarios, the user operating the form software might want to
+ specify a URL for remote data rather than a local file. In this case,
+ is there a way to allow the browser to send to the client a pointer
+ to the external data rather than the entire contents? This capability
+ could be implemented, for example, by having the client send to the
+ server data of type "message/external-body" with "access-type" set
+ to, say, "uri", and the URL of the remote data in the body of the
+ message.
+
+5.4 Non-ASCII field names
+
+ Note that MIME headers are generally required to consist only of 7-
+ bit data in the US-ASCII character set. Hence field names should be
+ encoded according to the method in RFC 2047 if they contain
+ characters outside of that set.
+
+
+
+
+
+
+
+Masinter Standards Track [Page 4]
+
+RFC 2388 multipart/form-data August 1998
+
+
+5.5 Ordered fields and duplicated field names
+
+ The relationship of the ordering of fields within a form and the
+ ordering of returned values within "multipart/form-data" is not
+ defined by this specification, nor is the handling of the case where
+ a form has multiple fields with the same name. While HTML-based forms
+ may send back results in the order received, and intermediaries
+ should not reorder the results, there are some systems which might
+ not define a natural order for form fields.
+
+5.6 Interoperability with web applications
+
+ Many web applications use the "application/x-url-encoded" method for
+ returning data from forms. This format is quite compact, e.g.:
+
+ name=Xavier+Xantico&verdict=Yes&colour=Blue&happy=sad&Utf%F6r=Send
+
+ however, there is no opportunity to label the enclosed data with
+ content type, apply a charset, or use other encoding mechanisms.
+
+ Many form-interpreting programs (primarly web browsers) now implement
+ and generate multipart/form-data, but an existing application might
+ need to optionally support both the application/x-url-encoded format
+ as well.
+
+5.7 Correlating form data with the original form
+
+ This specification provides no specific mechanism by which
+ multipart/form-data can be associated with the form that caused it to
+ be transmitted. This separation is intentional; many different forms
+ might be used for transmitting the same data. In practice,
+ applications may supply a specific form processing resource (in HTML,
+ the ACTION attribute in a FORM tag) for each different form.
+ Alternatively, data about the form might be encoded in a "hidden
+ field" (a field which is part of the form but which has a fixed value
+ to be transmitted back to the form-data processor.)
+
+6. Security Considerations
+
+ The data format described in this document introduces no new security
+ considerations outside of those introduced by the protocols that use
+ it and of the component elements. It is important when interpreting
+ content-disposition to not overwrite files in the recipients address
+ space inadvertently.
+
+ User applications that request form information from users must be
+ careful not to cause a user to send information to the requestor or a
+ third party unwillingly or unwittingly. For example, a form might
+
+
+
+Masinter Standards Track [Page 5]
+
+RFC 2388 multipart/form-data August 1998
+
+
+ request 'spam' information to be sent to an unintended third party,
+ or private information to be sent to someone that the user might not
+ actually intend. While this is primarily an issue for the
+ representation and interpretation of forms themselves, rather than
+ the data representation of the result of form transmission, the
+ transportation of private information must be done in a way that does
+ not expose it to unwanted prying.
+
+ With the introduction of form-data that can reasonably send back the
+ content of files from user's file space, the possibility that a user
+ might be sent an automated script that fills out a form and then
+ sends the user's local file to another address arises. Thus,
+ additional caution is required when executing automated scripting
+ where form-data might include user's files.
+
+7. Author's Address
+
+ Larry Masinter
+ Xerox Palo Alto Research Center
+ 3333 Coyote Hill Road
+ Palo Alto, CA 94304
+
+ Fax: +1 650 812 4333
+ EMail: masinter parc xerox com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masinter Standards Track [Page 6]
+
+RFC 2388 multipart/form-data August 1998
+
+
+Appendix A. Media type registration for multipart/form-data
+
+ Media Type name:
+ multipart
+
+ Media subtype name:
+ form-data
+
+ Required parameters:
+ none
+
+ Optional parameters:
+ none
+
+ Encoding considerations:
+ No additional considerations other than as for other multipart
+ types.
+
+ Security Considerations
+ Applications which receive forms and process them must be careful
+ not to supply data back to the requesting form processing site that
+ was not intended to be sent by the recipient. This is a
+ consideration for any application that generates a multipart/form-
+ data.
+
+ The multipart/form-data type introduces no new security
+ considerations for recipients beyond what might occur with any of
+ the enclosed parts.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masinter Standards Track [Page 7]
+
+RFC 2388 multipart/form-data August 1998
+
+
+References
+
+ [RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ November 1996.
+
+ [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+ Part Three: Message Header Extensions for Non-ASCII Text",
+ RFC 2047, November 1996.
+
+ [RFC 2231] Freed, N., and K. Moore, "MIME Parameter Value and Encoded
+ Word Extensions: Character Sets, Languages, and
+ Continuations", RFC 2231, November 1997.
+
+ [RFC 1806] Troost, R., and S. Dorner, "Communicating Presentation
+ Information in Internet Messages: The Content-Disposition
+ Header", RFC 1806, June 1995.
+
+ [RFC 1867] Nebel, E., and L. Masinter, "Form-based File Upload in
+ HTML", RFC 1867, November 1995.
+
+ [RFC 2183] Troost, R., Dorner, S., and K. Moore, "Communicating
+ Presentation Information in Internet Messages: The
+ Content-Disposition Header Field", RFC 2183, August 1997.
+
+ [RFC 2184] Freed, N., and K. Moore, "MIME Parameter Value and Encoded
+ Word Extensions: Character Sets, Languages, and
+ Continuations", RFC 2184, August 1997.
+
+ [HTML40] D. Raggett, A. Le Hors, I. Jacobs. "HTML 4.0
+ Specification", World Wide Web Consortium Technical Report
+ "REC-html40", December, 1997. <http://www.w3.org/TR/REC-
+ html40/>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masinter Standards Track [Page 8]
+
+RFC 2388 multipart/form-data August 1998
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masinter Standards Track [Page 9]
+
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
