要約

  • RFC 5328 は dvb NID を登録し、個別名の割当を DVB の標準化過程と指定 authority に置く。catalogue にあることは名の有効性を示すが、各端末の解決可能性までは示さない。
  • 放送 carousel、DVBSTP multicast、HTTP、DNS SRV は異なる経路である。名やresourceの認証情報は URN の外に置かれ、取得、rendering、application利用も後続の別 receipt になる。

片方の端末だけが成功した

運用画面では urn:dvb が緑だった。IP接続された端末は入口を発見し、resolverからlocatorを受け取り、resourceを取得した。一方、受信専用端末は何も得られなかった。

名前は同じで、catalogueの判定も同じだった。異なったのは利用できるchannelとbootstrapだった。中央のHTTP probeだけを見れば全体が正常に見えるが、そのprobeは放送streamのcarouselを観測していない。

RFC 5328 が単一の解決方式を指定しなかったのは欠落ではない。端末能力の差を設計に残した。監視もその差を残さなければならない。

NID登録は個別名の割当ではない

宣言された構造は urn:dvb:<NSS> である。IANA registryは dvb というnamespace identifierと参照文書を記録する。個別URNはDVBの標準化過程で割り当てられ、DVBが制度下の別主体へ一部を委任することもできる。

したがって、parserが正しい形だと認めても、個別名の存在は確定しない。RFC 8141 も、urn: で始まるsyntactically correctな文字列だけでは有効URNにならず、NID登録とnamespace固有規則が必要だとする。

receiptには入力文字列、正規化結果、NID registry版、DVB規則、assigner、delegation、catalogue版とmembershipを残す。単一の valid は根拠を失わせる。

catalogueが閉じるのは一問だけ

RFC 5328 は内蔵validation mechanismを指定せず、DVBがURN cataloguesを維持し、掲載されているURNをvalidとする。

これは割当の問いに対する明確な答えである。しかしresolver discovery、到達性、locatorのfreshness、resourceのauthenticityは別である。

catalogueが新しくなっても、broadcast pathはまだ旧RRを繰り返しているかもしれない。IP resolverのcacheだけが先に更新されることもある。双方が同じ名前をvalidと判断しても、返す場所は異なり得る。

catalogue publisher、version、publication time、authority、membership observationを解決receiptから分離して保存する必要がある。

永続性はendpoint固定ではない

DVBは割当済み文字列を再割当しないとし、正式URNを持つresourceのaccessibilityとpersistence維持を約束する。

この約束は名前の統治であり、一瞬のnetwork telemetryではない。location-independent identifierは、場所を変えても名前を変えないためにある。旧endpointが消えても、適切な新しい解決情報があれば名前は生き続ける。

逆に名前が有効でも、特定時点のDNS、multicast、HTTP、broadcastが必ず届くわけではない。名前の寿命と各pathのhealthを同じ時計で測ってはいけない。

放送端末は問い合わせられない

受信専用set-top boxは、service discovery情報をbroadcast streamから受け取る必要がある。home network end deviceはgateway経由でIPを使える。

文書はbroadcast内で周期送信されるResolution Authority RecordとResolution Record、DVBSTPによる周期multicast RR、GET /dvb/sdns へのunicast応答を説明する。

周期送信では、観測を始めた時刻とcycleが重要になる。multicastではjoinとrouteが必要になる。HTTPではendpoint discoveryとconnectionが必要になる。各pathの成功条件を一つの resolved に埋め込めば、どこで失われたか分からない。

receiver class、channel、first-seen time、record version、cache ageを残すことが最低条件になる。

bootstrap座標はserviceそのものではない

clientは最初にService Discovery and Selection entry pointを必要とする。RFCは dvbservdsc、TCP/UDP port 3937、登録multicast addressをdefaultとして説明し、非default入口を services.dvb.org 配下のDNS SRVで探す。

IANAのservice/port登録は番号の意味を合わせる。listenerの存在は証明しない。multicast address登録はjoinやpacket receptionを証明しない。SRV answerはtargetを示すが、接続、authority、current RRを証明しない。

bootstrap receiptはqueryまたは受信方法、answer、target、timestampまでを記録する。resolver receiptはその後に始まる。

RFC 8553 がRFC 5328を含むunderscore DNS利用を統合registry modelへ合わせたことも、命名coordinateの整備であってservice uptimeではない。

大文字小文字の一致はcontent比較ではない

RFC 5328ではNSSがcase-insensitiveである。二つの表記が同じ名として比較され得る。

それでもresolver response、catalogue epoch、locator、取得bytesが同じとは限らない。調査ではliteral inputとnormalized formを両方残し、その後のpathとcontent hashを比較する。

同じURNから異なるcontentが得られたとき、「名前は同じだった」は原因ではない。cache、authority、policyまたはresource updateを追うための出発点である。

認証はURNの外にある

RFC 5328 は、URNをlocationへ変換しaccessするときresource認証が必要になり得るとする。nameまたはresourceを認証する情報はURN内ではなく、URNとともに別情報として渡すべきだと明記する。

dvb prefix、catalogue掲載、正しいport、SRV response、HTTP successは自動的なtrust chainではない。何を、どのmechanismで、どのtrust anchorとpolicyに対して、いつ検証したかを別receiptにする。

NSS内のcharacterへDVBが特別な意味を与えた場合のsecurity consequenceもRFC 5328の範囲外である。見た目の階層からgeneric parserが権限を推論してはいけない。

authentic resourceでも端末が扱えない場合がある。表示できたresourceでもauthorityが不明な場合がある。authenticityとcompatibilityは別列である。

registrant更新は運用観測ではない

RFC 7354 はregistration informationとdeclared registrantを更新し、role-based emailを採用した。その他のfieldはRFC 5328のままと明記した。

これは行政上のcontact maintenanceを証明する。catalogue更新、resolver移行、DNS変更、broadcast到達性は証明しない。

新しいcontact日付をservice healthへ昇格させれば、registryが行っていない観測を付与することになる。contactとoperator endpointは関係していても同じ状態ではない。

例示URNをinventoryにしてはいけない

RFC内の二つのURNは教育用で、実在を保証しないと明記される。document parserがそれらをasset inventoryへ入れれば、syntax exampleからresourceを捏造する。

inventory登録にはassignmentとcatalogue evidenceが要る。監視対象化にはresolution authority、scope、ownerがさらに要る。IANAにNIDがあることも、その下の任意文字列の存在を示さない。

取得後にも複数の境界がある

resolutionはlocator、metadataまたはrepresentationを返し得る。その後にretrieval、authentication、freshness、parsing、transformation、rendering、application authorization、outcomeが続く。

異なるdevice classでは同じrepresentationを同じように扱えるとは限らない。metadataが正しくてもcontentが取れないことがある。画面が表示されてもinteractive actionが完了したとは限らない。

URNはreceiptを結合するpersistent keyである。最終結果を先取りする証明ではない。

証拠receipt

literal/normalized URN、NID registry、DVB rule、assigner/delegation、catalogue identity/version/membership、receiver class、channel、bootstrap、RAR/RR/DVBSTP/HTTP/DNS observation、selected authority、locator、separate authentication、content hash/freshness、parser、renderer、application authorization、outcomeを分けて保存する。

そのうち一列だけがgreenでも、他列の意味を引き継がせない。

出典