要約

  • 1982年8月のRFC 822は、正式に公表するメールの拡張項目と利用者が定める項目を分けた。前者の名前は X- で始めず、後者に保護された名前の領域を残した。
  • その区分は改名の負担も残した。1997年1月のRFC 2068はHTTPで x-gzip と gzip、x-compress と compress を互換として扱うよう求めた。2007年12月のRFC 5064は Archived-At を標準化しながら、旧名 X-Archived-At も記述し登録した。
  • 2012年6月のRFC 6648は、新たなアプリケーション層の文字列パラメーターについて X- 慣行を退けた。項目の正式性や安全性を名前の見た目だけで判断せず、登録簿と明確な手続きで扱うよう求めた。

私的な実験に与えた専用の棚

メッセージの項目には名前と値がある。受信するソフトウェアは、名前を見て値の扱いを決める。異なる集団が同じ名前を別の意味で使えば、メッセージが集団の境界を越えたときに衝突する。私的な試行に専用の名前の領域を与えるのは、当時としては理にかなっていた。規格化を待たずに試せるし、公式の拡張に使う名前も守れる。

1982年8月に公表されたRFC 822は電子メールでこの区分を明文化した。後から正式な文書で定義される拡張項目は X- で始めない。利用者が独自に定める項目には、その綴りを使える領域が残る。委員会の許可を先にもらわなくても、組織内のメッセージに必要な情報を載せられた。

人が X- を見れば「今は私的」と読める。プログラムはそうは読まない。二つの文字を項目名の一部として照合する。X-Example を受け取るよう作られた古いプログラムは、後日 Example が承認されたからといって新しい名前を理解しない。制度上の身分の変更と、通信や保存済みメッセージに刻まれた文字列の変更は別の仕事である。

使う人がいなければ改名は簡単だ。だが役立つ実験ほど送信側が採用し、受信側が対応し、アーカイブが記録する。正式名称ができた頃には、旧名も既に利用者を持っている。仮の棚を空にする条件は、成功した実験ほど満たしにくい。

HTTPが先に払った互換性の費用

1997年1月のRFC 2068には、その費用が短い指示として残る。HTTPの内容符号化について、過去の実装との互換性を保つため x-gzip を gzip と、x-compress を compress と同等に扱うよう求めた。新しく整った名前を一つ選ぶだけでは済まなかった。以前から稼働するソフトウェアが、旧い綴りを入力として受け渡していたからだ。

これは見栄えの問題ではない。送信側が一方の名前で符号化を示し、受信側がもう一方しか知らなければ内容を正しく扱えない。中継や保存をする仕組みも両者の関係を理解する必要がある。実験を示したはずの印が、正式な受信規則に組み込まれた。

メールでも規則の方は変わった。2001年4月のRFC 2822はRFC 822を置き換え、任意の項目を旧来の「公式拡張」と「利用者定義」に分ける構文を引き継がなかった。ただし、以前のメールに記録された名前やそれを読むソフトウェアを、文書の変更だけで書き換えることはできない。

2007年12月のRFC 5064は、その残り方をはっきり示した。アーカイブされたメールのURIを示す Archived-At を定める一方、前身の X-Archived-At も互換性のために記述した。旧名の解析は認め、新しい送信での使用は勧めない。登録簿には旧名が廃止予定の項目として載った。新しい名前の正式採用は、古い名前を無視できる状態を意味しなかった。

二つの事例の細部は異なる。HTTPでは特定の符号化名を同等に扱う。メールでは旧名を読み、新名を出す方向へ導く。どちらの仕様も、各時点で何台の実装がどちらを使ったかを数えていない。その規模を語るには日付のある実装資料やメッセージ標本が要る。ただし、二つの名前を扱う必要が規格の仕事になった事実は、原文に残っている。

名前の見た目から権威を剥がす

2012年6月にIETFのBest Current Practiceとして出たRFC 6648は、この経過を一般化した。未標準化の名前が広く使われた後で別名を正式採用すると、古い実装は前者だけを、新しい実装は後者だけを理解しがちだ。相互接続のために新しい側が旧名も長く受け入れれば、私的な名前は事実上の標準になる。分けたはずの名前空間が、結局は二つとも維持対象になる。

新しく定めるアプリケーションプロトコルの文字列パラメーターには X- を使わないよう勧める。ただし、既存の項目を一斉に消せという命令ではない。既存名を残すか移すかは管理者が判断する。私的な拡張を禁じるものでも、各プロトコルに固有の規則を自動的に上書きするものでもない。捨てたのは、現時点の身分を通信上の名前に焼き付ける設計である。

受信側への指示はさらに重要だ。X- の有無だけで標準化の状態を決めてはならない。同じ見た目だけで「正式名だから安全」「私的名だから危険」と判定してもならない。名前は値を識別する鍵であって、審査済みを示す証明書ではない。

代案は、十分な余地を持つ登録簿と簡単な登録手続きだ。必要なら暫定登録と恒久登録を用意する。X- の付いた名前の登録を禁止する必要もない。登録簿なら、ある名前の扱いや説明を更新できる。状態を変えるたびに線上の名前まで変える必要がない。

さらにRFC 6648は、試作版と正式版の意味が異なる場合を挙げる。標準化の審査で安全性や相互運用性の規則が変わったなら、接頭辞だけを取り去って同一視するのは危険だ。RFC 2068の x-gzip の同等性は、その符号化に対する具体的な規則である。すべての X- を機械的に削る一般規則ではない。

成功した実験ほど旧名が残る

1982年の分離は、試行する自由を与えた。2012年の見直しは、成功の後に起こることを記録した。ソフトウェアが名前を読み、保存されたメッセージが名前を残し、他のシステムがそれを前提に動く。標準化団体が新しい名前を決める前に、旧名には既に利用者がいる。

一次資料の上では結末が見える。1997年のHTTP規格は二つの名前を結び、2007年のメール規格は廃れた旧名を新名の横に登録した。各実装の普及率を知るには別の記録が必要だ。だが、名付けの権限と削除できる権限が違う場所にあることは分かる。登録簿は制度を決める。稼働中のプログラムと蓄積されたメッセージは、その名前をいつまで読まねばならないかを決める。

RFC 6648は古い棚を片付けたわけではない。次の実験のために同じ棚を新設するのをやめた。名前が育ったときの地位は登録簿に記せばよい。正式採用のたびに二つ目の名前を増やす必要はない。