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 822. Implementors will need to be familiar with this notation in order to understand this specification, and are referred to RFC 822 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 822 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 822 plus the modifications to RFC 822 defined in RFC 1123, 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 822 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.