diff options
Diffstat (limited to 'mime64/mime.txt')
| -rw-r--r-- | mime64/mime.txt | 831 |
1 files changed, 0 insertions, 831 deletions
diff --git a/mime64/mime.txt b/mime64/mime.txt deleted file mode 100644 index 109e481c..00000000 --- a/mime64/mime.txt +++ /dev/null @@ -1,831 +0,0 @@ -
-
- MIME Overview
-
- by Mark Grand <mark@premenos.sf.ca.us>
-
-Internet e-mail allows mail messages to be exchanged between users of
-computers around the world and occasionally beyond... to space
-shuttles. One of the main reasons that Internet e-mail has achieved
-such wide use is because it provides a standard mechanism for messages
-to be exchanged between over 1,000,000 computers connected to the
-Internet.
-
-The standards that are the basis for Internet e-mail were established
-in 1982. Though they were state of the art in 1982, in the
-intervening years they have begun to show their age. The 1982
-standards allow for mail messages that contain a single human readable
-message with the restrictions that:
-
- * the message contains only ASCII characters.
-
- * the message contains no lines longer than 1000 characters.
-
- * the message does not exceed a certain length
-
-The 1982 standards do not allow EDI to be transmitted through Internet
-mail, since EDI messages can violate all of these restrictions. There
-are a number of other types of messages and services that have are
-supported by other mail standards that have been designed more
-recently. In June of 1992 a new Internet mail standard was approved.
-This new standard is called MIME.
-
-MIME is an acronym for Multipurpose Internet Mail Extensions. It
-builds on the older standard by standardizing additional fields for
-mail message headers that describe new types of content and
-organization for messages.
-
-MIME allows mail messages to contain:
-
- * Multiple objects in a single message.
-
- * Text having unlimited line length or overall length.
-
- * Character sets other than ASCII.
-
- * Multi-font messages.
-
- * Binary or application specific files.
-
- * Images, Audio, Video and multi-media messages.
-
-MIME defines the following new header fields:
-
-1. A MIME-Version header field, which uses a version number to
- declare that a message conforms to the MIME standard.
-
-2. A Content-Type header field, which can be used to specify the type
- and subtype of data in the body of a message and to fully specify
- the encoding of such data.
-
- 2.a. A Text Content-Type value, which can be used to represent
- textual information in a number of character sets and
- formatted text description languages in a standardized
- manner.
-
- 2.b. A Multipart Content-Type value, which can be used to combine
- several body parts, possibly of differing types of data,
- into a single message.
-
- 2.c. An Application Content-Type value, which can be used to
- transmit application data or binary data.
-
- 2.d. A Message Content-Type value, for encapsulating a mail
- message.
-
- 2.e. An Image Content-Type value, for transmitting still image
- (picture) data.
-
- 2.f. An Audio Content-Type value, for transmitting audio or voice
- data.
-
- 2.g. A Video Content-Type value, for transmitting video or moving
- image data, possibly with audio as part of the composite
- video data format.
-
-3. A Content-Transfer-Encoding header field, that specifies how the
- data is encoded to allow it to pass through mail transports having
- data or character set limitations.
-
-4. Two optional header fields that can be used to further describe
- the data in a message body, the Content-ID and Content-Description
- header fields.
-
-MIME is an extensible mechanism. It is expected that the set of
-content-type/subtype pairs and their associated parameters will grow
-with time. Several other MIME fields, such as character set names,
-are likely to have new values defined over time. To ensure that the
-set of such values develops in an orderly, and public manner, MIME
-defines a registration process which uses the Internet Assigned
-Numbers Authority (IANA) as a central registry for such values.
-
-To promote interoperability between implementations, the MIME standard
-document specifies a minimal subset of the above mechanisms that are
-required for an implementation to claim to conform to the MIME
-standard.
-
-
-
- MIME Technical Summary
-
-MIME is defined by an Internet standard document called RFC 1341.
-This document summarizes the contents of RFC 1341. Sufficient detail
-is presented here to understand the capabilities of MIME. For
-sufficient detail to implement MIME please read RFC 1341.
-
-MIME allows messages to contain multiple objects. When multiple
-objects are in a MIME message, they are represented in a form called a
-body part. A body part has a header and a body, so it makes sense to
-speak about the body of a body part. Also, body parts can be nested in
-bodies that contain one or multiple body parts.
-
-The Content-Type values, subtypes, and parameter names defined in the
-MIME standard are not case insensitive. However, many parameter
-values are case sensitive.
-
-The MIME standard is written to allow MIME to be extended in certain
-ways, without having to revise the standard. MIME specifies sets of
-values that are allowed for various fields and parameters. The
-provides a procedure for extending these sets of values by registering
-them with an entity called the Internet Assigned Numbers Authority
-(IANA).
-
-
-The MIME-Version Header Field
-
-MIME is designed to be compatible with older Internet mail standards.
-In particular, it is compatible with RFC 822. If a mail reading
-program receives a message that is a MIME message then it will likely
-perform additional processing for the MIME message that it would not
-perform for non-MIME messages. In order to allow mail reading
-programs to recognize MIME messages, MIME messages are required to
-contain a MIME-Version header field. The MIME-Version header field
-specifies the version of the MIME standard that the message conforms
-to.
-
-As of this writing there is only version (1.0) of the MIME standard.
-Messages that comply with the standard must include a header field,
-with the following verbatim text:
-
- MIME-Version: 1.0
-
-The MIME-Version header field is required at the top level of a
-message. It is not required for each body part of a multipart entity.
-It is required for the embedded headers of a body of type "message" if
-and only if the embedded message is claimed to be MIME-compliant.
-
-
-The Content-Type Header Field
-
-The Content-Type field describes the data contained in the body fully
-enough that the mail reader can pick an appropriate mechanism to
-present the data to the user, or otherwise deal with the data in an
-appropriate manner.
-
-The Content-Type header field is used to specify the nature of data in
-the body or body part, by giving type and subtype identifiers, and by
-providing parameters that may be needed for certain types. After the
-type and subtype names, the remainder of the header field is a set of
-parameters, specified in an attribute/value notation. The set of
-meaningful parameters differs for different types. The order of
-parameters is not significant. Comments are allowed (in accordance
-with RFC 822 rules) in structured header fields by placing them in
-parentheses.
-
-The top-level Content-Type is used to declare the general type of
-data, while the subtype specifies a specific format for that type of
-data. Thus, a Content-Type of Image/xyz is enough to tell a mail
-reader that the data is an image, even if the mail reader has no
-knowledge of the specific image format xyz. Such information can be
-used, to decide whether or not to show a user the raw data from an
-unrecognized subtype -- such an action might be reasonable for
-unrecognized subtypes of Text, but not for unrecognized subtypes of
-Image or Audio. For this reason, registered subtypes of Audio, Image,
-Text, and Video, should not contain embedded information that is
-really of a different type. Such compound types are usually
-represented using the Multipart or Application types.
-
-Parameters are modifiers of the content-subtype. Although most
-parameters make sense only with certain content-types, others are
-"global" in the sense that they might apply to any subtype. For
-example, the Boundary parameter, which is used to indicate how body
-parts are separated from each other, makes sense only for the
-Multipart content-type. The Charset parameter might make sense with
-several content-types.
-
-The MIME standard defines seven content-types. The authors of the
-MIME standard state that the set of seven types is "substantially
-complete". They expect additional supported types to be accommodated
-by creating new subtypes of the seven initial top-level types. The
-MIME standard, functioning as a constitution for the MIME community,
-states that new standard content types can be defined only by revising
-the standard (as opposed to the registration procedure for other types
-of extensions). However, MIME does provide for the use of
-non-standard content types. Non-standard content-types can be used,
-but must be given names starting with X-. Future standard content
-type names will not begin with X-.
-
-The syntax for the content type header field is
-
- Content-Type := type "/" subtype [";" parameter]...
-
-The defined content types are:
-
- Application
- indicates data that does not fit into any of the other
- categories, such as uninterpreted binary data or information
- to be processed by a mail-based application. In addition to
- the following subtypes, it is likely that additional subtypes
- will be defined for applications such as mail-based scheduling
- systems, spreadsheets and EDI.
-
- Application/Octet-Stream
- indicates uninterpreted binary data, which a mail reading
- program may simply offer to write the information into a file.
- Possible parameters for Application/Octet-Stream include:
-
- Name
- a suggested name for the binary data if stored as a file.
-
- Type
- the general type or category of binary data. This is
- intended for human recipients rather than for automated
- processing.
-
- Conversions
- the operations that performed on the data before putting
- it the body. Note that the standard defines no conversion
- values. Any conversion values that do not begin with X-
- must be preceded by a published specification and by
- registration with IANA.
-
- Padding
- the number of bits of padding that were appended to the
- bitstream comprising the actual contents to produce the
- enclosed byte-oriented data. This is useful for enclosing
- a bitstream in a body when the total number of bits is not
- a multiple of the byte size.
-
- Application/ODA
- indicates a body containing information encoded according to
- the Office Document Architecture (ODA) standards, using the
- ODIF representation format. For Application/ODA, the
- Content-Type line should also specify an attribute/value pair
- that indicates the document application profile (DAP), using a
- Profile parameter. Thus an appropriate header field might
- look like this:
-
- Content-Type: application/oda;
- profile=Q112
-
- Consult the ODA standard for further information.
-
- Application/PostScript
- indicates a body containing a postscript document.
-
-Audio
- Indicates audio data. Audio requires an audio output device (such
- as a speaker or a telephone) to "display" the contents.
-
- Audio/Basic
- The content of the Audio/Basic subtype is audio encoded using
- 8-bit ISDN u-law. When this subtype is present, a sample rate
- of 8000 Hz and a single channel is assumed.
-
- Image
- Image data. Image requires a display device (such as a
- graphical display, a printer, or a FAX machine) to view the
- information.
-
- Image/Jpeg
- indicates an image in JPEG format.
-
- Image/Gif
- indicates an image in GIF format.
-
-Message
- indicates an encapsulated message.
-
- Message/Rfc822
- indicates that the body contains an encapsulated message, with
- the syntax of an RFC 822 message.
-
- Message/Partial
- indicates a partial message, allowing fragmented transmission
- of bodies too large to be passed through mail transport
- facilities. Message/Partial indicates that the body contains
- a fragment of a larger message.
-
- Three parameters are required in a Content-Type field of type
- Message/Partial: The first, Id, is a unique identifier, as
- close to world-unique as possible, used to match the parts
- together. The second, Number, an integer, is the part number
- indicating where this part fits into the sequence of
- fragments. The third, Total, another integer, is the total
- number of parts. Total is required on the final part, and
- optional on earlier parts.
-
- Message/External-Body
- indicates that the actual body data are not included, but
- merely referenced. In this case, the parameters describe a
- mechanism for accessing the external data.
-
- When a body or body part is of type Message/External-Body,
- it consists of a header, a blank line, and the message header
- for the encapsulated message. If another blank line appears,
- this ends the message header for the encapsulated message.
- However, since the encapsulated message's body is itself
- external, it does not appear in the area that follows. For
- example, consider this message:
-
- Content-type: message/external-body;
- access-type=local-file;
- name=/u/nsb/Me.gif
-
- Content-type: image/gif
-
- THIS IS NOT REALLY THE BODY!
-
- The area at the end, which constitutes a phantom body, is
- ignored for most external-body messages. However, it may be
- used to contain auxiliary information for a
- "mail-server".
-
- The only parameter of Message/ExternalÄBody that is always
- mandatory is Access-Type. Its other parameters are mandatory
- or optional depending on the value of Access-Type. The values
- defined for the Access-Type parameter are FTP, ANON-FTP, TFTP,
- AFS, LOCAL-FILE, and MAIL-SERVER. Except for values beginning
- with X-, other values must be registered with IANA.
-
- The standard also specifies additional parameters that are to
- be used in conjunction with the various access types.
-
- In addition to access-type specific parameters, the standard
- defines the following parameters which are optional for all
- access types:
-
- * The Expiration parameter is used to specify a date after
- which the existence of the external data is not
- guaranteed.
-
- * The Size parameter is used to specify the size of the
- data.
-
-Multipart
-
- indicates data consisting of multiple body parts; each having its
- own data type. It is possible to tell where each body part begins
- and ends because each body part is preceded by a special string
- called an encapsulation boundary; the last body part is followed
- by a closing boundary.
-
- The boundary strings used are specified by a mandatory parameter
- called Boundary. The encapsulation boundary is an end of line
- followed by two hyphens followed by the boundary parameter value
- of the ContentÄType header field. The closing boundary is the
- same as the encapsulation boundary with the addition of two
- hyphens at the end of the line.
-
- The encapsulation boundary must not appear inside any of the
- encapsulated parts. It is crucial that the composing user agent
- be able to choose and specify the unique boundary that will
- separate the body parts. Encapsulation boundaries may be no
- longer than 70 characters, not counting the blank line and leading
- hyphens.
-
- Thus, a typical multipart Content-Type header field might look
- like:
-
- Content-Type: multipart/mixed; boundary=gc0y0pkb9ex
-
- This indicates a body consisting of several body parts, each
- having a structure syntactically identical to an RFC 822 message,
- except that the header area may be completely empty, and each part
- is preceded by the line
-
- --gc0y0pkb9ex
-
- The closing boundary following the last body part indicates that
- no further body parts will follow. It is identical to the
- preceding encapsulation boundaries, with the addition of two more
- hyphens at the end of the line:
-
- --gc0y0pkb9ex--
-
- There is room for additional information prior to the first
- encapsulation boundary and following the final boundary. These
- areas are often blank. Anything appearing before the first or
- after the last boundary is ignored.
-
- As a simple example, the following multipart message has two
- parts, both plain text, one explicitly typed and one implicitly
- typed:
-
- From: Nathaniel Borenstein <nsb@bellcore.com>
- To: Ned Freed <ned@innosoft.com>
- Subject: Sample message
- MIME-Version: 1.0
- Content-type: multipart/mixed;
- boundary="simple boundary"
-
- This is the preamble. It is to be ignored, though it is a
- handy place for mail composers to include an explanatory note
- to non-MIME compliant readers.
-
- --simple boundary
-
- This is implicitly typed plain ASCII text.
- --simple boundary
- Content-type: text/plain; charset=us-ascii
-
- This is explicitly typed plain ASCII text.
- It DOES end with a line break.
-
- --simple boundary--
- This is the epilogue. It is also to be ignored.
-
- The use of a Content-Type of multipart in a body part within
- another multipart entity is explicitly allowed. In such cases,
- care must be taken to ensure that each nested multipart entity
- uses a different boundary delimiter.
-
- The use of the multipart Content-Type with only a single body part
- may be useful in certain contexts, and is explicitly permitted.
-
- Multipart/Mixed
- indicates multiple independent body parts to be viewed
- serially.
-
- Multipart/Alternative
- is syntactically identical to Multipart/Mixed. Each part is
- an "alternative" version of the same information. Mail
- readers should recognize that the content of the parts are
- interchangeable. The mail reader should either choose the
- "best" type based on the user's environment and preferences,
- or offer the user the available alternatives. Generally,
- choosing the best type means displaying only the last part
- that can be displayed. This may be used, for example, to send
- mail in a fancy text format in such a way that it can easily
- be displayed anywhere:
-
- From: Nathaniel Borenstein <nsb@bellcore.com>
- To: Ned Freed <ned@innosoft.com>
- Subject: Formatted text mail
- MIME-Version: 1.0
- Content-Type: multipart/alternative;
- boundary=boundary42
-
-
- --boundary42
- Content-Type: text/plain; charset=us-ascii
-
- ...plain text version of message goes here...
- --boundary42
- Content-Type: text/richtext
-
- ... richtext version of same message goes here ...
- --boundary42
- Content-Type: text/x-whatever
-
- ... fanciest formatted version of same message goes here
- ...
- --boundary42--
-
- In this example, users whose mail system understood the
- text/x-whatever format would see only the fancy version,
- while other users would see only the richtext or plain text
- version, depending on the capabilities of their system.
-
- Some mail reading programs that recognize more than one of the
- formats will offer the user a choice of which format to view.
- This makes sense, for example, if mail includes both a nicely
- formatted image version and an easily edited text version.
- The point is that multiple versions of the same data are not
- automatically shown. Either the user is shown the last
- recognized version or explicitly given the choice.
-
- Multipart/Parallel
- is syntactically identical to Multipart/Mixed. However, in a
- parallel body, all of the body parts are intended to be
- presented simultaneously on hardware and software that are
- capable of doing so. Composing agents should be aware that
- many mail readers will lack this capability and will show the
- parts serially in any event.
-
- Multipart/Parallel will likely be used for multimedia messages
- that combine such message types as text, audio and/or video.
-
- Multipart/Digest
- Indicates that each of the body parts is an RFC 822 mail
- message. Multipart/Digest is syntactically identical to
- Multipart/Mixed, except that the default Content-Type value
- for a body part is changed from Text/Plain to Message/Rfc822.
-
-Text
- The text Content-Type is for sending material that is principally
- textual in form. It is the default Content-Type. A Charset
- parameter may be used to indicate the character set of the text.
- The default Content-Type for Internet mail is
- text/plain; Charset=US-ASCII.
-
- The value of the Charset parameter is not case sensitive.
- Allowable values are US-ASCII, ISO-8859-1, ISO-8859-2, ... and
- ISO-8859-9. The default value for Charset is US-ASCII.
-
- Text/Plain
- indicates plain (unformatted) text. No special software is
- required to get the full meaning of the text, aside from
- support for the indicated character set. Other subtypes
- should be used for enriched text in forms where application
- software may enhance the appearance of the text, but such
- software must not be required in order to get the general idea
- of the content. Possible future subtypes include any readable
- word processor format.
-
- Text/Richtext
- indicates a simple portable word processing format that is
- defined by the MIME standard. It is a very small subset of
- SGML. Mail readers that implement Richtext may implement only
- a subset of it.
-
- When a mail composing program is given a file in a word
- processing format to send and there is no standardized subtype
- for that format, then the message composing program may
- reformat the file into richtext format which will preserve
- more of the original formatting information than reformatting
- the file to plain ASCII.
-
-Video
- indicates that the body contains a time-varying-picture image,
- possibly with color and coordinated sound. The term Video is
- used very generically and does not refer to any particular
- technology or format. It is not meant to preclude subtypes
- such as animated drawings encoded compactly.
-
- Video/Mpeg
- indicates video coded according to the MPEG standard.
-
-x-TypeName
- This is any type name that begins with X-. A Content-Type value
- beginning with X- is a private value, to be used by consenting
- mail systems by mutual agreement. The standard specifies no
- subtypes.
-
-No type may be specified without a subtype.
-
-The standard allows the use of additional sub-types without having to
-change the standard. However, it is important to insure that
-sub-types used by different user communities of MIME do not conflict.
-It would be confusing if Content-Type: application/foobar meant two
-different things. The standard specifies two mechanisms for defining
-new Content-Type subtypes:
-
-1. Private values (starting with X-) may be defined between
- cooperating mail composing and reading programs without outside
- registration. Use of this mechanism requires knowing that the
- reader of the message will not mistake the content type for
- something other than originally intended.
-
-2. New standard values must be registered with IANA. Where intended
- for public use, the formats they refer to must also be defined by
- a published specification.
-
-Messages that do not have a Content-Type field in their header are
-displayed by user agents as if
-
- Content-Type: Text/plain; Charset=US-ASCII
-
-had been specified.
-
-When a mail reader encounters mail with an unknown Content-Type value,
-it will generally treat it as equivalent to application/octet-stream.
-
-
-The Content-Transfer-Encoding Header Field
-
-Many Content-Types which could usefully be transported via e-mail are
-represented, in their "natural" format, as 8-bit character or binary
-data. Such data cannot be transmitted over some transport protocols.
-For example, SMTP (Simple Mail Transfer Protocol is an Internet
-standard for transporting e-mail defined by a document called RFC 821)
-restricts mail messages to 7-bit ASCII data with lines no longer than
-1000 characters.
-
-MIME provides two mechanisms for re-encoding such data into a 7-bit
-short-line format. The Content-Transfer-Encoding header field
-indicates the mechanism used to perform such an encoding. The
-Content-Transfer-Encoding field indicates the transformation that has
-been used to represent the body in an acceptable manner for transport.
-
-The possible values for the Content-Transfer-Encoding field are:
- BASE64
- QUOTED-PRINTABLE
- 8BIT
- 7BIT
- BINARY
- x-EncodingName
-These values are not case sensitive. That is, Base64, BASE64 and
-bAsE64 are all equivalent. An encoding type of 7BIT requires that the
-body is already in a 7-bit mail-ready representation. That is the
-default value: Content-Transfer-Encoding: 7BIT is assumed if the
-Content-Transfer-Encoding header field is not present.
-
-Both BASE64 and the QUOTED-PRINTABLE imply an encoding that consists
-of lines no longer than 76 ASCII characters. In other respects the
-two encoding schemes are very different.
-
-The encoding scheme implied by QUOTED-PRINTABLE is most appropriate
-for data that consists primarily of printable ASCII characters. Using
-this encoding method, printable ASCII character are represented as
-themselves. The equals sign (=) serves as an escape character. Any
-character that is not a printable or white space ASCII character is
-represented as an equals sign followed by two hexadecimal digits. An
-equals sign in the message is also represented in this way. Lines
-that are longer than 76 characters are cut off after the 75th
-character and the line ends with a equals sign.
-
-The advantages of using the QUOTED-PRINTABLE encoding for message that
-are mostly printable ASCII characters are that few additional
-characters are required and the message can be read by human beings
-who to not have a MIME aware mail reading program. As an example,
-here is an EDI interchange in QUOTED-PRINTABLE encoding:
-
-ISA*00* *00* *01*987654321 *12*8005551234 *910=
-607*0111*U*00200*110000777*0*T*>
-GS*PO*987654321*8005551234*920501*2032*7721*X*002003
-ST*850*000000001
-BEG*00*NE*MS1112**920501**CONTRACT#
-REF*IT*8128827763
-N1*ST*MAVERICK SYSTEMS
-N3*3312 NEW HAMPSHIRE STREET
-N4*SAN JOSE*CA*94811
-PO1*1*25*EA***VC*TP8MM*CB*TAPE8MM
-PO1*2*30*EA***VC*TP1/4*CB*TAPE1/4INCH
-PO1*3*125*EA***VC*DSK31/2*CB*DISK35
-CTT*3
-SE*11*000000001
-GE*1*7721
-IEA*1*110000777
-
-Except for the ISA segment having been wrapped onto two lines, the
-QUOTED-PRINTABLE encoding of the interchange is identical to its 7BIT
-representation.
-
-The BASE64 encoding mechanism is well suited for representing binary
-files. It represents any sequence of three bytes as four printable
-ASCII characters. The same interchange as shown above but using the
-BASE64 encoding would look like:
-
-SVNBKjAwKiAgICAgICAgICAqMDAqICAgICAgICAgICowMSo5ODc2NTQzMjEgICAgICAqMTIq
-ODAwNTU1MTIzNCAgICAgKjkxMDYwNyowMTExKlUqMDAyMDAqMTEwMDAwNzc3KjAqVCo+CkdT
-KlBPKjk4NzY1NDMyMSo4MDA1NTUxMjM0KjkyMDUwMSoyMDMyKjc3MjEqWCowMDIwMDMKU1Qq
-ODUwKjAwMDAwMDAwMQpCRUcqMDAqTkUqTVMxMTEyKio5MjA1MDEqKkNPTlRSQUNUIwpSRUYq
-SVQqODEyODgyNzc2MwpOMSpTVCpNQVZFUklDSyBTWVNURU1TCk4zKjMzMTIgTkVXIEhBTVBT
-SElSRSBTVFJFRVQKTjQqU0FOIEpPU0UqQ0EqOTQ4MTEKUE8xKjEqMjUqRUEqKipWQypUUDhN
-TSpDQipUQVBFOE1NClBPMSoyKjMwKkVBKioqVkMqVFAxLzQqQ0IqVEFQRTEvNElOQ0gKUE8x
-KjMqMTI1KkVBKioqVkMqRFNLMzEvMipDQipESVNLMzUKQ1RUKjMKU0UqMTEqMDAwMDAwMDAx
-CkdFKjEqNzcyMQpJRUEqMSoxMTAwMDA3NzcK
-
-BASE64 bears some resemblance to uuencode in both appearance and
-function. However, uuencode uses characters that may not be processed
-properly by an EBCDIC gateway.
-
-The values 8bit, 7bit, and binary all imply that no encoding has been
-performed. However, they are useful to indicate of the kind of data
-contained in the object, and therefore of the kind of encoding that
-might need to be performed for transmission in a given transport
-system. 7bit means that the data is all represented as short lines of
-ASCII data. 8bit means that the lines are short, but there may be
-non-ASCII characters. Binary means that not only may non-ASCII
-characters be present, but also that the lines are not necessarily
-short enough for SMTP transport.
-
-The difference between 8bit and binary is that binary does not require
-adherence to any limits on line length. 8bit and binary are intended
-for compatibility with future Internet e-mail transport standards and
-with gateways to non-Internet environments. As of this writing there
-are no standardized Internet e-mail transports for which it is
-legitimate to include unencoded 8-bit or binary data in mail bodies.
-
-Note that the five values defined for the Content-Transfer-Encoding
-field imply nothing about the Content-Type other than the algorithm by
-which it was encoded or the transport system requirements if
-unencoded.
-
-Some implementations may support additional Content-Transfer-Encoding
-values (it is permitted but strongly discouraged by the standard).
-Any such additional values must have names that begin with X- to
-indicate its non-standard status For example:
-
- Content-Transfer-Encoding: x-my-new-encoding.
-
-If a Content-Transfer-Encoding header field appears as part of a
-message header, it applies to the entire body of that message. If a
-Content-Transfer-Encoding header field appears as part of a body
-part's headers, it applies only to the body of that body part. If a
-message or body part is of type Multipart or Message, the
-Content-Transfer-Encoding must be 7bit, 8bit or Binary.
-
-The encoding mechanisms defined here explicitly encode all data in
-ASCII. Thus, for example, suppose a message or body part has header
-fields such as:
-
- Content-Type: text/plain; charset=ISO-8859-1
- Content-transfer-encoding: base64
-
-This should be interpreted to mean that the body is a Base64 ASCII
-encoding of data that was originally in ISO-8859-1, and will be in
-that character set again after decoding.
-
-
-Optional Content-ID Header Field
-
-It may be desirable to allow one body to reference another.
-Accordingly, bodies may be labeled using the Content-ID header field,
-which is syntactically identical to the RFC 822 Message-ID header
-field: Content-ID values should be be as unique as possible.
-
-
-Optional Content-Description Header Field
-
-The ability to associate descriptive information with a body is often
-desirable. For example, it may be useful to mark an Image body as
-"a picture of the Space Shuttle Endeavor." Such text may be
-placed in the Content-Description header field.
-
-
-Summary
-
-Using MIME-Version, Content-Type, and Content-Transfer-Encoding header
-fields, it is possible to include arbitrary types of data objects in
-RFC 822 conformant mail messages. No restrictions imposed by RFC 821
-or RFC 822 are violated. MIME has been designed to avoid problems
-caused by additional restrictions imposed by some Internet mail
-transport mechanisms. The Multipart and Message content types allow
-mixing and hierarchical structuring of objects of different types in a
-single message. Further content types provide a mechanism for tagging
-messages or body parts as audio, image, or other kinds of data. A
-parameter syntax allows further specification of data format details,
-particularly the specification of alternate character sets.
-Additional optional header fields provide mechanisms for certain
-extensions deemed desirable by many implementors. Finally, a number
-of useful content types are defined for general use by consenting user
-agents, notably Text/Richtext, Message/Partial, and
-Message/External-Body.
-
-To promote interoperability between user agents, the MIME standard
-specifies a minimal subset of MIME features a user agent must support
-to be considered MIME conformant.
-
-
-A Complex Multipart Example
-
-The outline of a complex multipart message follows. This message has
-five parts to be displayed serially: two introductory plain text
-parts, an embedded multipart message, a richtext part, and a closing
-encapsulated text message in a non-ASCII character set. The embedded
-multipart message has two parts to be displayed in parallel, a picture
-and an audio fragment.
-
- MIME-Version: 1.0
- From: Nathaniel Borenstein <nsb@bellcore.com>
- Subject: A multipart example
- Content-Type: multipart/mixed;
- boundary=unique-boundary-1
-
- This is the preamble area of a multipart message. Mail readers
- that understand multipart format should ignore this preamble.
- If you are reading this text, you might want to consider changing
- to a mail reader that understands how to properly display
- multipart messages.
- --unique-boundary-1
-
- Some text appears here...
- [Note that the preceding blank line means
- no header fields were given and this is text,
- with charset US ASCII. It could have been
- done with explicit typing as in the next part.]
-
- --unique-boundary-1
- Content-type: text/plain; charset=US-ASCII
-
- This could have been part of the previous part, but illustrates
- explicit versus implicit typing of body parts.
-
- --unique-boundary-1
- Content-Type: multipart/parallel; boundary=unique-boundary-2
-
- --unique-boundary-2
- Content-Type: audio/basic
- Content-Transfer-Encoding: base64
-
- ... base64-encoded 8000 Hz single-channel
- u-law-format audio data goes here ...
-
- --unique-boundary-2
- Content-Type: image/gif
- Content-Transfer-Encoding: Base64
-
- ... base64-encoded image data goes here...
-
- --unique-boundary-2--
-
- --unique-boundary-1
- Content-type: text/richtext
-
- This is <bold><italic>richtext.</italic></bold><nl><nl>Isn't it
- <bigger><bigger>cool?</bigger></bigger>
-
- --unique-boundary-1
- Content-Type: message/rfc822
-
- From: (name in US-ASCII)
- Subject: (subject in US-ASCII)
- Content-Type: Text/plain; charset=ISO-8859-1
- Content-Transfer-Encoding: Quoted-printable
-
- ... Additional text in ISO-8859-1 goes here ...
-
- --unique-boundary-1--
-
|