Network Working Group N. Freed Request for Comments: 2017 Innosoft International Category: Standards Track K. Moore University of Tennessee A. Cargille, WG Chair October 1996 MIME external-body の新 access-type「URL」の仕様 (原題:Definition of the URL MIME External-Body Access-Type) 翻訳 Rev.1 この文書の status この文書は、インターネット上で標準化過程にある文書であり、 汎く指摘・意見を求めるものである。標準化とそのプロトコル については、最新の「Internet Official Protocol Standards」 (STD 1)を読まれたし。この文書は無制限に再配布可能である。 1. 概要 これは MIME の message/external-body パートに、新しく access-type として URL(Uniform Resource Locator)を追加するための文書である。 URL は、日々増え続ける HTTP や Gopher、TELNET などといったプロトコ ルによって公開されているネットワーク上の資源へのアクセス方法を示す しくみであり、基本的な URL の仕様は RFC 1738 において規定されてい る。 2. はじめに Multipurpose Internet Message Extensions、こと MIME においては、実 際のマルチメディアデータ自体だけでなく、データの所在を示す「ポイン タ」をオブジェクトとして取り扱うことが可能である。これは RFC 1521 において規定されている message/external-body 形式によって実現され る。このような機能は、たとえば、大規模なメーリングリストに巨大デー タを送付してネットワークに負荷をかけるような事態を避けるためにも有 用である。 message/external-body で伝送されるポインタは、実データを取得する方 法がきちんとわかるようなものでなくてはならない。この方法、つまり 「access-type」については RFC 1521 で次のような基本セットが定義さ れている: FTP, ANON-FTP, TFTP, LOCAL-FILE, MAIL-SERVER Uniform Resource Locator(以下 URL)は、同様にネットワーク上のデー タを自動アクセスできるしくみを提供するものだ。一般に URL は文字列 であり、そのはじめの部分で「スキーム」(プロトコル)を指定し、残り の部分はそのスキームに従い、たとえばデータ取得用のスキームであれば その所在を示すためなどに使われる。しかし、URL のスキームのうちには MIME の message/external-body に対応する access-type がないものも ある。URL を access-type として規定すれば、このように従来 access-type によるサポートのなかったデータ取得スキームを利用できる ことになり、また、今後 URL のスキームが新たに規定された場合にも対 応が可能だ。 この access-type は、何らかのデータを実際に取得するような URL につ いてのみ使用することを想定している。つまり、mailto などのしくみに 関しては本論の範囲外である。 3. URL access-type の仕様 URL の access-type は、以下のように定義される: (1) access-type 名は「URL」とする。 (2) 実際の URL 文字列を格納するために、新しく message/external-body の content-type パラメータを規定する。 パラメータ名は URL で、これは当 access-type においては必ず 必要である。構文については次項。 (3) message/external-body のダミー body については、これを使用 しない。ブランクにしておくこと。 以下に URL access-type の使用例を示す: Content-type: message/external-body; access-type=URL; URL="http://www.foo.com/file" Content-type: text/html Content-Transfer-Encoding: binary THIS IS NOT REALLY THE BODY! 3.1. URL パラメータの構文と使用法 RFC 822 および RFC 1521 の ANBF 記法に従って、以下に URL パラメー タの構文を示す: URL-parameter := <"> URL-word *(*LWSP-char URL-word) <"> URL-word := token ; 40文字を超えてはならない 正確な URL 文字列の構文については RFC 1738 において記述されている。 URL 文字列は任意長でかつ任意の文字を含むことができることになってい るが、この条件で MIME ヘッダ中に埋め込むと、RFC 822 の行の長さ規定 に抵触する。そのため、このような問題を引き起こす URL 文字列の場合 は、以下のようにして URL パラメータに変換する: (1) URL 文字列中の SPACE(空白文字)、CTL(コントロールキャ ラクタ)、二重引用符、バックスラッシュ、および 8ビット文 字が、すべて RFC 1738 に規定されている「URL エンコーディ ングの手法に基づいて符号化されていることを確認する。符号 化されていない文字は、すべて符号化せねばならない。注意し ておくが、これは元の URL 文字列を単に外見上異なるものに 変えるだけの作業である。 (2) URL 文字列を40文字以下の長さからなる文字列に分割する。 (3) それぞれの分割された文字列をひとつ以上の空白で区切り、 URL-word として、URL パラメータの値にする。URL は常に ひとつ以上の「:」(これは RFC 1521 で規定されている tspecial に該当する)を含むので、かならず引用符で囲む こと。 URL パラメータから元の URL 文字列を取得することは容易に可能で ある。引用符と連続するホワイトスペースをすべて削除すれば、残っ た文字列が URL 文字列である。 以下に、長い URL を取り扱っている例を示す: Content-type: message/external-body; access-type=URL; URL="ftp://ftp.deepdirs.org/1/2/3/4/5/6/7/ 8/9/10/11/12/13/14/15/16/17/18/20/21/ file.html" Content-type: text/html Content-Transfer-Encoding: binary THIS IS NOT REALLY THE BODY! URL のスキームによっては、同じものを示しているように見えて実際に は異なったフォーマットを扱うことが可能なものがある。HTTP はこの 一例である。が、アプリケーション側は message/external-body 中で 指定された以外のフォーマットタイプのデータを受け取ることができる ように実装されるべきではない。message/external-body 中のフォーマ ット情報を絶対のものとして扱うこと。 この件に関連して、以下のように規定する: access-type に URL が用いられた場合、その指し示す先のデー タの content-type が message/external-body のものとマッ チしたときのみ、そのデータを取得し、使用すること。 4. セキュリティ上の問題 MIME access-type 中で URL を使用する際にも、他の局面と同様の保安 上の問題が存在する。URL のセキュリティ問題については URL の規定 文書において考察がなされている。 message/external-body の access-type を使用する際、Content-MD5 フィールドを利用すれば安全性の確認ができる。これは、確かにメッセ ージの発信者が参照したデータかどうか、を確認するためのしくみであ る。Content-MD5 は、(安全性が確実な)署名システムなどではないの でその点を誤解してはならないが、いずれにしても多くの場合において 有用である。 5. さいごに John Beck および John Klensin によるフィードバックに感謝する。 6. 参考文献 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [RFC-1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September, 1993. [RFC-1590] Postel, J., "Media Type Registration Procedure", RFC 1590, USC/Information Sciences Institute, March 1994. [RFC-1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", December 1994. 7. 提出者連絡先 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 Keith Moore Computer Science Dept. University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA EMail: moore@cs.utk.edu 8. この翻訳の作成者、およびこの文書について しおばらひろあき EMail: h_siobar@st.rim.or.jp http://www.st.rim.or.jp/~h_siobar/ 典拠を示した引用、改変なき転載は自由です。内容の誤り などによって利用者が不利益を被った場合でも、責任は負 えません。原著からこの文書への翻訳過程で誤りが混入し ている可能性があるので、原著者に問い合わせる前に原文 を確認することを強く推奨します。 事実誤認・誤訳の指摘についてはよろこんで受け付けます。 ただし、意図的に意訳しているところが多いので、誤訳か どうかご一考の上、ご連絡ください。その他、カミソリの 入っていないメールも随時受け付けています :) 誤りが発見された場合、修正した文書を同ファイル名にて 公開します。 Rev.1 1997/05/19 訳出