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 テキストとしている。一口 　　に Multipurpose Internet Mail Extensions, MIME と呼ばれるドキュメン 　　トのセットはメッセージの形式として以下を許可するように再定義している: 　　(1) US-ASCII 以外の文字セットにおけるテキストメッセージボディ 　　(2) 非テキストボディに対する異なる形式の拡張セット 　　(3) マルチパートメッセージボディ 　　(4) US-ASCII 以外の文字セットでのテキストヘッダ情報 　　これらのドキュメントは RFC 934, STD 11 と RFC 1049 で記述されている 　　初期の作業を元にしているが、それらを拡張して改訂している。RFC 822 　　はメッセージボディに関してほとんど言及していないため、これらのドキュ 　　メントは RFC 822 に (改訂というより) 広く直行している。 　　この個別のドキュメントはこのシリーズの第三のドキュメントである。これ 　　はインターネットメールヘッダフィールドに非　US-ASCII テキストデータ 　　を許可するため、RFC 822 への拡張を詳述する。 　　このシリーズのほかのドキュメントは以下を含む: 　　+ RFC 2045, MIME メッセージの構造を記述するために使用されるさまざま 　　 なヘッダの説明。 　　+ 2046, MIME メディアタイプシステムの一般構造の定義とメディアタイプ 　　　の初期セットの定義。 　　+ RFC 2048, MIME に関連した機関のさまざまな IANA 登録手順。 　　+ RFC 2049, MIME 標準順応性と MIME メッセージフォーマットの実例、謝 　　　辞、文献。 　　これらのドキュメントは RFC 1521, 1522, 1590 の改訂であり、それら自身 　　RFC 1341, 1342 の改訂であった。RFC 2049 の付録は前バージョンからの相 　　違と変更を記述している。 【1. イントロダクション】 　　RFC 2045 はさまざまな文字セットでコード化されたメッセージボディ部分 　　を印字可能な US-ASCII 文字のシーケンスとして符号化するための方法だけ 　　でなく、そのようなテキストボディ部分を表すためのメカニズムを記述する。 　　この記述はさまざまな RFC 822 [2] メッセージヘッダの部分の非 ASCII テ 　　キストを符号化できる、ある程度既存のメッセージ処理ソフトウェアを混乱 　　させないような類似した技術を記述する。 　　RFC 2045 で記述されている符号化技術と類似して、ここで概説されている 　　技術は既存のインターネットメッセージ処理プログラムの急変によって混乱 　　させられない方法で、メッセージヘッダにおいて非 ASCII 文字が使用でき 　　るように設計されている。特に、いくつかのメール伝達プログラムは (a) 　　他を残す一方であるメッセージヘッダを削除し、(b) To や Cc フィールド 　　のアドレス順序を変更し、(c) ヘッダフィールドの (縦方向の) 順序を変更 　　し、そして (d) オリジナルのメッセージにおけるメッセージヘッダの場所 　　を別のところに "wrap" すると知られている。さらに、いくつかのメール読 　　み出しプログラムは、RFC 822 にしたがって合法的であるが、"<"、","、":" 　　のような特殊文字を "隠す" ため、バックスラッシュ引用を使ったり、その 　　仕様書のめったに使用されない別の機能を利用しているメッセージヘッダを 　　正確に解析する事が困難であると分かっている。 　　これらのプログラムは RFC 822 ヘッダを正確に中間処理しないため不適切 　　であるが、これらのプログラムを "中断" する事は、インターネットメール 　　システムに対する深刻な運営上の問題を引き起こす。そのため、この記述で 　　詳述される拡張は RFC 822 のほとんど使用されていない機能に頼らない。 　　代わりに、("符号化文字" として知られる) "普通の" 印字可能な ASCII 文 　　字の特定のシーケンスが符号化されたデータとして使用するため予約されて 　　いる符号化文字の構文は、メッセージヘッダにおいて通常のテキストとして 　　"偶然的に" 現れないようなものである。さらに、符号化文字で使用されて 　　いる文字は、符号化文字が現れる状況で特別な意味を持たないように制限さ 　　れている。 　　一般的に、"符号化文字" は "=?" で始まり "?=" で終了する印字可能な 　　ASCII 文字のシーケンスであり、その間に "?" を二つもつ。これは文字 　　セットと符号化方法を記述し、その符号化方法のルールに従って符号化され 　　たグラフィック ASCII 文字のオリジナルテキストも含んでいる。 　　この仕様書を実装するメール製作プログラムはヘッダフィールドに非 ASCII 　　文字を入れる方法を供給するだろうが、メッセージヘッダにこれらのフィー 　　ルドを挿入する前に、符号化文字の中にこれらのフィールド (もしくはその 　　適当な一部) を変換するだろう。 　　この仕様書を実装するメール読み出しプログラムは、メッセージヘッダのあ 　　る一部に符号化文字が現れた時、それらを認識するだろう。符号化文字を 　　"そのまま" 表示する代わり、符号化文字を元に戻して指定された文字セッ 　　トでオリジナルテキストを表示するだろう。 注意 　　この記述は RFC 822 と RFC 2045 で定義されている表記法と用語に密に頼っ 　　ている。特に、この記述で使用されている ABNF 構文は RFC 822 で定義さ 　　れている。 This memo relies heavily on notation and terms defined RFC 822 and RFC 2045. In particular, the syntax for the ABNF used in this memo is defined in RFC 822, as well as many of the terminal or nonterminal symbols from RFC 822 are used in the grammar for the header extensions defined here. Among the symbols defined in RFC 822 and referenced in this memo are: 'addr-spec', 'atom', 'CHAR', 'comment', 'CTLs', 'ctext', 'linear-white-space', 'phrase', 'quoted-pair'. 'quoted-string', 'SPACE', and 'word'. Successful implementation of this protocol extension requires careful attention to the RFC 822 definitions of these terms. When the term "ASCII" appears in this memo, it refers to the "7-Bit American Standard Code for Information Interchange", ANSI X3.4-1986. The MIME charset name for this character set is "US-ASCII". When not specifically referring to the MIME charset name, this document uses the term "ASCII", both for brevity and for consistency with RFC 822. However, implementors are warned that the character set name must be spelled "US-ASCII" in MIME message and body part headers. This memo specifies a protocol for the representation of non-ASCII text in message headers. It specifically DOES NOT define any translation between "8-bit headers" and pure ASCII headers, nor is any such translation assumed to be possible. 【2. 符号化文字の構文】 　　'符号化文字' は以下の ABNF 構文によって定義される。'符号化文字' の中 　　に空白文字が含まれては *いけない* 以外、RFC 822 の表記法が使用されて 　　いる。 　　encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" 　　charset = token ; 3 章参照 　　encoding = token ; 4 章参照 　　token = 1* 　　especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" 　　encoded-text = 1*<"?" や SPACE 以外のすべての印字可能な ASCII 文字> ; (ただし、5 章の "メッセージヘッダでの符号化文字の ; 使用" 参照) 　　'encoding' と 'charset' 名の両方は大文字と小文字を区別しない。従って、 　　文字セット名 "ISO-8859-1" は "iso-8859-1" と等価であり、符号化名 "Q" 　　は "Q" もしくは "q" のどちらでも記す事ができる。 　　'charset', 'encoding', 'encoded-text' と区切り文字を含めて、'符号化 　　文字' は 75 文字長を超えないだろう。もしそれ以上のテキストを 75 文字 　　の '符号化文字' に一致するように符号化する事を望むなら、複数の '符号 　　化文字' (CRLF SPACE で区切られた) を使用できる。 　　複数行ヘッダフィールドの長さに制限はないが、一つ以上の '符号化文字' 　　を含むヘッダフィールドのそれぞれの行は 76 文字に制限される。 　　この長さ制限は、ネットワークメールゲートウェイを通しての中間処理性を 　　容易にし、トークンが "符号化文字" か他の文字かを決定できる前に、ヘッ 　　ダパーサが (最後の ?= 区切りを見つけるまでの間) 使用しなければならな 　　い前方参照の数の制限を課すために加えられた。 　　*重要*: '符号化文字' は RFC 822 パーサによって 'アトム' として認識さ 　　れるように設計されている。結果として、符号化されていない空白文字 　　(SPACE や HTAB など) は '符号化文字' の中で *禁止されている*。たとえ 　　ば、文字シーケンス 　　　=?iso-8859-1?q?this is some text?= 　　は、(RFC 822 パーサによって) 単一の 'アトム' や ('符号化文字' を理解 　　するパーサによって) '符号化文字' ではなく、四つの 'アトム' として解 　　析される。文字列 "this is some text" を符号化する正しい方法は、さら 　　に SPACE 文字を符号化する事である。e.g. =?iso-8859-1?q?this=20is=20some=20text?= 　　'符号化テキスト' に現れる事のできる文字は 5 章のルールによってさらに 　　制限されている。 【3. charset】 　　'符号化文字' の一部である 'charset' は符号化されていないテキストに関 　　連する文字セットを記述する。'charset' は "text/plain" ボディパートの 　　MIME "charset" パラメータで許可される名前の文字セット、もしくは MIME 　　text/plain content-type と共に使用する IANA に登録された文字セット名 　　のどんなものでも可能である。 　　いくつかの文字セットは "ASCII モード" と他のモードをスイッチするため、 　　コードスイッチ技術を使用する。もし '符号化文字' の符号化されていない 　　テキストが、文字セットインタープリタを ASCII モードをスイッチアウト 　　させるシーケンスを含むなら、ASCII モードが '符号化文字' の終端に再度 　　選ばれるような追加的な制御コードを含まなければ *ならない* (このルー 　　ルは、単一のヘッダフィールド内の隣接した '符号化文字' を含む、 　　それぞれの '符号化文字' にそれぞれ適用される)。 　　'符号化文字' や、メッセージの送信者と受信者の間のプライベートな同意 　　の欠如でテキストを表現するため、一つ以上の文字セットを使用する可能性 　　がある場合、ISO-8859-* シリーズの一つが別の文字セットより優先して使 　　用される事を勧める。 【4. encoding】 　　はじめに、"encoding" に対する合法的な値は "Q" と "B" である。これら 　　のエンコーディングは下記に記述されている。"Q" エンコーディングは符号 　　化されている文字のほとんどが ASCII 文字セットである時の使用が勧めら 　　れる; そうでなければ、"B" エンコーディングが使用されるべきである。た 　　だし、'符号化文字' を認識すると主張するメール読み出しプログラムは、 　　それがサポートするすべての文字セットに対するどちらのエンコーディング 　　も受け入れられなければ *ならない*。 　　印字可能な ASCII 文字セットのサブセットのみが '符号化テキスト' で使 　　用できる。'符号化文字' の開始と終了が明確なため、スペースとタブ文字 　　は許可されない。"?" 文字は '符号化文字' のさまざまな部分とその他の部 　　分を分割するため '符号化文字' の中で使用される。従って、'符号化テキ 　　スト' の一部として現れる事はできない。他の文字も特定な状況で非合法的 　　である。たとえば、From ヘッダフィールドのアドレスに先行する 'phrase' 　　での '符号化文字' は、RFC 822 で定義されている "specials" のどんなも 　　のも含まないだろう。結果的に、ネットワークメールゲートウェイを通って 　　渡されるメッセージの信頼性を保証するため、その他の特定の文字はいくつ 　　かの状況で許可されない。 　　"B" エンコーディングは自動的にこれらの要求を満たしている。"Q" エン 　　コーディングは、他の場所で有効に使われている少数の文字で、印字可能な 　　文字のワイドレンジをメッセージヘッダの重要でない場所 (e.g., Subject) 　　において使用できるようになっている。 4.1. "B" エンコーディング 　　"B" エンコーディングは RFC 2045 で定義されている "BASE64" エンコー 　　ディングを示している。 4.2. "Q" エンコーディング 　　"Q" エンコーディングは RFC 2045 で定義されている "Quoted-Printable" 　　content-transfer-encoding と類似している。これは、主に ASCII 文字を 　　含むテキストが複合化を行わないまま ASCII 端末上で判読可能であるよう 　　に設計されている。 　　(1) すべての 8 ビット値は二つの 16 進数値を伴う "=" で表す事ができる。 　　　　たとえば、もし使用されている文字セットが ISO-8859-1 圏であれば、 　　　　"=" 文字は "=3D"、SPACE は "=20" として符号化されるだろう ("A" 　　　　から "F" までの大文字が 16 進数として使用される)。 　　(2) 8 ビット 16 進数値 20 (e.g., ISO-8859-1 SPACE) は "_" (アンダー 　　　　スコア, ASCII 95) として表す事ができる (この文字はいくつかのネッ 　　　　トワークメールゲートウェイに渡す事ができないが、その使用はこのエ 　　　　ンコーディングをサポートしていないメール読み出しプログラムの "Q" 　　　　符号化データの可読性を非常に高めるだろう)。たとえ SPACE 文字が使 　　　　用されている文字セットで異なるコード領域を占有しているとしても、 　　　　"_" は常に 16 進数 20 を表す事に注意。 　　(3) "=", "?", "_" (アンダースコア) 以外の印字可能な ASCII 文字と一致 　　　　する 8 ビット値はそのまま表す事が *できる* (ただし制限に対して 5 　　　　章参照)。特に、SPACE と TAB は符号化された文字の中に現れては *な 　　　　らない*。 【5. メッセージヘッダでの符号化文字の使用】 　　'符号化文字' はいかのルールに従ってメッセージヘッダもしくはボディ 　　パートヘッダに現れる: (1) '符号化文字' は　Subject や Comment ヘッダフィールドの 'text' トーク 　　ン (RFC 822 で定義されている)、すべての拡張メッセージヘッダフィール 　　ド、フィールドボディが '*text' として定義されているすべての MIME ボ 　　ディパートフィールドとおきかえる事ができる。'符号化文字' はすべての 　　ユーザ定義のメッセージ ("X-") やボディパートヘッダフィールドに現れる 　　事もできる。 　　普通の ASCII テキストと '符号化文字' はあるヘッダフィールドで共に現 　　れる事ができる。しかしながら、'*text' として定義されているヘッダフィー 　　ルドに現れる '符号化文字' は、'linear-white-space' によって隣接した 　　'符号化文字' や 'text' を区切らなければ *ならない*。 (2) '符号化文字' は "(" と ")" で区切られて 'comment' 内に現れる事ができ 　　る。i.e., 'ctext' が許されるところならどこでも。より厳密には、 　　'comment' に対する RFC 822 ABNF 定義が以下のように訂正される: 　　　comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" 　　'comment' に現れる "Q" で符号化された '符号化文字' は文字 "("、")"、 　　" (訳注: ダブルクォート?) を含んでは *ならない*。'comment' に現れる 　　'符号化文字' は 'linear-white-space' によって隣接する '符号化文字' 　　や 'ctext' と分けられなければ *ならない*。 　　'comment' は "構造化された" フィールドボディの中でのみ認識される事に 　　注意する事が重要である。ボディが '*text' として定義されているフィー 　　ルドにおいて、"(" と ")" はコメント区切りではなく正規の文字として扱 　　われ、この章のルール (1) が適用する (RFC 822, 3.1.2, 3.1.3 章参照)。 (3) 'phrase' 内の 'word' エンティティの置き換えとして、たとえば From, 　　To, Cc ヘッダのアドレスに先行するもの。RFC 822 からの 'phrase' の 　　ABNF 定義は以下のようになる: 　　　phrase = 1*( encoded-word / word ) 　　この場合、"Q" で符号化された '符号化文字' で使用される文字のセットは 　　<大文字と小文字の ASCII 文字, 10 進数値, "!", "*", "+", "-", "/", 　　"=", "_" (アンダースコア, ASCII 95)> に制限される。'phrase' に存在す 　　る '符号化文字' は 'linear-white-space' によって隣接するすべての 　　'word', 'text', 'special' と分割されなければ *ならない*。 　　これらは '符号化文字' が存在できる場所 *のみ* である。特に: 　　+ '符号化文字' は 'addr-spec' のどの場所にも存在しては *ならない*。 　　+ '符号化文字' は 'quoted-string' のどの場所にも存在しては *ならない*。 　　+ '符号化文字' は Received ヘッダフィールドで使用されては *ならない*。 　　+ '符号化文字' は MIME Content-Type や Content-Desposition フィール 　　　ドのパラメータや、'comment' や 'phrase' を除くすべての構造化された 　　　フィールドボディで使用されては *ならない*。 　　'符号化文字' における '符号化テキスト' は self-contained でなければ 　　ならない: '符号化テキスト' はある '符号化文字' から別のものに続いて 　　は *ならない*。これは、"B" '符号化文字' の '符号化テキスト'部分が 4 　　文字長の倍数となる事を意味する; "Q" '符号化文字' に対して、'符号化文 　　字' の一部に存在するすべての "=" 文字は二つの 16 進数文字を伴う。 　　それぞれの '符号化文字' は 8 ビットバイトの整数値で符号化されなけれ 　　ば *ならない*。それぞれの '符号化文字' の '符号化テキスト' はエンコー 　　ディングで指定されているようにうまく形成されていなければならない; 　　'符号化テキスト' は次の '符号化文字' に続けることはできない (たとえ 　　ば、"=?charset?Q?=?= =?charset?Q?AB?=" は二つの 16 進数値 "AB" が同 　　じ '符号化文字' で "=" に続かなければならないため、不正である)。 　　それぞれの '符号化文字' は文字の整数値を表さなければ *ならない*。複 　　数の 8 ビットバイト文字は隣接する '符号化文字' をまたがって分割でき 　　ない。 　　印字可能な文字と空白文字データのみがこのスキームを使用して符号化され 　　るべきである。しかしながら、これらの符号化スキームが独断的な 8 ビッ 　　トバイト値の符号化を可能にしているため、この複合化を実装するメール読 　　み出しプログラムも、受信者の端末上で符号化されたデータを表示する事が 　　不測の副作用を引き起こさない事を保証しなければならない。 　　非テキストデータ (e.g., 画像や音声) を符号化するためのこれらの方法の 　　使用はこの記述において定義されない。純粋な ASCII 文字の文字列を表す 　　ため '符号化文字' の使用は許されるが、控えるべきである。まれな場合と 　　して、'符号化文字' に見える元のテキストを符号化するために必要であろ 　　う。 【6. メールヘッダによる '符号化文字' のサポート】 6.1. メッセージヘッダでの '符号化文字' の認識 A mail reader must parse the message and body part headers according to the rules in RFC 822 to correctly recognize 'encoded-word's. 'encoded-word's are to be recognized as follows: (1) Any message or body part header field defined as '*text', or any user-defined header field, should be parsed as follows: Beginning at the start of the field-body and immediately following each occurrence of 'linear-white-space', each sequence of up to 75 printable characters (not containing any 'linear-white-space') should be examined to see if it is an 'encoded-word' according to the syntax rules in section 2. Any other sequence of printable characters should be treated as ordinary ASCII text. (2) Any header field not defined as '*text' should be parsed according to the syntax rules for that header field. However, any 'word' that appears within a 'phrase' should be treated as an 'encoded-word' if it meets the syntax rules in section 2. Otherwise it should be treated as an ordinary 'word'. (3) Within a 'comment', any sequence of up to 75 printable characters (not containing 'linear-white-space'), that meets the syntax rules in section 2, should be treated as an 'encoded-word'. Otherwise it should be treated as normal comment text. (4) A MIME-Version header field is NOT required to be present for 'encoded-word's to be interpreted according to this specification. One reason for this is that the mail reader is not expected to parse the entire message header before displaying lines that may contain 'encoded-word's. 6.2. '符号化文字' の表示 Any 'encoded-word's so recognized are decoded, and if possible, the resulting unencoded text is displayed in the original character set. NOTE: Decoding and display of encoded-words occurs *after* a structured field body is parsed into tokens. It is therefore possible to hide 'special' characters in encoded-words which, when displayed, will be indistinguishable from 'special' characters in the surrounding text. For this and other reasons, it is NOT generally possible to translate a message header containing 'encoded-word's to an unencoded form which can be parsed by an RFC 822 mail reader. When displaying a particular header field that contains multiple 'encoded-word's, any 'linear-white-space' that separates a pair of adjacent 'encoded-word's is ignored. (This is to allow the use of multiple 'encoded-word's to represent long strings of unencoded text, without having to separate 'encoded-word's where spaces occur in the unencoded text.) In the event other encodings are defined in the future, and the mail reader does not support the encoding used, it may either (a) display the 'encoded-word' as ordinary text, or (b) substitute an appropriate message indicating that the text could not be decoded. If the mail reader does not support the character set used, it may (a) display the 'encoded-word' as ordinary text (i.e., as it appears in the header), (b) make a "best effort" to display using such characters as are available, or (c) substitute an appropriate message indicating that the decoded text could not be displayed. If the character set being used employs code-switching techniques, display of the encoded text implicitly begins in "ASCII mode". In addition, the mail reader must ensure that the output device is once again in "ASCII mode" after the 'encoded-word' is displayed. 6.3. 不正に形成された '符号化文字' を処理するメール読み出しプログラム It is possible that an 'encoded-word' that is legal according to the syntax defined in section 2, is incorrectly formed according to the rules for the encoding being used. For example: (1) An 'encoded-word' which contains characters which are not legal for a particular encoding (for example, a "-" in the "B" encoding, or a SPACE or HTAB in either the "B" or "Q" encoding), is incorrectly formed. (2) Any 'encoded-word' which encodes a non-integral number of characters or octets is incorrectly formed. A mail reader need not attempt to display the text associated with an 'encoded-word' that is incorrectly formed. However, a mail reader MUST NOT prevent the display or handling of a message because an 'encoded-word' is incorrectly formed. 【7. 順応性】 A mail composing program claiming compliance with this specification MUST ensure that any string of non-white-space printable ASCII characters within a '*text' or '*ctext' that begins with "=?" and ends with "?=" be a valid 'encoded-word'. ("begins" means: at the start of the field-body, immediately following 'linear-white-space', or immediately following a "(" for an 'encoded-word' within '*ctext'; "ends" means: at the end of the field-body, immediately preceding 'linear-white-space', or immediately preceding a ")" for an 'encoded-word' within '*ctext'.) In addition, any 'word' within a 'phrase' that begins with "=?" and ends with "?=" must be a valid 'encoded-word'. A mail reading program claiming compliance with this specification must be able to distinguish 'encoded-word's from 'text', 'ctext', or 'word's, according to the rules in section 6, anytime they appear in appropriate places in message headers. It must support both the "B" and "Q" encodings for any character set which it supports. The program must be able to display the unencoded text if the character set is "US-ASCII". For the ISO-8859-* character sets, the mail reading program must at least be able to display the characters which are also in the ASCII set. 【8. 例】 　　以下は '符号化文字' を含むメッセージヘッダの例である: 　　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 フィールドの最初の '符号化文字' で、'符号化テ 　　　キスト' 最後の "=" は 　　　それぞれの '符号化文字' が self-contained' でなければならないため 　　　("=" 文字は Note: In the first 'encoded-word' of the Subject field above, the last "=" at the end of the 'encoded-text' is necessary because each 'encoded-word' must be self-contained (the "=" character completes a group of 4 base64 characters representing 2 octets). An additional octet could have been encoded in the first 'encoded-word' (so that the encoded-word would contain an exact multiple of 3 encoded octets), except that the second 'encoded-word' uses a different 'charset' than the first one. 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 The following examples illustrate how text containing 'encoded-word's which appear in a structured field body. The rules are slightly different for fields defined as '*text' because "(" and ")" are not recognized as 'comment' delimiters. [Section 5, paragraph (1)]. In each of the following examples, if the same sequence were to occur in a '*text' field, the "displayed as" form would NOT be treated as encoded words, but be identical to the "encoded form". This is because each of the encoded-words in the following examples is adjacent to a "(" or ")" character. encoded form displayed as --------------------------------------------------------------------- (=?ISO-8859-1?Q?a?=) (a) (=?ISO-8859-1?Q?a?= b) (a b) Within a 'comment', white space MUST appear between an 'encoded-word' and surrounding text. [Section 5, paragraph (2)]. However, white space is not needed between the initial "(" that begins the 'comment', and the 'encoded-word'. (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) White space between adjacent 'encoded-word's is not displayed. (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) Even multiple SPACEs between 'encoded-word's are ignored for the purpose of display. (=?ISO-8859-1?Q?a?= (ab) =?ISO-8859-1?Q?b?=) Any amount of linear-space-white between 'encoded-word's, even if it includes a CRLF followed by one or more SPACEs, is ignored for the purposes of display. (=?ISO-8859-1?Q?a_b?=) (a b) In order to cause a SPACE to be displayed within a portion of encoded text, the SPACE MUST be encoded as part of the 'encoded-word'. (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b) In order to cause a SPACE to be displayed between two strings of encoded text, the SPACE MAY be encoded as part of one of the 'encoded-word's. 【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 1522 からの変更 (順不同)】 + explicitly state that the MIME-Version is not requried to use 'encoded-word's. + add explicit note that SPACEs and TABs are not allowed within 'encoded-word's, explaining that an 'encoded-word' must look like an 'atom' to an RFC822 parser.values, to be precise). + add examples from Olle Jarnefors (thanks!) which illustrate how encoded-words with adjacent linear-white-space are displayed. + explicitly list terms defined in RFC822 and referenced in this memo + fix transcription typos that caused one or two lines and a couple of characters to disappear in the resulting text, due to nroff quirks. + clarify that encoded-words are allowed in '*text' fields in both RFC822 headers and MIME body part headers, but NOT as parameter values. + clarify the requirement to switch back to ASCII within the encoded portion of an 'encoded-word', for any charset that uses code switching sequences. + add a note about 'encoded-word's being delimited by "(" and ")" within a comment, but not in a *text (how bizarre!). + fix the Andre Pirard example to get rid of the trailing "_" after the =E9. (no longer needed post-1342). + clarification: an 'encoded-word' may appear immediately following the initial "(" or immediately before the final ")" that delimits a comment, not just adjacent to "(" and ")" *within* *ctext. + add a note to explain that a "B" 'encoded-word' will always have a multiple of 4 characters in the 'encoded-text' portion. + add note about the "=" in the examples + note that processing of 'encoded-word's occurs *after* parsing, and some of the implications thereof. + explicitly state that you can't expect to translate between 1522 and either vanilla 822 or so-called "8-bit headers". + explicitly state that 'encoded-word's are not valid within a 'quoted-string'. 【13. 和訳作業】 開始: 1999年12月19日 完訳: 訳者: ToRA. URL : http://www.mars.dti.ne.jp/~torao/program/index.html 補足: