が原著。 翻訳版は、翻訳からくる間違いがあり得ます。 message メッセージ: 通信 (交流) o a communication passed or sent by speech, in writing, by signals etc. o a official communication/the President's message to Congress o RFC 822: messages (mail) By 1977, the Arpanet employed several informal standards for the text messages (mail) sent among its host computers. ---------------------------------------------------------------------- (Obsoletes RFC2184) (Updates RFC2045, RFC2047 RFC2183) (Status: PROPOSED STANDARD) ---------------------------------------------------------------------- Yasutaka Kato 加藤泰孝 ----------------------------------------------------------------------  rfc2231 Network Working Group N. Freed Request for Comments: 2231 Innosoft Updates: 2045, 2047, 2183 K. Moore Obsoletes: 2184 University of Tennessee Category: Standards Track November 1997 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations MIMEパアラメーター値と符号化単語拡張 文字セット・言語そして継続 この覚書の位置付け この文書はインターネット交流のためのインターネット標準トラックプロト コールを特定し、改善への議論と示唆を求めています。この文書の標準化状況 と位置付けについては、最新の"Internet Official Protocol Standards" (STD 1) を参照してください。この覚書の配布には、制限はありません。 著作権注意 Copyright (C) The Internet Society (1997). All Rights Reserved. 1. 要約 この覚書は、RFC 2045メディアタイプとRFC 2183配置値機構に拡張を提供する ために、定義しています。 (1) US-ASCII以外の文字セットでパラメーター値を特定する手段 (2) 使用されるべき言語を特定するのに、値が表示されるべきで、そし て (3) ヘッダー行折り返しにともなう問題を回避する、長いパラメーター値 用の継続機構 これはまた、RFC 2047で、文字セットと同じようにうまく表示されるべき言語 の仕様をゆるすために、定義された符号化単語に拡張を定義することを意味し ます。 2. はじめに 多目的インターネットメール拡張、もしくはRFC 2045・RFC 2046・RFC 2047・ RFC 2048・RFC 2049、は以下を可能にするメッセージ書式を定義しています: (1) US-ASCII以外の文字セットでテキストメッセージボディ (2) 非テキストメッセージボディ (3) 多元部分メッセージボディ、そして (4) US-ASCII以外の文字セットでテキストヘッダー情報 MIMEは今や広く採用され、色々なインターネットプロトコール、勿論インター ネットメルも含まれています、で使用されています。しかし、MIMEの成功は、 オリギナルなプロトコール使用で提供されていない、追加的な機構への要求を もたらしています。 特に既存のMIME機構は、指定された配置 (content-dispositionフィールド) と指定されたメディアタイプ (content-typeフィールド) パラメーターを提供 しています。MIMEメディアタイプは、いくらでもパラメーター、その全てのサ ブタイプと強調する、を特定するかもしれませし、どんな特別なサブタイプも それ自身の使用のための追加的なパラメータを特定するかもしれません。 MIME配置値は強調サウブタイプをいくらでも特定するかもしれなく、そのなか で最も重要なものは添付配置のファイル名パラメーターです。 これらのパラメーターと値は、インターネットメールでは content-type と content-dispositionヘッダーフィールドで終ります。これは、本来、三つの 重要な制限を課します; (1) インターネット電子メールヘッダーフィールドの行は、RFC 822の折り 重ね規則に従って、折り重ねられます。これが、長いパラメーター値 にとって問題となります。 (2) MIMEヘッダーは、しばしば現われるRFC 822ヘッダーのように、7ビッ トUS-ASCIIに制限され、RFC 2047の符号化単語機構はパラメーター値で は得られません。これは、US-ASCII以外の文字セット、或る種の個人的 なパラメーター符号化を特定することなく、を持つことを不可能にしま す。 (3) 文字セット情報は或る種の情報を適切に表示するには十分ではないこ とが最近明らかになってきています -- 言語情報も要求されています [RFC-130]。例えば、障壁のある利用者のサポートは、テキスト文字 列の音声読みの必要があるかもしれません。テキストが書かれている言 語は、これが正しくなされることを要求されています。パラメーター 値によっては、表示されなければならない、それ故に言語情報の同封 が可能なことが要求されます。 このリストの最後の問題は、符号化単語は主として表示目的が考えられている ので、RFC 2047で定義されている符号化単語の問題でもあります。 この文書はこれら制限全てを達成する拡張を定義します。これら全ての拡張 は、現存するMIME装備と構文レベルで完全に互換性である形式で、装備されま す。更に、この拡張は現存のMIME利用者に出来るだけ衝撃を与えないように設 計されます。 重要な注意: これらの機構は、実際に使用される場合、多少突出することで 終ります。そのようなので、これら機構は軽々しく使用すべきではありません; これらに対する本当の必要性がある状況に、取っておくべきです。 2.1. 命名条件 (Requirements notation) この文書は時に大文字の用語を使っています。"MUST"・"SHOULD"・"MUST NOT"・"SHOULD NOT"そして"MAY"といった用語が大文字になっている場合、こ の仕様書の特別な要求を指すのに使われます。これらの用語の意味の議論は、 [RFC 2119]にあります。 3. パラメーター値継続 (Parameter Value Continuations) 長いMIMEメディアタイプもじくは配置値は、ヘッダー行折り返しと相互にうま く交流できません。特に適切なヘッダー行折り返しは、行空白スペースが何処 に、パラメーター値にあるかもしれないしないかもしれません、許されるかに 依存し、そしてもしあってもパラメーター値構文の特別な知識が、行折り返し をする代行手段に備わっていないので、ヘッダー行折り返しはそのように認識 されないかもしれません。その結果、長いパラメーター値は縮められだけもし くはそうでないなら不適切な行折り返し装備によって損傷されるだけに終るか もしれません。 従って、行折り返しに馴染みやすい小さな単位にパラメーター値を分断する機 構が必要です。そのような機構は、いかなるものであっても、既存のMIME処理 と互換性がなければなりません。これは以下のことを意味します。 (1) 機構は、MIMEメディアタイプと配置行を変更してはいけませんし、そ して (2) 機構は、パラメーター順位に依存してはいけません、というのはパラ メーターは順位感受性ではないとMIMEは声明しているからです。MIME は、転送中、MIMEヘッダーの修正を禁じていますが、それでもパラ メーターが、表示代行手段レベルの処理が成される際再順位化される ことが可能であることに注意してください。 そこで、明白な解決は、単一パラメーター値を内容としそれが成された場合に 示唆する或る種の区別される名前を使った、多元パラメーターを使用すること です。そして、アスタリック文字 ("*") に続いて十進値カウントが採用さ れ、多元パラメーターが単一パラメーター値をカプセル化するのに使用されて いることを示唆します。このカウントは0から始まり、連続しておこる各パラ メター値セクションで1づづ増加します。十進値が使われ、先導ゼロも連続の 欠損も許されません。 オリジナルのパラメーター値は、そのパラメーターの色々なセクションを順に 連結することによって、復元されます。例えば、ontent-typeフィールドが、 Content-Type: message/external-body; access-type=URL; URL*0="ftp://"; URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar" なのは、構文的に以下と同じです。 Content-Type: message/external-body; access-type=URL; URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar" パラメーター値を囲う引用は、値構文の部分です; それらは値そのものの部分 ではありません。さらに、引用非引用の連続フィールドの混在を持つことも許 されています。 4. パラメーター値文字セットそして言語情報 (Parameter Value Character Set and Language Information) パラメーターによっては、文字セットもしくは言語情報で規定される必要があ るものもあります。区別されたパタメーター名は、この情報があれば、その値 の情報の特別な構文にそって同定される必要があります。更に、軽い符号化機 構、パラメーター値の8ビット情報に適応するのに、が必要です。 アスタリック ("*") が、言語と文字セット情報がありそして符号化が使われ ているいることの指標を提供するために、再利用されます。一重引用 ("'") は、文字セットと言語情報を区別するのに、パラメーター値の始めに使用され ます。パーセント記号 ("%") は、符号化の印として使用され、それはRFC 2047 と一致します。 特別に、パラメーター名の終りのアスタリックは、文字セットと言語情報がパ ラメター値の始めに来ているという指標として、働きます。一重引用符号は文 字セット・言語情報をパラメーター値文字列の実際の値情報を分離するために 使用されそしてパーセント記号は、十六進値符号化されたオクテックを印付け するのに、使用されます。例えば: Content-Type: application/x-stuff; title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A 文字セットか言語情報を空白のままにしていおくことは、完全に許されている ことに注意してください。一重引用識別子は、フィールドの一つが省略された 場合でも、存在しなければなりません。文字セットか言語もしくは両者が、用 意されたパラメーター値に適切でない場合、これが成されます。デフォルトの 文字セットもしくは言語情報を指すのに、これがなされてはいけません -- パ ラメーターフィールド定義が、デフォルト文字セットもしくは言語情報を割り 当ててはいけません。 4.1. 文字セット・言語とパラメーター継続の結合 (Combining Character Set, Language, and Parameter Continuations) 文字セットと言語情報は、パラメーター継続機構と結び付けられるかもしれま せん。例えば: Content-Type: application/x-stuff title*0*=us-ascii'en'This%20is%20even%20more%20 title*1*=%2A%2A%2Afun%2A%2A%2A%20 title*2="isn't it!" これに注意: (1) 言語と文字セット情報は、一定のパラメーター値の始めに現われる だけです。 (2) 継続は、同じパラメータ値で一つ以上の文字セットもしくは言語情 報装備を提供していません。 (3) 多元継続を使って表現している値は、符号化と非符号化断片の混在 を内容としているかもしれません。 (4) 継続の最初の断片は、言語と文字情報が与えられているなら、符号 化されなければなりません。 (5) 継続されたパラメーター値の最初の断片が符号化されているなら、 その言語と文字セットフィールド識別子は、フィールドがたとえ空 白のままであっても、存在しなければなりません。 5. 符号化単語の言語仕様 (Language specification in Encoded Words) RFC 2047は、RFC 822メッセージヘッダーコメント・フレーズそしてどんな非 構造テキストフィールドで非US-ASCII文字セットのサポートを提供していま す。これは、それらの場所に来れる符号化単語構成成分を定義することで成さ れています。これらは表示を意図されたフィールドであることを仮定していま すが、文字セットだけと同じように言語情報を符号化単語と協調することが、 時には必要になります。この仕様書は、そのような情報を同封することが可能 なる符号化単語の定義を拡張しています。これは、文字セット仕様に言語タグ (名札) に続くアスタリックを付け加えることで、単純に成されます。例えば: From: =?US-ASCII*EN?Q?Keith_Moore?= 6. パラメーター値のIMAP4取り扱い (IMAP4 Handling of Parameter Values) IMAP4 [RFC-2060]サーバーは、ボディやボディ構造フェッチ属性を生成する 際、パラメーター値継続をデコード (復元) すべきです。 7. MIME ABNFの修正 (Modifications to MIME ABNF) RFC 2045で与えられたMIMEパラメーター値のABNFは: parameter : = attribute "=" value attribute : = token ; Matching of attributes ; is ALWAYS case-insensitive. この仕様はこのABNFを変更して: parameter : = regular-parameter / extended-parameter regular-parameter : = regular-parameter-name "=" value regular-parameter-name : = attribute [section] attribute : = 1*attribute-char attribute-char : = section : = initial-section / other-sections initial-section : = "*0" other-sections : = "*" ("1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9") *DIGIT) extended-parameter : = (extended-initial-name "=" extended-value) / (extended-other-names "=" extended-other-values) extended-initial-name : = attribute [initial-section] "*" extended-other-names : = attribute other-sections "*" extended-initial-value : = [charset] "'" [language] "'" extended-other-values extended-other-values : = * (ext-octet / attribute-char) ext-octet : = "%" 2 (DIGIT / "A" / "B" / "C" / "D" / "E" / "F") charset : = language : = RFC 2047で与えられたABNFは: encoded-word : = "=?" charset "?" encoding "?" encoded-text "?=" この仕様はこのABNFを変更して: encoded-word : = "=?" charset ["*" language] "?" encoded-text "?=" 8. 言語仕様を許す文字セット (Character sets which allow specification of language) 将来、文字セットによってはインライン言語ラベル付けの装備を提供すると 思われます。そのような装備は、文字列の途中で言語切り替えを許すので、 ここで定義されたものよりより本来柔軟です。 そのような装備が発展させられる場合、ここで定義された言語ラベル付け装 備の方を取って使用されるべきです。ここで定義されたすべての機構は、こ の可能性ある将来の利用に合わせることができるように、言語ラベルの省略 を許します。 9. 安全性への考慮 (Security Considerations) このRFCは安全性問題を議論してなく、電子メールで既に固有でない安全問 題を生じたり十分に適合しているMIME装備で起こるとは考えていません。 10. 参照 (References) [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822 August 1982. [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC-2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996. [RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996. [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-ASCII Text in Internet Message Headers", RFC 2047, December 1996. [RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC 2048, December 1996. [RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996. [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC-2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M., and P. Svanberg, "Report from the IAB Character Set Workshop", RFC 2130, April 1997. [RFC-2183] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 2183, August 1997. 11. 著者への連絡 Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA Phone: +1 626 919 3600 Fax: +1 626 919 3614 EMail: ned.freed@innosoft.com Keith Moore Computer Science Dept. University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA EMail: moore@cs.utk.edu 12. 著作権声明全文 (Full Copyright Statement) Copyright (C) The Internet Society (1997). 全ての権利を留保します。 Copyright (C) The Internet Society (1997). All Rights Reserved. この文書とその翻訳は、複写され他者に供給されるかもしれなく、そしてコ メントを付けたりもしくは別のやり方で説明したり、その装備に支援したり する派生的な仕事が作成され、複写され、上記の著作権注意書とこのパラグ ラフがそのような全ての複写や派生的仕事に含まれているなら、公開や配 布、全体にせよ一部分にせよ、されるかもしれません。しかし、この文書自 体は、著作権注意やインターネット協会もしくはその他のインターネット組 織への参照を取り除くように、如何なる方法であれ修正されないかもしれま せん、発展するインターネット標準の目的上必要な場合、このケースではそ のインターネット標準過程で定義された著作権の手順に従わなけれなりませ ん、もしくはそれを英語以外の言葉に翻訳する必要がある場合は例外です。 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 上で授けられた制限された許可は恒久てきなもので、インターネット協会も しくはその後継者もしくは被譲渡人によって取り消されません。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. この文書とそこに内容となっている情報は「ありのまま」状態で提供され、 インターネット協会とインターネット工業委員会は全ての保証、ここの 情報の使用が権利もしくは市場や実際的な目的適合の暗黙の保証を侵害しな い保証も、これだけに限りませんが、含み、を明示的もしくは暗黙的にも、 否認します。 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.