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

                                                                                              9
                                                                                 X 5810-1 : 2008
                  "application" / extension-token
         composite-type := "message" / "multipart" / extension-token
         extension-token := ietf-token / x-token
         ietf-token := <標準化手続のRFCによって定義され,IANAで登録された拡張トークン>
         x-token := <“X-”又は“x-”の2文字で始まり,空白を含まない,任意のトークン。>
         subtype := extension-token / iana-token
         iana-token := <公式に定義された拡張トークン。
                  この形式のトークンは,RFC 2048で規定されるとおりに
                  IANAに登録されなければならない。>
         parameter := attribute "=" value
         attribute := token
                  ; 属性の合致は,
                  ; 常に大文字・小文字を区別しない。
         value := token / quoted-string
         token := 1*<SPACE,CTL,tspecialsを除く,任意の(US-ASCII)   HAR>
         tspecials := "(" / ")" / "<" / ">" / "@" /
                  "," / ";" / ":" / "\" / <">
                  "/" / "[" / "]" / "・" / "="
                  ; パラメタ値内で使うため,
                  ; quoted-stringでなければならない。
  tspecialsの定義は,“/”,“・”及び“=”の3文字を追加したこと,並びに“.”を削除したこと以外は,RFC 822
のspecialの定義と同じであることに注意する。
  メディア下位型の指定は必す(須)であることにも注意する。すなわち,メディア下位型の指定は,
Content-Typeヘッダフィールドから省いてはならない。このように,デフォルトのメディア下位型は存在
しない。
  メディア型名,メディア下位型名及びパラメタ名は,大文字・小文字を区別しない。例えば,TEXT,
Text及びTeXtは,等価な最上位のメディア型とする。パラメタ値は,通常,大文字・小文字を区別するが,
意図される使用によっては,大文字・小文字を区別しないように解釈されることがある。例えば,マルチ
パート境界は大文字・小文字を区別するが,message/External-bodyの“access-type”パラメタは大文字・小文

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

10
X 5810-1 : 2008
字を区別しない。
  引用文字列( quoted-string )パラメタの値は引用符を含まないことに注意する。すなわち,quoted-stringの
中の引用符はパラメタ値の一部ではなく,単にパラメタ値を区切るのに使われる。さらに,構造化ヘッダ
フィールドに関するRFC 822規則に従う注釈は許される。そこで,次の二つの形式は完全に等価とする。
         Content-type: text/plain; charset=us-ascii (Plain text)
         Content-type: text/plain; charset="us-ascii"
  この構文以外の,メディア下位型名の定義における構文上の唯一の制約は,それらの使用は重複しては
ならないという要求とする。すなわち,二つの異なる意味の“Content-Type: application/foobar”を使う,二つ
の異なるコミュニティがあることは望ましくない。そこで,新しいメディア下位型を定義する過程は,制
限を課すための機構を意図しているのでなく,単純にそれらの定義及び使い方を公にする機構とする。そ
のために,新しいメディア下位型を定義するための受入可能な次の二つの機構が存在する。
a) “X-”で始まる私的な値は,外部での登録又は標準化なしに二つの協力的エージェントの間で双方で(合
    意して)定義してよい。これらの値は,登録又は標準化することはできない。
b) 新しい標準の値は,RFC 2048に記述されるとおりにIANAに登録することが望ましい。
  MIMEを規定する2番目の規格( JIS X 5810-2 )では,MIMEのメディア型の初期集合を定義する。

5.2 Content-Typeデフォルト

  MIMEのContent-TypeヘッダなしのデフォルトのRFC 822メッセージは,このプロトコルによって,
US-ASCII文字集合によるプレーンテキストとされ,明示的に次のとおりに指定できる。
         Content-type: text/plain; charset=us-ascii
  このデフォルトは,Content-Typeヘッダフィールドが指定されなかった場合を想定している。構文的に
有効でないContent-Typeヘッダフィールドに遭遇したときにも,このデフォルトを想定することが望まし
い。MIME-Versionヘッダフィールドが存在し,Content-Typeヘッダフィールドが存在しない場合,受信側
のUAは,プレーンUS-ASCIIテキストが送信者の意図であったと想定することもできる。MIME-Version
が存在しない,又は構文上有効でないContent-Typeヘッダフィールドが存在する場合であって,送信者の
意図によらず,プレーンUS-ASCIIテキストを想定してもよい。

6 Content-Transfer-Encoding(内容転送符号化)ヘッダフィールド

  電子メールによって便利に転送できる多くのメディア型は,8 bit文字又はbinaryデータとして,“自然
な”フォーマットで表現される。これらのデータは,幾つかの転送プロトコルでは転送することができな
い。例えば,RFC 821 ( SMTP ) は,メールメッセージを,末尾のCRLF行分離子を含む1 000文字以下の
行をもった7 bitUS-ASCIIデータに制限する。
  したがって,これらデータを7 bitの短い行のフォーマットに符号化する標準的な機構を定義する必要が
ある。制限の少ないトランスポート上での直接使用のために,制限の少ないフォーマットの中での符号化
されていないデータを適切にラベル付けすることも望まれる。この規格は,これら符号化が新しい
“Content-Transfer-Encoding”ヘッダフィールドによって指示されることを規定する。このフィールドは,今
までのいかなる規定によっても定義されていない。

6.1 Content-Transfer-Encoding構文

  Content-Transfer-Encodingフィールド値は,次に列挙されるとおり,符号化の型を指定する単一トークン
とする。形式文法は次による。
         encoding := "Content-Transfer-Encoding" ":" mechanism

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

                                                                                             11
                                                                                 X 5810-1 : 2008
         mechanism := "7bit" / "8bit" / "binary" /
                  "quoted-printable" / "base64" /
                  ietf-token / x-token
  これらの値は大文字・小文字を区別しない。Base64,BASE64及びbAsE64はすべて等価とする。7 bit
の符号化型は,本体が既に7 bitメールに使える表現であることを要求する。これは,デフォルト値とする。
すなわち,Content-Transfer-Encodingフィールドがない場合は,“Content-Transfer-Encoding: 7bit”が仮定され
る。

6.2 Content-Transfer-Encodingセマンティクス

  この単一のContent-Transfer-Encodingトークンは,実際には,二つの情報を提供する。これは,本体がど
んな種類の符号化変換に従っているか(そのために,それを元の形式に戻すためにどの復号操作を使わな
ければならないか)及び結果の領域が何になるかを指定する。
  Content-Transfer-Encodingの提供する二つの情報のうちの変換に関する部分は,単一の明確に定義された
復号アルゴリズムを,明示的に又は暗黙的に,指定する。このアルゴリズムは,符号化されたオクテット
のすべての列に対して,符号化される前の元のオクテット列に変換するか,又は符号化列として不正であ
ることを示すかのいずれかを行う。Content-Transfer-Encodingは,適切な操作のために追加される外部プロ
ファイル情報に依存することはない。復号器は,有効な符号化に対して,単一の明確に定義された出力を
生成しなければならないが,符号化器にはこのような制限はないことに注意する。すなわち,与えられた
同じオクテット列を,場合によって異なる等価な符号化列へと符号化することは完全に正しい。
  同一(符号化変換),“quoted-printable”(印字可能引用)符号化及び“base64”符号化の三つの変換が,現
在定義されている。その(変換)領域は,“binary”,“8 bit”及び“7 bit”とする。
  Content-Transfer-Encoding値の“7 bit”,“8 bit”及び“binary”は,すべて同一符号化変換がなされること,す
なわち,いかなる符号化変換もなされないことを意味する。このように,それらは単に本体データの領域
の指示子として役に立ち,与えられたトランスポートシステムにおいて転送のために必要かもしれない符
号化の種類についての有用な情報を提供する。用語“7 bitデータ”,“8 bitデータ”及び“binaryデータ”
は,すべて箇条2で定義されている。
  quoted-printable符号化及びbase64符号化は,任意の領域からの入力を“7 bit”範囲のデータへと変換する
ので,制限のあるトランスポートシステムで運ぶことを安全にする。変換の特定の定義は,後に示す。
  正しいContent-Transfer-Encodingラベルが常に使われなければならない。8 bit文字を含む符号化されて
いないデータを“7 bit”とラベル付けしてはならず,行に基づかない符号化されていないデータを“binary”以
外にラベル付けしてはならない。
  メディア下位型と違って,Content-Transfer-Encoding値の増加は望ましくないし不必要でもある。しかし,
“7 bit”領域への単一の変換だけを制定する訳にはいかない。多くのbinaryデータの小規模で効率的な符号
化に対する要望と,ほとんどが7 bitだがすべてではないデータのある程度可読性のある符号化に対する要
望との間にはトレードオフが存在する。この理由によって,少なくとも二つの符号化機構,すなわち,多
かれ少なかれ可読性のある符号化(quoted-printable)及び“密な”又は“一様な”符号化( base64 )が,必要で
あった。
  符号化されていない8 bitデータのメールトランスポートは,RFC 1652で定義されている。この規格の
原規定の初期の公開のときには,メール本体に符号化されていないbinaryデータを含めるのに適正な,標
準化されたインターネットメールトランスポートは存在しなかった。そこで,インターネットメールにお

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

12
X 5810-1 : 2008
いて“binary”Content-Transfer-Encodingが実際に有効である状況は存在しなかった。しかし,binaryメールト
ランスポートがインターネットメールで現実のものとなるか,又はMIMEが他のbinary可能なメールトラ
ンスポート機構と一緒に使われる場合には,binaryの本体は,この機構を使うものとしてラベル付けされ
なければならない。
    注記 Content-Transfer-Encodingフィールドのために定義される五つの値は,そのフィールドが符号化
          されたアルゴリズム,又は符号化されない場合にはトランスポートシステム要件以外は,メデ
          ィア型について何も示唆しない。

6.3 新しいContent-Transfer-Encoding

  実装者は,必要ならば,私的Content-Transfer-Encoding値を定義してよいが,非標準の状態を示す“X-”
で始まる名前の,x-tokenを使わなければならない(例えば,“Content-Transfer-Encoding: x-my-new-encoding”)。
標準として追加するContent-Transfer-Encoding値は標準化手続のRFCによって規定されなければならない。
これら規定が満たさなければならない要件は,RFC 2048で与えられる。このようにして,“X-”で始まるも
のを除き,すべての内容転送符号化の名前空間は,IETFで将来の使用のために明示的に予約されている。
    注記 Content-Transfer-Encoding値は大文字・小文字を区別しないので,“X-”と“x-”とは同等である。
  メディア型及びメディア下位型と異なり,新しいContent-Transfer-Encoding値の生成は,ほとんど可能性
のない利益のために互換性を妨げることが多いと考えられるので,強く非推奨とする。

6.4 解釈及び使用

  Content-Transfer-Encodingヘッダフィールドが,メッセージヘッダの一部として現れる場合,そのメッセ
ージの本体全体に適用される。Content-Transfer-Encodingヘッダフィールドが,実体ヘッダの一部として現
れる場合,その実体全体に適用される。実体が“multipart”の型である場合,Content-Transfer-Encodingは,“7
bit”,“8 bit”又は“binary”以外の値をもってはならない。“message”型の幾つかのメディア下位型へは,更に
厳しい制限を適用する。
  ほとんどのメディア型は,bitでなくオクテットを用いて定義されていて,ここで示される機構は,ビッ
トストリームではなく,任意のオクテットストリームを符号化するための機構となっていることに注意す
るほうがよい。これらの機構のうちの一つを通してビットストリームが符号化される場合,ネットワーク
で標準のビット順(ビッグエンディアン),すなわち,ストリームの中で最初のほうのビットが,8 bitバ
イトの中の高位ビットになるように,まず最初にビットストリームが8 bitバイトストリームに変換されな
ければならない。8 bit境界で終わらないビットストリームは,0を用いてパディングされなければならな
い。JIS X 5810-2は,“padding”パラメタをもつapplication/octet-streamメディア型の場合に,それらパディ
ングの追加に言及する機構を提供する。
  ここで定義する符号化機構は,US-ASCIIのすべてのデータを明示的に符号化する。そこで,例えば,次
のヘッダフィールドをもつ実体を想定する。
         Content-Type: text/plain; charset=ISO-8859-1
         Content-Transfer-Encoding: base64
  これは,本体が,元はISO-8859-1だったデータのbase64 US-ASCII符号化であって,復号後は,その文
字集合になることを意味すると,解釈されなければならない。
  あるContent-Transfer-Encoding値は,あるメディア型だけに使われ,他のメディア型には使えないことが
ある。特に,“7 bit”,“8 bit”又は“binary”以外の符号化を複合的なメディア型(他のContent-Typeフィール
ドを再帰的に含むメディア型。)に使用することは,明確に禁止される。現在,複合的なメディア型は,
“multipart”及び“message”だけである。multipart型又はmessage型の本体の符号化は,すべて,最も内側の

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

                                                                                             13
                                                                                 X 5810-1 : 2008
レベル,すなわち符号化されることが必要な実際の本体のところでなされなければならない。
  複合的な実体が“7 bit”になる内容転送符号化値をもつが,それに取り囲まれた実体の一つが“8 bit”といっ
たより制限のゆるい値をもつ場合,内側に実際に8 bitデータが含まれていて,外側の“7 bit”というラベル
付けが,エラーであるか,又は内側に実際に含まれているデータが実は7 bit安全なデータであって,内側
の“8 bit”というラベル付けが,トランスポートシステムに不必要な高い要求を課しているのか,そのいず
れかであることが明らかだということを注意しておく。
    注記1 複合的な本体データに内容転送符号化( Content-Transfer-Encoding )を使うことを禁止するの
            は過度に制限的と思われるかもしれないが,これは,データが一つの符号化アルゴリズムを
            複数回通過し,適切に見るために複数回復号をしなければならないという,入れ子になった
            符号化を防ぐために必要とする。入れ子になった符号化は,UAに相当な複雑さを加える。
            これら複数回符号化の明白な効率の問題とは別に,入れ子になった符号化は,メッセージの
            基本構造を不明りょうにすることがある。特に,入れ子になった符号化は,メッセージがど
            んな型の本体を含むかを単に見付けるために,何回もの復号操作が必要になることを示唆す
            る。入れ子になった符号化を禁止することは,特定のメールゲートウェイの仕事を複雑にす
            るかもしれないが,入れ子になった符号化がUAへ及ぼす影響に比べれば,問題が少ないよ
            うに思われる。
  認識されないContent-Transfer-Encodingをもつ実体は,Content-Typeヘッダフィールドに実際に何と書い
てあるかにかかわらず,“application/octet-stream”のContent-Typeをもつものとして取り扱われなければな
らない。
    注記2 Content-Transfer-Encodingは,符号化されるメディアの特質から推測できるか,又は少なくと
            もあるContent-Transfer-Encodingを特定のメディア型とともに使用するのが必す(須)となる
            ものと思われるかもしれない。これが事実でない幾つもの理由がある。まず,メールに使わ
            れるトランスポートの様々な型を与えた場合,ある符号化はメディア型とトランスポートと
            のある組合せに対して適切だが,他の組合せには適切でなくともよい。例えば,8 bitトラン
            スポートでは,特定の文字集合によるテキストに対して符号化は必要でないが,7 bitSMTP
            では,それら符号化が明白に必要とされる。
            次に,特定のメディア型は,異なる状況では異なる型の内容転送符号化を要求することがあ
          る。例えば,多くのPostScriptの本体は,全体的には7 bitデータの短い行から構成されるかも
          しれないので,その場合,符号化は必要でない。他のPostScriptの本体,特に,レベル2 PostScript
          のbinary符号化機構を使った本体は,binaryトランスポート符号化を使った場合にだけ適切に
          表現されてよい。最後に,Content-Typeフィールドは拡張可能な指定機構となることを意図し
          ているので,メディア型と符号化との間の関連の厳密な指定が,応用プロトコルの指定と特定
          の下位トランスポートとを効果的に結び付けることになる。このことは,メディア型の開発者
          が,使われているすべてのトランスポート及びそれらの制限について意識しなければならない
          ので,望ましくない。

6.5 符号化の変換

  quoted-printable符号化及びbase64符号化は,それらの間の変換が可能なように設計されている。これら
変換において生じる唯一の課題は,quoted-printable符号化出力での原文内( hard )行区切りの扱いである。
quoted-printableからbase64に変換するとき,quoted-printable形式の原文内( hard )行区切りは,データの正
準形式のCRLF列で表現される。そこで,その行区切りは,データのbase64形式での対応する符号化され

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

次のページ PDF 16