要約

  • 任意実装のCompleteコレクションには、成功した処理だけでなく、今後の状態更新を行わないprocessedの要求も入る。分類だけでは全処理の成功を証明できない。
  • 個別状態のcompleteは、関係する下流CDNを含めた成功を求める。下流のprocessedを中継側がcompleteへ格上げすることはできない。
  • 推定終了時刻は計画の助けであり、完了の証明ではない。このトリガー仕様は、相互接続CDN間の時計同期を要求していない。
  • 無効化、パージ、事前取得、取消し、状態リソースの削除には異なる効果がある。後続作業は、自分が必要とする前提の結果を見極めなければならない。
  • 以下の入れ替え場面は仕様の分析であり、実測した障害や特定事業者の不具合、普遍的な採用状況を述べたものではない。

管理画面では終わった作業

同じURLでコンテンツを入れ替える配信元を考える。古い内容をパージするよう配信パートナーに求め、その後で新しい内容を事前取得してもらう。新しい内容を古いパージに巻き込ませないことが、順番を分ける理由だ。

パートナーは要求を受け付ける。しばらくして、その状態リソースが活動中の分類からCompleteコレクションへ移る。担当者が一覧だけを見れば、次の取得を開始してよいように思える。

しかし、個別状態はcompleteではなくprocessedかもしれない。要求を受け付けたが、今後の状態更新は行わず、完了を確認できない場合にも使える状態である。報告の終了は、旧パージが新しい内容へ影響しないことの証明ではない。

これは仮定した運用場面だ。RFC 8007が明示する報告能力の限界を、後続の意思決定に照らしている。特定の商用CDNでこの誤りを観測したという意味ではない。

一覧を整理する側の質問は「まだ追跡すべき報告があるか」だ。入れ替えを進める側の質問は「必要な処理が成功したか」である。同じリソースを見ていても、必要な答えは異なる。

Completeという分類の意味

RFC 8007は2016年12月のIETF Standards Track文書で、RFC Editorの記録ではProposed Standardとされる。CDNI制御インターフェースのうち、処理を要求するトリガー部分を定義する。

上流CDNは、自分の代わりに配信する下流CDNへ、メタデータやコンテンツの取得、無効化、パージを依頼できる。その進行を状態リソースで確認する。これだけで、初期設定や商業上の信頼関係まで一つの管理方式に統合されるわけではない。

下流は要求元ごとの状態リソースの集合を提供する。絞り込んだコレクションは任意実装であり、提供する場合は全体コレクションからそのリンクを公開する。全実装が同じ絞り込み表示を持つとは限らない。

Completeコレクションは、成功して終わった要求と、今後の更新がないprocessedの要求をまとめる。名称は報告の追跡を整理するための分類であって、各要求に一律の結果保証を追加するものではない。

小文字のcompleteは個別処理の成功状態である。processedは、受け付け済みで今後の更新がないことを表し、完了を確認できない場面も含む。集合名と個別状態を同じ意味で読めば、仕様が残した情報を失う。

processedは、必ず失敗したという意味ではない。同時に、必ず成功した、何も実行していない、実際の処理が止まった、今後の効果がない、とも限らない。報告できる範囲が閉じたことと、効果が確定したことを分ける必要がある。

受付が与えるのは確認先

下流が要求を受け付けると、状態リソースを作り、HTTP 201でその場所を返す。上流は後からそれを参照できる。受付応答そのものは、要求した仕事がすべて済んだことを証明しない。

確認先は返されたリンクを使う。URLの構造やリソースとの対応を推測してはならず、仕様の例を固定の経路規則として扱ってはならない。一度使った状態リソースのURIは、削除後も再利用してはならない。

この識別の継続性は、過去の要求に後から結果を対応させるために重要だ。同じ場所が別の仕事に付け替われば、参照が生きているように見えても、判断の対象が変わってしまう。

追跡できる実装は待機、活動、成功または失敗を報告する。進行を追跡できない場合は、processedによって限界を示し、Completeに入れる。予定を立てるため、適切な推定終了時刻を提供することも推奨される。

新たな動作が不要な場合もある。まだ取得していないデータへのパージや、既に有効なデータの事前取得は、processedまたはcompleteで正しく扱える。成功状態を、移動したバイト数や消去した装置数の測定値に読み替えてはならない。

中継は確かさを増やさない

下流CDNがさらに別のCDNへ配信を委ねる場合、影響を受ける下流へトリガーを転送しなければならない。中継側のローカル作業だけが終わっても、関係する下流の結果は残る。

RFC 8007は、すべての関係する下流がcompleteになるまで、上位がcompleteを報告することを禁じる。ある下流がprocessedなら、中継側もprocessedを報告する。確認できなかった結果を、集約の途中で確認済みに変えることはできない。

これは全体を一か所から操作する要求ではない。実行の判断は分散していてよい。ただし、集約された答えは、実際に得られた証拠を超えて成功を主張してはならない。

一部のURLやパターンについてエラーが判明し、別の対象は活動中という場合もある。失敗は下流で発生した時点で報告でき、個別エラーは要求中の対象を特定する。

エラーに含めるURLやパターンは、要求された形を正確に保ち、より広い範囲へ一般化してはならない。一つの対象の失敗は全対象の失敗ではなく、別の対象のエラーがまだないことは成功の証明でもない。

この粒度は、選択的な継続を支える。独立した仕事には十分な結果があり、別の依存作業にはまだないことがある。すべてを止める判断も、一斉に次へ進める判断も、実際の依存関係には粗すぎるかもしれない。

RFC 7337のCDNI要件は、下流を含む処理について適切な完了報告と成否を求めていた。これは情報提供を目的とする要件文書であり、別の通信形式を規定する標準ではない。トリガー仕様は、限定された報告能力も明示的に表す。

成功の条件は処理ごとに違う

事前取得はメタデータやコンテンツの取得を求める。無効化は再利用前の再検証を要求するが、保存したデータの消去までは求めない。パージは処理後に指定データを保持しないことを求め、必要なら後から再取得できる。

現在のIANA登録も、この違いを保っている。再利用に条件を付ける結果と、データを保存しない結果は同じ物理的出来事ではない。

仕様は、対象となるキャッシュがオフラインでも、復帰後に再検証せず使わないという条件の下で、無効化をcompleteと報告できるとしている。これは将来の使用条件に関する成功で、オフラインの各装置が既に空になったという証明ではない。

パージや事前取得は、キャッシュの復帰後に完了する場合、processedを使える。作業を放棄するならエラーを報告すべきである。終端の報告をすべて、物理消去の完了として数えることはできない。

範囲は、要求されたデータと配信関係である。インターネット上のすべての複製が消えたとは言えない。過去に受信者へ渡った内容も、報告を変更しただけでは回収されない。

送信順と実行順の間にある裁量

開始時刻や実行のペースは下流が決める。パージと無効化は受付以前に取得したデータへ適用しなければならない。受付後の取得へ適用しないことは推奨されるが、上流はその除外が常に実現できると頼ってはならない。

命令の到着時に取得が既に始まっていた場合の扱いも、実装の判断に残される。上流が二つの要求を順番に送ったことは、すべての遠隔データに対する明確な切替線を作らない。

そのためRFC 8007は、同じURLで代替内容を事前取得する前に、パージまたは無効化を完了させることを推奨する。並行して進めれば、新しい内容を取得した直後に、まだ続く古い命令がそれを無効化または消去する可能性がある。

菱形の配信構成では、正当な取得経路が複数存在し、同じ命令が別々に届くこともある。下流は重複する処理を別々に予定できる。一方のパージが終わって事前取得を始めても、もう一方のパージが続いているかもしれない。

再取得によって利用可能性を回復できるという説明は、最初の継続判断がすべての競合処理の瞬時完了に支えられていたことを意味しない。依存する範囲と、残る別の命令を見分ける必要がある。

配信元は、確認済みの結果を待つのか、限定された見積りを合意して使うのか、次の仕事が不確かな対象から独立しているのかを決める。Completeという分類名は、どの選択も代行しない。

見積りと時計は証明の代わりにならない

任意のetimeは、下流が処理を終えると予想する時刻である。後続の取得を予定する助けにはなるが、その時刻に成功したと証明する項目ではない。

作成時刻、変更時刻、推定終了時刻は下流側で決められる。このインターフェースは互いの時計を同期させることを要求しない。異なる事業者の数値を並べても、それだけで共通の因果順序は得られない。

時計の基準や不確かさを考慮した予定は、当事者が局所的に合意できる。その合意はprocessedの意味をcompleteへ変えない。時計が正確に合っていても、見積りは見積りのままだ。

条件付きHTTP要求は、同じ表示を何度も取得する負担を減らす。RFC 8007はリソースとコレクションのETag利用を推奨し、HTTPの意味論とキャッシュ規則がその道具を説明する。

変わらないprocessedの報告への304は、表現が変わっていないことを示せる。しかし、もう提供しないと明示された結果を補えない。観測の頻度を上げても、観測契約の限界が広がるわけではない。

取消しは過去の効果を戻さない

サービスは取消し命令へ適切に応答する必要があるが、実際の取消しの実装は任意である。処理が非活動になった場合、受け付けたがまだ活動中の場合、機能を提供しない場合は区別される。

待機中の仕事が、取消しを処理する前に開始することがある。活動中の仕事をすぐ停止できるとも限らない。既に消去した内容を戻したり、取得をなかったことにしたりする一般的な効果はない。

既にcompleteまたはfailedの仕事を、後から取消し済みへ変更してはならない。報告の管理と実際に起きた効果の歴史を分ける必要がある。

通信で使う文字列にも注意が要る。検証済みの技術的訂正5053は状態値をcancellingとcancelledへ修正し、5054はecancelledを修正する。編集上の訂正5064は取消し例を状態削除の例と区別する。自然な説明へ言い換えても、プロトコル値自体を別の綴りにしてはならない。

状態リソースを削除すると、確認先と各集合内の参照がなくなる。取消しに似た効果はあるが、後の状態報告を残さない。削除後のGETが失敗したことは、削除以前の結果が成功だったことを示さない。

自動保管期限も、証拠を読める期間の終わりである。古い状態を削除する場合は、保管時間を知らせる必要がある。終端の報告を少なくとも二十四時間残すことは推奨で、無条件の必須下限ではない。必要な結果は、その窓が閉じる前に取得すべきだ。

安全な通信でも答えの限界は残る

命令の作用は、要求した上流のデータに限定される。菱形構成にある複数の正当な取得元は、他者のデータへ自由に干渉する権限ではない。状態集合も要求元ごとのもので、他のCDNへ見せてはならない。

仕様はTLSと遠隔相手の認証を要求するが、情報を守る別の安全な方法を使う場合は例外がある。具体的なアクセス制御は下流固有で、商業的な信頼関係はプロトコルの範囲外だ。

現在のTLS推奨事項は、元の仕様が引用する以前の指針を更新している。保護された交換は報告の出所を確認する助けになるが、すべての要求動作の成功を保証しない。

CDNIの枠組み、メタデータ、ログは補助的な根拠を提供する。一地点の配送成功や健全な記録を、オフラインを含む全下流の処理結果へ拡張してはならない。

出典

以下は仕様と検証済み訂正の一次資料である。実装の普及率や障害頻度を測定したものではない。