[2]
仕様書ですべての機能を厳密に規定すると応用の発展の速度に仕様の改正が追いつかず、
技術と市場の発展の阻害要因となるおそれがあります。
そこで一部のプロトコル要素に拡張性を導入し、
他の仕様にその解釈を移譲する形をとることがあります。
無秩序な拡張は相互運用性を実現できませんから、
登録制度を設けて衝突の回避と一定の審査を行います。
登録簿によって利用者が目的の仕様を容易に発見できるようにもなります。
標準化団体と登録制度
[1]
ISO/IEC
は規格ごとに RA (registration authority)
を指定して登録簿を管理させます。
実例は RA
[3] IETF の規格については
IANA が一括して請け負っています。
(IANA登録簿)
[5] W3C には XPointer Registry があります。
[6] WHATWG は WHATWG Wiki や microformats wiki を使っています。
[19] OpenTypeタグは OpenType 仕様書に登録簿が組み込まれています。
失敗
[7] 関係者はあまり認めたがりませんが、登録制度はたいてい失敗します。
[8] 政治的理由で登録されないことがある。
実例: 国符号にコソボが登録されない,
ISO-IR に CNS 11643 (台湾) を登録するために政治的配慮を要した
[9] 煩雑な登録を避けて勝手に使われがち。
実例:
インターネットメールヘッダー, HTTPヘッダー, MIME型など
[11] 登録前は暫定的に私用の仕組みを使うべきとされがちだが、
登録に時間がかかっている間に私用の方の実装とデータが増えて、
正式に登録された方に移行しづらくなる。
強引に移行しようとして相互運用性の低下を招くこともある。
実例: X-
[12] 登録前に登録予定に基づき仕様書を書いたり実装したり、
データを生成したりした後に、違った形で正式登録されてしまう事故がたまに起きる。
実例: ISO-IR における JIS X 0201 終端バイト
[10] 登録後に登録簿の登録内容が放置されて、参照先規格の改訂に追随しないで放置されがち。
関連
[4] 製品の規格への適合性を検証する認証制度とは異なります。
メモ
[13]
IETF の一部の IANA登録簿では登録の敷居を下げるため
GitHub Issues による申請受付を導入したようです.
[14]
HTML のリンク型 (rel="") 登録簿は元々
WHATWG Wiki
にありましたが、 W3C 方面(?)からの政治的圧力に対する譲歩で
microformats wiki
に移動されました。
外野からは理解し難いのですが、謎の中立性(?)を求める人がいたみたいです。
[15]
HTML の <meta name> は WHATWG Wiki
に登録簿がありましたが、
標準規格を無視して好き放題に利用される現状にそぐわないということで廃止され、
どんな値でも使っていいことになりました。
ある種標準化の失敗といえます。
[16]
WHATWG は既存の IETF や W3C の Web 関連規格の標準化作業の機能不全を契機に設立されたという経緯もあって、
既存規格が採用し破綻していた IANA登録簿の置き換えを企図して新システムを模索していました。
誰でも編集可能な WHATWG Wiki による登録簿管理がそれで、
登録の敷居を下げ、登録担当者の個人的理由 (政治的理由を含む。) による登録停滞を防ぐことには成功しました。
しかし WHATWG 界隈では十分に成功したとは認識されていないようです。
[17]
近年の WHATWG は
<meta name> や rel="" で利用者エージェントの実装要件に関わるものは仕様書本体への
pull-request
で運用しています。
getContext は登録簿が廃止されて HTML Standard に統合されました。
登録制度を設けたことのない registerProtocolHandler
も同様です。
ウィキによる登録より作業コストは増えていますが、
他の種類の新機能も仕様書本体への
pull-request
によって追加されるのは同じです。
仕様書本体に追加され同じ基準でメンテナンスされ続けるので、
登録された後に実態と合わなくなるという課題も解消されています。
[18]
数年に1回紙の仕様書を出版していた前時代の標準化プロセスでは登録簿を分離する必要性もあったのでしょうが、
Living Standard
モデルで必要に応じて仕様書を随時改正し続けられる現代の標準化の世界では、
登録簿の必要性も薄れてきているのかもしれません。