要約

  • RFC 2987 は charset と language に同じ等価比較を与えながら、前者を通常は機器能力、後者を通常は利用者の選好とした。
  • 文字集合の主名称と、言語タグを一つの完全なトークンとして扱う規律は曖昧さを減らしたが、復号・表示・発話品質・理解を証明しなかった。
  • q 値はローカルな選択の入力であり、候補の存在、利用者の満足、サービス成功を測った結果ではない。

並んだ二つの登録

RFC 2987 の本文は短い。RFC 2506 の手続きに従う登録票が中心で、charset に OID 1.3.6.1.8.1.31、language に 1.3.6.1.8.1.32 を割り当てた。IANA の現行メディア機能タグ表にも、両者は31番と32番として残っている。

登録の狙いは、アプリケーションごとに異なる語彙を作らず、提示に関する能力や希望をプロトコル横断で表すことだった。RFC 2533 は述語を組み合わせ、品質値を付ける構文を用意した。共通の名前があれば、独立した実装が同じ問いを交換できる。

両登録の形式はよく似ている。値は登録済みトークンで、比較は等価だけ、大文字小文字は区別しない。例は複数候補を OR で並べ、それぞれに q 値を付ける。

しかし、問いの種類は違った。

RFC 2987 は、多くの機器にとって charset は通常 capability だと説明する。未知の文字集合に属するテキストは、機器が知的に処理できないのが普通だからだ。一方、language は多くの場合 requirement ではなく preference である。「表示」はコンピューター音声を指すことが多いとされたが、要点は音声に限られない。人がある言語を望むことと、機械が別の言語を技術的に処理できないことは別である。

同じ式が、実行の壁と選択の順位を運んでいた。

文字集合は実行可能性を問う

文字集合の例では utf-8、iso-8859-1、utf-16 が 1.0、0.9、0.5 の順に並ぶ。だが、デコーダーが存在しなければ、順位の対象となる出力自体がない。

トークンが一致しても、ペイロードのラベルと実際のバイト列が一致するとは限らない。デコーダーが未実装かもしれない。文字には変換できてもフォントに字形がないかもしれない。画面に正しく出ても、利用者が読めないかもしれない。一致は最初の条件であって、全工程の証明ではない。

RFC 2913 が type を別のメディア機能として登録したことも重要である。text/plain を扱える機器が、平文のあらゆる符号化を扱えるとは限らない。媒体の型と、バイトから文字への規則は隣接するが、同じ能力ではない。

別名にも罠があった。RFC 2978 は一つの文字集合に複数の名前を許す一方、主名称を一つ定め、各名称が一つの文字集合だけを指すよう求めた。RFC 2987 は機能式で別名を使わないよう勧める。処理ツールが別名を主名称へ変換し、表面上は保存したはずの式の挙動を変える可能性があるからだ。

主名称を小文字で書くことは、不要な名前差を減らす。デコーダーの実装や変換表の正しさまでは保証しない。正規化は名前を揃えるだけで、動くコードを作らない。

さらに文書は、テキストデータを扱えると主張するなら charset 能力も示すべきだとした。「テキスト」という分類だけでは、受け取ったバイトをどう読めるかが分からない。

言語は人の優先順位を問う

言語の例は no-nynorsk、no-bokmaal、i-sami-no を並べる。比較演算子は同じでも、不一致の扱いは同じではない。

RFC 1766 の言語タグは主タグと副タグで構成できる。しかし、アプリケーションはタグ全体を一つのトークンとして扱うよう求められた。副タグは管理上の構造であり、言語間の理解可能性を自動推論する地図ではない。接頭部が共通でも、話者が相互に理解できるとは限らない。

RFC 2987 も、タグ全体を大文字小文字を無視して等価比較し、副タグを比較に使わないとした。文字列の階層から、人間についての権威ある結論を作らないための制約である。

同時に、不一致は機器故障とは限らない。利用者は第一希望がなくても第二希望を受け入れるかもしれず、何も届かない方を望む場合もある。どちらにするかは、利用可能な版、明示された順位、アプリケーションのフォールバック方針で決まる。

選好をすべて必須条件にすると、使えるサービスまで捨てる。すべてを軽い助言にすると、利用者の意思を無視する。登録は判断材料を共通化したが、世界共通の判断者を置かなかった。

品質値は品質検査の結果ではない

RFC 2533 の品質値は述語を修飾し、未指定なら1となる。一方、複数の選好をどう合成するかについて普遍的な規則は定めなかった。用途ごとに候補集合も失敗時の扱いも異なるからだ。

したがって q=1.0 は、そのプロファイルがその時点で一つの述語を高く置いた証拠にすぎない。プロファイルの新鮮さ、該当コンテンツの存在、音声の自然さ、復号の成功、利用者の理解を証明しない。

文字集合でも、硬い能力境界があるだけで同じ限界が残る。重みは実在する複数の復号経路を順序づけられるが、デコーダーを導入せず、ラベルとバイトの一致も、中継中の保存も証明しない。

説明可能な記録には、受信した機能集合、正規化結果、評価器の版、ローカル方針、候補一覧、選択理由、実行資源、提示結果が必要である。「交渉成功」という一語では、これらの問いに答えられない。

登録は問いを共有する

IANA 登録が残っていることは、RFC 2987 の最小協調が長く使える形だったことを示す。独立した実装が同じ名前と比較規則を参照できる。だが、登録機関が個々の選択を実行するわけではない。

プロファイル作成者は何を申告するか決める。コンテンツ提供者はどの版を用意するか決める。受信側は正規化、順位、フォールバックを決める。結果を経験するのは利用者である。

Lu Heng の最小初期仕様という観点では、共通層は名称、値域、比較意味にとどまる。その後の決定は各実装に残り、中央の選好機関は作られない。

ただし、ローカル判断には説明責任が伴う。言語選好を拒否条件に格上げしたり、文字集合能力を単なる希望に格下げしたりする実装は、重要な解釈を支配する。その判断を標準の命令に見せかけず、方針と結果を記録しなければならない。

動くコードの優位という原則は、さらに境界を明確にする。登録は仕様の存在を証明するが、デコーダー、フォント、音声、コンテンツが配備されたことを証明しない。運用上の事実は、実装が実際に何を比較し、選び、復号し、提示したかにある。

現実の層は、登録、表現、正規化、評価、選択、能力、実行、知覚、結果に分かれる。前の層が正しくても、後ろの層を代弁する権限は得られない。

小さなセキュリティ上の開示

RFC 2987 は両登録で、特定の文字集合や言語の表示に既知のバグがある環境では、その対応能力を知らせることが攻撃者をわずかに助ける可能性があると述べた。製品名や事件は挙げていない。

この注意は、能力申告が運用データであることを示す。選択を導き、攻撃面も明かし得る。意思決定に必要な範囲だけを開示し、「受理できる」を「安全である」と読み替えないことが重要だ。

RFC 2987 の価値は、二つのタグを同じにした点ではない。同じ機械で扱いながら、意味の差を残した点にある。

一方は通常「機械に可能か」を答え、もう一方は通常「人は何を望むか」を答える。同じ等価比較と同じ重みを使えても、答えの効力は同じではない。

情報源