2. Notations, Conventions, and Generic BNF Grammar

   This document is being published in two versions, one as plain ASCII
   text and one as PostScript (PostScript is a trademark of Adobe
   Systems Incorporated.).  While the text version is the official
   specification, some will find the PostScript version easier to read.
   The textual contents are identical.  An Andrew-format copy of this
   document is also available from the first author (Borenstein).

   Although the mechanisms specified in this document are all described
   in prose, most are also described formally in the modified BNF
   notation of RFC 822std11(-> 2822prop).  Implementors will need to be familiar with this
   notation in order to understand this specification, and are referred
   to RFC 822std11(-> 2822prop) for a complete explanation of the modified BNF notation.

   Some of the modified BNF in this document makes reference to
   syntactic entities that are defined in RFC 822std11(-> 2822prop) and not in this
   document.  A complete formal grammar, then, is obtained by combining
   the collected grammar appendix of this document with that of RFC 822std11(-> 2822prop)
   plus the modifications to RFC 822std11(-> 2822prop) defined in RFC 1123std3, which
   specifically changes the syntax for `return', `date' and `mailbox'.

   The term CRLF, in this document, refers to the sequence of the two
   ASCII characters CR (13) and LF (10) which, taken together, in this
   order, denote a line break in RFC 822std11(-> 2822prop) mail.

   The term "character set" is used in this document to refer to a
   method used with one or more tables to convert encoded text to a
   series of octets.  This definition is intended to allow various kinds
   of text encodings, from simple single-table mappings such as ASCII to
   complex table switching methods such as those that use ISO 2022's
   techniques.  However, a MIME character set name must fully specify
   the mapping to be performed.

   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 overall 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 conformant 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.