要約

  • 人名由来の文字列は宛先を推測しやすくする一方、入力の多様性を狭い技術空間へ圧縮するため、利用者が増えるほど衝突する。
  • RFC 1439は、識別用の番号を常に表示し、番号なしの曖昧な形式を拒否し、古いメール参照が生きる間は識別子を再利用しないよう勧めた。
  • 表示名、ユーザー名、安定ID、外部ID、メールボックス、SMTPの責任移転、認証、認可は、それぞれ異なる範囲の事実しか証明しない。

二人目が同じ候補を持ってきた日

1990年代初めの組織で、アカウント名の作り方を一枚の紙に書けたとしよう。名とミドルネームの頭文字、姓を記号でつなぐ。規則を一例知れば、外部の相手も名簿を引かずにメールアドレスを推測できる。

その美しさは、同じ候補を作る二人目が現れた瞬間に崩れる。文字列は人を発見したのではない。割り当て前のキーを計算しただけだ。二人目だけに数字を付けるのか、最初から全員に付けるのか。大文字小文字や句読点は差になるのか。退職後に文字列を再配布するのか。どの判断も、名前空間が外部へ与える保証を書き換える。

Craig Finsethが1993年3月に公表したRFC 1439は情報提供文書であり、Internet Standardではない。文書は三つの方式を整理した。個人情報に依存しない不透明で一意な文字列を発行する方式は、衝突を管理しやすいが推測できない。人名を主成分にして数字などで一意に調整する方式は、推測可能性を残す。人名から生成し、重複だけを場当たり的に処理する方式もあった。

電子メールの普及は推測可能性の価値を高めた。だが、文字列を当てられることと、人との結び付きを証明できることは同じではない。人名は表示情報である。正規化は比較候補を作る。空き確認はある時点の局所状態を見る。割り当てが初めて枠と資源を結ぶ。

名簿にも誕生日問題がある

RFC 1439は、イニシャル、名、姓、それらの組み合わせが持つ典型的・最大の情報量をビットで見積もった。多くの形式は典型値で8～20ビットに収まり、表で最も豊かな典型形式でも26ビット、最大値も40ビットを超えなかった。空間が埋まって見えるより前に重複が起きる条件だった。

用いたのは誕生日問題の計算である。衝突機会は占有率だけでなく、比較される組み合わせの数とともに増える。名と姓を使う形式を典型17ビットとした例では、100人の組織で重複確率は2～5％、およそ4％。1000人では20％を大きく上回るとされた。

この数値をすべての社会へ移してはいけない。資料となった名前、文化、文字体系、転写、組織人口はいずれも歴史的な前提を持つ。残る原理は、衝突率が入力分布、比較関数、割り当て数に依存することだ。見た目の長さは実効的な多様性を示さない。

アクセント記号を落とす、大文字小文字を畳む、空白を消す、長い名前を切る、別の文字体系をローマ字化する。これらは一つの場面で互換性を上げながら、別々だった候補を同一化する。「一意」という言葉には、どの範囲で、どの比較規則によって、いつまで、という条件が必要になる。

番号なしを拒否することの意味

付録はFirst.M.Last-#という形式を検討した。最初の人だけ番号なしを使い、二人目に-2を付けてもよいか。答えは「否」だった。番号なしが最初の受取人へ黙って届けば、送信者は別人を選んだ可能性に気付けない。全員に番号を付け、番号なしを拒否すれば、失敗そのものが「識別情報が足りない」と知らせる。

この拒否は可用性の欠如ではない。システムが解けない曖昧さを、成功に見せないための制御である。最初の登録者を暗黙に選ぶ処理は、名前の衝突を誤配送へ変えてしまう。

文書は電子メールを慎重に扱う理由として、米国の1987年Electronic Communications Privacy Actにも触れた。これは1993年当時の著者の説明として読むべきで、現在法への判断材料ではない。技術的境界は明確だ。有効なメールボックスへ入ったことは、送信者が思い浮かべた人物の箱であることを証明しない。

さらにRFC 1439は、メールシステムの存続期間中、この種の識別子を再利用すべきでないとした。再利用は衝突を時間方向へ移す。古い連絡先、保存メール、配布リスト、アクセス権、復旧先、人の記憶は、最初の保持者が去った後も文字列を参照する。同じ枠を別人へ渡すと、文字列だけでなく、そこへ蓄積された信頼と未実行の操作まで引き継がれる。

したがって寿命は在職期間と一致しない。古いACLや回復経路、購読、メッセージが動作を起こせる限り、識別子は運用上まだ生きている。

SMTPの成功は人間の受領証ではない

RFC 5321は、アドレスをメール送付先の利用者または預け先を示す文字列、メールボックスをその保管場所として区別する。ローカル部の意味を決められるのはドメイン部が示すホストだけである。外部から同じ形に見えても、個人、共有キュー、転送別名、プログラム、継続用の旧入口かもしれない。

メッセージデータの終端でサーバーが成功を返すと、SMTP上の責任は正式に移る。受け取ったサーバーは配送するか、失敗を適切に通知しなければならない。これはプロトコルの引き渡し証拠であって、想定した人が所有し、読み、後続行為をした証拠ではない。

RFC 2142は人ではなく役割を指すメールボックスを標準化した。postmaster、abuse、noc、securityはサービス、役割、機能への入口であり、その機能に適切な受取人へ届けることが目的だ。担当者が変わっても入口は続く。

大文字小文字にも全世界共通の直感はない。RFC 5321はローカル部の大小を保存し、形式上は区別する一方、その差を利用すると相互運用性を損なうとして推奨しない。ドメイン名は区別しない。途中のシステムが宛先ドメインに代わって意味を正規化することはできない。

一つの「ID」に仕事を集めない

RFC 7643のSCIMスキーマでは、idはサービス提供者が発行し、その全資源内で一意、安定、再割り当て不可である。externalIdはプロビジョニングクライアントが発行し、そのドメインに限定され、サーバーは一意性を強制しない。userNameは提供者のUsers全体で一意な利用者向け識別子で、人名の構成要素は別属性だ。

同じ文字列でも発行者と範囲が違えば別の主張になる。異なる文字列でも、二つのシステムから同じ資源を参照できる。設計は、見やすい一つの値にすべての権限を負わせない。

RFC 8265は国際化ユーザー名を、しばしば人が使うが必ずしも人とは限らないアカウント指示子と定義し、制約の強いアカウント識別子と表現力のある表示名・ニックネームを分ける考え方を示す。大小を写像するプロファイルと保存するプロファイルの両方があり、選択はプロトコル、実装、運用に属する。重要なのは一律小文字化ではなく、検証側がどの比較を実行するかの明示だ。

証拠を段階に戻そう。表示名は提示する。正規化は候補を作る。空き確認は局所状態を観測する。割り当ては枠を結ぶ。メールアドレスは宛先ドメインの規則で保管場所を指す。SMTP成功は責任を渡す。認証は資格情報の制御を確かめ、認可は一つの行為を許す。どの段階も有用だが、上位の意味を自動では得ない。

共通層に必要なのは、全文化の人名を統一することではない。範囲、比較、衝突処理、割り当て遷移、再利用条件を決定的にすることだ。名簿は記述する。実行中の比較と配送が結果を作る。

出典