が原著。 翻訳版は、翻訳からくる間違いがあり得ます。 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. Yasutaka Kato 加藤泰孝 ----------------------------------------------------------------------  rfc2047 Network Working Group K. Moore Request for Comments: 2047 University of Tennessee Obsoletes: 1521, 1522, 1590 November 1996 Category: Standards Track MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text マインム (インターネットメールの多目的拡張) 第三部: 通信 (メッセージ) ヘッダーでの非アスキーテキスト拡張 この覚書の位置付け この文書はインターネット交流社会用のインターネット標準過程手順 (プロト コール) を特定し、改善への議論と提案を求めるものです。この手順の標準化 状況や位置付けについては、"Internet Official Protocol Standards" (STD 1) の最新版を見てください。この覚書の配布の制限はありません。 要 約 STD 11、RFC 822、は US-ASCII通信ヘッダーについての詳細を特定する通信表 現手順を定義していますが、通信内容もしくは通信本体は平坦なUS-ASCIIテキ ストとしたままです。多目的インターネットメール拡張もしくはマインムと総 称されるこの一組の文書は、以下のことが可能になる通信形式を再定義します。 (1) 通信本体でのUS-ASCII以外の文字セットによるテキスト、 (2) 通信本体での非テキストの色々な形式への拡張、 (3) 多元的な通信本体、そして (4) ヘッダー情報でのUS-ASCII以外の文字セットによるテキスト これら文書は、RFC 934、STD 11、と RFC 1049で文書化されている初期の作業 に基づいていますが、これを拡張改訂しています。RFC 822は通信本文につい て殆ど言及していませんので、これらの文書は (改訂というより) RFC 822と は別方向のものです。 この特別な文書は、シリーズの第三番目にあたります。非ASCIIテキストデー ターをインターネットメールヘッダーで可能にするためのRFC 822の拡張を記 載しています。 このシリーズの他の文書には: + RFC 2045は、マインムメッセージの構造を記載するのに使われる色々なヘッ ダーを特定します。 + RFC 2046は、マインムメディアタイプシステムの一般的な構造を定義し、メ ディアタイプの初期設定を定義します。 + RFC 2048は、マインム関連機能のIANA登録手順を特定します。 + RFC 2049は、マインム適合基準を記載し、マインムメッセージ形式の図解 例・謝辞・文献を提供します。 これらの文書は、RFCs 1521・1522と 1590の改訂版で、さらに後者は RFCs 1341と1342の改訂でした。RFC 2049の付録で、前の版との違いと変更が記載さ れています。 1. はじめに RFC 2045には、一連の印字可能なUS-ASCII文字としてボディ部分をコード化す る方法と同様に、様々な文字セットでコード化されたテキストボディ部分を表 記する機序を記載しています。この覚書は、非ASCIIテキストが RFC 822 [2] メッセージヘッダーの色々な場所で、既存の通信処理ソフトウェアーを惑わさ ないような方法で可能にする同じ様な技術に言及します。 RFC 2045で記載されているコード化技術と同様、ここに概観されている技術 は、既存のインターネットメール処理プログラムの気紛れによって邪魔されな いやり方で、非ASCII文字が使えるように設計されました。特に、 (a) メッセー ジをとどめておく間にメッセージヘッダー領域を削除したり、 (b) To: や Cc: 領域の順位を再整理したり、 (c) ヘッダー領域の順位 (垂直) を再整理した、 また乃至は (d) 元のメッセージと違う場所でメッセージヘッダーを折り返した りするメール関連プログラムがしられています。更に、RFC 822にそった正し くても、 "<"・","や": "といった特別な文字を隠すためのバックスラッシュ の使用や仕様書の稀にしか使用されない機能を利用するメッセージヘッダーを 適切に解析することが困難なメール読みプログラムもあります。 これらのプログラムがRFC 822を適切に解釈しないことは残念ではありますが、 これらを引き裂くことはインターネットメールシステムに深刻な操作問題を引 き起こします。従って、この覚書に記載される拡張は、RFC 822で殆ど使用さ れない機能には依存していません。 その代わりに、一連の"普通の"印字可能なASCII文字 (「符号化-単語= "encoded-words"」として知られている) が、データーをコード化するのに使 うよう予約されています。「符号化-単語="encoded-words"」の構文は、メッ セージヘッダーの普通のテキストとして"偶然に"現われることがないように なっています。更に、「符号化-単語="encoded-words"」で使われる文字は、 「符号化-単語="encoded-words"」が現われる文脈上特別な意味を持たないも のに制限されています。 一般的にいって、「符号化-単語 "encoded-words"」は一連の印刷可能な ASCII文で、"=?"にはじまり"?="で終わり、その間に"?"が二つきます。文字 セット (character set) と符号化方法 (encoding method) を特定し、元のテ キストは符号化方法 (encoding method) に従った画像的な (テキストでな い) ASCII文字として符号化されます。 この仕様を装備するメール構成は、ヘッダー領域の非ASCIIテキストを置く手 段を提供しますが、メッセージヘッダーに非ASCIIテキストを挿入する前に、 この領域 (これらの領域の適切な場所) を「符号化-単語 "encoded-words"」 に翻訳します。 この仕様を装備するメールリーダーは、メッセージヘッダーのある場所に「単 語の符号化 "encoded-words"」が現われている場合それを認識します。「単語 の符号化 "encoded-words"」を「そのまま」表示するのではなくて、符号を復 元して指定された文字セットで元のテキストを表示します。 注 意 この覚書はRFC 822とRFC 2045を定義した表記法と用語と緊密に関わっていま す。特にこの覚書で使われているABNFの構文は、RFC 822で定義され、同じ様 にRFC 822からの表記上のシンボルがここで定義されたヘッダー拡張の文法で 使われています。RFC 822で定義されこの覚書で参照しているシンボルは: 'addr-spec'・'atom'・'CHAR'・'comment'・'CTLs'・'ctext'・'linear- white-space'・'phrase'・'quoted-pair・'quoted-string'・'SPACE', そして 'word'です。この手順拡張を満たす装備では、用語のRFC 822定義に充分な注 意が必要です。 この覚書に"ASCII"という用語が出てきた場合、"7-Bit American Standard Code for Information Interchange"、ANSI X3.4-1986を意味しています。マ インム文字セット名は、"US-ASCII"です。特別にマインム文字名を参照しない 場合、この文書では"ASCII"という用語、簡潔さとRFC 822との統一性の両者の ために、を使います。しかし装備では、マインムメッセージやボディ部分ヘッ ダーで文字セット名は"US-ASCII"と記載しなければなりません。 この覚書はメッセージヘッダーの非ASCIIテキストの表現の手順を特定しま す。 "8-bit headers"と純粋のASCIIヘッダー間の変換もしくは可能と思われ るそのような変換を何ら定義していません。 2. 符号化-単語="encoded-words"の構文 符号化-単語="encoded-words"は以下のABNF文法によって定義されています。 RFC 822の命名法が使われ、空白スペース文字は符号化-単語="encoded- words"の構成内に現われていけないと言う例がありますが。 encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" charset = token トークン (字句) ; 3.文字記号セットを参照 encoding = token トークン (字句) ; 4.符号化を参照 token = 1*<スペース・CTLsとespecialsを除く文字> especials = " (" / ") " / "<" / ">" / "@" / "," / ";" / ": " / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1*<"?" スペース以外の文字> ; (5. メッセージヘッダーでの ; encoded-wordsの使い方を参照) 'encoding'と'charset'名は両者とも大文字小文字を区別しません。"ISO- 8859-1"と"iso-8859-1"は同じで、エンコード名"Q"は、"Q"や"q"と書けます。 符号化-単語= 'encoded-word'は、'charset'・'encoding'・'encoded-text' そして区別子をいれて75文字以上にならないように。75文字の符号化-単語= 'encoded-word'に合う以上のテキストをエンコードしたいなら、多元的な単語 の符号化= 'encoded-word' (CRLFスペースで区切って) を利用します。 多元列ヘッダー領域の長さに制限はありませんが、一つ以上の符号化-単語= 'encoded-word'を含むヘッダー領域の各列は、76文字に制限されています。 長さの制限は、インターネットメールゲートウェイ通過で相互操作性を容易に するためと、ヘッダーパーサーがトークンが符号化-単語= 'encoded-word'で あるかその他のものであるかを決定する前に採用する先き取る量の限界を義務 付けるためのものです。 重要: 符号化-単語='encoded-word'は、RFC 822パーサーは'atom'として認 識されるように設計されています。それで、コード化されていない空白スペー ス (スペースやタブ) は符号化-単語='encoded-word'内では隠されます。例 えば、以下の文字列 =?iso-8859-1?q?this is some text?= は単一でなく四つの'atom' (RFC 822パーサーによって) もしくは単語の符号 化='encoded-word' (符号化-単語='encoded-word'を理解するパーサーによっ て) として解析されます。"this is some text"をコード化する適切な方法 は、スペース文字を同様にコード化することで、例えば =?iso-8859-1?q?this=20is=20some=20text?= 'encoded-text'内に現われる文字は更にセクション5の規則によって制限され ます。 3. 文字セット 符号化-単語='encoded-word'の'charset'部分はコード化されていないテキス トに付随する文字セットを特定します。 'charset'は、"text/plain" ボディ 部分のMIME "charset"で許される文字セット名もしくはMIME text/plain content-typeで使用するIANA登録された文字セット名ならどれでもなれます。 文字によってはコード変換技術を使い、"ASCIIモード"から他のモード間を変 換します。符号化-単語='encoded-word'ないのコード化されていいないテキ ストがASCIIモードから変更するために文字セット変換をもたらすシーケンス を持っていたら、符号化-単語='encoded-word'の終わりでASCIIモードが再び 選ばれるような追加制御コードを持っていなければなりません。 (単一のヘッ ダー領域内に隣接する符号化-単語='encoded-word'があるなら、各単語の符 号化='encoded-word'に別々に、この規則は適用されます。) 符号化-単語='encoded-word'のテキストを表現するのに一つ以上の文字セッ トを使う可能性があり送信者とメッセージの受け手の間に個人的な了解がない 場合、ISO-8859-*シリーズのものが別の文字セットに優先して使用されること を薦めます。 4. 符号化 初期値 (デフォルト) で正式な符号化は、"Q"と"B"です。以下にこの符号化に ついて記載します。符号化される文字記号がほとんど ASCIIの場合符号化"Q" が薦められ、そうでない場合は符号化"B"を使用すべきです。そうでないなら、 符号化-単語='encoded-word'を認識すると宣言しているメールリーダーは、 サポートされているいかなる文字セット用のコード化を受け入れることができ なければなりません。 印字できるASCII文字の組だけが「符号化されたテキスト」内で使用できます スペースとタブは許されません、というのは「符号化-単語」の始まりと終り ははっきりしているからです。"?"記号は「符号化-単語」内で使われ、「単 語の符号化」の色々な部分を他から分けるのに使われ、したがって「符号化さ れたテキスト」内には現われることはことはできません。そのほかにもある種 の文脈上合法的でないものもあります。たとえば、Fromヘッダー欄のアドレス に先行する句の「符号化-単語」は、RFC 822で定義されている "specials"を どれもとれません。最後にインターネット=メールのゲートウェイを通過する メッセージの信頼性を確保するために、ある種の文字記号はある文脈上許され ないものもあります。 符号化"B"はこの要求に適合します。符号化"Q"は、印字可能な幅広い文字を、 メッセージ・ヘッダー (例えば、Sucject) の厳密でない場所で、別の場所で 使うのに入手できる幾つかの文字とともに、使用できます。 4.1. "B"符号化 符号化"B"は、RFC 2045で定義されている"BASE64"符号化と同じです。 4.2. "Q"符号化 符号化"Q"は、RFC 2045で定義されれいる "Quoted-Printable"内容転送符号化 と類似しています。大部分ASCII文字符号からなるテキストがデコードされな くてもなんとか判読できるように設計されています。 (1) 8ビット値は、"="に続いて二つ十六進法ジギタルで表現されます。例えば 使用中の文字セットがISO-8859-1なら、 "="文字は"=3D"とスペースは"=20" とコード化されます。 (大文字は十六進法ジギタルの"A"から"F"に使用され るべきです。 (2) 8ビット十六進値20 (ISO-8859-1のスペース) は、"_" (下線、ASCII 95) として表現されるかもしれません。 (この文字を通さないインターネッ トゲートウェイがありますが、その使用はこのコード化をサポートしてい ないメールリーダーにとって "Q" コード化されたデーターの判読可能性を 大いに 高めます。) スペース文字が使用されている文字コードで異なった コード位置を占める場合でも、"_"は常に十六進値20を表現することに注意 して下さい。 (3) "="・"?"・and "_" (underscore) 以外の印字可能なASCII文字に対応する 8ビット値は、文字として表現されるかもしれません。 (しかし、制限に ついてはセクション5参照。) 特に、スペースとタブはコード化された言 葉内でそれ自身として表現されてはいけません。 5. メッセージヘッダーでの符号化-単語=encoded-wordsの使用 符号化-単語=encoded-wordsは、メッセージヘッダーもしくは以下の規則に そってボディ部分のヘッダーに現われます: (1) Subjectもしくはコメントヘッダー領域・拡張メッセージヘッダー領域 もしくは領域ボディが'*text'として定義されているマインムボディ部分領 域の'text'トークン字句 (RFC 822で定義されたように) を符号化-単語= 'encoded-word'に置き換えます。符号化-単語='encoded-word'はまたユザ ー定義の ("X-") メッセージもしくはボディ部分ヘッダー領域に現われるかも しれません。 普通のASCIIテキストや符号化-単語='encoded-word'は同じヘッダー領域に 一緒に現われかもしれません。しかし、'*text'と定義されたヘッダー領域に 現われる符号化-単語='encoded-word'は、隣接する符号化-単語= 'encoded-word'もしくは'text'を'linear-white-space'で分離しなければな りません。 (2) " ("と") "で識別されたコメント='comment'、'ctext'で許される、内に単語の 符号化='encoded-word'がくるかもしれません。より正確には、RFC 822 ABNFのコメントの定義は以下のように修正されています: comment = " (" * (ctext / quoted-pair / comment / encoded-word) ") " コメントにくる"Q"コード化された符号化-単語は、 " (", ") "文字を含んでは いけませんし、コメントにくる符号化-単語は空白行文字'linear-white- space'で隣接する符号化単語'encoded-word'や'ctext'から分離させられなけ ればなりません。 コメントは構造化された領域ボディ部分 (field bodies) 内で認識されるだ けです。そのボディ部分が'*text', " ("や") "と定義されているなら、コメン ト識別子でなく普通の文字として処理され、このセクションの規則 (1) が適用 されます。 (RFC 822 セクション3.1.2や3.1.3を参照) (3) 句'phrase'内の単語'word'実体、例えばFrom, To, or Ccヘッダーのaddressに 先行するもの置き換えとして。RFC 822の'phrase'のABNF定義は、以下のように なります: phrase = 1* ( encoded-word / word ) このケースで"Q"コード化された符号化-単語'encoded-word'は、<大文字 小文字のASCII文字・整数値・ "!"・"*"・"+"・"-"・"/"・"="そして"_" (underscore, ASCII 95) >に制限されます。句'phrase'内にくる符号化 -単語'encoded-word'は隣接する'word'・'text'もしくは'special'と空白 文字'linear-white-space'でわけられなければなりません。 これらは符号化-単語'encoded-word'が現われる所だけにきます。特に: + 符号化-単語'encoded-word'は、'addr-spec'の何処にもきてはいけません。 + 符号化-単語'encoded-word'は、'quoted-string'内にきてはいけません。 + 符号化-単語'encoded-word'は、受け取ったヘッダー領域で使ってはいけま せん。 + 符号化-単語'encoded-word'は、MIME Content-TypeもしくはContent- Disposition領域のパラメーターや、また'comment'もしくは'phrase'内を除 き構造化された領域ヘッダーの何処にも使われてはいけません。 符号化-単語'encoded-word'内の'encoded-text'は、自己充足でなければなり ません: 'encoded-text'は一つの符号化-単語'encoded-word'から他のものに 続いてはいけません。これは、"B"符号化-単語'encoded-word'の'encoded- text'部分は多元的な4文字長になることを当然のこととしています;"B"符号 化-単語'encoded-word'では'encoded-text'部分にくる"="文字は、二つの十六 進法文字が続きます。 符号化-単語'encoded-word'は整数のオクテットをコード化しなければなりま せん。符号化-単語'encoded-word'の'encoded-text'は指定されたコード化に 従って書式化されなばなりません;'encoded-text'は次の 符号化-単語 'encoded-word'につながらないかもしれません。 (例えば、"=?charset?Q?=?= =?charset?Q?AB?=" は、正しくありません、というのは二つのディギット "AB"は同じ符号化-単語'encoded-word'の"="に続かなければならないからで す。 符号化-単語'encoded-word'は、整数の文字で表現しなければなりません。多 元オクテット文字は隣接する符号化-単語'encoded-word'を超えて分離されま せん。 印字可能な文字と空白文字データだけがこの方針を使ってコード化されるべき です。しかしこれらのコード化方針は随意のオクテット値を許すので、受信側 の端末でデコードされたデーター表示が思わぬ副次的な結果を起こさないこと を、このデコードを装備するメールリーダーは確認すべきです。 非テキスト (つまり、画像や音響) をコード化のためのこの方法の使用は、こ の覚書で定義されていません。純粋にASCII文字列を表現するための符号化-単 語'encoded-word'の使用は許されていますが、薦めていません。稀なケースと して、符号化-単語'encoded-word'に見える普通のテキストをコード化する必 要があるかもしれません。 6. 符号化-単語='encoded-word'のメールリーダーによるサポート 6.1. メッセージヘッダー内の符号化-単語='encoded-word'の認識 メールリーダーは、RFC 822の規則にそって符号化-単語を正しく認識するため に、メッセージとボディ部分のヘッダーを解析しなければなりません。 符号化-単語は、以下のように認識されなければなりません: (1) '*text'と定義されたメッセージやボディ部分のヘッダー領域もしくは ユーザー定義のヘッダー領域は以下のように解析されなければなりませ ん: 域ボディのはじまり、すぐ続く'linear-white-space'と印字可能な 75文字までの文字列 ('linear-white-space'を含まない) があるかを、セ クション2の構文規則にそった議号化-単語であるかどうかを見るために、 調べます。その他の印字可能な文字列は、ASCIIテキストとして処理され るばきです。 (2) '*text'として定義されていないヘッダー領域は、そのヘッダー領域の構 文規則に従って解析されるべきである。しかし'phrase'内に現われる 'word"は、セクション2の構文規則にあっている場合、符号化-単語 'encoded-word'として処理されるべきである。そうでないなら、普通の 'word'として処理されるべきである。 (3) コメント'comment'内では、セクション2の構文規則に合う75までの印字可 能な文字 ('linear-white-space'を含まない) は、符号化-単語 'encoded-word'として処理されるべきである。そうでないなら、普通のコ メントとして処理されるべきである。 (4) MIMEバージョンヘッダー領域は、この仕様書にそって解釈されるのに符号 化-単語として表現される必要はない。このひとつの理由は、メールリー ダーは符号化-単語を含まない行を表示する前に全てのメッセージヘッ ダーを解析すると期待されていないからです。 6.2. 符号化-単語の表示 そうだと認められた符号化-単語 'encoded-word'は、デコード (復元化) さ れ、可能なら復元されたテキストは元の文字セットで表示します。 注意: 構造化された領域ボディがトークン (字句) の解析がなされた*後*、符 号化-単語のデコードと表示がおこなわれます。従って符号化-単語、表示され た時まわりのテキストの'special'文字と区別していて、内の'special'文字を 隠すことができます。これとその他の理由により、符号化-単語を含んでいる メッセージヘッダーを、RFC 822メールリーダーによって解析できるコード化 されていない形式に、翻訳することは一般的にはできません。 多元符号化-単語'encoded-word'を含む特殊なヘッダーを表示する場合、隣接 する符号化-単語'encoded-word'を分ける空白文字'linear-white-space'は無 視されます。 (スペースがコード化されていないテキストにある符号化-単語 'encoded-word'を分けなくてコード化されていない長いテキスト文字列を表現 するために多元符号化-単語'encoded-word'が使えます。) 別のコード化が将来定義され、メールリーダーが使用されているコード化をサ ポートしていないことがあったら、 (a) その符号化-単語'encoded-word'を普通 のテキストとして表示するかもしくは (b) そのテキストをデコードできないこ とを示唆する適切なメッセージを代わりにします。 メールリーダーが、使われている文字セットをサポートしていない場合、 (a) 符号化-単語'encoded-word'を普通のテキスト (ヘッダーに現われる通りに) として表示する、 (b) 入手可能な文字を使って表示するようにベストをつくす、 もしくは (c) デコードされたテキストを表示できないことを示唆する適切な メッセージが代わりをするかもしれません。 使われている文字セットがコード切り替え技術を採用しているなら、コード 化されたテキストの表示ははっきりと"ASCII mode"ではじまります。さらに メールリーダーは、符号化-単語'encoded-word'が表示された後出力装置が 再度"ASCII mode"になることを確認しなければなりません。 6.3. 間違って書式化された符号化-単語のメールリーダーの取り扱い セクション2で定義された構文にそって正当である符号化-単語が、使用され たコード化の規則にそって間違って書式化されることはありえます。例えば: (1) 特殊なコード化 (例えば、"B"コード化での "-" もしくは"B"や"Q"コード 化でのスペースやタブ) が正しくない文字を含む符号化-単語は、不正確 に書式化されています。 (2) 非整数の文字もしくはオクテットをコード化している符号化-単語は不正確 に書式化されています。 メールリーダーは、正しくない書式の符号化-単語'encoded-word'に付随する テキストを表示しようとする必要はありません。しかしメールリーダーは、符 号化-単語が間違って書式化されているので、メッセージを表示もしくは処理 を先駆けて行うべきではありません。 7. 適合性 この仕様書に従うと宣言しているメールリーダーは、'*text'もしくは'*ctext' 内で "=?"ではじまり"?="で終わる非空白印字可能なASCII文字は正しい符号化 -単語'encoded-word'であると確認しなければなりません。 (はじまるという 意味は: 領域ボディのはじまりで、空白スペース'linear-white-space'が直ぐくるもし くは '*ctext'内の'encoded-word'用の " ("がすぐくるか。終わり"ends"の意味 は: 領域ボディの終わりで、空白スペースがすぐ先行するもしくは'*ctext'内 の'encoded-word'用の " ("がすぐ先行する。さらに、"=?"ではじまり"?="で終 わる句'phrase'内の'word'はどれも正しい'encoded-word'でなければなりませ ん。 この仕様書の適合を宣言するメールリーダープログラムは、セクション6の規 則にそって、符号化-単語'encoded-word'形式を、メッセージヘッダーの適切 な場所に現われたら必ず、'text'・'ctext'もしくは'word'sと区別できなけれ ばなりません。メーラーがサポートする文字の"B"と"Q"コード化両方をサポー トしなければなりません。文字セットが"US-ASCII"なら、符号化されないテキ ストを表示できなければなりません。ISO-8859-*系文字セットでメールリー ダープログラムは、少なくともASCIIセットにある文字を表示できなくてはな りません。 8. 事例 以下に、符号化-単語encoded-word'sを含んだメッセージヘッダーの事例をあ げます: From: =?US-ASCII?Q?Keith_Moore?= To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= CC: =?ISO-8859-1?Q?Andr=E9?= Pirard Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= 注意: 上の最初のSubject領域の符号化-単語'encoded-word'で、 'encoded-text'の終わりにある最後の"="は必要で、というのは各符号化- 単語'encoded-word'は自己完結でなければならないからです ("="文字は、 2オクテットスを表現する4 base64文字のグループを完成します)。二番目 の符号化-単語'encoded-word'は最初のものとは異なった'charset'を使っ ていることを除けば、追加的なオクテットスは最初の符号化-単語 'encoded-word'ないでコード化され (ですから、符号化-単語'encoded- word'は3コード化の正確な倍数を含んでいます) ます。 From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se Subject: Time for ISO 10646? To: Dave Crocker Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: RFC-HDR care and feeding From: Nathaniel Borenstein (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=) To: Greg Vaudreuil , Ned Freed , Keith Moore Subject: Test of new header generator MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 以下の事例で、構造化された領域ボディ部にくる符号化-単語'encoded- word'sをテキストはどのように含み込むかを図解しています。'*text'として 定義された領域とは規則が多少異なっています、と言うのは" (" や ") " は 'comment'識別子として認められていないからです。[セクション5、パラグラ フ (1) ]。 以下の例で同じ列が'*text'領域にくるなら、"displayed as"形式は符号化-単 語encoded wordsとして処理しませんが、"encoded form"と同じです。これ は、以下の例での符号化-単語encoded-wordsが " ("もしくは") "文字に隣接し ているからです。 encoded form displayed as --------------------------------------------------------------------- (=?ISO-8859-1?Q?a?=) (a) (=?ISO-8859-1?Q?a?= b) (a b) コメント'comment'内では空白文字が符号化-単語'encoded-word'と 周囲のテキストの間に現われねばなりません。[セクション5、パラ グラフ (2) ]。しかし、コメントがはじまる初期の " (" と 空白文字 が符号化-単語'encoded-word'の間にくる必要はありません。 (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) 隣接する符号化-単語'encoded-word'間の空白文字は表示されません。 (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) 符号化-単語'encoded-word'間に複数の空白文字でさえ表示目的としては 無視されます。 (=?ISO-8859-1?Q?a?= (ab) =?ISO-8859-1?Q?b?=) 符号化-単語'encoded-word間の空白文字linear-space-white'が幾つ あっても、例えスペースに引き続いてCRLFがあっても、表示目的と しては無視されます。 (=?ISO-8859-1?Q?a_b?=) (a b) コード化されたテキストencoded text部分内で、スペースを表示 するには、スペースを符号化-単語 'encoded-word'の一部として コード化します。 (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b) コード化されたテキストencoded textの二つの文字列間でスペース を表示するには、スペースを符号化-単語 'encoded-word'の一つの 部分としてコード化します。 9. リファレンス [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [RFC 2049] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC 2045] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC 2046] Borenstein N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. 10. 安全性へ配慮 安全性問題はこの覚書では言及されていません。 11. 謝辞 The author wishes to thank Nathaniel Borenstein, Issac Chan, Lutz Donnerhacke, Paul Eggert, Ned Freed, Andreas M. Kirchwitz, Olle Jarnefors, Mike Rosin, Yutaka Sato, Bart Schaefer, and Kazuhiko Yamamoto, for their helpful advice, insightful comments, and illuminating questions in response to earlier versions of this specification. 12. 著者との連絡 Keith Moore University of Tennessee 107 Ayres Hall Knoxville TN 37996-1301 EMail: moore@cs.utk.edu 付録 - RFC 1552以後の変更 (順不動) + MIMEバージョンは符号化-単語を使うのに必須ではない、と明示的に宣言。 + 符号化-単語'encoded-word'はRFC 822パーサー値で'atom'のようにみられ ということを明白にするため、符号化-単語'encoded-word's内でスペース やタブは許されませんと、正確にするために明示的な注意を加えた。 + Olle Jarnefors (thanks!) 氏の例を加え、隣接する空白文字のある符号化- 単語がどのように表示するかを図解しています。 + RFC 822で定義された用語とこの覚書での参照を明確にリスト + テキストで一ないし二行と二文字がテキストで消えるという複写誤植を修正。 (due to nroff quirks) + 符号化-単語encoded-wordsは、RFC 822ヘッダーやMIMEボディパートヘッダー 両者の'*text'領域で許されますが、パラメーター値としては許されなこと を明確にする。 + コード切り替え文字列を使用する文字では、符号化-単語'encoded-word'の コード化部分内でASCIIに戻る必要性を明確にする。 + コメント内で、*textでなく (奇妙です)、 " (" と ") "で区切られた符号 化-単語'encoded-word'sについての注を追加。 + Andre Pirardの事例で、 =E9の後に尾を引いていた"_"を取り除き、修正す る。 (no longer needed post-1342). + 宣言: 符号化-単語'encoded-word'は、*ctext.の*中*の" ("と") " に隣接し ないで、コメント区切る初めの" ("に直ぐ続いてもしくは終わりの ") "の直 ぐ前にきます。 + "B"符号化ー単語'encoded-word'は必ずコード化テキスト'encoded-text'部 分で4文字倍数を持っていることを明白にする注意を追加。 + 事例で、 "="について注意。 + 符号化-単語'encoded-word'sの処理は解析後に起こり、従って巻添えが起こ ることに注意 + 1552と基本の822もしくは所謂"8-bit headers"間で翻訳できると考えるこ とができないと明示的に宣言。 + 符号化-単語'encoded-word'sは、引用記号'quoted-string'内では正しくな いと明示的に宣言。