要約

  • RFC 2277 は、プロトコル要素と人向けテキストの区別、charset の明示、UTF-8 を使えること、言語情報を運ぶ方法を IETF 仕様に求めた。
  • それは設計判断を審査できるようにする規則であり、受信実装の能力、交渉の採用、ロケール、字形表示、利用者の理解を示す実行証跡ではなかった。

1998 年 1 月の RFC 2277 は BCP 18、すなわち Best Current Practice として刊行された。対象は新しい符号化方式ではなく、IETF の標準化過程へ提出される仕様だった。同時期の IESG 発表は、テキストを扱うプロトコルが UTF-8 を利用でき、言語タグを運べなければならず、例外には variance の承認が要ると整理している。

この規則によって、国際化を「別の層が処理する」とだけ書いて終えることは難しくなった。仕様は、文字に見える部分が機械のためのプロトコル記号なのか、人が読むテキストなのかを示す必要があった。責任を別層へ渡すなら、その層が責任を認識しているかも確認する。名前についても、国際化するのか US-ASCII とするのかを記述する。

ここで得られるのは審査可能性である。RFC 2277 の charset は、octet の列を文字の列へ写す規則を指す。ラベルは受信者に復号規則を伝えるが、実際の octet が正しいか、古い実装がその規則を備えるか、必要な字形があるかまでは検査しない。

すべてのテキストに UTF-8 を使えることという要求も、全環境の移行完了を意味しなかった。既存プロトコルや保存済みデータには別の既定値が必要な場合があり、登録された別 charset も認められた。共通の将来方向と互換性の負担を同時に記録した政策だった。

表現を決める方法も一つではない。HTTP のように生成側と消費側が通信できれば charset を交渉できる。メールや保存データでは、将来の受信者とその場で話せないため、データと一緒に charset を明示するしかない。交渉は提示と選択の記録であり、保存ラベルは送信側の主張である。どちらも表示成功の確認応答ではない。

言語情報はさらに別である。RFC 2277 は、言語を運ぶ手段を要求したが、各テキストに常に値があるとはしていない。当時推奨された RFC 1766 のタグは言語を識別する。一方 POSIX locale は照合、日付、通貨などの文化的規則を含み得る。送信側の locale の提案を受信側が採用する義務もない。

したがって、言語タグは理解証明ではない。RFC 2068 の Accept-Language は利用者の選好を表すが、理解可能性は個人に依存すると注意していた。接頭辞一致も、より具体的なすべての変種を理解できるという意味ではない。RFC 1766 も、日本語と中国語が混在する文章などでは言語タグだけで charset の表示を常に正しく決められないと述べた。

RFC 2277 が仕様へ勧めた “Internationalization Considerations” 節は、この分離を運用するための台帳だった。テキストの位置、charset、言語情報、交渉、別層の責任を一か所に集め、Security Considerations の隣で審査する。そこに書かれるのは設計上の選択であり、実装、翻訳、表示、利用者行動の合格記録ではない。

文書自身のセキュリティ節も、外国語の警告が不適切な行動を招き、多言語版の整合性が問題になり得ると認めた。RFC 2277 の歴史的価値は、理解を保証したことではなく、理解までの前提を仕様から隠せなくしたことにある。

情報源と証拠の限界

一次資料は 1998 年の政策、その RFC 2130 との関係、当時の MIME・HTTP・言語タグ、UTF-8 仕様の境界を裏付ける。現在の普及率、特定製品、特定通信、利用者の理解は裏付けない。