3.1. Type Values

   Initially, the type parameter would be limited to the following set
   of values:

   type:=           "POSTSCRIPT"/"SCRIBE"/"SGML"/"TEX"/"TROFF"/
                    "DVI"/"X-"atom

   These values are not case sensitive.  POSTSCRIPT, Postscript, and
   POStscriPT are all equivalent.

   POSTSCRIPT      Indicates the enclosed document consists of
                   information encoded using the Postscript Page
                   Definition Language developed by Adobe Systems,
                   Inc. [1]

   SCRIBE          Indicates the document contains embedded formatting
                   information according to the syntax used by the
                   Scribe document formatting language distributed by
                   the Unilogic Corporation. [6]

   SGML            Indicates the document contains structuring
                   information to according the rules specified for
                   the Standard Generalized Markup Language, IS 8879,
                   as published by the International Organization for
                   Standardization. [3] Documents structured according
                   to the ISO DIS 8613--Office Docment Architecture and
                   Interchange Format--may also be encoded using SGML
                   syntax.

   TEX             Indicates the document contains embedded formatting
                   information according to the syntax of the TEX
                   document production language. [4]

   TROFF           Indicates the document contains embedded formatting
                   information according to the syntax specified for the
                   TROFF formatting package developed by AT&T Bell
                   Laboratories. [5]

   DVI             Indicates the document contains information according
                   to the device independent file format produced by
                   TROFF or TEX.

   "X-"atom        Any type value beginning with the characters "X-" is
                   a private value.

3.2. Version Number

   Since standard structuring techniques in fact evolve over time, we
   leave room for specifying a version number for the content type.
   Valid values will depend upon the type parameter.

   ver-num:=      local-part

     In particular, we have the following valid values:

     For type=POSTSCRIPT

   ver-num:= "1.0"/"2.0"/"null"

     For type=SCRIBE

   ver-num:= "3"/"4"/"5"/"null"

     For type=SGML

   ver-num:="IS.8879.1986"/"null"

3.3. Resource Reference

   resource-ref:=  local-part

   As Apple has demonstrated with their implementation of the
   Laserwriter, a very general document structuring technique can be
   made more efficient by defining a set of macros or other similar
   resources to be used in interpreting any transmitted stream.  The
   Macintosh transmits a LaserPrep file to the Laserwriter containing
   font and macro definitions which can be called upon by subsequent
   documents.  The result is that documents as sent to the Laserwriter
   are considerably more compact than if they had to include the
   LaserPrep file each time.  The Resource Reference parameter allows
   specification of a well known resource, such as a LaserPrep file,
   which should be used by the receiving system when processing the
   message.

   Resource references could also include macro packages for use with
   TEX or references to preprocessors such as eqn and tbl for use with
   troff.  Allowed values will vary according to the type parameter.

     In particular, we propose the following values:

     For type = POSTSCRIPT

   resource-ref:=  "laserprep2.9"/"laserprep3.0"/"laserprep3.1"/
                   "laserprep4.0"/local-part

     For type = TROFF

   resource-ref:=  "eqn"/"tbl"/"me"/local-part

3.4. Comment

   The comment field can be any additional comment text the user
   desires.  Comments are enclosed in parentheses as specified in
   RFC-822.

5.1. Syntax of the Content-Type Header Field

5.1. Content-Type 頭領域の構文

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

RFC 822 の拡張 BNF 記法により、 Content-Type 頭領域値は 次のように定義します。

     content := "Content-Type" ":" type "/" subtype
                *(";" parameter)
                ; Matching of media type and subtype
                ; is ALWAYS case-insensitive.

; 媒体型及び亜型の照合は常に大文字・小文字を区別しません。

     type := discrete-type / composite-type

     discrete-type := "text" / "image" / "audio" / "video" /
                      "application" / extension-token

     composite-type := "message" / "multipart" / extension-token

     extension-token := ietf-token / x-token

     ietf-token := <An extension token defined by a
                    standards-track RFC and registered
                    with IANA.>

; <標準化過程 RFC で定義され、 IANA に登録された拡張 token>

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

; <2文字「X-」または「x-」に、空白間隔を挟まずに続く token>

     subtype := extension-token / iana-token

     iana-token := <A publicly-defined extension token. Tokens
                    of this form must be registered with IANA
                    as specified in RFC 2048.>

; <公式に定義された拡張 token。この形式の token は RFC 2048 で規定された 通りに IANA に登録されなければならない。>

     parameter := attribute "=" value

     attribute := token
                  ; Matching of attributes
                  ; is ALWAYS case-insensitive.

; 属性の照合は常に大文字・小文字を区別しない。

     value := token / quoted-string

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

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

; parameter value 内で使うには常に quoted-string 内でなければならない

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

なお、「tspecials」の定義は RFC 822 の「specials」定義から 3文字 "/", "?", "=" を加えて「.」を除いたものです。

Note also that a subtype specification is MANDATORY -- it may not be omitted from a Content-Type header field. As such, there are no default subtypes.

また、 subtype 指定は絶対必要です。 Content-Type 頭領域から 省略してはいけません。ですから、規定の亜型はありません。

The type, subtype, and parameter names are not case sensitive. For example, TEXT, Text, and TeXt are all equivalent top-level media types. Parameter values are normally case sensitive, but sometimes are interpreted in a case-insensitive fashion, depending on the intended use. (For example, multipart boundaries are case-sensitive, but the "access-type" parameter for message/External-body is not case-sensitive.)

type, subtype, parameter 名は大文字・小文字を区別しません。 例えば、 TEXT, Text, TeXt は全て同じ上位媒体型です。 parameter 値は一般に大文字・小文字を区別しますが、 その用途により区別せずに解釈されることもあります。 (例えば、 multipart 区切りは大文字・小文字を区別しますが、 message/External-body の「access-type」 parameter は 区別しません。)

Note that the value of a quoted string parameter does not include the quotes. That is, the quotation marks in a quoted-string are not a part of the value of the parameter, but are merely used to delimit that parameter value. In addition, comments are allowed in accordance with RFC 822 rules for structured header fields. Thus the following two forms

なお、引用符で囲まれた文字列の parameter の値は引用符を含みません。 これは、 quoted-string の引用符は parameter の value の一部ではなく、 単に parameter value の区切りとして使われているということです。 更に、 RFC 822 の構造化頭領域の規則に則り注釈を入れることが出来ます。 従って次の2例は完全に同等です。

     Content-type: text/plain; charset=us-ascii (Plain text)

     Content-type: text/plain; charset="us-ascii"

are completely equivalent.

Beyond this syntax, the only syntactic 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 media subtypes, then, is not intended to be a mechanism for imposing restrictions, but simply a mechanism for publicizing their definition and usage. There are, therefore, two acceptable mechanisms for defining new media subtypes:

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

    (2)   New standard values should be registered with IANA as
          described in RFC 2048.

   The second document in this set, RFC 2046, defines the initial set of
   media types for MIME.

5.2. Content-Type Defaults Content-Type 既定値

Default RFC 822 messages without a MIME Content-Type header are taken by this protocol to be plain text in the US-ASCII character set, which can be explicitly specified as:

MIME CT 頭がない既定の RFC 822 メッセージはこのプロトコルでは US-ASCII 文字集合の平文とみなされ、陽に示すと次のようになります。

Content-type: text/plain; charset=us-ascii

This default is assumed if no Content-Type header field is specified. It is also recommend that this default be assumed when a syntactically invalid Content-Type header field is encountered. In the presence of a MIME-Version header field and the absence of any Content-Type header field, a receiving User Agent can also assume that plain US-ASCII text was the sender's intent. Plain US-ASCII text may still be assumed in the absence of a MIME-Version or the presence of an syntactically invalid Content-Type header field, but the sender's intent might have been otherwise.

この既定値は CT 頭欄が指定されていない時に仮定されます。構文的に不正な CT 頭欄が現れた時にもこの既定値を仮定することを推奨します。 MIME-Version 頭欄があって CT 頭欄がない時は、受信した利用者エージェントは US-ASCII の平文が送信者の意図であるとも仮定出来ます。 MIME-Version 頭欄がないか構文的に不正な CT 頭欄があるときにも US-ASCII の平文を依然仮定して構いませんが、送信者の意図は違ったかもしれません。