UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 開始 1999年05月02日 / translation 01 May 1999 翻訳 2001年02月07日 / translation 07 February 2001 修正 2003年12月16日 / correction 16 December 2003 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc2048 を訳者 (marimo@wdic.org) が個人的な好奇心で適当に 翻訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。 誤訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要 な場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容につい ての指摘は、いつでも歓迎します。 Network Working Group N. Freed Request for Comments: 2048 Innosoft BCP: 13 J. Klensin Obsoletes: 1521, 1522, 1590 MCI Category: Best Current Practice J. Postel ISI November 1996 Multipurpose Internet Mail Extensions [多目的インターネットメール拡張] (MIME) パート4: 登録手続 このメモの位置づけ この文書は、インターネットコミュニティのためのインターネット標準運 用プロトコルを定義し、改良のための議論と提案を求めている。このメモの 配布は無制限である。 摘要 STD 11 すなわち RFC 822 は、US-ASCII メッセージヘッダについてのか なりの詳細を記述するメッセージ表現のためのプロトコルを定義しており、 メッセージの内容あるいはメッセージボディはフラットな US-ASCII テクス トとしたままである。 正式には Multipurpose Internet Mail Extensions または MIME と呼ば れるこの一連の文書は、次のことを可能にするためにメッセージのフォー マットを再定義する。 (1) US-ASCII 以外のキャラクタセットによるテクストメッセージボディ、 (2) 非テクストのメッセージボディのための種々のフォーマットの拡張 性のセット、 (3) マルチパート(多部分的)なメッセージボディ、そして (4) US-ASCII 以外のキャラクタセットにおけるテクストのヘッダ情報 これらの文書は RFC 934, STD 11 および RFC 1049 に述べられている初期 の作業に基づいているが、それらをさらに拡張し、改訂するものである。 RFC 822 はメッセージボディに関してほとんど述べていないので、これらの 文書は RFC 822 に対する改訂というよりも、むしろ、RFC 822 と概ね直交し たものとなっている。 この4番目の文書 RFC 2048 は、次の MIME 設備のための様々な IANA レ ジストレーション手続きを指定する: (1) メディアタイプ、 (2) 外部ボディアクセスタイプ、 (3) content-transfer-encodings. MIME で使用するための文字セットへの登録は、他の場所でカバーされ、 そして、このドキュメントによってはもはやアドレスされない。 これらの文書は RFC 1521、1522 および 1590 の改訂版である。それはさ らに RFC 1341 と 1342 の改訂版である。RFC 2049 の付録は、以前の版との 変更点を述べている。 目次 1. はじめに 2. メディアタイプの登録 2.1 レジストレーションツリーとサブタイプ名 2.1.1 IETFツリー 2.1.2 Vendorツリー 2.1.3 Personal または Vanity ツリー 2.1.4 特別な "x." ツリー 2.1.5 付加的なレジストレーションツリー 2.2 登録要件 2.2.1 機能要件 2.2.2 要件の命名 2.2.3 パラメータ要件 2.2.4 正規化及びフォーマット要求 2.2.5 交換推薦 2.2.6 セキュリティ要件 2.2.7 非要件の用法と実装 2.2.8 公表要件 2.2.9 追加情報 2.3 登録手続 2.3.1 メディアタイプをレビューのためのコミュニティに提示する 2.3.2 IESG 承認 2.3.3 IANA 登録 2.4 メディアタイプレジストレーションについてのコメント 2.5 登録されたメディアタイプリストのありか 2.6 メディアタイプ登録のためのIANA手続き 2.7 変更制御 2.8 レジストレーションテンプレート 3. 外部ボディ アクセスタイプ 3.1 登録要件 3.1.1 命名要件 3.1.2 メカニズム仕様要件 3.1.3 公表要件 3.1.4 セキュリティ要件 3.2 登録手続 3.2.1 アクセスタイプのコミュニティへの提示 3.2.2 アクセスタイプの査閲者 3.2.3 IANA 登録 3.3 登録されたアクセスタイプリストの所在 3.4 アクセスタイプを登録するためのIANA手続 4. 転送エンコーディング 4.1 転送エンコーディング要件 4.1.1 命名要件 4.1.2 アルゴリズム仕様要件 4.1.3 インプットドメイン要件 4.1.4 アウトプット範囲要件 4.1.5 データの完全性と一般性要件 4.1.6 新機能要件 4.2 転送エンコーディング定義手続 4.3 転送エンコーディング登録のためのIANA手続 4.4 登録された転送エンコーディングリストの所在 5. 奥付 A. 既得権的メディアタイプ (訳注:本訳は都合上ページを振っていないので、上記のページ番号はす べて消した。読みづらい点はご容赦) 1. はじめに 最近のインターネットプロトコルは、一定のエリアで容易に拡張可能なよ うに慎重に設計された。特に、MIME [RFC 2045] は無制限の枠組であり、 どのような変化も無しで、基本的なプロトコルに、付加的なオブジェクトタ イプ、文字セット、およびアクセス方式を適応できる。しかし、そのような 値のセットが、整然とし、よく指定されて、公的な方法で発展させられるこ とを保証するために、登録プロセスが必要である。 この文書は、そのような値のための中心的な登記所としてインターネット アドレス管理機構 (IANA) を使う登録手続を定義する。 歴史的な注意事項: メディアタイプのための登録プロセスは、最初、非同期のインターネッ トメール環境の文脈において定義された。このメール環境では、遠隔メー ルシステムの能力が知られていないとき、相互運用性の可能性を増大させ るために、可能なメディアタイプの数を制限する必要性がある。メディア タイプが新しい環境 (メディアタイプの拡散がインタオペラビリティの妨 害ではない) に使われるので、オリジナルの手続きは、非常に制限的で、 そして、一般化する必要があった。 2. メディアタイプの登録 新しいメディアタイプの登録はレジストレーション提案の解釈で始まる。 レジストレーションは、いくらかの異なるレジストレーションツリー(下で 論じられたように、異なる必要条件を持つ)において生じるべきである。一 般的に、新しいレジストレーション提案は、関係があるツリーに適した方式 で循環し、そして再検討される。もし提案が受け入れられたら、メディアタ イプはその時記録される。次のセクションは各々の異なるレジストレーショ ンツリーのために使われる要求、及び、手続きを示す。 2.1. レジストレーションツリーとサブタイプ名 レジストレーション手続きの効率と柔軟性を増加させるために、サブタイ プ名の異なる構造は、異なる自然の要件を適応させるために登録されうる。 例えば、ファイルを動かすために使用されるインターネットコミュニティま たはサブタイプにより広いサポートとインプリメンテーション(実装)に推薦 されるサブタイプは、専売権付ソフトウェアと結合した。 以下の小区分は、切り子面を作られた名前を使用して区別される "trees" という登録を定義する(例えばフォームの名 "tree.subtree...type")。この 文書に先がけて定義されたいくつかのメディアタイプが、後述された命名規 約に適合していないことに注意せねばならない。それらの議論のために、付 録A を見よ。 2.1.1. IETFツリー IETFツリーは、一般的な関心のタイプのためにインターネットコミュニテ ィに意図されている。IETFツリーにおけるレジストレーションは、IESGによ る承認、及び、いくらかの形のRFCとしてのメディアタイプレジストレーショ ンの発表を必要とする。 IETFツリーのメディアタイプは、普通明示的に切り子面を作らないこと、 すなわち不包含期間 ("."、終止符) の文字の名により示される。 IETFツリーのメディアタイプのレジストレーションの "owner" は、IETF 自身であるとみなされる。指定の部分修正または変更は、初期の登録のため に必要な処理(例えば標準トラック)と同じレベルを必要とする。 2.1.2. Vendor ツリー Vendor ツリーは、商業的に入手可能な製品と関連したメディアタイプの ために使われる。"Vendor" または "producer" が解釈されることとして、 この文脈において、同等であり、かつ非常に広い。 レジストレーションは、特定の製品と関連したファイルを交換する必要を 持つ誰もがVendorツリーに置かれるべきである。しかしながらレジストレー ションは、ソフトウェアまたはファイルフォーマットを生み出すベンダ、ま たは組織に正式に属している。次のセクションで述べられるように、仕様へ の変更は、それらのリクエストで行なわれるべきである。 Vendor ツリーにおけるレジストレーションは、主要面 "vnd." によって 区別される。自由な登録には有名な製作者(例えば "vnd.mudpie") からの、 または、それからメディアタイプを従えている生産者の名前の IANA に承認 された指示によるメディアタイプ名か製品指示 (例えば vnd.bigcompany. funnypictures) のいずれかによってレジストレーションの思いどおりにそ れが進められるかもしれない。 Vendor ツリーにおいてレジストレーションされるメディアタイプの公開 とレビューは必要とされない。と同時に、レビューのための ietf-type リ ストを使い、それらの仕様書の品質を高めることが強く促進される。 Vendor ツリーのレジストレーションはIANAに直接提出できる。 2.1.3. Personal または Vanity ツリー 実験的に作成された、または配布されない製品の一部としてのメディアタ イプのためのレジストレーションは、Personal または Vanity ツリーに商 業的に登録されうる。レジストレーションは、主要な面 "prs." によって区 別される。 "personal" レジストレーションのオーナーおよび関連した仕様書は、登 録者、または登録したエンティティ、もしくは後述されているように責任が 転嫁されたものである。 personal ツリーにおいてレジストレーションされるメディアタイプの公 開とレビューは必要とされない。と同時に、レビューのための ietf-type リストを使い、それらの仕様書の品質を高めることが強く促進される。 personal ツリーのレジストレーションはIANAに直接提出できる。 2.1.4. 特別な "x." ツリー このレジストレーション計画を持つ利便性と対称のために、最初の面とし ての "x." を持つメディアタイプ名は、"x-" で始まる名前が通常使われる 同じ目的のために使われている。 これらのタイプは未登録で、実験的で、それらを交換するパーティーの活 動的な合意によってのみ使われるべきである。 しかし、上述の Vendor および personal ツリーのように、単純化された レジストレーション手続きのため、登録されていない実験的タイプを使うこ とは滅多になく、また仮にあったとしても必要性はない。従って、"x-" と "x." フォームの両方の使用は、妨害されるべきである。 2.1.5. 付加的なレジストレーションツリー 時々、そしてコミュニティが必要な時、IANA は IESG のアドバイスと同 意により新トップレベルのレジストレーションツリーを作成できる。 それらが科学に特有なメディアタイプのための科学的社会などをカバーす る有名な永久的なボディのため、外部のレジストレーションと管理のために これらのツリーが作成できることは明白に推測される。 一般に、これらの付加的なレジストレーションツリーのうちの1つのため の、仕様書のレビューの品質が、IETFがそれ自身のツリーのレジストレーシ ョンに与えるそれと等しいことが予想されている。これらの新しいツリーの 開設は、IESGにより承認された RFC の発行によって公表される。 2.2. 登録要件 メディアタイプ登録提案のすべてが、以下のセクションで述べられる様々 な要件に対応することが予想される。また、以下のセクションで述べられる ように、要件細目は時々依存するレジストレーションツリーを変えることに 注意せねばならない。 2.2.1. 機能要件 メディアタイプは、現実のメディアフォーマットとして機能せねばならな い: 転送エンコーディングとは更によく考えられるものの、文字セットとし ての、及び他のタイプの個別の実体の収集としてのレジストレーションは許 されない。例えば、base64 転送エンコーディング [RFC2045] を解読するた めにアプリケーションは存在するが、base64 は、メディアタイプとして登 録することができない。 この要件は、関係するレジストレーションツリーを問わずあてはまる。 2.2.2. 要件の命名 すべての登録されたメディアタイプは、MIMEタイプ、およびサブタイプ名 が割り当てられねばならない。これらの名前の結合は、メディアタイプを独 特に識別する際に役立ち、サブタイプ名のフォーマットはレジストレーショ ンツリーを識別するのに役立つ。 トップレベルのタイプ名の選択は、関係するメディアタイプの性質を考慮 しなければならない。例えば、オーディオ情報がオーディオに属することを 示せるメディアがタイプを満足させるのに対して、イメージを表わすために 通常使われるメディアは、イメージコンテンツの型のサブタイプであるべき である。 トップレベルタイプおよびそれらの特徴の基本的なセットについての付加 的な情報は RFC 2046 を見よ。 もしあれば、新しいサブタイプのトップレベルのタイプは、トップレベル のタイプの制限に適合しなければならない。例えば、全てのサブタイプのマ ルチパートコンテンツ型は、同じカプセル化構文を使わなければならない。 場合によっては、新メディアタイプは、現在あるどのような定義済トップ レベルのコンテンツタイプの下にも "fit" (適合) しないかもしれない。こ のような事態は希だと予測されるが、もしそのような事態が起こるなら、新 トップレベルのタイプは、それの便宜をはかるために、定義され得る。その ような定義は標準トラックRFCを経ねばならない; 他のメカニズムは、追加 トップレベルのコンテンツの型を定義するために使うことはできない。 この要件は、関係するレジストレーションツリーを問わずあてはまる。 2.2.3. パラメータ要件 メディアタイプは、 1つ以上の MIME コンテンツ型パラメータを使うこと を決定できるかもしれない。もしくは、いくらかのパラメータは、自動的に そのサブタイプのうちのどれにでも適用できるパラメータのセットを定義す るコンテンツ型のサブタイプであることによるメディアタイプに利用可能に されるかもしれない。いずれにせよ、メディアタイプがIETFツリーにおいて 登録されるとき、名前、値、及びあらゆるパラメータの意味は十分に明示さ れなければならず、そして、メディアタイプがVendor、または Personalツ リーにおいて記録されるとき、できる限り完全に明示されるべきである。 新しいパラメータを、既存の機能を変更しない違った形で付加情報を伝え るために新パラメータが追されるかもしれないが、IETFツリーにおいて登録 されたタイプの新機能を導入の方法と定義してはならない。 これの例は、JPEG などの外部の明示の改訂レベルを示す "revision" (改 訂) パラメータである。同様な行動は、Vendor または Personalに登録され たメディアタイプのために奨励されるが、必須ではない。 2.2.4. 正規化及びフォーマット要求 レジストレーションツリーに関係なく、全ての登録されたメディアタイプ は単一の正規なデータフォーマットを使わなければならない。各メディアタ イプの、正確で公然と入手可能なフォーマットの仕様は、IETFツリーと、も し実際それがメディアタイプ登録提案自身に含まれていないなら、最小参照 を付けることが必要となる。 フォーマットと処理詳細の仕様書は、Vendorツリーにおいて登録されたメ ディアタイプで公に利用可能ではないかもしれず、そのような登録提案が、 ソフトウェアとバージョン生産またはそのようなメディアタイプを処理する 明示だけを含むことは明示的に許される。それへの参照、または登録提案の フォーマット仕様書の含有は、奨励されるが必須ではない。 フォーマット仕様書はまだ Personal ツリーにおけるレジストレーション のために必要とされるが、RFC として公表されるか、もしくは、他の場合は IANA に預けられたか、どちらでもであるかもしれない。 いくらかのメディアタイプは、特許を取得した技術の使用を包含する。特 許を取得された技術を包含するメディアタイプへの登録でも、明確に可能に される。しかしながら、メディアタイプの仕様が標準トラックプロトコルの 一部であるとき、標準トラックプロトコルにおける特許を取られた技術の使 用に関する RFC 1602 において示された制限は尊重されなければならない。 2.2.5. 交換推薦 メディアタイプは、可能ならいつでも、できる限り多くのシステム、及び アプリケーションを横断して相互運用されるべきである。しかしながら、い くらかのメディアタイプは、異なるプラットフォームを横切って相互運用す る問題を必然的に持っているであろう。異なるバージョンに関する問題、バ イトオーダー、そしてゲートウェイ処理の詳細についての問題は生じるかも しれないし、生じるであろう。 メディアタイプの一般的な相互運用性は必須ではない。だが、知られてい る相互運用性問題は、可能なら常に確認されるべきである。メディアタイプ の発表は、相互運用性の徹底的なレビューを必要とせず、そして、相互運用 性は、継続評価が必要である。 この要件は、関係するレジストレーションツリーを問わずあてはまる。 2.2.6. セキュリティ要件 セキュリティ問題の分析は, IETFツリーにおいて登録されたすべてのタイ プのために必要である(これは、全てのIETFプロトコルの基礎的な必要条件と 一致している)。ベンダまたは個人的に登録されたメディアタイプのための同 様な分析は、推奨はされるが、必須ではない。しかし証券分析が持つ持たな いに関係なく、セキュリティ問題の全ての記述はレジストレーションツリー を問わずできる限り正確でなければならない。特に「このタイプと関連して いたセキュリティは問題ない」という論述を「このタイプを持つセキュリテ ィ問題提携者は評価されなかった」と混同してはならない。 完全な要求が全くなく、危険のない安全で完璧なあらゆるツリーにメディ アタイプが登録された。それでもなお、全ての既知のセキュリティ上の危険 は、レジストレーションツリーを問わずメディアタイプへの登録において確 認されなければならない。 すべてのレジストレーションのセキュリティ考慮セクションは継続評価と 部分修正が必要で、次のセクションで述べられる「メディアタイプについて のコメント」メカニズムによって特に拡張できる。 メディアのセキュリティ分析において見られるべき問題のうちのいくつか は、下記のとおりである: (1) 複合的なメディアタイプは、受取人のファイル、または、他の資源 の動作を設ける指令に対する準備を含むかもしれない。多くの場合、 供給は、それから破壊的効果を持つかもしれない制限されない方式 で随意の動作を明示するために、発信者のために行なわれる。その ような指令の例であり、及び、それらを扱う方法である RFC 2046 の application/postscript を見よ。 (2) 複雑なメディアタイプは、受取人に直接有害ではない情報のディス クロージャーを結果として生じるかもしれない。一方、動作を設立 する指令への用意を含むかもしれず、どちらでも次の攻撃を容易に するか、または受取人のプライバシーにある点で違反する。また、 application/postscript メディアタイプの登録により、どのように そのような指令が処理できるかが述べられる。 (3) メディアタイプは、ある種類のセキュリティ保証を必要とするアプ リケーションのターゲットとされているが、必要なセキュリティメ カニズムはそれら自身は提供しない。例えば、メディアタイプは、 秘密の医学の情報(外部の秘密サービスを交互に必要とする)の記憶 装置のために定義されるべきである。 2.2.7. 非要件の用法と実装 非同期のメール環境(遠隔メールエージェントの能力に関する情報は、送 信者は頻繁に利用出来無い)において、最大の相互運用性は、広く実装され ることを期待しているそれらの "common" (共通の)フォーマットに慣れてい るメディアタイプの数を限定することによって達成される。これは、可能な メディアタイプの数を制限する理由として過去に主張され、そしてメディア タイプを記録するそれらのための重要な障害、及び遅延によるレジストレー ションプロセスに帰着した。 しかし "common" (共通の)メディアタイプの必要は、新メディアタイプの 登録を制限することを必要としない。もしメディアタイプの制限されたセッ トが特定のアプリケーションに推薦されるならば、それはアプリケーション および/または環境のために、具体的な別個の適応性ステートメントにより 主張されるであろう。 そのようなものとして、メディアタイプの一般的なサポートと実装は、登 録のための要件【ではない】。もししかし、制限された使用のためにメディ アタイプが明示的に意図されているならば、これはその登録において言及さ れるべきである。 2.2.8. 公表要件 IETFツリーにおいて登録されたメディアタイプについての提案は、RFCとし て公表されなければならない。ベンダおよびパーソナルメディアタイプ提案 のRFC出版物は、推奨されるが必須ではない。全てのケースにおいてIANAは、 全てのメディアタイプ提案のコピーを保持し、そして、メディアタイプレジ ストレーションツリーそのものの一部としてそれらを「公表」するだろう。 IETFツリーより他に、データタイプへの登録は、IANA、IETF、及び、その 仕様が十分である証明によってさえ、裏書、承認、及び推薦を意味しない。 インターネット標準になるためには、プロトコル、データオブジェクト、も しくはどんなものでも、IETF標準プロセスを通り抜けなければならない。こ れはメディアタイプへの便利な登録のための、そして、あまりにも難しく、 あまりにも長いプロセスである。 IETFツリーは、ベンダと共に実体的レビュー、及び承認プロセスを必要と するメディアタイプのために存在し、そして、パーソナルツリーは、そうで ないもののために存在する。特別なアプリケーションのための適応性ステー トメントが時間からそれらの文脈において特に有益であると証明されたメデ ィアタイプのインプリメント(と、それのためのサポート)を推薦する時間ま で掲載されれるだろうことが予測される。 上記で論じられるように、トップレベルのタイプの登録は標準トラック処 理とRFC出版物を必要とする。 2.2.9. 追加情報 もしそれが利用可能なら、様々な種類のオプション情報は、メディアタイ プの仕様に含まれるだろう : (1) マジックナンバー (長さ、オクテット値)。マジックナンバーは常に 存在し、そしてエンティティを、与えられたメディアタイプである と確認するために使われうるバイトシーケンスである。 (2) ファイル拡張子は、いくらかのファイルがあるタイプのメディアを 含んでいることを示すために、1以上のプラットフォームで一般に使 用された。 (3) Macintoshのファイル種類コード(4オクテット)は、あるタイプのメ ディアを含むファイルを分類するために用いられた。 これらの情報はしばしば実装者にとって有益であり、もし入手可能ならば 備えるだろう。 2.3. 登録手続 以下の手続きは、新メディアタイプのレビュー、及び承認のためのIANAに よって実装された。これは、正式の標準プロセスではなく、むしろ過度の時 間遅延なしのコミュニティコメントと健全性チェックを可能にすることを意 図している行政上の手続きである。IETFツリーでの登録のためには、通常の IETFプロセスに従うべきで、ietf-typesリスト(隣のサブセクションにおい て説明されるような)のインターネット草稿と告知の投稿を最初のステップ とみなす。ベンダまたはパーソナルツリーのレジストレーションのために、 下に説明された最初のレビューステップが省略でき、そしてそのタイプはテ ンプレートと説明をIANA(iana@iana.org)に直接提出することにより直接登録 された。しかし、ベンダまたはプライベートメディアタイプ仕様書の作者が、 それを実現可能な時には、いつでも、コミュニティレビューおよびコメント を求めることが奨励される。 2.3.1. メディアタイプをレビューのためのコミュニティに提示する 2週間のレビュー期間中に、提案されたメディアタイプ登録証明書を "ietf-types@iana.org" メーリングリストに送る。このメーリングリストは、 提案されたメディア、及びアクセスタイプを再検討するために設立された。 提案されたメディアタイプは正式には登録されず、それを使ってはならない; RFC 2045において指定された "x-" 接頭辞は、登録が完了するまで使われる だろう。 公的な投稿の意図は、type/subtype名、バージョン、及び外部のプロファ イリング情報に関しての参照の無曖昧さの選択、及びあらゆるインタオペラ ビリティのレビューに関してコメント、フィードバック、または、セキュリ ティ考察事項を考慮することである。提出者は、改訂された登録証明書を提 出するか、または登録をいつでも完全に撤回することができる。 2.3.2. IESG 承認 IETFツリーにおいて登録されたメディアタイプは、承認のためのIESGに提 出されなければならない。 2.3.3. IANA 登録 もしメディアタイプがメディアタイプのための要件を満たし、必要な承認 を得たならば、作者は登録要求をIANAに提出し、そしてメディアタイプはコ ミュニティで利用できるように登録されるだろう。 2.4. メディアタイプレジストレーションについてのコメント 登録されたメディアタイプについてのコメントは、コミュニティのメンバ によりIANAに提出できる。これらのコメントは、可能であればメディアタイ プの「所有者」(owner)に伝えられるだろう。コメントの提案者が、それらの コメントがメディアタイプレジストレーション自身に付加されるように依頼 することができる。そしてもしIANAがこれに賛成するならば、コメントはタ イプレジストレーション自体と連携してアクセス可能にされるだろう。 2.5. 登録されたメディアタイプリストのありか メディアタイプレジストレーションは、anonymous FTP ディレクトリ "ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/" で示されて おり、そして全ての登録されたメディアタイプは、定期的に発行される「割 り当て番号(Assigned Numbers)」RFC [現在はSTD 2, RFC 1700]にリストされ るだろう。メディアタイプ記述、そして他のサポートする材料は、それを "rfc-editor@isi.edu" に送ることによって情報提供プロトコルRFCとして同 様に公表されだろう(RFC著者に対する命令[RFC-1543]に従って頂きたい) 。 2.6. メディアタイプ登録のためのIANA手続き IANAは、あるレジストレーションが認められたことを承認するIESGからの 通信に答えてIETFツリーにおけるメディアタイプを記録するだけである。ベ ンダ、そしてパーソナルタイプは、下記と最小の条件が満たされているのと 同じくらい長いあらゆる正式のレビューなしで、IANAによって自動的に登録 される: (1) メディアタイプは、現実のメディアフォーマットとして機能しなけ ればならない。特に、文字セット、そして転送エンコーディングは、 メディアタイプとして登録されえない。 (2) 全てのメディアタイプは、適切に形成されたタイプ、及びサブタイ プの名前を持っていなければならない。全てのタイプ名は、標準ト ラックRFCによって定義されなければならない。全てのサブタイプ の名前は一意でなければならず、そのような名前のためのMIME文法 に適合し、かつ適切なツリー接頭辞を含まなければならない。 (3) パーソナルツリーにおいて登録されたタイプは、それにフォーマッ ト仕様またはポインタを提供しなければならない。 (4) 与えられた全くセキュリティ考察事項は、明らかに偽であってはい けない(メディアタイプレジストレーションの包括的なセキュリティ 再調査を行なうことは、IANAには不可能であり、また必要とされな い。それでもなお、IANAは明らかに無能な素材を確認し、そして、 それを遮断する権限を持っている)。 2.7. 変更制御 いったん、メディアタイプがIANAによって公表されたら、作者はその定義 の変更を要求できる。上の異なるレジストレーションツリーの記述は、各タ イプのレジストレーションの「オーナー」を指定する。変化要求は登録要求 と同じ手続に従う: (1) ietf-typeリストで、改正されたテンプレートを公表しなさい。 (2) コメントは、少なくとも2週間分残しなさい。 (3) もし必要なら、正式のレビュー後にIANAを用いて公表しなさい。 変更は、公表された仕様に重大な省略やエラーがある時のみ、要求される べきである。レビューが必要な時には、それが前の定義の下で有効であった エンティティを新しい定義の下で無効にするならば、変更要求は否定される だろう。 コンテンツタイプのオーナーは、コンテンツタイプに対する責任を、IANA 及びietf-typeリストに通知することにより、他の人または機関に渡すかも しれない; これは、討論もしくはレビューなしで行なわれ得る。 IESGは、メディアタイプの責任を再び定めるかもしれない。これの最も一 般的なケースは、登録した作者が死亡しコンタクトが取れなくなるか、また は違った形でコミュニティに重要な変化を起こすことができない場合でも、 タイプの変更を可能にすることである。 メディアタイプレジストレーションは、削除されないかもしれない; もう 使用するに適切とは思われないメディアタイプは、それの "intended use" (意図されている使用)フィールドを変更し、OBSOLETEと宣言できる; そのよ うなメディアタイプは、IANAにより公表されたリストにおいて、明瞭に示さ れるだろう。 2.8. レジストレーションテンプレート To: ietf-types@iana.org Subject: Registration of MIME media type XXX/YYY (MIMEメディアタイプ XXX/YYY の登録) MIME media type name: (MIMEメディアタイプ名) MIME subtype name: (MIMEサブタイプ名) Required parameters: (必要なパラメータ) Optional parameters: (オプションのパラメータ) Encoding considerations: (エンコーディング考慮) Security considerations: (セキュリティ考慮) Interoperability considerations: (相互運用性考慮) Published specification: (公開の仕様) Applications which use this media type: (このメディアタイプを使うアプリケーション) Additional information: (付加情報) Magic number(s): File extension(s): Macintosh File Type Code(s): (マジック・ナンバー/拡張子/Macintoshファイルの種類コード) Person & email address to contact for further information: (詳細について連絡する人&電子メールアドレス) Intended usage: (意図する用法) (COMMON, LIMITED USE, OBSOLETEのいずれか一つ) Author/Change controller: (制作者/更新 制御) (この行以降に、作者が興味深いと考えているどのような他の情報でも追 加できる。) 3. 外部ボディ アクセスタイプ RFC 2046は、データをエンティティボディに直接含める代わりに、MIMEエ ンティティがポインタとして実際のボディデータに作動するかもしれない message/external-bodyメディアタイプを定義する。個々の message/external-body参照によりアクセスタイプが指定され、それは、実 際のボディデータを検索するために用いられたメカニズムを決定する。 RFC 2046はアクセスタイプの初期のセットを定義するが、新しい検索メカニ ズムを収容させるため、追加のアクセスタイプの登録を考慮する。 3.1. 登録要件 新しいアクセスタイプ仕様は、下記に示された幾つかの要件に対応しなけ ればならない。 3.1.1. 命名要件 個々のアクセスタイプは一意名を持っていなければならない。この名前は、 message/external-body content-typeヘッダフィールドのアクセスタイプパ ラメータにおいて出現し、MIME content-typeパラメータ構文に対応しなけ ればならない。 3.1.2. メカニズム仕様要件 プロトコルのうちのすべては転送し、そして与えられたアクセスタイプに より使われた手続きは、アクセスタイプ自身の仕様、またはアクセスタイプ がどのような有能な実装者によっても実装される十分な記述のある他の公然 と入手可能な仕様において説明されなければならない。アクセスタイプの、 秘密のおよび/または所有権を主張した方法の使用は明確に禁止される。 RFC 1602によって、特許を取得したアルゴリズムの規格化に課された制限は、 同様に尊重されなければならない。 3.1.3. 公表要件 すべてのアクセスタイプは、RFCによって示されなければならない。標準 トラックというよりも、RFCが、標準のトラックレビューおよびすべてのア クセスタイプのために促進される承認が情報であるかもしれない。 3.1.4. セキュリティ要件 アクセスタイプの使用から生ずるあらゆる既知のセキュリティ問題でも、 完全かつ十分に説明される。アクセスタイプが安全であるということ、及び、 もし既知の危険が確認されなければ、それが危険が無いということが不要で ある。新アクセスタイプの公表は、徹底的なセキュリティレビューを必要と せず、そしてセキュリティ考慮セクションは、継続評価が必要である。付加 的なセキュリティ考察事項は、アクセスタイプ仕様の改訂されたバージョン を出版することによって扱われるべきである。 3.2. 登録手続 新アクセスタイプの登録は、 RFCのドラフトの作成で始まる。 3.2.1. アクセスタイプのコミュニティへの提示 2週間のレビュー期間中に、"ietf-types@iana.org" メーリングリストに 対して提案されたアクセスタイプ仕様を送ること。このメーリングリストは、 提案されたアクセス及びメディアタイプを再検討するために設立された。提 案されたアクセスタイプは正式には登録されず、それを使ってはならない。 公の投稿の意図は、アクセスタイプ仕様書上でコメント、及び、フィード バック、及び、あらゆるセキュリティ考察事項のレビューを懇請することで ある。 3.2.2. アクセスタイプの査閲者 2週間の期間が経過後、IETFアプリケーションエリアディレクターにより 任命される、アクセスタイプの査閲者は、要求を iana@isi.edu に送るか、 またはリストにより引き起こされた重要な反対によって、それを拒絶する。 査閲者によりされた決定は、14日以内のietf-typeメーリングリストに投 稿されなければならない。査閲者によりされた決定は、IESGに上訴されるこ ともある。 3.2.3. IANA 登録 もしアクセスタイプがレビューを通過したか、もしくはIESGに首尾よく上 訴されたならば、IANAはアクセスタイプコミュニティで利用できるように登 録するだろう。アクセスタイプの仕様はまた、RFCとして公表されなければ ならない。参考(Informational)RFCは、それらを "rfc-editor@isi.edu" に 送ることによって公表されだろう(RFC著者に対する命令[RFC-1543]に従って 頂きたい) 。 3.3. 登録されたアクセスタイプリストの所在 アクセスタイプレジストレーションは、anonymous FTPディレクトリの "ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/" に置かれ、 すべての登録されたアクセスタイプは、周期的に出される「割り当て番号」 (Assigned Numbers)RFC [現在の最新はRFC-1700] にリストされる。 3.4. アクセスタイプを登録するためのIANA手続 アクセスタイプ査閲者のアイデンティティはIESGによってIANAに伝達され る。アクセスタイプ定義に呼応してその時のIANAが作動するだけで、どちら でもアクセスタイプ査閲者により是認される。そして、登録のために、また は通信に呼応して、アクセスタイプ査閲者の裁定により棄却されたアクセス タイプ定義要求はIESGからIANAに転送される。 4. 転送エンコーディング 転送エンコーディングは、メディアタイプの正規のフォームへの変換後に MIMEメディアタイプに適用された変換である。転送エンコーディングはいく つかの目的のために使われる: (1) 多くのトランスポート、特にメッセージトランスポートは、テクス トの比較的短い行から成るデータだけ扱うことができる。テクスト のこれらの行において文字が使われうるものに、厳しい制限がある かもしれない -- いくらかのトランスポートは、US-ASCIIの小さい サブセットに制限され、そして、他のものは、一定の文字シーケン スを扱うことができない。転送エンコーディングは、バイナリデー タを、そのようなトランスポートに耐え抜くことができるテクスト フォームに変換するために使われる。この種類の転送エンコーディ ングの例は、RFC 2045で定義されたbase64とquoted-printable転送 エンコーディングを含む。 (2) Image、audio、video、およびapplicationの実体さえもが、時に巨 大である。圧縮アルゴリズムは、大きなエンティティのサイズを減 らす時に、しばしば効果的である。転送エンコーディングは、汎用 のnon-lossy(減衰なしの)圧縮アルゴリズムをMIMEエンティティに 適用するために使用できる。 (3) トランスポートエンコーディングは、MIME文脈において現存するエ ンコーディングフォーマットを表わす方法と定義され得る。 【重要】: 多くの種々の転送エンコーディングの規格化は、広範囲に及ん だ相互運用性への重要な障害と考えられて、特別に阻止される。それにも 関らず、以下の手続は、規格化を正当化するために付加的な転送エンコー ディングを定義する方法を提供するために定義された。 4.1. 転送エンコーディング要件 転送エンコーディング仕様は、下記に説明された幾つかの要件に対応しな ければならない。 4.1.1. 命名要件 個々の転送エンコーディングは一意名を持っていなければならない。この 名前はContent-Transfer-Encodingヘッダフィールドに表われ、そのフィー ルドの構文に対応しなければならない。 4.1.2. アルゴリズム仕様要件 転送エンコーディング(例えば印刷可能なフォームへの変換や圧縮)に使わ れるアルゴリズムの全ては、転送エンコーディング仕様において完全に説明 されなければならない。規格化された転送エンコーディングの秘密の、およ び/または所有権を主張したアルゴリズムの使用は、明確に禁止される。 RFC 1602によって、特許を取得したアルゴリズムの規格化に課された制限は、 同様に尊重されなければならない。 4.1.3. インプットドメイン要件 すべての転送エンコーディングは、いかなる長さの任意のオクテットシー ケンスにでも適用できなければならない。特定のインプットフォームへの依 存は許されない。 7ビットおよび8ビットエンコーディングがこの要件に対応しないことは言 及されるべきである。エンコーディングを特殊化したことの不適当は別とし て、ここの趣旨は7ビットおよび8ビットのラインに沿って付加的なエンコー ディングの付加を禁じることである。 4.1.4. アウトプット範囲要件 特別な転送エンコーディングが特別な形の符号化された出力にもたらす要 件がない。しかし個々の転送エンコーディングのためのアウトプットフォー マットは十分にでなければならず、完全に文書化されねばならない。特に、 各仕様は、出力フォーマットが7ビットデータ、8ビットデータの境界の中に 常にあるか、もしくは、全く純粋なバイナリデータであるかを明瞭に明示し なければならない。 4.1.5. データの完全性と一般性要件 全ての転送エンコーディングは、あらゆるプラットホームで十分に逆にす ることが出来ねばならない; 誰でも、一致するデコーディング操作を行うこ とによって、オリジナルのデータを回復することが出来ねばならない。この 要件により、転送エンコーディングとして使われる暗号化の全てのフォーム と同様に、lossy(減衰する)圧縮のすべてのフォームが効果的に遮断される。 4.1.6. 新機能要件 全ての転送エンコーディングは、ある種の新しい機能を提供しなければな らない。以前に定義された転送エンコーディングによるある程度の機能性の オーバラップは受け入れられる。しかし、あらゆる新しい転送エンコーディ ングは、他の転送エンコーディングが供給しない何かを同じく提供しなけれ ばならない。 4.2. 転送エンコーディング定義手続 新転送エンコーディングの定義は標準トラックRFCのドラフト(草稿)の作 成で始まる。RFCは、正確に、そして完全に転送エンコーディングを定義し なければならず、そして、新しい転送エンコーディングを定義して、標準化 するために現実の位置合せも同じく提供しなければならない。この仕様は、 それから考慮のためのIESGに提示されなければならない。 IESGが出来ることは、 (1) 標準化にふさわしくない仕様を徹底的に拒絶すること、 (2) IETFの手続きに従って仕様に取り組むために、IETFワーキング・グ ループの形成を是認すること、もしくは、 (3) ありのまま(as-is)の仕様を受け入れ、そして、それを直接標準ト ラックの上に置くこと。 標準トラック上の転送エンコーディング仕様は、標準トラックドキュメン トのために正常なIETF規則に従う。転送エンコーディングは定義されると考 えられ、いったんそれが標準トラックにあったら、使用で利用可能である。 4.3. 転送エンコーディング登録のためのIANA手続 IANAと共に転送エンコーディングを記録するための特別な手続きは必要が ない。すべての合法な転送エンコーディングレジストレーションは、標準ト ラックRFCとして出現しなければならない。従って新しい転送エンコーディ ングが承認された時には、IANAに通知することがIESGの責任である。 4.4. 登録された転送エンコーディングリストの所在 転送エンコーディングレジストレーションは、anonymous FTPディレクト リの "ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-encodings/" に置かれ、すべての登録された転送エンコーディングは、周期的に出される 「割り当て番号」(Assigned Numbers)RFC [現在の最新はRFC-1700] にリス トされる。 5. 奥付 更に情報が必要な場合、インターネットメールがこのドキュメントの著者 との最良の連絡方法である: Ned Freed Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA Phone: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com John Klensin MCI 2100 Reston Parkway Reston, VA 22091 Phone: +1 703 715-7361 Fax: +1 703 715-7436 EMail: klensin@mci.net Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 USA Phone: +1 310 822 1511 Fax: +1 310 823 6714 EMail: Postel@ISI.EDU 付録 A -- 既得権的メディアタイプ 1996年以前に記録されたいくつかのメディアタイプが、このドキュメント におけるガイドラインで記録されたならば、ベンダーかパーソナルツリーの いずれかに置かれる。適切なツリーを反映するためのそれらのタイプへの再 登録は推奨されるが、必須ではない。それらが上で示されたツリーにおいて 記録されたかのように、このドキュメントにおいて概説された所有権、及び 変更制御の原則は、それらのタイプに適用される。