rfc1341.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

            The term "message", when not further qualified, means either
            the (complete or "top-level") message being transferred on a
            network, or  a  message  encapsulated  in  a  body  of  type
            "message".

            The term "body part", in this document,  means  one  of  the
            parts  of  the body of a multipart entity. A body part has a
            header and a body, so it makes sense to speak about the body
            of a body part.

            The term "entity", in this document, means either a  message
            or  a  body  part.  All kinds of entities share the property
            that they have a header and a body.

            The term "body", when not further qualified, means the  body
            of  an  entity, that is the body of either a message or of a
            body part.

            Note : the previous four definitions are  clearly  circular.
            This  is  unavoidable,  since the overal structure of a MIME
            message is indeed recursive.

            In this document, all numeric and octet values are given  in
            decimal notation.

            It must be noted that  Content-Type  values,  subtypes,  and
            parameter  names  as  defined  in  this  document  are case-
            insensitive.  However, parameter values  are  case-sensitive
            unless otherwise specified for the specific parameter.

            FORMATTING NOTE:  This document has been carefully formatted
            for   ease  of  reading.  The  PostScript  version  of  this
            document, in particular, places notes like this  one,  which
            may  be  skipped  by  the  reader, in a smaller, italicized,
            font, and indents it as well.  In the text version, only the
            indentation  is  preserved,  so  if you are reading the text
            version of this you  might  consider  using  the  PostScript
            version  instead.  However,  all such notes will be indented
            and preceded by "NOTE:" or some similar  introduction,  even
            in the text version.

            The primary purpose  of  these  non-essential  notes  is  to
            convey  information about the rationale of this document, or
            to  place  this  document  in  the  proper   historical   or
            evolutionary  context.   Such  information may be skipped by
            those who are  focused  entirely  on  building  a  compliant
            implementation,  but  may  be  of  use  to those who wish to
            understand why this document is written as it is.

            For ease of  recognition,  all  BNF  definitions  have  been
            placed  in  a  fixed-width font in the PostScript version of
            this document.



            Borenstein & Freed                                  [Page 4]




            RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992


            3    The MIME-Version Header Field

            Since RFC 822 was published in 1982, there has  really  been
            only  one  format  standard for Internet messages, and there
            has  been  little  perceived  need  to  declare  the  format
            standard  in  use.  This document is an independent document
            that complements RFC 822. Although the  extensions  in  this
            document have been defined in such a way as to be compatible
            with RFC 822, there are  still  circumstances  in  which  it
            might  be  desirable  for  a  mail-processing  agent to know
            whether a message was composed  with  the  new  standard  in
            mind.

            Therefore, this document defines a new header field,  "MIME-
            Version",  which is to be used to declare the version of the
            Internet message body format standard in use.

            Messages composed in  accordance  with  this  document  MUST
            include  such  a  header  field, with the following verbatim
            text:

            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:

            MIME-Version := text

            Thus, future  format  specifiers,  which  might  replace  or
            extend  "1.0", are (minimally) constrained by the definition
            of "text", which appears in RFC 822.

            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-compliant.
















            Borenstein & Freed                                  [Page 5]




            RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992


            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.   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 "multipart" content-type,
            but the "charset" parameter might make  sense  with  several
            content-types.

            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



            Borenstein & Freed                                  [Page 6]




            RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992


            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 Extended BNF notation  of  RFC  822,  a  Content-Type
            header field value is defined as follows:

            Content-Type := type "/" subtype *[";" parameter]

            type :=          "application"     / "audio"
                      / "image"           / "message"
                      / "multipart"  / "text"
                      / "video"           / x-token

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

            subtype := token

            parameter := attribute "=" value

            attribute := token

            value := token / quoted-string

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

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

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

            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



            Borenstein & Freed                                  [Page 7]




            RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992


            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