JIS X 5810-1:2008 多目的インターネットメール拡張(ＭＩＭＥ)―第１部：インターネットメッセージ本体のフォーマット | ページ 2

4
X 5810-1 : 2008
の拡張BNF記法を用いて形式的にも記述される。実装者は,JIS X 5810規格群を理解するために,この記
法に親しむ必要がある(拡張BNF記法の完全な説明は,RFC 822にある。)。
  JIS X 5810規格群における拡張BNFの幾つかは,RFC 822で定義される構文規則へ名前付きで参照され
ている。そのため,完全な形式文法は,MIMEを規定する規格の文法一覧の附属書と,RFC 822の拡張BNF
及びRFC 1123で定義されるRFC 822の修正(具体的には,“return”,“date”及び“mailbox”の構文の変更)
とを組み合わせることによって得られる。
  JIS X 5810規格群では,すべての数値及びオクテット値は,10進記法で与えられる。JIS X 5810規格群
が定義する,すべてのメディア型値,メディア下位型値及びパラメタ名は,大文字・小文字を区別しない。
しかし,パラメタ値は,特定のパラメタで特に指定される場合を除いて,大文字・小文字を区別する。
     注記 本質的な事項を失うことなく読み飛ばしてもよい,追加の非本質的な情報は,このような注記
           として提供する。これらの非本質的な注記の主な目的は,JIS X 5810規格群の理論的根拠につ
           いての情報を与えること,又はJIS X 5810規格群を適切な歴史的又は発展的な文脈に位置付け
           ることである。この情報は,とりわけ,適合した実装を構築することだけに注目している人々
           は読み飛ばしてもよいが,特定の設計上の選択がなぜなされたかを理解したい人々には有用な
           ことがある。
2.1
CRLF(復帰改行)
  用語“CRLF”は,JIS X 5810規格群では,CR(10進の値が13)及びLF(10進の値が10)の二つの
US-ASCII文字に対応し,この順番で一緒に用いられ,RFC 822メールでは行区切りを示している,オクテ
ット列とする。
2.2
文字集合,character set
  用語“文字集合”は,MIMEでは,オクテット列を文字列に変換する方法とする。無条件であいまい性
のない逆方向への変換は要求されないことに注意する。すなわち,一つの与えられた文字集合において,
それで表現できない文字があってもよいし,二つ以上のオクテット列が,同じ文字列を表現していてもよ
い。
  この定義は,US-ASCIIなどの単純な単一の表による対応付けから,JIS X 0202の技法を使う複雑な表切
換え方法まで,多くの種類の文字符号化を,文字集合として使用するために許すことが意図されている。
しかし,MIME文字集合の名前に関連する定義は,実行される対応付けを完全に規定しなければならない。
特に,正確な対応付けを決定する外部プロファイル情報を用いてはならない。
    注記 用語“文字集合”は,元来は,1オクテットから1文字への単純な1対1写像(対応付け)を
          もつ,US-ASCII及びISO-8859-1といった単純な方式を記述するものであった。複数オクテッ
          ト符号化文字集合及び切換え技法は,状況をより複雑にしている。例えば,ある人々は,MIME
          でいうところの“文字集合( character set )”に対して,“文字符号化( character encoding )”という
          用語を使う一方,オクテットではない整数から文字への抽象的な対応付けを表すのに語句“符
          号化文字集合( coded character set )”を使う。
2.3
メッセージ,message
  用語“メッセージ”は,何も修飾句が付かない場合には,ネットワークに転送される(完全又は最上位
の)RFC 822メッセージを意味するか,又は“message/rfc822”若しくは“message/partial”の型で本体にカプセ

――――― [JIS X 5810-1 pdf 6] ―――――

                                                                                              5
                                                                                 X 5810-1 : 2008
ル化されたメッセージを意味する。
2.4
実体,entity
  用語“実体”は,特に,MIMEで定義されたヘッダフィールド及び内容とする。ここで,内容とは,メ
ッセージか,又はマルチパート実体の本体における複数の部分の一つか,それらのいずれかとする。これ
ら実体の規定が,MIMEの本質になっている。実体の内容は“本体”と呼ばれることが多いので,実体の
本体について語ることは意味がある。実体のヘッダには,どのような種類のフィールドも存在してよいが,
実際には,“content-”で始まるフィールドだけがMIMEに関係する意味をもつ。このことは,“content-”で
始まらないフィールドが全く意味をもたないことを意味する訳ではない。RFC 822で意味が定義されてい
る非MIMEヘッダフィールドをもつメッセージも実体である。
2.5
本体部分 ( body part )
  用語“本体部分”は,マルチパート実体の内部の実体とする。
2.6
本体,body
  用語“本体”は,更に限定されない場合には,実体の本体の意味とする。すなわち,メッセージ又は本
体部分の本体とする。
     注記 2.32.6の四つの定義は,明らかに循環的である。MIMEメッセージ全体の構造は実際に再帰
           的なので,このことは避けられない。
2.7
7 bitデータ ( 7 bit data )
  “7 bitデータ”は,CRLF行分離シーケンスの間の,998オクテット以下の相対的に短い行として表現
されるデータとする[RFC 821]。10進の値が127より大きいオクテットがあってはならず,NUL(10進の
値が0のオクテット)があってはならない。CR(10進の値が13)及びLF(10進の値が10)は,CRLF
行分離シーケンスの一部としてだけ現れる。
2.8
8 bitデータ ( 8 bit data )
  “8 bitデータ”は,CRLF行分離シーケンスの間の,998オクテット以下の相対的に短い行として表現
されるデータとする[RFC 821]。10進の値が127より大きいオクテットを用いてもよい。7 bitデータと同
様に,NULがあってはならず,CR(10進の値が13)及びLF(10進の値が10)は,CRLF行分離シーケ
ンスとしてだけ現れる。
2.9
binaryデータ ( binary data )
  “binaryデータ”は,どのようなオクテットの列も含むことができるデータとする。
2.10
行 ( lines )
  “行”は,CRLFシーケンスによって分離された,オクテットの列として定義される。この定義は,RFC
821及びRFC 822の両方と整合している。“行”は,メッセージの中のデータの単位としてだけ参照され,
UAが実際に表示するものと対応していてもよいし,対応していなくてもよい。

――――― [JIS X 5810-1 pdf 7] ―――――

6
X 5810-1 : 2008

3 MIMEヘッダフィールド

  MIMEは,MIME実体の内容を記述するために使用される多くの新しいRFC 822ヘッダフィールドを定
義する。これらのヘッダフィールドは,少なくとも次の二つの文脈で出現する。
a) 通常のRFC 822メッセージヘッダの一部として
b) マルチパート構成内のMIME本体部分ヘッダの中で
  これらのヘッダフィールドの形式定義は,次のとおりとする。
         entity-headers := [ content CRLF ]
                  [ encoding CRLF ]
                  [ id CRLF ]
                  [ description CRLF ]
                  *( MIME-extension-field CRLF )
         MIME-message-headers := entity-headers
                  fields
                  version CRLF
                  ; この拡張BNF定義が含むヘッダフィールドの順序付けは,
                  ; 無視するほうがよい。
         MIME-part-headers := entity-headers
                  [ fields ]
                  ; “content-”で始まらないすべてのフィールドは,
                  ; 定義された意味をもつことはできず,無視してよい。
                  ; この拡張BNF定義が含むヘッダフィールドの順序付けは,
                  ; 無視するほうがよい。
  種々の特定のMIMEヘッダフィールドの構文は,箇条4以降に示す。

4 MIME-Version(MIME版)ヘッダフィールド

  1982年にRFC 822が公開されて以来,それがインターネットメッセージのフォーマット規定として唯一
のものであり,使われているフォーマットの規定を宣言する必要性はほとんど認知されていなかった。こ
の規格は,RFC 822を補完する独立の規定とする。この規格で,拡張は,RFC 822と互換性のある方法で
定義されてはいるが,そうであっても,新しい規定を用いてメッセージが作成されたかどうかを,メール
処理エージェントが知っていることが望ましいかもしれない状況が存在する。
  そのために,この規格は,使われているインターネットメッセージ本体のフォーマット規定の版を宣言
するために使用する,新しいヘッダフィールド“MIME-Version”を定義する。
  この規格に従って作成されるメッセージは,このヘッダフィールドを,次のテキストでそのまま,含ま
なければならない。
         MIME-Version: 1.0
  このヘッダフィールドがあることは,メッセージがこの規格に従って作成されていることを明言してい
る。
  将来の規格がメッセージフォーマットの規定を再び拡張するかもしれないことを可能とするので,

――――― [JIS X 5810-1 pdf 8] ―――――

                                                                                              7
                                                                                 X 5810-1 : 2008
MIME-Versionヘッダフィールドの内容のための形式拡張BNFは,次による。
         version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
  そこで,“1.0”を置き換える又は拡張するかもしれない,将来のフォーマット指定子は,ピリオドで分離
された二つの整数フィールドに制限される。“MIME-Version”の値が“1.0”以外のメッセージを受け取る場合,
この規格に適合するとみなすことはできない。
  MIME-Versionヘッダフィールドは,メッセージの最上位にあることが要求されることに注意する。マル
チパート実体のそれぞれの本体部分には要求されない。“message/rfc822”型又は“message/partial”型の本体に
組み込まれたヘッダに対しては,組み込まれたメッセージそれ自体がMIME適合になっていると主張され
る場合に限り,要求される。
  この規格で定義されるとおりにMIMEと適合するメールリーダが,将来到着するかもしれない“1.0”以外
のMIME-Versionの値をもつメッセージをどう扱うのがよいかを,完全に規定することは可能ではない。
  特定のメディア型の版管理は,MIME-Version機構を使っては,達成されないことに注意する。特に,
application/postscriptといった幾つかのフォーマットは,メディアフォーマット内部に版番号付け規約をも
つ。これら規約が存在する場合には,MIMEはそれにとって代わることはしない。これら規約が存在しな
い場合には,必要があれば,MIMEメディア型は,内容型フィールドの中で“version”パラメタを使うかも
しれない。
     注記 MIME-Versionの値を検査するとき,RFC 822注釈文字列がある場合には,それらを無視する。
           特に,次の四つのMIME-Versionヘッダフィールドは等価とする。
              MIME-Version: 1.0
              MIME-Version: 1.0 (produced by MetaSend Vx.x)
              MIME-Version: (produced by MetaSend Vx.x) 1.0
              MIME-Version: 1.(produced by MetaSend Vx.x)0
  MIME-Versionヘッダフィールドがなかった場合,受信側のメールUAは,MIME要件に適合していても
していなくても,局所的な規約に基づき,メッセージの本体を解釈することを選んでよい。多くのこれら
規約は現在使われており,実際には非MIMEメッセージが,ほとんど何でも含むことができることに注意
したほうがよい。
  非MIMEメールメッセージが,実際にUS-ASCII文字集合を用いたプレーンテキストであるかは,確実
ではない。これは,MIME以前の非標準の局所的な規約の集合を使って,他の文字集合を用いたテキスト,
又は例えば圧縮( compress )されてuuencodeされたUNIX tarファイルなどの,自動的には認識できない方
法によって表現されたテキストでないデータを含むメッセージであるかもしれないことによる。

5 Content-Type(内容型)ヘッダフィールド

  Content-Typeフィールドは,受信側のUAが,利用者にデータを表示するために,適切なエージェント
若しくは機構を選ぶこと,又は適切な方法でデータを扱うことができるほど十分に,本体に含まれるデー
タを記述することを目的としている。このフィールドに含まれる値は,メディア型と呼ばれる。
     注記 Content-Typeヘッダフィールドは,最初,RFC 1049で定義された。RFC 1049では,より単純
           で強力ではない構文を使っていたが,その多くは,この規格(及び原規定のRFC 2045)で与え
           る機構と大部分は互換性がある。
  Content-Typeヘッダフィールドは,メディア型及びメディア下位型の識別子を与えること,及びある種
のメディア型が要求することのある補助情報を提供することによって,実体の本体中のデータの性質を指

――――― [JIS X 5810-1 pdf 9] ―――――

8
X 5810-1 : 2008
定する。メディア型及びメディア下位型の名前の後の,ヘッダフィールドの残りは,単に,“属性=値”の記
法で指定されたパラメタの集合とする。パラメタの順番は意味をもたない。
  一般に,最上位のメディア型は,データの一般的な型を指定し,メディア下位型は,そのデータの型に
対する特定のフォーマットを指定する。そこで,メディア型“image/xyz”は,UAが“xyz”という特定の画像
フォーマットを知らなかったとしても,データが画像であることを知らせるのに十分である。このような
情報は,例えば,認識されないメディア下位型からの生データを利用者に見せるかどうかを決定するため
に利用できる。テキストの場合には,認識されないメディア下位型の生データを利用者に見せるのが妥当
であっても,画像又は音声の場合には妥当でないことがあるので,最上位のメディア型を使うことが必要
となる。このように,認識されないメディア下位型の処理の問題があるので,テキスト,画像,音声及び
映像の登録されたメディア下位型は,より下位において認識できない型への分化を生むような組込み情報
を含まないほうがよい。これら複合フォーマットは,“multipart”型又は“application”型を用いて表したほう
がよい。
  パラメタは,メディア下位型の修飾子であって,内容の性質には,基本的には影響しない。意味のある
パラメタの集合は,メディア型及びメディア下位型に依存する。ほとんどのパラメタは,単一の特定のメ
ディア下位型に関連する。ただし,与えられた最上位のメディア型が,その型のどのメディア下位型へも
適用可能なパラメタを定義してもよい。内容型又はメディア下位型の定義によって,パラメタは必す(須)
であってもよいし,オプションであってもよい。MIME実装は,認識しない名前のパラメタを無視しなけ
ればならない。
  例えば,“charset”パラメタは,“text”のあらゆるメディア下位型に適用でき,“boundary”パラメタは,
“multipart”メディア型のあらゆるメディア下位型に要求される。
  すべてのメディア型に適用される大域的に意味のあるパラメタは存在しない。真に大域的な機構は,
MIMEモデルでは,付加的なContent-*ヘッダフィールドの定義によって,最もよく言及される。
  七つの最上位メディア型の初期集合は,JIS X 5810-2で定義される。そのうち五つは,MIME処理が関
係する限りにおいては,本質的に不透明な内容をもつ別々の型とする。残りの二つは,MIME処理系によ
って追加の処理が必要な内容の複合型とする。
  最上位メディア型のこの集合は,実質的に,完全となることを意図している。一般に,サポートされる
型のより大きな集合への追加は,これら初期の型の新しいメディア下位型を作ることによって,達成され
る。将来,この規格への標準化手続の拡張によってだけ,より多くの最上位の型を定義してよい。何らか
の理由によって他の最上位型を使うことが望ましい場合,非標準の状況を示すため,及び将来の公式の名
前と衝突する可能性を避けるために,その型には,“X-”で開始する名前を与えなければならない。

5.1 Content-Typeヘッダフィールドの構文

  Content-Typeヘッダフィールドの値は,RFC 822の拡張BNF記法を用いて,次のとおりに定義される。
         content := "Content-Type" ":" type "/" subtype
                  *(";" parameter)
                  ; メディア型及びメディア下位型の合致は,
                  ; 常に大文字・小文字を区別しない。
         type := discrete-type / composite-type
         discrete-type := "text" / "image" / "audio" / "video" /

――――― [JIS X 5810-1 pdf 10] ―――――

次のページ PDF 11