が原著です。 翻訳版は、翻訳からくる間違いがあり得ます。 Yasutaka Kato 加藤泰孝 ----------------------------------------------------------------------  rfc1896 Network Working Group P. Resnick Request for Comments: 1896 QUALCOMM Obsoletes: 1523, 1563 A. Walker Category: Informational InterCon February 1996 The text/enriched MIME Content-type text/enriched マインム内容タイプ この覚書の位置付け この覚書はインターネット交流社会の情報を提供します。この覚書は如何なる 種類のインターネット標準を特定するものではありません。この覚書の配布に 制限はありません。 要約 MIME [RFC-1521]は、インターネットメールの様々なデータータイプの表現の 書式と一般的な枠組みを定義しています。この文書はMIMEデーターのひとつの 特殊なタイプ、text/enriched マインムタイプを定義します。text/enriched マインムタイプは、幅広いハードウェアーとソフトウェアーの交流でシンプル な豊かなテキスト (enriched text) の広い相互操作性を装備するよう意図さ れています。この文書は、[RFC-1523]と[RFC-1563]で最初に記載された豊かな テキスト (enriched text) サブタイプの小幅な改訂版に過ぎなく、インター ネットメールでテキスト整形の別のタイプが配置される迄、短期間使用するこ とを意図しているだけです。 text/enriched マインムタイプ 単純な整形されたテキストの幅広い相互操作性を促進するために、この文書は MIME内容タイプ"text"の非常に単純なサブタイプ、"text/enriched"サブタイ プ、を定義します。このタイプの内容タイプ行は、"text/plain"MIME内容タイ プに許されているのと同じ値を取る一つのパラメーター、"charset" パラメー ター、を持っています。 text/enriched サブタイプは、以下の規範に合うように設計されました: 1. 構文は解析するのに非常に単純で、従ってテレタイプ指向のメールシステ ムでさえも容易にこの整形する情報を取り去り、判読可能なテキストだけ を解き放ちます。 2. 構文は新しい整形指示命令、アプリケーションによっては本質と考えられる、 ができるように拡張性でなければなりません。 3. 使用されている文字セットがASCIIないしは8ビットASCII上位セットなら、 データーの生の書式は、万一MIME非適合のメールリーダーの利用者の画面 で表示されることになっても、殆ど異議なく十分判読できなければなりま せん。 4. 能力は、利用者の初歩的なワードプロセッサーでも表現できそうである以 上ののものは表現できないことを保証するために、非常に限定されなけれ ばなりません。これは何を送信するかを制限する一方、送信されたものが 適切に表示されることができる公算を高めます。 これらの規範のあるものに合うテキスト整形標準が他にもあります。特に、 HTMLとSGMLはインターネットで広く行き渡って使われています。しかし、この 文書がそのような他の標準を越えてインターネットメールでtext/enrichedの 使用を進めるには二つの重要な理由があります: 1. 大部分のMIMEが分かるインターネットメールアプリケーションは、text/ enrichedメールを適切に書式化するか、もしくは少なくとも整形指示命令 (コマンド) を取り去り判読可能なテキストを表示することが既にできま す。HTMLやSGMLでは同じようにはいきません。 2. 最近のHTMLに関するRFC [RFC-1866]やSGMLに関するインターネットドラフ トは、多くの機能、インターネットメールには必要ない、を備え、text/ enrichedが既に持っている幾つかの能力を外れ守っていません。 これらの理由から、この文書はtext/enrichedの使用、別のインターネット標 準の使用がより広く行き渡る迄、を薦めています。HTMLを使いたいたい人に は、この文書の付録Bに、text/enrichedを[RFC-1866]に記載されているHTML 2.0に変換するシンプルなCプログラムがあります。 構文 "text/enriched"の構文 (使い方) は非常に単純です。単一文字セット--規定 値はUS-ASCII、で、異なる文字セットは"charset"パラメーターを使って特定 されますが、テキストを表現します。 (非ASCII文字セットでのtext/enriched の意味は、この文書の後半で言及されます。) 文字全ては、書式命令の始め をマークするのに使用される"<"文字 (ASCII 60) を除いて、自分自身を表 します。字義通りのより小さいという記号 ("<") は、二つのそのような文 字の連続体、 "<<"によって表現されることができます。 整形指令は、角括弧 ("<>", ASCII 60 と 62) で囲われた整形指示命令から 構成されます。各整形指示命令は長さで60文字を超さないで、全てがアルファ ベットとハイフェン ("-") 文字に制限されたUS-ASCIIです。各整形指示命令 は個相線 ("/", ASCII 47) によって先行されるかもしれなく、それらを否定し、 そのような否定は始めの開く命令とバランスをとるために必ず存在しなければ なりません。かくて、書式命令 ""が同じ点で現われるならバランスを とるために後のは""でなければなりません。 (書式命令での60文字制 限は、そのような命令に沿え付けられる"<", ">"・もしくは"/" 文字を含まな いことに注意してください。) 書式命令は何時も大文字小文字を区別しません。 言い替えると"bold"と"BoLd"は効果の上では、好みの上ではそうでないとして も、同じものです。 行分断規則 行分断 (標準ネットワーク表現でCRLF組) は、特別に取り扱われます。特に、 個別のCRLF組は単一スペース文字に変換されます。しかし、N連続CRLF組の連 続体は、N-1の実際の行分断に変換されます。これが、インターネットメール で行ラップの頻度に関わらず、長い行を自然な見え方で表現することを許して います。メール転送を準備する場合個別行分断を、各々を80文字以下に保つ必 要がある所に、挿入すべきです。利用者に表現するためにそのようなデーター を準備する場合、個別行分断は単一スペースに置き換えられなければならな く、N連続CRLF組はN-1行分断として利用者に表現されるべきです。 かくて、text/enriched データーは以下のように見えます: This is a single line This is the next line. This is the next section. は、text/enriched解釈者によって以下のように表示されるべきです: This is a single line This is the next line. This is the next section. 書式命令 (コマンド) は、手段提供者全てによって装備されているもの全部で はありませんが、以下のセクションで説明されます。 書式命令 (Formatting Commands) 訳者注 [マーク付け命令 (Markup Commands) へ][本文の事例へ] 書式命令は全てで始まり、で終わり、この二つ の字句 (トークン) の間のテキストの整形に影響します。この命令はここで、 タイプに従ってグループ化し、説明します。 パラメーター命令 (Parameter Command) 書式命令によっては、一つ以上の協調パラメーターを要求するかもしれませ ん。"param"命令はこれらのパラメーターを含むために使用される特別な整形 命令です。 Param 影響を受けるテキストを命令パラメターとしてマークし、text/ enriched解釈者は解釈もしくは無視したりしますが、読み手には見せ ません。"param"命令は必ず別の書式命令に直ぐ引き続かなければなら なく、そのパラメーターデータは施されている整形についての追加的 な情報を示唆しています。パラメーターデータ ( (始めの""と 終の""の間に来るものは何でも) の構文が、使用する各命令 を定義します。しかし、そのようなデーターの書式は、ネストされた "param"命令を内容にしてはいけないし、"<" 文字を使用してはいけな くて、text/enriched解析と互換性がある方法で使用しなければなりま せん。つまり、パラメーターデーターの終は二つのアルゴリズムのど ちらかで認識されるべきです: 単純に最初に来る""を探すか もしくは均衡の取れた "<;/param>"命令が見つかるまで解析するかです。 しかし、どちらの場合でも、パラメーターデーターは読み手に見せら れるべきではありません。 字体変更命令 (Font-Alteration Commands) 以下の書式命令は、テキストを表示する際文字を変更することを狙ったもの で、字下げやテキストの均等状態を変更するものではありません: Bold 影響を受けるテキストをボールド (太字) 体にします。入れ子された bold命令は単一bold命令と同じ効果を持ちます。 Italic 影響を受けるテキストをイタリック (斜) 体にします。入れ子された italic命令は単一italic命令と同じ効果を持ちます。 Underline 影響を受けるテキストに下線を付けます。入れ子された下線命令は単 一下線命令と同じ効果を持ちます。 Fixed 影響を受けるテキストを等幅文字にします。入れ子された等幅命令は単 一等幅命令と同じ効果を持ちます。 FontFamily 影響を受けるテキストは特別な文字体で表示されます。"fontfamily" 命令は、"param"命令を使って特定されるパラメーターが必須です。こ のパラメーターデータは大文字小文字の区別があり文字族名を含む文 字列です。現在入手できるどんな文字でも (例えば、Times・ Palatino・Courierなど)、使用されます。これには、 Adobe.BitStreamなどの商業文字体製造者もしくはその他の業者に よって定義された文字体族も含まれます。装備 (道具立て) は、特殊 な文字体名でなく、一般的な文字体族名だけ (例えば"Times"であって "TimesRoman"や"TimesBoldItalic"ではなく) を使用すべきです。入れ 子の場合、内側の"fontfamily"命令が優先されます。また、 "fontfamily"命令はただ助言的であるだけであることに注意してくだ さい; 別の装備も、システムの文字能力は様々なので、この命令の文 字体情報を尊重すると期待べきではありません。 Color 影響を受けるテキストを特定された色で表示します。"color"命令には "param"命令を使って特定されたパラメーターが必須です。このパラ メーターデータは以下の中の一つです: red blue green yellow cyan magenta black white もしくは以下の書式のRGB色値です: ####,####,#### ここでの '#' は'0' から '9' までの十六進値・ 'F', or 'a' ・'a' から'f' です。十六進4桁値の三つはそれぞれ赤・緑そして青で、各構 成要素は 0 (0000) と 65535 (FFFF) の間の無署名の値として表現され ます。メッセージの色既定値、多くの環境で黒が一般的な選択です が、は特定されていません。入れ子の場合内側の "color" 命令が優先 されます。 Smaller 影響を受けるテキストを小さな文字体にします。文字サイズは二点に よって変更されますが、環境によっては別の量がより適切であるかも しれないことが勧告されています。入れ子された小さい命令はさらに それを理に適った表示をする装備の能力の制限内で、小さな文字体も 作り、その後さらなる小さい命令は効果をましません。 Bigger 影響を受けるテキストを大きな文字体にします。文字サイズは二点に よって変更されますが、環境によっては別の量がより適切であるかも しれないことが勧告されています。入れ子された大きい命令はさらに それを理に適った表示をする装備の能力の制限内で、大きな文字体も 作り、その後さらなる大きな命令は効果をましません。 "bigger" と "smaller" 操作は、効果的に入れ替えられますが、例えば"< smaller>"を ""効果を終らせるために使用することは薦められませ ん。これは適切に""でなされます。 装備の能力は様々ですので、装備によっては文字体変更命令の幾つかで作動で きないかもしれません。しかし、装備はそれでもなお理に適ったやり方でテキ ストを利用者に表示すべきです。特に、特殊な文字体・色もしくはその他のテ キスト属性を表示できる能力に欠けることは、装備がテキスト表示に失敗すべ きであることを意味していません。 充満/均等/字下げ命令 (Fill/Justification/Indentation Commands) 初期値でtext/enrichedテキストは、適当なカーニングと文字トラッキングと 受信表示代行手段ソフトウェアーの能力に合わせて最大の入手マージンを使っ て、全部を埋めるように (つまり、CRLF組をスペースに置き換えるよう特定さ れた規則を使って) 表示されるように考えられています。 以下の命令はその状態を変更します。これら命令ひつひとつは、書式環境の前 後で行分断、他に行分断がなければ、を強要します。例えば、これらの命令の 一つがテキストの行の始めでない何処にでも、表現されたように、表われたら、 新しい行が始められます。 Center 影響を受けるテキストを中央化します。 FlushLeft 影響を受けるテキストを右マージンは不揃いで左に調整します。 FlushRight 影響を受けるテキストを左マージンは不揃いで右に調整します。 FlushBoth 影響を受けるテキストを左右マージンが均等になるように満たし詰め 物をし、つまり満たすように調整します。 ParaIndent 影響を受けるテキストの連続するマージンを内に移動します。推奨さ れている字下げ変更は四文字幅ですが、これは装備によって異なるか もしれません。この"paraindent"命令は、"param"命令を使うことに よって特定されるパラメーターが必須です。このパラメーターデー ターは、以下のものの一つ以上のコンマ区切りのリストです。 Left 連続する左マージンを右に移動します。 Right 連続する右マージンを左に移動します。 In 連続マージンに追加して、影響を受けるパラグラフの最初の行を 字下げします。残りの行は連続マージンに流すままにします。 Out 連続マージンに追加して、影響を受けるパラグラフの最初の行を 除いた行全てを字下げします。最初の行は連続マージンに流すま まにします。 Nofill 影響を受けるテキストを満たすことなく表示します。つまり、テキス トはCRLF組をスペースに置き換えるもしくはCRLF組の連続文字を取り 除く規則を使わないで表示されます。しかし、マージンや均等の現在 の状態は尊重されます; どんな字下げもしくは均等命令もなお "nofill"の視野内のテキストに適用されます。 "center"・"flushleft"・"flushright"そして"flushboth"命令は、互いに両立 しなく、入れ子の場合内側の命令が優先します。 "nofill"命令は、"paraindent" 命令の "in" と "out" パラメーターと互いに 両立しません: 同じ場面に来た場合その振るまいは定義されていません。 "paraindent" 命令のパラメーターデータは、同じパラメーター (例えば、 "left"・"right"・"in"もしくは"out") の多元的出現を内容にするかもしれま せん。各出現は、テキストをパラメーターが示唆するやり方で更に字下げしま す。入れ子された"paraindent"命令は、影響を受けるテキストをパラメーター に従って更に字下げします。"paraindent"の "in" と "out"パラメーターは、 互いに両立しません: 一緒に現われる場合もしくは入れ子になった"paraindent" 命令がその両者を内容としている場合、それらの振るまいは定義されていない ことに注意してください。 "in" と "out" パラメーターの目的には、CRLF組をスペースに置き換えるもし くはつながっているCRLF組連続体を取り除く、規則を摘要後行分断によって区 切られたテキストとしてパラグラフは定義されています。例えば、"out"の場 面内で各CRLFに続かれる行は現在のマージンと伴に流し込まれそして連続行 は字下げされます。 "in"の場面内でCRLFに続かれる最初の行が字下げされ連 続行は現在のマージンにただ流し込まれます。 デフォルトでテキストが均等になっているかそうでないか (つまり、デフォル ト環境が"flushleft"・"flushright"もしくは"flushboth"であるか) は、特定 されてなく、利用者の好み・ローカルソフトウェアーとハードウェアーの能 力・使用されている文字の性質に依存します。全均等は望ましくないと考える システムでは、デフォルト環境で、"flushboth"環境が同じになっています。 "center"・"flushleft"・"flushright"もしくは"nofill"環境内では、全均等 は実行されるべきでないことに注意してください。非ASCII文字によっては、 全均等は基本的に不適当であることも注意してください。 [RFC-1563]は、さらに二つの字下げ命令、 "Indent" と "IndentRight"、を定 義していることに注意してください。これらの命令は、行分断を強制しませ ん、従ってそれらの振る舞いは、特殊な装備が使用しているマージンと文字サ イズに依存するので、予想がつきません。従って、それらの使用は破棄され、 その他の認識されない命令と丁度同じ様に無視されるべきです。 マーク付け命令 (Markup Commands) このセクションの命令は、その他のext/enriched命令と違って、宣言的なマー ク付け言語です。Text/enrichedは全部のマーク付け言語としてでなく、代わ りに書式命令を表現する単純な方法として考えられいます。従って、マーク付 け命令は意図的に最小に抑えられています。これらの特殊な命令が含まれてい るのは、それが電子メール環境で普及し必要であると思えるからです。 Excerpt (引用) 影響を受けるテキストが別の資源、恐らくそれに対応するメッセージ、 からのテキストの引用として解釈されることを意図しています。典型 的には、字下げされ文字を変更するもしくは行を字下げし "> " が先 頭にきますが、そのような決定は装備にかかっています。行内均等使 用のように、引用命令は行分断で始まりまた終り、一つがそこになく ても、ます。入れ子になった"excerpt"命令は受け入れられ、意味とし ては、引用されたテキストがまた別の資源から引用されていると、解 釈されるべきです。また、これは追加情報、異なる色などを使って表 示することができます。 選択性で、"excerpt"命令は"、param"命令を使うことによって、パラ メーターを取ることができます。データーの書式は特定されていませ んが、引用がそこから取られているテキストを特異的に識別すること が意図されています。この情報で装備は如何なる特殊な引用資源を特 異的に、特にメッセージに二つ以上の引用が同じ資源からのものでそ してこれが利用者に明らかになるような方法で表示する場合、識別す ることができるべきです。 Lang 影響されるテキストは、特殊な言語に属するものとして解釈されます。 二つの異なった言語が同じ文字セットを使用しますが、言語に依存し た (沿った) 異なった文字もしくは整形を必要とする場合、これは非 常に有益です。例えば、中国語と日本語は同じグリフ (絵文字) を割 り当てまたUNICODEのような文字セットで共通のコード点を割り当てま すが、異なった文字が二つの言語用に使われる、特に一緒に表われ意 味が失われないなら、ことは大変重要なことと考えられます。また言 語情報は、変わったテキスト取り扱い、スペルチェクもしくはハイフ ン付き表示のように、の準備をするために使われることができます。 "lang"命令には、"param"命令を使ったパラメーターが必須です。この パラメーターデーターは、[RFC-1766]、"Tags for the Identification of Languages"、で特定された言語名札 (タグ) で す。これらのタグは、[ISO-639]から取られた二文字の言語コードで、 また言語タグRFCの指示に従って登録された、別の言語コードでも可で す。より詳しい情報はその覚書を参照して下さい。 書式命令の均衡と入れ子 (Balancing and Nesting of Formatting Commands) 一式の書式命令は適切に均衡を取らされ入れ子されなければなりません。かく て、太字体のイタリック体でテキストを記載する適切な方法は: the-text もしくは、替わりに、 the-text しかし、特に以下のものは間違ったtext/enrichedです: the-text 書式命令を入れ子にすることで、text/enriched bodiesの構成に少なからず重 荷を課せますが、スタックベース (後入れ先出し型) にすることでtext/ enriched表示を原理的には簡素化します。text/enrichedの主な目標は、多元 文字で整形されたメールが広く読めるのに十分に簡素なものになり、その送信 能力で自信をもってそうできるようになることです。かくて、構成ソフトウェ アーが多少複雑さがましますが、簡素化された解読ソフトウェアーで十分相殺 されると思われます。けれども、text/enrichedリーダーの道具提供者は、送 信には保守的で受信には先進的であるという一般的なインターネット指針に従 うように薦められます。そうすることができる装備は、適切に入れ子にされた text/enrichedデーターを理に適って取り扱うように薦められています。 認識されない書式命令 (Unrecognized formatting commands) 装備は認識されない書式命令を「運船中止便="no-op"」命令、つまり何の効 果もなく、かくて"text/enriched"の将来の拡張に備える命令とみなさなけれ ばなりません。個人的な拡張は、"X-"で始まる書式命令を使用することでイン ターネットメールヘッダーフィールド名のように、定義されるかもしれませ ん。 拡張命令を正式に定義するためには、新しいインターネット文書が公開されな ければなりません。 Text/enrichedデーターでの空白行 (White Space in Text/enriched Data) SPACE や TAB (HT) 文字で、なんら特別な振るまいを要求されていません。し かし、少なくとも固定幅文字体が使用されている場合、TAB (HT) 文字の共通の 意味が見られ、即ちそれは8の倍数だけ次の列に移動します。 (言い替える と、TAB (HT) が最も左を0として列nに来るなら、TAB (HT) は8- (n mod 8: 8で 割った余) だけスペース文字に置き換えられます)。また、メール通過門に よっては行の終りの空白スペースを落とすことで悪名高いものもることに注意 すべきで、し、それ故に行の終りの SPACE や TAB に頼ることは推奨されませ ん。 text/enriched解釈の初期状態 (Initial State of a text/enriched interpreter) Text/enrichedは、普通の字体で色々な幅の文字で、当該の表示と利用者に とって平均的なサイズのテキストで始まると考えられています。左右のマージ ンは最大である、つまり最も左側と最も右側までの位置であるとみなされてい ます。 非ASCII文字セット (Non-ASCII character sets) MIMEの大きな利益の一つは、メッセージに異なる様々な非ASCIIが使えること です。メッセージで非ASCIIテキストを使うには、普通charsetパラメーター が、文字セットが使われていることを指すContent-typeの行で特定されます。 このRFCの目的にとって、正式なMIMEcharsetパラメーターはtext/ enrichedContent-type で使用できます。しかし、非ASCIIテキストを望む場合 text/enriched Content-typeに関して二つの困難があります。最初の問題には、 同じtext/enrichedメッセージに多元非ASCII文字セットを必要とするテキスト を利用者が生成したい場合に起こる困難さがあります。二番目の問題には、整 形命令で"<"のtext/enriched使用のため起こって来る不明確さがあります。 多元的非ASCII文字セットの使用 (Using multiple non-ASCII character sets) 同じMIMEメッセージ内に全く異なる文字セットからの文字 (例えば、ISO 8859-5でロシア・シリリック文字をまたISO 8859-8でヘブライ語を) を内容と するテキスを作成したい、と利用者が望んだ場合、普通は多元メッセージを使 います。新しい文字セットが望まれるごとに毎回、Content-type行の文字パラ メーターで特定される異なった文字セットで、新しい MIMEボディは始まりま す。しかし多元文字セットを使用すると、text/enriched メッセージでのこの 方法は問題を引き起こします。charsetパラメーターの変更は新しい部分を要 求するので、最初の部分のtext/enriched 書式命令は引き続く部分に起こるテ キストに適用することができません。MIMEボディ部分境界を越えて、text/ enriched書式命令を適用することはできません。 [RFC-1341]は、現在は破棄されたtext/richtextでのこの問題を、 "iso- 8859-5" and "us-ascii"のような異なった文字セット書式命令を導入すること で、切り抜ける試みをしました。しかしこれもしくは同じ行にそったより一般 的な解決でさえ、なお望ましいものではありません: 例えば、Content-type行 のcharsetパラメーターによって提供される情報を元にして要求される文字字 体資源もしくは文字検索表は何かを、ボディ部分データーを解釈もしくは表示 しはじめる前に、決定するのがMIMEアプリケーションの場合普通です。ext/ enrichedを解釈し引き続いて文字セットを変更、恐らくContent-type 行で特 定されたcharsetから完全にことなるものに (潜在的に多くの異なる資源要求 を伴って)、することを可能にすれば、text/enriched解釈自体に余りにも多 い荷が置かれることになります。 従って、非ASCII文字の多元タイプをtext/enriched 文書で希望するなら、以 下の二つの方法の一つが使用されなければなりません: 1. 非ASCIIテキストの異なるタイプが別個の書式でパラグラフ自体に制限され ているケースでは、多元部分メッセージをtext/enrichedのContent-Typeと 異なるcharsetパラメーターを持った個々の部分を伴って使用できます。こ の方法を使うことの一つの注意は、各新しい部分は text/enriched 文書の 初期状態で始まらなければならないことです。これは、先行部分の text/ enriched命令は次のtext/enriched部分が始まる前に終了命令で適切に均衡 されなければならないこと、を意味しています。また、各text/enriched部 分は新しいパラグラフを開始しなければなりません。 2. 同じ行やパラグラフで異なるタイプの非ASCIIテキストがくる場合もしくは text/enriched書式 (例えば、マージン・字体・均等) が幾つかの異なるタ イプの非ASCIIテキストにまたがっている場合、単一のtext/enrichedボ ディ部分が、要求されている文字全てを内容にしているよう特定された文 字セットで、使用されるべきです。例えば、[RFC-1642]で特定されている ように、charsetパラメーター"UNICODE-1-1-UTF-7"がそのような目的に使 えます。UNICODEは、その他の登録されたISO 8859 MIME文字セット全てで 表現されることができる文字すべてを内容にしているだけでなく、UTF-7 は、文字が以下で参照される"<"も含んで、text/enriched標準の別の面と 十分に互換性があります。非ASCIIテキストの色々なタイプを内容とする MIMEで使用を特定されたその他の文字セットなら如何なるものもこれらの 例で使用されることができます。 書式命令での"<"文字の使用 (Use of the "<" character in formatting commands) Content-typeの行でcharsetパラメーターによって特定された文字セットが "US-ASCII"以外である場合、これは、text/enriched書式命令で記載されたテ キストは非ASCII文字セットであること、を意味します。しかし、命令自体は この文書で定義されたと同じASCII命令です。これは、"<"、十進値 60 のオク テット、文字への照合のときだけ多義的になります。ISO-8859族のような単一 バイト文字セットではこれは問題になりません; オクテット 60 は、丁度 ASCIIでのように、二回含むことによって引用されます。しかし問題は、多元 バイト文字セットの例では、より込み入ったもになり、そこではオクテット 60は幾つかの文字列のバイト連続体でどんな所にも現われます。 しかし実際上では、大部分の多元バイト文字セットはこの問題を内部的に近づ きます。例えば、UNICODE文字セットは、重要なASCII文字全てを単一バイト書 式で予約するUTF-7コード化を利用することができます。ISO-2022族文字セッ トは、いつでもASCIIに切り替える或る種の文字連続体を利用できます。従っ て、text/enriched書式命令の前で主な文字セットはASCIIに「切り替え」られ るべきで、そしてプレーンテキストで"<"として解釈されるこれらの文字だけ がtext/enrichedで区切りトークンとして解釈されるべきです。 ASCIIを含まない仮定の将来の文字セットでどうなるかの疑問については、こ の覚書で近づきません。 最小text/enriched適合性 (Minimal text/enriched conformance) 最小 text/enriched 装備は、"<<"を"<"に変換し、命令と次の均衡命令 の間のもの全てを取り除き、その他書式命令全てを取り除き、そして環境 外で一連のn CRLFsをn-1 CRLFsに変換しそして単独のCRLF組をスペースに変換する、 ものです。 道具 (装備) 提供者への注意 (Notes for Implementors) 将来のメールシステムの装備はtext/enriched 用に現在定義されているものよ りも豊かなテキスト機能性を求められると思われます。text/enriched の意図 は、少なくとも相互操作性のソフトウェアーによって理解できる、書式でその 機能性を表現する共通の書式を提供することにあります。かくて、特に、 text/enriched より豊かな書式化されたテキストの命名法を持ったソフトウェ アーは、それでもなおその基本的な表現としてtext/enriched を使うことがで きますが、新しい書式命令やtext/enriched構成でそのシステムに特有 な隠れた情報によって、それを拡張できます。そのようなシステムが発展する ので、text/enriched の定義は将来公開される仕様書によって更に純化される と期待され、ここで定義された text/enrichedは発展的純化が基盤と出来る舞 台 (プラットフォーム) を提供しています。 洗練されたメールプログラムがtext/enrichedデーターを生成する予想される 共通命令は、multipart/alternative 構成の一部となるものです。例えば、 ODA 書式で豊かなメールを生成できるメール代行手段は、同じデーターの text/enriched と ODA版両方を生成することで、より広く相互操作可能な書式 で、そのメールを創作でき、例えば: Content-type: multipart/alternative; boundary=foo --foo Content-type: text/enriched [データーのtext/enriched 版 ] --foo Content-type: application/oda [データーのODA 版 ] --foo-- ODCを理解できるMIME適合メールリーダーを使ってそのようなメッセージを読 むなら、ODA 版が表示され; そうでないなら、text/enriched 版が見えます。 環境によっては、或る種のtext/enriched書式命令を組み合わせることができ なく、一方別の環境では容易に結合できるかもしれません。例えば、と の組み合わせは、そのような文字体をサポートしているシステムでは 太文字で斜体文字を作りますが、太字体テキストか斜体文字テキストを作るこ とはできますが、両者を作れないシステムが存在します。そのような場合、最 も新しく命令された (一番内側) と認められる書式命令が登用されるべきで す。 text/enriched 設計での主な目標の一つは、テキスト専用メーラーでもエン リッチからプレーンテキスト転送を装備しかくてエンリッチテキストが非常に 広く使用されるに安全になる可能性を増すぐらい、シンプルにすることです。 この単純性を示すために、text/enriched入力をプレーンテキスト出力に変換 する非常に単純なC言語を付録Aにあげてあります。 text/enrichedの拡張 (Extensions to text/enriched) 様々なメールシステム著者はtext/enrichedに拡張を望むと思われます。認識 できない書式命令は単に無視されるというtext/enrichedのシンプルな構文と 仕様は、このような拡張を促進する為に意図されています。 事例 (An Example) これを全て一緒に配置すれば、以下の"text/enriched"ボディ断片は: From: Nathaniel Borenstein To: Ned Freed Content-type: text/enriched Now is the time for all good men (and <) to come to the aid of their redbeloved country. By the way, I think that left< should REALLY be called left< and that I am always right. -- the end 以下の整形されたテキスト (テキスト専用版のこの文書上では何かおかしくみ えますが) を表現します: Now is the time for all good men (and ) to come to the aid of their beloved country. By the way, I think that should REALLY be called and that I am always right. -- the end "beloved"という単語は、ここではカラー画面で赤になります。 ti 0 安全性への考慮 安全性問題は、機構上安全性問題は持ち上がってこないので、この覚書では言 及されていません。 著者連絡 (Authors' Addresses) For more information, the authors of this document may be contacted via Internet mail: Peter W. Resnick QUALCOMM Incorporated 6455 Lusk Boulevard San Diego, CA 92121-2779 Phone: +1 619 587 1121 Fax: +1 619 658 2230 EMail: presnick@qualcomm.com Amanda Walker InterCon Systems Corporation 950 Herndon Parkway Herndon, VA 22070 Phone: +1 703 709 5500 Fax: +1 703 709 5555 EMail: amanda@intercon.com 謝辞 (Acknowledgements) 多くの寄与者・読者そしてこの文書の仕様の装備提供者に心から感謝いたしま す。特に、 RFC 1563の原著者である Nathaniel Borenstein に感謝致しま す。 参照文献 (References) [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) : Mechanisms for Specifying and Describing the Format of Internet Message Bodies", 06/11/1992. [RFC-1521] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", 09/23/1993. [RFC-1523] Borenstein, N., "The text/enriched MIME Content-type", 09/23/1993. [RFC-1563] Borenstein, N., "The text/enriched MIME Content-type", 01/10/1994. [RFC-1642] Goldsmith, D., Davis, M., "UTF-7 - A Mail-Safe Transformation Format of Unicode", 07/13/1994. [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", 03/02/1995. [RFC-1866] Berners-Lee, T., and D. Connolly, D., "Hypertext Markup Language - 2.0", 11/03/1995. 付録 A -- 単純なenrichedからplainへのC言語による変換 (Appendix A--A Simple enriched-to-plain Translator in C) テキストContent-Typeのtext/enrichedサブタイプの設計主要目標のひとつ は、整形されたテキストをシンプルなものにし、テキスト専用メーラーでも豊 かな書式からプレーンなテキストへ (enriched-to-plain-text) の翻訳を装備 し多元文字テキストが安全に広く使用されるようになることです。この単純性 を見せるために、text/enriched入力をプレーンテキスト出力に変換するシン プルなC言語を以下にあげています。ローカルでの新しい行慣例 ("\n"で表現 される単一文字) が、このプログラムによって想定されていますが、特別な CRLF取り扱いが、システムによっては、必要になるかもしれません。 #include #include #include #include main() { int c, i, paramct=0, newlinect=0, nofill=0; char token[62], *p; while ((c=getc(stdin)) != EOF) { if (c == '<') { if (newlinect == 1) putc(' ', stdout); newlinect = 0; c = getc(stdin); if (c == '<') { if (paramct <= 0) putc(c, stdout); } else { ungetc(c, stdin); for (i=0, p=token; (c=getc(stdin)) != EOF && c != '>'; i++) { if (i < sizeof(token)-1) *p++ = isupper(c) ? tolower(c) : c; } *p = '\0'; if (c == EOF) break; if (strcmp(token, "param") == 0) paramct++; else if (strcmp(token, "nofill") == 0) nofill++; else if (strcmp(token, "/param") == 0) paramct--; else if (strcmp(token, "/nofill") == 0) nofill--; } } else { if (paramct > 0) ; /* ignore params */ else if (c == '\n' && nofill <= 0) { if (++newlinect > 1) putc(c, stdout); } else { if (newlinect == 1) putc(' ', stdout); newlinect = 0; putc(c, stdout); } } } /* The following line is only needed with line-buffering */ putc('\n', stdout); exit(0); } ダムターミナルでのtext/enrichedデーターの表示において、あるものはこれ よりも遥かにうまくすることができるということに注意されるべきです。特に ものによっては、テキスト強調 ( *this* or _T_H_I_S_のような) に"bold"と いった文字体情報を置き換えることができます。また、ものによっては字下 げ・均等化調整その他についてtext/enriched書式命令を適切に取り扱えま す。しかし、上記のプログラムはダムターミナルで、利用者に何ら整形産物を 見せることなく、text/enriched を表現するために必要な全てです。 付録 B -- 単純な enrichedからHTMLへのC言語による変換 (Appendix B--A Simple enriched-to-HTML Translator in C) HTMLやSGMLのような別の書式標準が、インターネットメールでtext/enriched に取って替わることが十分に考えられます。このことが起こるので、text/ enrichedメールの受信者がHTML閲覧でそのようなメールを閲覧したいと思うこ ともありえます。text/enrichedをHTMLに変換するC言語のシンプルな例を以下 にあげておきます。この文書の公開の時点での最新HTMLバージョンは、[RFC- 1866]で定義されたHTML 2.0ですので、このプログラムはその標準を変換しま す。HTML 2.0と等価でないtext/enriched命令も幾つかあります。そのような 例では、このプログラムは処理機構にそれらの命令を単に配置するだけです; つまり、 "" によって囲まれた。付録Aでのように、ローカル新しい 行慣例 () がこのプログラムで想定されていますが、システムによっては特別 な CRLF取り扱いが必要になるかもしれません。 #include #include #include #include main() { int c, i, paramct=0, nofill=0; char token[62], *p; while((c=getc(stdin)) != EOF) { if(c == '<') { c = getc(stdin); if(c == '<') { fputs("<", stdout); } else { ungetc(c, stdin); for (i=0, p=token; (c=getc(stdin)) != EOF && c != '>'; i++) { if (i < sizeof(token)-1) *p++ = isupper(c) ? tolower(c) : c; } *p = '\0'; if(c == EOF) break; if(strcmp(token, "/param") == 0) { paramct--; putc('>', stdout); } else if(paramct > 0) { fputs("<", stdout); fputs(token, stdout); fputs(">", stdout); } else { putc('<', stdout); if(strcmp(token, "nofill") == 0) { nofill++; fputs("pre", stdout); } else if(strcmp(token, "/nofill") == 0) { nofill--; fputs("/pre", stdout); } else if(strcmp(token, "bold") == 0) { fputs("b", stdout); } else if(strcmp(token, "/bold") == 0) { fputs("/b", stdout); } else if(strcmp(token, "italic") == 0) { fputs("i", stdout); } else if(strcmp(token, "/italic") == 0) { fputs("/i", stdout); } else if(strcmp(token, "fixed") == 0) { fputs("tt", stdout); } else if(strcmp(token, "/fixed") == 0) { fputs("/tt", stdout); } else if(strcmp(token, "excerpt") == 0) { fputs("blockquote", stdout); } else if(strcmp(token, "/excerpt") == 0) { fputs("/blockquote", stdout); } else { putc('?', stdout); fputs(token, stdout); if(strcmp(token, "param") == 0) { paramct++; putc(' ', stdout); continue; } } putc('>', stdout); } } } else if(c == '>') { fputs(">", stdout); } else if (c == '&') { fputs("&", stdout); } else { if(c == '\n' && nofill <= 0 && paramct <= 0) { while((i=getc(stdin)) == '\n') fputs("
", stdout); ungetc(i, stdin); } putc(c, stdout); } } /* The following line is only needed with line-buffering */ putc('\n', stdout); exit(0); }