MIME-Version: 1.0

   The presence of this header field is an assertion that the message
   has been composed in compliance with this document.

   Since it is possible that a future document might extend the message
   format standard again, a formal BNF is given for the content of the
   MIME-Version field:

   version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

   Thus, future format specifiers, which might replace or extend "1.0",
   are constrained to be two integer fields, separated by a period.  If
   a message is received with a MIME-version value other than "1.0", it
   cannot be assumed to conform with this specification.

   Note that 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 itself claimed to be
   MIME-conformant.

   It is not possible to fully specify how a mail reader that conforms
   with MIME as defined in this document should treat a message that
   might arrive in the future with some value of MIME-Version other than
   "1.0".  However, conformant software is encouraged to check the
   version number and at least warn the user if an unrecognized MIME-
   version is encountered.

   It is also worth noting that version control for specific content-
   types is not accomplished using the MIME-Version mechanism.  In
   particular, some formats (such as application/postscript) have
   version numbering conventions that are internal to the document
   format.  Where such conventions exist, MIME does nothing to supersede
   them.  Where no such conventions exist, a MIME type might use a
   "version" parameter in the content-type field if necessary.

   NOTE TO IMPLEMENTORS: All header fields defined in this document,
   including MIME-Version, Content-type, etc., are subject to the
   general syntactic rules for header fields specified in RFC 822.  In
   particular, all can include comments, which means that the following
   two MIME-Version fields are equivalent:

                    MIME-Version: 1.0
                    MIME-Version: 1.0 (Generated by GBD-killer 3.7)





 
RFC 1521                          MIME                    September 1993


4.    The Content-Type Header Field

   The purpose of the Content-Type field is to describe the data
   contained in the body fully enough that the receiving user agent can
   pick an appropriate agent or mechanism to present the data to the
   user, or otherwise deal with the data in an appropriate manner.

   HISTORICAL NOTE: The Content-Type header field was first defined in
   RFC 1049.  RFC 1049 Content-types used a simpler and less powerful
   syntax, but one that is largely compatible with the mechanism given
   here.

   The Content-Type header field is used to specify the nature of the
   data in the body of an entity, by giving type and subtype
   identifiers, and by providing auxiliary information that may be
   required for certain types.  After the type and subtype names, the
   remainder of the header field is simply a set of parameters,
   specified in an attribute/value notation.  The set of meaningful
   parameters differs for the different types.  In particular, there are
   NO globally-meaningful parameters that apply to all content-types.
   Global mechanisms are best addressed, in the MIME model, by the
   definition of additional Content-* header fields.  The ordering of
   parameters is not significant.  Among the defined parameters is a
   "charset" parameter by which the character set used in the body may
   be declared. Comments are allowed in accordance with RFC 822 rules
   for structured header fields.

   In general, 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 user agent that the data is an image, even if the user agent has no
   knowledge of the specific image format "xyz".  Such information can
   be used, for example, 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 should be represented using the "multipart" or
   "application" types.

   Parameters are modifiers of the content-subtype, and do not
   fundamentally affect the requirements of the host system.  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 makes sense only for the