この文書は、インターネット・コミュニティーのために Internet Best Current Practices (インターネットの現時点での最良の慣行) を定め、かつ改善のための議論と提案とを求めるものである。 このメモの配布に制限はない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
インターネットは国際的なものである。
国際的なインターネットであれば、途方もない数の文字を擁する多様な言語の間でデータを交換することは絶対的な要件である。
この文書では、インターネットのプロトコルがそうした要件を満たすのを支援するために IESG (Internet Engineering Steering Group) が IETF (Internet Engineering Task Force) における標準化の取り組みに対して適用している現在の方針について示す。
この文書は、1996 年 2 月 29 日～ 3 月 1 日の IAB 文字集合ワークショップでの勧告——これは RFC 2130 [WR] に文書化されている——に多く基づいているが、簡潔かつ明瞭たらんことを企図したものである。 より詳しく知りたい向きには RFC 2130 を読むことをお勧めする。
この文書では「しなければならない」「すべきである」「してもよい」の用語およびこれらの否定形を [RFC 2119] に記述されているとおりに使用する。 その場合、RFC 2119 で用いられている「仕様」は、IETF 標準化プロセスに提出されているプロトコルの処理のことを言う。
国際化は人間のためのものである。 このことは、国際化が必要なのはプロトコルではなく、テキスト文字列であるということを意味する。 IETF の多くのアプリケーション層プロトコルにおけるような、プロトコル要素がテキスト・トークンのように見える場合、プロトコルは、どの部分がプロトコルでどの部分がテキストであるかを指定しなければならない。[WR 2.2.1.1]
厄介なのは名前である。 というのも、人は名前というものを強く意識するうえに、名前の多くはたいてい局所的に使うためのものでありながら、それらはすべて時として局所的な環境から漏れ出す傾向を有するからである。 RFC 1958 [RFC 1958] では、広範囲に見える名前に対しては US-ASCII を推奨している。
この文書では、名前の国際化の方針を義務づけることはしないが、すべてのプロトコルに対し、名前を国際化すべきか US-ASCII とすべきかを記述するよう要求するものである。
注意 — いかなるアプリケーションもそのプロトコル・スタックにはこれらの問題への対処を必要とするひとつないし少数のレイヤー (層) が存在するのが普通である。
たとえば、イーサネット・フレームに言語タグを定義することは不適当であろう。 しかし、国際化の責任を「もうひとつのレイヤー」に委ねる場合は常に、そのレイヤーに対して責任のある WG (Working Group、作業部会) が国際化の責任も自らにあると実際に認識していることを保証するのは、委ねる側の WG の責務である。
この文書では、「charset」という用語を、符号化文字集合と文字符号化方式の組み合わせのような、オクテット連続を文字連続へ写像するための規則の集合という意味で用いる。 これはまた、MIME の "charset=" パラメーターにおける識別子として使用されるものであり、IANA charset レジストリー [REG] に登録されている。(ISO などの他の標準化団体によって使用される用語ではないということに注意。)
「符号化文字集合」(coded character set) という用語の定義についてはワークショップ報告を参照されたい。
「名前」(name) は、人名、ホスト名、ドメイン名、ファイル名、E メール・アドレスなどの識別子である。 名前はテキストの一部としてよりも識別子として扱われることが多く、プロトコルの中ではエンティティーの識別子としてテキストに取り囲まれることなく使われることが多い。
すべてのプロトコルは、あらゆる文字データについて、どの charset が使われているかを識別しなければならない。
プロトコルは、あらゆるテキストについて、UTF-8 charset を使うことができなければならない。 UTF-8 charset は、[10646] の補遺 R (修正 2 版で発行) に定義されているように、UTF-8 文字符号化方式と組み合わされた ISO 10646 符号化文字集合で構成される。
加えてプロトコルは、他の charset や、あるいは UTF-16 のような ISO 10646 の他の文字符号化方式について、それをどのように使うかを指定してもよい。 しかし、UTF-8 の使用能力の欠如はこの方針への違反となる。 そうした違反には、標準路線に乗ったり進んだりする前に、プロトコル仕様文書における明瞭かつ確乎たる正当な理由とともに不一致の手続き ([BCP9] 第 9 章) が必要となろう。
既存のプロトコルにとって、あるいは既存のデータストアからデータを移すプロトコルにとっては、他の charset をサポートすることや、あるいは UTF-8 以外のデフォルトを使うことさえも、必須事項であるかもしれない。 これは容認できる。 ただし、UTF-8 のサポートは可能でなければならない。
UTF-8 以外の charset を使う場合、それは IANA charset レジストリーに登録されているものでなければならない。 必要ならばそのプロトコルが発行される際に登録する。
(注意 — ISO 10646 では UTF-8 CES のことを「文字符号化方式」(character encoding scheme) ではなく「変換フォーマット」(Transformation Format) と呼んでいるが、それは charset ワークショップ報告の文字符号化方式の定義に当てはまるものである。)
プロトコルが複数の charset からの選択を認めている場合、どの charset を使うかについて誰かが決定を下さなければならない。
ある場合には、HTTP のように、テキストを含むデータの生産者と消費者との間に直接または半直接の通信が存在する。 そのような場合、データを送る前に charset について折衝をすることは有意義かもしれない。
またある場合には、E メールや格納されているデータのように、そのような通信がなく、できることと言えば、せいぜい格納されたデータによって charset が明確に識別されるようにすることと、できるだけ広く知られた charset を選ぶことぐらいである。
charset は絶対的なものであることに留意されたい。 ある charset で符号化されたテキストは、その charset をサポートすることなしには完全に表示することはできないのである。
(このことは英語のテキストにも当てはまる。 EBCDIC のような charset はその真部分集合として ASCII を含有しているわけではない。)
charset についての折衝は、UTF-8 による交換のサポートが普及するまでの間だけサポートすべき暫定的な仕組みであると見做すことができる。 ただし、「暫定」期間は少なくとも 50 年であるかもしれず、したがって事実上はそれを永続的なものと考えて差し支えない。
人間の読めるテキストはすべて言語によっている。
高品質の文書整形、テキスト音声合成、探索、ハイフネーション、スペルチェックなど多くの操作は、一片のテキストについてその言語に関する情報にアクセスすることによって大きな恩恵を受ける。[WR 3.1.1.4]
人間は外国語にいくらか寛容であるが、一般的には、理解できない言語のテキストを前にして非常に残念に思うものである。 言語についての折衝が必要とされる理由はここにある。
ほとんどの場合、機械は自らが伝送するテキストの言語を推定することはできないであろう。 プロトコルは、言語情報が仮にも入手できるべきものとするならば、その転送方法を指定しなければならない。
言語と処理の間の相互作用は複雑である。 たとえば、"name-of-thing(lang=en)" (1) が "name-of-thing(lang=no)" (2) と等しいか比較するとき、たいていは一致することを期待するが、"ask(no)" という語は木の一種であり(3)、とてもコマンドの動詞としては使えない。
テキストを転送するプロトコルは、そのテキストの言語に関する情報の伝達について規定しなければならない。
プロトコルはまた、必要に応じて、名前の言語に関する情報の伝達について規定すべきである。
このことが、そのような情報が常に存在しなければならないということを意味するわけではないことに留意されたい。 要求事項は、情報の送り手がテキストの言語に関する情報を送りたいと望めば、その情報を伝えるための明確な方法をプロトコルが提供してくれるということである。
目下のところ、RFC 1766(4) の言語タグが言語の識別に利用できる最も柔軟な手段である。 プロトコルは、これを利用するか、さもなくば他の手段を採る明瞭かつ確乎たる正当な理由を文書中に与えるべきである。
言語は POSIX のロケールとは異なることにも留意されたい。 POSIX のロケールは文化慣習の集合——言語を含みうる (POSIX ロケールあるいは C ロケールはもちろんそうではない)——を識別するものであるが、RFC 1766 に記述されている言語タグは言語のみを識別するものである。
利用者の働き掛けに応えて利用者にテキストを提示するプロトコルは、複数言語のサポートを規定しなければならない。
これがどのようになされるかは、プロトコルごとに異なる。 たとえば、ある場合には、クライアントが言語の集合を示しサーバーがひとつを回答するような折衝が適している。 またある場合には、サーバーは同じテキストの複数の変種を送ってクライアントに表示するものを選ばせることを選択するかもしれない。
折衝は、プロトコル交換の一方が相手側に対して複数の言語によるテキストを提示できる能力をもち、かつ相手側がそれらのうちのひとつを好むような場合に有用である。 最も一般的な例は、エラー応答のテキスト部分や、複数の言語による表示が可能なウェブ・ページである。
言語について折衝する機能は、将来いかなる時にも消え去ることのない、プロトコルの永続的な要件と見做すべきである。
多くの場合、認証やその他の選好事項の折衝とともに、接続確立の一部としてそれを含むことができるべきである。
人間の読めるテキストを、受信側の言語の好みについての知識が送信側にない状況 (ログイン失敗や E メールによる警告、あるいは言語について折衝する前など) で与えなければならないとき、テキストはデフォルト言語で提示すべきである。
デフォルト言語には、RFC 1766 の手続きに従って "i-default" のタグが割り当てられる。 それは特定の言語ではなく、むしろ利用者の言語の好みが確定できないという状況を識別するものである。
デフォルト言語によるメッセージは、英語話者の理解できるものでなければならない。 英語は、世界的に見て最も多くの人々が、コンピューターを使って作業をする際に翻訳することによって適切な援助が得られるであろう言語だからである。
折衝の結果が英語であることと、デフォルト言語とは同じではないということに留意されたい。 デフォルト言語は、それ以外には管理しようのない局面における非常手段である。
多くの場合、英語のテキストのみを使うのが合理的である。 ある場合には、他の言語のテキストによって英語のテキストが補強されるかもしれない。
POSIX 標準 [POSIX] では「ロケール」と呼ばれる概念を定義している。 ロケールには、ソートのための照合順序や日付の書式、通貨の書式など、多くの情報が含まれる。
場合によっては、とりわけ利用者によって処理することが期待されるテキストを伴う場合には、ロケール情報をテキストに添付することは有益かもしれない。 それは文書を処理する際に従うべき規則についての送り手の見解を確認するものとなろう。 受け手はそれに同意することも無視することもできる。
この文書では、すべてのテキストについてロケール情報に関する通信を要求することはしないが、適切な場合にはそれを含めることを奨励する。
言語および文字集合の情報はしばしばロケール・タグの一部として存在することに留意されたい (no_NO.iso-8859-1 など、言語はアンダースコアの前に、文字集合はドットの後にある)。 ひとつのテキスト項目に対して文字集合と言語のどちらの指定が適用されるかを明確に定義することに意を注ぐ必要がある。
デフォルトのロケールは "POSIX" ロケールである。
多少なりとも国際化の問題を扱う文書においては、国際化のために選ばれたアプローチの概要を「国際化に関する考慮事項」(Internationalization Considerations) と題した章に集め、セキュリティーに関する考慮事項 (Security Considerations) の章の次に置くべきである。
そうすることにより、プロトコルの実装にあたってこれらの問題についての助言を求める者が容易に参照できるようになる。
外国語によるセキュリティー上の警告が利用者の不適切な振る舞いの原因となりうるという事実や、多言語システムにはたいてい各言語のバージョン間の一貫性に関して問題があるという事実を別にすれば、関連するセキュリティー上の問題点は確認されていない。
Harald Tveit Alvestrand
UNINETT
P.O.Box 6883 Elgeseter
N-7002 TRONDHEIM
NORWAY
Phone: +47 73 59 70 94
EMail: Harald.T.Alvestrand@uninett.no
Copyright (C) The Internet Society (1998). 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.
この文書およびその翻訳は、全体または一部について、いかなる種類の制約も受けることなく、複製および他者への供与ができるほか、これについて注釈し、または他の方法で解説し、あるいはその実装を助ける派生的著作を用意、複製、出版、および配布することができる。 ただし、上記の著作権表示およびこの一節が当該の複製および派生的著作のすべてに含まれるものとする。 一方、この文書自体は、著作権表示を削除したり Internet Society ないし他のインターネット機関への参照を削除したりするなどのいかなる方法によっても改変してはならない。 ただし、インターネット標準の開発の目的のために必要とされるインターネット標準化プロセスの著作権の手続きを踏む場合、および英語以外の言語に翻訳するのに必要とされる場合を除く。
上で与えた制限つきの許諾は恒久のものであり、Internet Society またはその後継者ないし譲受人によって取り消されることはない。
この文書およびここに含まれる情報は「現状有姿」方式で提供されるものであり、Internet Society および Internet Engineering Task Force は、明示的であるか黙示的であるかを問わず、一切を保証しない。 ここでいう保証には、ここにある情報の利用がいかなる権利をも侵害しないという保証や、特定の目的に対する市場性ないし適合性についての暗黙の保証が含まれるが、それらのみに限定されない。
| (1) | en は英語を表わす 2 文字コード。 | |
| (2) | no はノルウェー語を表わす 2 文字コード。 | |
| (3) | ノルウェー語で ask はトネリコ (セイヨウトネリコ) の意。 | |
| (4) | RFC 1766 の後継となる RFC 3282、RFC 4646、RFC 4647 が発行されている。 | |
| (5) | RFC 2278 の後継となる RFC 2978 が発行されている。 | |
| (6) | RFC 2279 の後継となる RFC 3629 が発行されている。 |
※ 原文における明らかな誤りは訂正した。