rack-mail_exception 0.0.1

data/vendor/mail/reference/rfc2111 Content-ID and Message-ID URLs.txt

@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                        E. Levinson
+Request for Comments: 2111                                   XIson, Inc.
+Category: Standards Track                                     March 1997
+
+
+          Content-ID and Message-ID Uniform Resource Locators
+
+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.
+
+Abstract
+
+   The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow
+   references to messages and the body parts of messages.  For example,
+   within a single multipart message, one HTML body part might include
+   embedded references to other parts of the same message.
+
+1. Introduction
+
+   The use of [MIME] within email to convey Web pages and their
+   associated images requires a URL scheme to permit the HTML to refer
+   to the images or other data included in the message.  The Content-ID
+   Uniform Resource Locator, "cid:", serves that purpose.
+
+   Similarly Net News readers use Message-IDs to link related messages
+   together.  The Message-ID URL provides a scheme, "mid:", to refer to
+   such messages as a "resource".
+
+   The "mid" (Message-ID) and "cid" (Content-ID) URL schemes provide
+   identifiers for messages and their body parts.  The "mid" scheme uses
+   (a part of) the message-id of an email message to refer to a specific
+   message.  The "cid" scheme refers to a specific body part of a
+   message; its use is generally limited to references to other body
+   parts in the same message as the referring body part.  The "mid"
+   scheme may also refer to a specific body part within a designated
+   message, by including the content-ID's address.
+
+   A note on terminology.  The terms "body part" and "MIME entity" are
+   used interchangeably.  They refer to the headers and body of a MIME
+   message, either the message itself or one of the body parts contained
+   in a Multipart message.
+
+
+
+
+
+Levinson                    Standards Track                     [Page 1]
+
+RFC 2111                    CID and MID URLs                  March 1997
+
+
+2. The MID and CID URL Schemes
+
+   RFC1738 [URL] reserves the "mid" and "cid" schemes for Message-ID and
+   Content-ID respectively.  This memorandum defines the syntax for
+   those URLs.  Because they use the same syntactic elements they are
+   presented together.
+
+   The URLs take the form
+
+        content-id    = url-addr-spec
+
+        message-id    = url-addr-spec
+
+        url-addr-spec = addr-spec  ; URL encoding of RFC 822 addr-spec
+
+        cid-url       = "cid" ":" content-id
+
+        mid-url       = "mid" ":" message-id [ "/" content-id ]
+
+      Note: in Internet mail messages, the addr-spec in a Content-ID
+      [MIME] or Message-ID [822] header are enclosed in angle brackets
+      (<>).  Since addr-spec in a Message-ID or Content-ID might contain
+      characters not allowed within a URL; any such character (including
+      "/", which is reserved within the "mid" scheme) must be hex-
+      encoded using the %hh escape mechanism in [URL].
+
+   A "mid" URL with only a "message-id" refers to an entire message.
+   With the appended "content-id", it refers to a body part within a
+   message, as does a "cid" URL.  The Content-ID of a MIME body part is
+   required to be globally unique.  However, in many systems that store
+   messages, body parts are not indexed independently their context
+   (message).  The "mid" URL long form was designed to supply the
+   context needed to support interoperability with such systems.
+
+   A implementation conforming to this specification is required to
+   support the "mid" URL long form (message-id/content-id).  Conforming
+   implementations can choose to, but are not required to, take
+   advantage of the content-id's uniqueness and interpret a "cid" URL to
+   refer to any body part within the message store.
+
+   In limited circumstances (e.g., within multipart/alternate), a single
+   message may contain several body parts that have the same Content-ID.
+   That occurs, for example, when identical data can be accessed through
+   different methods [MIME, sect. 7.2.3].  In those cases, conforming
+   implementations are required to use the rules of the containing MIME
+   entity (e.g., multi-part/alternate) to select the body part to which
+   the Content-ID refers.
+
+
+
+
+Levinson                    Standards Track                     [Page 2]
+
+RFC 2111                    CID and MID URLs                  March 1997
+
+
+   A "cid" URL is converted to the corresponding Content-ID message
+   header [MIME] by removing the "cid:" prefix, converting %hh hex-
+   escaped characters to their ASCII equivalents and enclosing the
+   remaining parts with an angle bracket pair, "<" and ">".  For
+   example, "mid:foo4%25foo1@bar.net" corresponds to
+
+        Message-ID: <foo4%foo1@bar.net>
+
+   A "mid" URL is converted to a Message-ID or Message-ID/Content-ID
+   pair in a similar fashion.
+
+   Both message-id and content-id are required to be globally unique.
+   That is, no two different messages will ever have the same Message-ID
+   addr-spec; no different body parts will ever have the same Content-ID
+   addr-spec.  A common technique used by many message systems is to use
+   a time and date stamp along with the local host's domain name, e.g.,
+   950124.162336@XIson.com.
+
+Some Examples
+
+   The following message contains an HTML body part that refers to an
+   image contained in another body part.  Both body parts are contained
+   in a Multipart/Related MIME entity.  The HTML IMG tag contains a
+   cidurl which points to the image.
+
+     From: foo1@bar.net
+     To: foo2@bar.net
+     Subject: A simple example
+     Mime-Version: 1.0
+     Content-Type: multipart/related; boundary="boundary-example-1";
+                   type=Text/HTML
+
+     --boundary-example 1
+     Content-Type: Text/HTML; charset=US-ASCII
+
+     ... text of the HTML document, which might contain a hyperlink
+     to the other body part, for example through a statement such as:
+     <IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
+
+     --boundary-example-1
+     Content-ID: foo4*foo1@bar.net
+     Content-Type: IMAGE/GIF
+     Content-Transfer-Encoding: BASE64
+
+
+
+
+
+
+
+
+Levinson                    Standards Track                     [Page 3]
+
+RFC 2111                    CID and MID URLs                  March 1997
+
+
+     R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
+     NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
+     etc...
+
+     --boundary-example-1--
+
+   The following message points to another message (hopefully still in
+   the recipient's message store).
+
+     From: bar@none.com
+     To: phooey@all.com
+     Subject: Here's how to do it
+     Content-type: text/html; charset=usascii
+
+     ...  The items in my
+     <A HREF= "mid:960830.1639@XIson.com/partA.960830.1639@XIson.com">
+     previous message</A>, shows how the approach you propose can be
+     used to accomplish ...
+
+3. Security Considerations
+
+   The URLs defined here provide an addressing or referencing mechanism.
+   The values of these URLs disclose no more about the originators
+   environment than the corresponding Message-ID and Content-ID values.
+   Where concern exists about such disclosures the originator of a
+   message using mid and cid URLs must take precautions to insure that
+   confidential information is not disclosed.  Those precautions should
+   already be in place to handle existing mail use of the Message-ID and
+   Content-ID.
+
+4. References
+
+[822]     Crocker, D., "Standard for the Format of ARPA Internet Text
+          Messages," August 1982, University of Delaware, STD 11, RFC
+          822.
+
+[MIME]    N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
+          Extensions) Part One:  Mechanisms for Specifying and
+          Describing the Format of Internet Message Bodies,"
+          September 1993, RFC 1521.
+
+[URL]     Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform
+          Resource Locators (URL)," December 1994.
+
+[MULREL]  E. Levinson, "The MIME Multipart/Related Content-type,"
+          December 1995, RFC 1874.
+
+
+
+
+
+Levinson                    Standards Track                     [Page 4]
+
+RFC 2111                    CID and MID URLs                  March 1997
+
+
+5. Acknowledgments
+
+   The original concept of "mid" and "cid" URLs were part of the Tim
+   Berners-Lee's original vision of the World Wide Web. The ideas and
+   design have benefited greatly by discussions with Harald Alvestrand,
+   Dan Connolly, Roy Fielding, Larry Masinter, Jacob Palme, and others
+   in the MHTML working group.
+
+6. Author's Address
+
+   Edward Levinson
+   47 Clive Street
+   Metuchen, NJ  08840-1060
+   USA
+   +1 908 549 3716
+   <XIson@cnj.digex.net>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levinson                    Standards Track                     [Page 5]
+

data/vendor/mail/reference/rfc2183 Content-Disposition Header Field.txt

@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                          R. Troost
+Request for Comments: 2183                           New Century Systems
+Updates: 1806                                                  S. Dorner
+Category: Standards Track                          QUALCOMM Incorporated
+                                                        K. Moore, Editor
+                                                 University of Tennessee
+                                                             August 1997
+
+
+               Communicating Presentation Information in
+                           Internet Messages:
+                  The Content-Disposition Header Field
+
+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.
+
+Abstract
+
+   This memo provides a mechanism whereby messages conforming to the
+   MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
+   2049] can convey presentational information.  It specifies the
+   "Content-Disposition" header field, which is optional and valid for
+   any MIME entity ("message" or "body part").  Two values for this
+   header field are described in this memo; one for the ordinary linear
+   presentation of the body part, and another to facilitate the use of
+   mail to transfer files.  It is expected that more values will be
+   defined in the future, and procedures are defined for extending this
+    set of values.
+
+   This document is intended as an extension to MIME.  As such, the
+   reader is assumed to be familiar with the MIME specifications, and
+   [RFC 822].  The information presented herein supplements but does not
+   replace that found in those documents.
+
+   This document is a revision to the Experimental protocol defined in
+   RFC 1806.  As compared to RFC 1806, this document contains minor
+   editorial updates, adds new parameters needed to support the File
+   Transfer Body Part, and references a separate specification for the
+   handling of non-ASCII and/or very long parameter values.
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 1]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+1.  Introduction
+
+   MIME specifies a standard format for encapsulating multiple pieces of
+   data into a single Internet message. That document does not address
+   the issue of presentation styles; it provides a framework for the
+   interchange of message content, but leaves presentation issues solely
+   in the hands of mail user agent (MUA) implementors.
+
+   Two common ways of presenting multipart electronic messages are as a
+   main document with a list of separate attachments, and as a single
+   document with the various parts expanded (displayed) inline. The
+   display of an attachment is generally construed to require positive
+   action on the part of the recipient, while inline message components
+   are displayed automatically when the message is viewed. A mechanism
+   is needed to allow the sender to transmit this sort of presentational
+   information to the recipient; the Content-Disposition header provides
+   this mechanism, allowing each component of a message to be tagged
+   with an indication of its desired presentation semantics.
+
+   Tagging messages in this manner will often be sufficient for basic
+   message formatting. However, in many cases a more powerful and
+   flexible approach will be necessary. The definition of such
+   approaches is beyond the scope of this memo; however, such approaches
+   can benefit from additional Content-Disposition values and
+   parameters, to be defined at a later date.
+
+   In addition to allowing the sender to specify the presentational
+   disposition of a message component, it is desirable to allow her to
+   indicate a default archival disposition; a filename. The optional
+   "filename" parameter provides for this.  Further, the creation-date,
+   modification-date, and read-date parameters allow preservation of
+   those file attributes when the file is transmitted over MIME email.
+
+   NB: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+   document, are to be interpreted as described in [RFC 2119].
+
+2.  The Content-Disposition Header Field
+
+   Content-Disposition is an optional header field. In its absence, the
+   MUA may use whatever presentation method it deems suitable.
+
+   It is desirable to keep the set of possible disposition types small
+   and well defined, to avoid needless complexity. Even so, evolving
+   usage will likely require the definition of additional disposition
+   types or parameters, so the set of disposition values is extensible;
+   see below.
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 2]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+   In the extended BNF notation of [RFC 822], the Content-Disposition
+   header field is defined as follows:
+
+     disposition := "Content-Disposition" ":"
+                    disposition-type
+                    *(";" disposition-parm)
+
+     disposition-type := "inline"
+                       / "attachment"
+                       / extension-token
+                       ; values are not case-sensitive
+
+     disposition-parm := filename-parm
+                       / creation-date-parm
+                       / modification-date-parm
+                       / read-date-parm
+                       / size-parm
+                       / parameter
+
+     filename-parm := "filename" "=" value
+
+     creation-date-parm := "creation-date" "=" quoted-date-time
+
+     modification-date-parm := "modification-date" "=" quoted-date-time
+
+     read-date-parm := "read-date" "=" quoted-date-time
+
+     size-parm := "size" "=" 1*DIGIT
+
+     quoted-date-time := quoted-string
+                      ; contents MUST be an RFC 822 `date-time'
+                      ; numeric timezones (+HHMM or -HHMM) MUST be used
+
+
+
+   NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters)
+   parameter value containing only non-`tspecials' characters SHOULD be
+   represented as a single `token'.  A short parameter value containing
+   only ASCII characters, but including `tspecials' characters, SHOULD
+   be represented as `quoted-string'.  Parameter values longer than 78
+   characters, or which contain non-ASCII characters, MUST be encoded as
+   specified in [RFC 2184].
+
+   `Extension-token', `parameter', `tspecials' and `value' are defined
+   according to [RFC 2045] (which references [RFC 822] in the definition
+   of some of these tokens).  `quoted-string' and `DIGIT' are defined in
+   [RFC 822].
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 3]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+2.1  The Inline Disposition Type
+
+   A bodypart should be marked `inline' if it is intended to be
+   displayed automatically upon display of the message.  Inline
+   bodyparts should be presented in the order in which they occur,
+   subject to the normal semantics of multipart messages.
+
+2.2  The Attachment Disposition Type
+
+   Bodyparts can be designated `attachment' to indicate that they are
+   separate from the main body of the mail message, and that their
+   display should not be automatic, but contingent upon some further
+   action of the user.  The MUA might instead present the user of a
+   bitmap terminal with an iconic representation of the attachments, or,
+   on character terminals, with a list of attachments from which the
+   user could select for viewing or storage.
+
+2.3  The Filename Parameter
+
+   The sender may want to suggest a filename to be used if the entity is
+   detached and stored in a separate file. If the receiving MUA writes
+   the entity to a file, the suggested filename should be used as a
+   basis for the actual filename, where possible.
+
+   It is important that the receiving MUA not blindly use the suggested
+   filename.  The suggested filename SHOULD be checked (and possibly
+   changed) to see that it conforms to local filesystem conventions,
+   does not overwrite an existing file, and does not present a security
+   problem (see Security Considerations below).
+
+   The receiving MUA SHOULD NOT respect any directory path information
+   that may seem to be present in the filename parameter.  The filename
+   should be treated as a terminal component only.  Portable
+   specification of directory paths might possibly be done in the future
+   via a separate Content-Disposition parameter, but no provision is
+   made for it in this draft.
+
+   Current [RFC 2045] grammar restricts parameter values (and hence
+   Content-Disposition filenames) to US-ASCII.  We recognize the great
+   desirability of allowing arbitrary character sets in filenames, but
+   it is beyond the scope of this document to define the necessary
+   mechanisms.  We expect that the basic [RFC 1521] `value'
+   specification will someday be amended to allow use of non-US-ASCII
+   characters, at which time the same mechanism should be used in the
+   Content-Disposition filename parameter.
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 4]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+   Beyond the limitation to US-ASCII, the sending MUA may wish to bear
+   in mind the limitations of common filesystems.  Many have severe
+   length and character set restrictions.  Short alphanumeric filenames
+   are least likely to require modification by the receiving system.
+
+   The presence of the filename parameter does not force an
+   implementation to write the entity to a separate file. It is
+   perfectly acceptable for implementations to leave the entity as part
+   of the normal mail stream unless the user requests otherwise. As a
+   consequence, the parameter may be used on any MIME entity, even
+   `inline' ones. These will not normally be written to files, but the
+   parameter could be used to provide a filename if the receiving user
+   should choose to write the part to a file.
+
+2.4 The Creation-Date parameter
+
+   The creation-date parameter MAY be used to indicate the date at which
+   the file was created.  If this parameter is included, the paramter
+   value MUST be a quoted-string which contains a representation of the
+   creation date of the file in [RFC 822] `date-time' format.
+
+   UNIX and POSIX implementors are cautioned that the `st_ctime' file
+   attribute of the `stat' structure is not the creation time of the
+   file; it is thus not appropriate as a source for the creation-date
+   parameter value.
+
+2.5 The Modification-Date parameter
+
+   The modification-date parameter MAY be used to indicate the date at
+   which the file was last modified.  If the modification-date parameter
+   is included, the paramter value MUST be a quoted-string which
+   contains a representation of the last modification date of the file
+   in [RFC 822] `date-time' format.
+
+2.6 The Read-Date parameter
+
+   The read-date parameter MAY be used to indicate the date at which the
+   file was last read.  If the read-date parameter is included, the
+   parameter value MUST be a quoted-string which contains a
+   representation of the last-read date of the file in [RFC 822] `date-
+   time' format.
+
+2.7 The Size parameter
+
+   The size parameter indicates an approximate size of the file in
+   octets.  It can be used, for example, to pre-allocate space before
+   attempting to store the file, or to determine whether enough space
+   exists.
+
+
+
+Troost, et. al.             Standards Track                     [Page 5]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+2.8  Future Extensions and Unrecognized Disposition Types
+
+   In the likely event that new parameters or disposition types are
+   needed, they should be registered with the Internet Assigned Numbers
+   Authority (IANA), in the manner specified in Section 9 of this memo.
+
+   Once new disposition types and parameters are defined, there is of
+   course the likelihood that implementations will see disposition types
+   and parameters they do not understand.  Furthermore, since x-tokens
+   are allowed, implementations may also see entirely unregistered
+   disposition types and parameters.
+
+   Unrecognized parameters should be ignored. Unrecognized disposition
+   types should be treated as `attachment'. The choice of `attachment'
+   for unrecognized types is made because a sender who goes to the
+   trouble of producing a Content-Disposition header with a new
+   disposition type is more likely aiming for something more elaborate
+   than inline presentation.
+
+   Unless noted otherwise in the definition of a parameter, Content-
+   Disposition parameters are valid for all dispositions.  (In contrast
+   to MIME content-type parameters, which are defined on a per-content-
+   type basis.) Thus, for example, the `filename' parameter still means
+   the name of the file to which the part should be written, even if the
+   disposition itself is unrecognized.
+
+2.9  Content-Disposition and Multipart
+
+   If a Content-Disposition header is used on a multipart body part, it
+   applies to the multipart as a whole, not the individual subparts.
+   The disposition types of the subparts do not need to be consulted
+   until the multipart itself is presented.  When the multipart is
+   displayed, then the dispositions of the subparts should be respected.
+
+   If the `inline' disposition is used, the multipart should be
+   displayed as normal; however, an `attachment' subpart should require
+   action from the user to display.
+
+   If the `attachment' disposition is used, presentation of the
+   multipart should not proceed without explicit user action.  Once the
+   user has chosen to display the multipart, the individual subpart
+   dispositions should be consulted to determine how to present the
+   subparts.
+
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 6]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+2.10  Content-Disposition and the Main Message
+
+   It is permissible to use Content-Disposition on the main body of an
+   [RFC 822] message.
+
+3.  Examples
+
+   Here is a an example of a body part containing a JPEG image that is
+   intended to be viewed by the user immediately:
+
+        Content-Type: image/jpeg
+        Content-Disposition: inline
+        Content-Description: just a small picture of me
+
+         <jpeg data>
+
+   The following body part contains a JPEG image that should be
+   displayed to the user only if the user requests it. If the JPEG is
+   written to a file, the file should be named "genome.jpg".  The
+   recipient's user might also choose to set the last-modified date of
+   the stored file to date in the modification-date parameter:
+
+        Content-Type: image/jpeg
+        Content-Disposition: attachment; filename=genome.jpeg;
+          modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
+        Content-Description: a complete map of the human genome
+
+        <jpeg data>
+
+   The following is an example of the use of the `attachment'
+   disposition with a multipart body part.  The user should see text-
+   part-1 immediately, then take some action to view multipart-2.  After
+   taking action to view multipart-2, the user will see text-part-2
+   right away, and be required to take action to view jpeg-1.  Subparts
+   are indented for clarity; they would not be so indented in a real
+   message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 7]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+        Content-Type: multipart/mixed; boundary=outer
+        Content-Description: multipart-1
+
+        --outer
+          Content-Type: text/plain
+          Content-Disposition: inline
+          Content-Description: text-part-1
+
+          Some text goes here
+
+        --outer
+          Content-Type: multipart/mixed; boundary=inner
+          Content-Disposition: attachment
+          Content-Description: multipart-2
+
+          --inner
+            Content-Type: text/plain
+            Content-Disposition: inline
+            Content-Description: text-part-2
+
+            Some more text here.
+
+          --inner
+            Content-Type: image/jpeg
+            Content-Disposition: attachment
+            Content-Description: jpeg-1
+
+            <jpeg data>
+          --inner--
+        --outer--
+
+4.  Summary
+
+   Content-Disposition takes one of two values, `inline' and
+   `attachment'.  `Inline' indicates that the entity should be
+   immediately displayed to the user, whereas `attachment' means that
+   the user should take additional action to view the entity.
+
+   The `filename' parameter can be used to suggest a filename for
+   storing the bodypart, if the user wishes to store it in an external
+   file.
+
+
+
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 8]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+5.  Security Considerations
+
+   There are security issues involved any time users exchange data.
+   While these are not to be minimized, neither does this memo change
+   the status quo in that regard, except in one instance.
+
+   Since this memo provides a way for the sender to suggest a filename,
+   a receiving MUA must take care that the sender's suggested filename
+   does not represent a hazard. Using UNIX as an example, some hazards
+   would be:
+
+   +    Creating startup files (e.g., ".login").
+
+   +    Creating or overwriting system files (e.g., "/etc/passwd").
+
+   +    Overwriting any existing file.
+
+   +    Placing executable files into any command search path
+        (e.g., "~/bin/more").
+
+   +    Sending the file to a pipe (e.g., "| sh").
+
+   In general, the receiving MUA should not name or place the file such
+   that it will get interpreted or executed without the user explicitly
+   initiating the action.
+
+   It is very important to note that this is not an exhaustive list; it
+   is intended as a small set of examples only.  Implementors must be
+   alert to the potential hazards on their target systems.
+
+6.  References
+
+   [RFC 2119]
+        Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119, March 1997.
+
+   [RFC 2184]
+        Freed, N. and K. Moore, "MIME Parameter value and Encoded Words:
+        Character Sets, Lanaguage, and Continuations", RFC 2184, August
+        1997.
+
+   [RFC 2045]
+        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
+        Extensions) Part One: Format of Internet Message Bodies", RFC
+        2045, December 1996.
+
+
+
+
+
+
+Troost, et. al.             Standards Track                     [Page 9]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+   [RFC 2046]
+        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
+        Extensions) Part Two: Media Types", RFC 2046, December 1996.
+
+   [RFC 2047]
+        Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+        Three: Message Header Extensions for non-ASCII Text", RFC 2047,
+        December 1996.
+
+   [RFC 2048]
+        Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose
+        Internet Mail Extensions) Part Four: Registration Procedures",
+        RFC 2048, December 1996.
+
+   [RFC 2049]
+        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
+        Extensions) Part Five: Conformance Criteria and Examples", RFC
+        2049, December 1996.
+
+   [RFC 822]
+        Crocker, D., "Standard for the Format of ARPA Internet Text
+        Messages", STD 11, RFC 822, UDEL, August 1982.
+
+7.  Acknowledgements
+
+   We gratefully acknowledge the help these people provided during the
+   preparation of this draft:
+
+        Nathaniel Borenstein
+        Ned Freed
+        Keith Moore
+        Dave Crocker
+        Dan Pritchett
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                    [Page 10]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+8.  Authors' Addresses
+
+   You should blame the editor of this version of the document for any
+   changes since RFC 1806:
+
+        Keith Moore
+        Department of Computer Science
+        University of Tennessee, Knoxville
+        107 Ayres Hall
+        Knoxville TN  37996-1301
+        USA
+
+        Phone: +1 (423) 974-5067
+        Fax: +1 (423) 974-8296
+        Email: moore@cs.utk.edu
+
+
+        The authors of RFC 1806 are:
+
+        Rens Troost
+        New Century Systems
+        324 East 41st Street #804
+        New York, NY, 10017 USA
+
+        Phone: +1 (212) 557-2050
+        Fax: +1 (212) 557-2049
+        EMail: rens@century.com
+
+
+        Steve Dorner
+        QUALCOMM Incorporated
+        6455 Lusk Boulevard
+        San Diego, CA 92121
+        USA
+
+        EMail: sdorner@qualcomm.com
+
+
+9. Registration of New Content-Disposition Values and Parameters
+
+   New Content-Disposition values (besides "inline" and "attachment")
+   may be defined only by Internet standards-track documents, or in
+   Experimental documents approved by the Internet Engineering Steering
+   Group.
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                    [Page 11]
+
+RFC 2183                  Content-Disposition                August 1997
+
+
+   New content-disposition parameters may be registered by supplying the
+   information in the following template and sending it via electronic
+   mail to IANA@IANA.ORG:
+
+     To: IANA@IANA.ORG
+     Subject: Registration of new Content-Disposition parameter
+
+     Content-Disposition parameter name:
+
+     Allowable values for this parameter:
+          (If the parameter can only assume a small number of values,
+          list each of those values.  Otherwise, describe the values
+          that the parameter can assume.)
+     Description:
+          (What is the purpose of this parameter and how is it used?)
+
+10. Changes since RFC 1806
+
+   The following changes have been made since the earlier version of
+   this document, published in RFC 1806 as an Experimental protocol:
+
+   +    Updated references to MIME documents.  In some cases this
+        involved substituting a reference to one of the current MIME
+        RFCs for a reference to RFC 1521; in other cases, a reference to
+        RFC 1521 was simply replaced with the word "MIME".
+
+   +    Added  a section on registration procedures, since none of the
+        procedures in RFC 2048 seemed to be appropriate.
+
+   +    Added new parameter types: creation-date, modification-date,
+        read-date, and size.
+
+
+   +    Incorporated a reference to draft-freed-pvcsc-* for encoding
+        long or non-ASCII parameter values.
+
+   +    Added reference to RFC 2119 to define MUST, SHOULD, etc.
+        keywords.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Troost, et. al.             Standards Track                    [Page 12]
+