要約

  • 初期 LDAP の MessageID は、同じ session で処理中の request 同士を区別すればよかった。一件の search が返す entry、reference、最終結果は同じ番号を持ち、複数操作の応答を交錯させられた。
  • Abandon は自分の envelope ID と対象操作の ID を別々に持つが、結果応答を返さない。停止の成否が必要な用途には、RFC 3909 が応答を伴う Cancel を追加した。
  • paged search は page ごとに新しい message ID を使い、継続状態は opaque cookie が担う。ID は認証情報でも、永続的な検索名でも、rollback の証明でもない。

一回の検索は一通の返事ではなかった

LDAP の lightweight は X.500 directory への接続方法を軽くするという意味で、結果を一通に縮めるという意味ではない。subtree search は、多数の directory entry、未探索領域への reference、そして最後の成否を順に返し得る。

1993 年 7 月の RFC 1487 は、全操作を共通の LDAPMessage envelope に入れた。共通 field は整数の messageID で、同じ LDAP session に残る他の request と異なる値を使う。server は、その request に対応する全 response envelope に値を写す。

従って番号は packet の通し番号ではない。一件の search が百件の entry を返しても、百件は一つの操作状態に属する。entry の対象は distinguished name が示し、message の種類は protocolOp が示す。Message ID は受信した PDU を client の正しい未完了状態へ戻す join key である。

別 session の client が同じ 12 を使っても問題はない。同じ client も旧操作の終了を確かめた後なら 12 を再利用できる。必要だったのは世界的な一意性ではなく、receiver が比較できる範囲で同時作業を混同しないことだった。

transport 順序と操作順序を切り離した

1995 年の RFC 1777 は、client と server に synchronous な動作を要求しなかった。複数操作の request と response は任意の順序で交換できる。

たとえば search 12 の entry が一件届いた後、compare 13 の結果が先に戻り、その後 search 12 の残りと最終結果が続く。TCP は byte を順序どおり運ぶが、各 message がどの application operation に属するかは決めない。Message ID が一本の byte stream を複数の論理 stream に分けた。

RFC 2251 は 1997 年の LDAPv3 でもこの仕組みを維持し、最大値を 2^31−1 とした。典型的 client は counter を増やすが、重要なのは単調増加ではなく、未完了 request の間で重複させないことである。最終 response 前の再利用は未定義の動作を招く。

Search response は SearchResultEntry、SearchResultReference、SearchResultDone に分かれた。entry と reference は混在でき、一つの Done が最後に成功か error を示す。entry を受け取った事実は search 完了の証明にならない。Done は結果を伝えると同時に、通常は ID の寿命を閉じる観測可能な境界となった。

ID ゼロは質問のない通知に残された

2006 年には LDAPv3 文書群が整理された。RFC 4510 が旧仕様との関係を記録し、RFC 4511 が protocol rule を引き継いだ。

request の messageID は nonzero と明記された。zero は server が request への応答ではなく送る unsolicited notification 用である。Notice of Disconnection は zero と通知固有の OID を使うため、存在しない operation zero の返事に見えない。

これは server の権威を証明する reserved number ではない。client 起点の進行中 work と、定義済みの server 起点通知を局所的に分けるだけである。通知の意味は operation type と OID が与え、transport protection や authentication は別の層が担う。

ID の再利用時期も時計ではなく server-side service life に従う。最終 response や後続 Bind の完了などから、旧 request がもう処理されていないと判断できて初めて再利用できる。local timeout は connection close や reconciliation の trigger にはなっても、remote state 消滅の証拠ではない。

Abandon は二つの番号を使い、結末は返さなかった

Abandon 自体も LDAP request なので、その envelope には新しい MessageID がある。payload には別の MessageID が入り、止めたい以前の操作を指す。新しい行為の相関と target 選択を一つの値に押し込めなかった点が重要である。

Abandon response は存在しない。RFC 4511 では server は対象を abandon してもよい。entry 送信中の search を止めるなら、その後の entry を送らず SearchResultDone も返さない。しかし、既に transport に出た結果は届き得るし、そもそも abandon できない操作もある。

client が結果を不要としたときには効率的だが、silence を receipt に変えることはできない。正しい target ID を送ったことと、server が停止したことは別の fact である。

RFC 2251 はこの不確実性に対し、後から送った別 request の response を受けるまで Abandon と対象の ID を再利用しないよう求めた。その後続 response は abandon 成功の確認ではなく、session 処理が先へ進んだという控えめな手掛かりにすぎない。

Cancel は古い信号を誇張せず、新しい結果を作った

2004 年の RFC 3909 は、結果を必要とする application 向けに Cancel extended operation を定義した。Abandon の意味を書き換えず、response を持つ別操作を追加した。

Cancel envelope は自分の ID を持ち、cancelID が未完了の対象を示す。成功すれば Cancel response が success を返し、対象操作は canceled result で終わる。失敗時には noSuchOperation、cannotCancel、tooLate が理由を分ける。

tooLate の例は underlying data store に既に commit された modify である。対象を完全に識別できても、不可逆な effect を巻き戻す権能は生まれない。correlation と rollback は異なる制御面にある。

Bind、StartTLS、Unbind、Abandon、Cancel は Cancel の対象にできない。これらは通常操作を支える authentication、security、association を作り替える。相関番号が、自分の意味を成立させる枠組みまで無制限に消せないようにした境界である。

次の page には次の operation が必要だった

RFC 2696 の simple paged results は、Message ID が永続検索名でないことを示す。server は page の SearchResultDone に opaque cookie を入れる。client は次 page を求める際、検索条件をほぼ同じにしつつ messageID を変え、最新 cookie を送る。

page request ごとに LDAP operation は新しい。結果集合の continuation を担うのは cookie である。古い cookie の再利用は未定義になり得て、empty cookie は終了を示す。Abandon は進行中 page を止められるが cookie を無効にする場合があり、sequence の終了には size zero と最新 cookie を持つ新 search を使う。

つまり ID は「この session のどの進行中操作の message か」を答える。cookie は「後続操作が server のどの結果位置を再開できるか」を答える。directory entry の名、access permission、attribute の真実性はいずれも別問題である。

RFC が証明する範囲

閉じた史料集合は RFC 1487、RFC 1777、RFC 2251、RFC 2696、RFC 3909、RFC 4510、RFC 4511 である。protocol の形式と規範の変遷は示すが、現代の普及率、製品の適合性、個別 operation の実際の結末は示さない。

小さな整数が長く機能した理由は、権限の範囲が小さかったからだ。receiver が検査可能な state に message を結ぶ。それ以上の完了、取消、継続、認証、認可には別証拠を要求した。