"multipart" content-type, but the "charset" parameter might make
   sense with several content-types.




 
RFC 1521                          MIME                    September 1993


   An initial set of seven Content-Types is defined by this document.
   This set of top-level names is intended to be substantially complete.
   It is expected that additions to the larger set of supported types
   can generally be accomplished by the creation of new subtypes of
   these initial types.  In the future, more top-level types may be
   defined only by an extension to this standard.  If another primary
   type is to be used for any reason, it must be given a name starting
   with "X-" to indicate its non-standard status and to avoid a
   potential conflict with a future official name.

   In the Augmented BNF notation of RFC 822, a Content-Type header field
   value is defined as follows:

     content  :=   "Content-Type"  ":"  type  "/"  subtype  *(";"
     parameter)
               ; case-insensitive matching of type and subtype

     type :=          "application"     / "audio"
               / "image"           / "message"
               / "multipart"  / "text"
               / "video"           / extension-token
               ; All values case-insensitive

     extension-token :=  x-token / iana-token

     iana-token := <a publicly-defined extension token,
               registered with IANA, as specified in
               appendix E>

     x-token := <The two characters "X-" or "x-" followed, with
                 no intervening white space, by any token>

     subtype := token ; case-insensitive

     parameter := attribute "=" value

     attribute := token   ; case-insensitive

     value := token / quoted-string

     token  :=  1*<any (ASCII) CHAR except SPACE, CTLs,
                   or tspecials>

     tspecials :=  "(" / ")" / "<" / ">" / "@"
                /  "," / ";" / ":" / "\" / <">
                /  "/" / "[" / "]" / "?" / "="
               ; Must be in quoted-string,
               ; to use within parameter values




 
RFC 1521                          MIME                    September 1993


   Note that the definition of "tspecials" is the same as the RFC 822
   definition of "specials" with the addition of the three characters
   "/", "?", and "=", and the removal of ".".

   Note also that a subtype specification is MANDATORY.  There are no
   default subtypes.

   The type, subtype, and parameter names are not case sensitive.  For
   example, TEXT, Text, and TeXt are all equivalent.  Parameter values
   are normally case sensitive, but certain parameters are interpreted
   to be case-insensitive, depending on the intended use.  (For example,
   multipart boundaries are case-sensitive, but the "access-type" for
   message/External-body is not case-sensitive.)

   Beyond this syntax, the only constraint on the definition of subtype
   names is the desire that their uses must not conflict.  That is, it
   would be undesirable to have two different communities using
   "Content-Type: application/foobar" to mean two different things.  The
   process of defining new content-subtypes, then, is not intended to be
   a mechanism for imposing restrictions, but simply a mechanism for
   publicizing the usages. There are, therefore, two acceptable
   mechanisms for defining new Content-Type subtypes:

            1.  Private values (starting with "X-") may be
                defined bilaterally between two cooperating
                agents without outside registration or
                standardization.

            2.  New standard values must be documented,
                registered with, and approved by IANA, as
                described in Appendix E.  Where intended for
                public use, the formats they refer to must
                also be defined by a published specification,
                and possibly offered for standardization.