要約

  • RFC 3017のXML電話帳は、POPの選択だけでなく、dial script、DNS、proxy、gateway、username prefix/suffixをclientへ渡せた。表示用directoryではなく、接続挙動を変えるbundleだった。
  • phoneBookとPOPの増加counterは既知の系譜で差分を見つける手掛かりにすぎず、更新protocol、発行者認証、atomic commit、現役の接続先、認証結果を代替しなかった。

空港のホテルで、利用者は二冊の電話帳を見つけた。以前つながった版は41、新しく取得した版は73。数字だけなら73を選べばよい。

しかしRFC 3017が想定した世界では、consortiumが利用者群ごとに別の電話帳を配り、利用者も国別・媒体別のsubsetを作れた。phoneBook@nameは任意の文字列だった。版73と版41が同じ発行者、同じaudience、同じbaseから続くとは限らない。

2000年12月に公開されたRFC 3017は、roaming access phone bookのXML DTDを定義した。携帯電話網の現在のroamingとは別に、旅先で複数ISPのlocal access numberを選び、dial-upでnetworkへ入る時代の課題である。

電話帳にはaddressとmediaだけでなく、速度、tunnel、dial script、料金、場所、support、provider、DNS、mail、各種proxy、default gateway、usernameへ加えるprefixとsuffixを格納できた。softwareが自動抽出すれば、文書の値が実際の接続手順になる。

一冊にまとめても、情報の出所は一つにならない

各providerがPOP情報をconsortiumへ渡し、consortiumが統一版を作る。利用者向けに便利な構造だが、記録はproviderの申告、consortiumの編集、audienceごとの抽出、client側の保存という複数段階を通る。

RFC 2194は先行する実装の一つで、memberがsecretariatへPOPとproviderの情報を送り、手作業で電話番号を連結し、FTP、web、clientで更新を配っていたと記録する。proxy、dialer設定、support、server情報も含まれた。これはRFC 3017採用の証拠ではない。共通formatが必要になった運用背景である。

XMLが同じでも、どの申告がいつ取り込まれ、どの版へ残ったかは別の証拠だった。

版番号は時刻ではなく、scope付きの差分signalだった

phoneBook@versionは変更のたびに増やす整数とされた。serverはclientの値と比較して更新の必要を判断し、差分fileのURLを返すこともできる。

ところがRFCは差分fileの形式も、requestも、transportも定めなかった。そもそもphone book update/transfer protocolはscope外だと明記した。どのbaseへ適用するか、全byteが届いたか、検証後に一括commitしたか、失敗時に戻せるかは別の設計である。

RFC 2477が求めたupdate protocolの条件を見ると不足が分かる。server authenticity、任意の旧版から最新版への更新、適用前のintegrity確認、生成後bookのintegrity確認、軽量なtransfer、言語とcharacter setの選択が必要だった。

つまり「73」は発行側が変更を表明したことを示せても、clientのactive stateが73だとは示さない。同じ番号でdigestが違えば、番号だけではどちらも説明できない。

POPのentryVersionも同じである。mergeに有用とされたが、popにはXML IDがない。setup、support、providerはIDと参照を持てる。電話番号が変わった時、同一POPの更新なのかreplacementなのかは外側が識別しなければならない。消えたentryが削除、audience filter、不完全transfer、編集漏れのどれかもDTDからは決まらない。

counterの周りにidentityとtransition ruleが必要だった。

Valid XMLは電話をかけなかった

DTDの多くの値は#PCDATAだった。FQDN、IP address、encoded imageのnotationは意図する型を伝えるが、DNSへqueryせず、numberをdialせず、料金の期限を確認しない。

古い番号でも構文は正しい。到達不能proxyでも文字列としてvalidである。maxBitsPerSecondが記録されていても今回のline rateではない。extensionが登録されても、古いclientがその意味を実装済みとは限らない。

しかもclientは値を実行できた。dialScriptを使ってPOPへ接続し、usernameの前後へ文字列を自動連結し、DNS、mail、proxy、gatewayを設定する。誤った一行がdial先、認証identity、application trafficの経路を同時に変え得た。

文書のvalidityは重要だった。それは運用truthとは別だった。

Signatureはbyteの由来を守り、POPの現在を守らなかった

RFC 3017はissuer authenticationとintegrityを必要としながら、DTD内にsecurity elementを置かなかった。外部のPGP署名を例に挙げた。

署名検証は、trust policyの下で特定keyが特定byteを認証したことを示せる。しかし、署名後に番号が廃止されたか、料金が変わったか、そのeditionが現在のaudience向けかを確認しない。正しい署名を誤ったbaseへ適用することも、client実装の問題として残る。

接続後にも境界が続く。RFC 2486のNetwork Access IdentifierはPPP認証でuserを示し、authentication requestのroutingを助けた。carrierが上がってもNAIが拒否される場合がある。認証が通ってもIP address、tunnel、DNS、proxyが使えない場合がある。

download success、install success、dial success、authentication success、application successは同じreceiptではない。

DHCPと電話帳が異なる答えを出すこともあった

RFC 3017は、setupの一部の値がDHCPなど別の手段でも得られると認めた。電話帳のDNSとDHCPのDNSが違う時、DTDは優先順位を決めない。client policyとnetwork contextが決め、実際に使用された値を観測する必要がある。

したがってincident recordには、issuer、book name、audience、whole-book digest、version、選択POP、address、entryVersion、signature、parser/DTD revision、extension set、update base、commit結果、active configuration digestが要る。その後にdial、link、PPP、NAI、auth、address、tunnel、DNS、proxy、applicationを別々に残す。

「最新版を入れた」だけでは、古いdirectory、誤merge、回線障害、認証拒否、service障害を分けられない。

Standardが狭かったことは欠点ではなかった

RFC 3017はformatだけで全roaming systemを支配しようとしなかった。共通化すべきshapeを定義し、updateとtransportは別の課題として残した。このscope disciplineを壊すのはRFCではなく、狭いcounterへ過大な証明力を与える実装である。

Lu HengのRunning-Code Primacyは、published configurationをrunning networkで確かめる視点を与える。Reality Layersはdocument、issuer、installed state、service outcomeを分離する。Minimum Initial Specificationは共通層を薄く保つ理由と、transition、compatibility、local verificationを別途明示する必要を示す。

これらは分析枠であり、Lu HengがRFC 3017へ関与したという主張ではない。

電話帳は旅先の接続を現実的にした。しかし高い版番号が語れたのは、recordが動いたことまでだった。

networkがまだ答えるかどうかは、dialerの外で確かめるしかなかった。

情報源