要約

  • RFC 3059は、SLPv2のUser Agentが、Service Reply中の各URLとともに完全な登録属性リストを求められるようにした。要求側では意図的に空の拡張を送り、応答側がURLごとの拡張を埋めた。
  • 0x0002は任意実装で、未知なら無視する拡張だった。応答に拡張がないことは空属性の証明ではなく、URLごとのAttribute Requestへ移る合図であり、要求したSLP SPIの認証ブロックを返せない場合にも同じ不在が生じた。

空の器が要求を表した

サービス発見には、候補を見つける問いと、候補を選ぶための属性を得る問いがある。SLPv2の基本交換では、User AgentがService Requestを送り、SAまたはDAがService URLを返した。属性が必要なら、URLやサービス型に対して別のAttribute Requestを送る。

2001年2月にProposed Standardとして公開されたRFC 3059は、この二段階を一往復にまとめた。User AgentはService RequestへAttribute List Extensionを付ける。その要求形式ではService URL LengthとAttribute List Lengthをゼロにし、URLと属性リスト自体を省略した。

ここで空白は欠損ではない。「返信に属性を付けてほしい」という操作可能な記号である。要求中のゼロ長を、サービスが属性を持たないという観測へ変換すれば、応答を受ける前に結論を捏造することになる。

URLが属性との結合キーだった

拡張を実装したSAまたはDAは、Service ReplyのURL Entry一件につき一つのAttribute List Extensionを返す。拡張には対応するService URLと、そのサービスの完全な属性リストが入る。拡張の順序はURL Entryと同じであることが望ましい一方、対応URLは拡張内にも明記された。

したがって結合を支えるのはURLである。順序は検査材料にはなるが、明示された識別子を捨てて配列位置だけに依存すべきではない。

「完全な属性リスト」にも範囲がある。要求の言語で、応答側が保持している登録属性の全体である。実サービスの全状態ではない。登録の寿命が残っていても接続不能なことはあり、現実の能力が登録されていなければ一覧には現れない。RFC 3059が速くしたのは広告記述の搬送であり、実行の観測ではなかった。

任意番号が後方互換性を作った

IANAはAttribute List Extensionへ0x0002を割り当てた。RFC 2608では0x0000から0x3FFFまでが、標準化されているが任意実装で、未知なら無視する範囲だった。古い相手は拡張を理解しなくても、通常のService Replyを返せた。

その互換性はクライアント側に責任を残す。拡張のないService Replyを受けたUser Agentは、SAまたはDAが拡張を支援しないと仮定し、得られたURLごとにAttribute Requestを送らなければならない。不在は回復手順の入口であり、空の属性リストではない。

RFC 3421のSelectやSortのように、後の拡張には必須実装範囲とOPTION_NOT_UNDERSTOODを使うものもあった。それは有用な比較だが、0x0002へ遡及する規則ではない。拡張という形式だけから失敗動作は決まらない。

認証要求も拡張を消し得た

Service RequestにはSLP Security Parameter Indexを含められた。SPIがあれば、返すAttribute List ExtensionはそのSPIの認証ブロックを含まなければならない。SAまたはDAがそのブロックを支援できない、または返せないなら、拡張自体を返してはならない。

同じ「拡張なし」には、未実装と認証文脈を満たせない状態が重なる。RFC 3059がクライアントに求めた実務上の行動は、いずれも個別のAttribute Requestへのフォールバックだった。沈黙から細かな原因を創作してよいとは書いていない。

認証ブロックの意味も限定的である。RFC 2608では、対象内容が変更されず、認可されたエージェントから送信されたことを、SPIが示す鍵材料と期限の下で検証する。検証成功は、サービスの現在の到達性、利用者のアクセス権、アプリケーション処理の成功を証明しない。

一往復に圧縮されたのは会話だった

四つのURLを発見し、その属性を知る場合、拡張なしでは一つのService Requestに四つのAttribute Requestが続き得る。双方が対応すれば、同じ登録記述を一つの返信で運べる。変わるのは遅延とメッセージ数であり、データの権威ではない。

この区別を失うと、富化データが届かなかった画面が「能力なし」と表示し、互換経路を実行しなかった資産表が「属性ゼロ」を保存し、選択器が利用可能な候補を捨てる。RFC 3059のフォールバック規則は、「ここで運ばれなかった」と「存在しない」を分ける古いが鋭い設計だった。

出典