Summary

  • RFC 8007's optional Complete collection contains successful triggers and processed triggers for which no further status updates will be made. Membership alone does not establish success.
  • The individual complete state requires successful completion, including affected downstream CDNs in a cascade. A processed descendant cannot be converted into a parent's complete result.
  • Estimated completion time supports scheduling but is not an attestation. The interface does not require interconnected CDNs to synchronise their clocks.
  • Invalidation, purge and pre-positioning have different outcomes. Cancellation and status deletion do not reverse work already performed.
  • The release scenario below is analysis of specified semantics, not a reported implementation defect or evidence of universal adoption.

The replacement waits for the wrong signal

Imagine a publisher replacing material at an existing set of URLs. It asks its delivery partner to purge the previous material, intending to pre-position the replacement afterwards. The partner accepts the request. Later, the trigger appears in the collection reserved for completed reporting.

A release controller could take that movement as permission to start the next job. The word Complete is reassuring. The request is no longer in an active queue. No new error has arrived. Yet the individual resource says processed rather than complete.

That is not a cosmetic difference. The reporting channel has reached a point at which it will provide no further updates. Successful completion of the underlying purge may remain unconfirmed. A publisher that depends on the purge's result has not necessarily received the result it needs.

This imagined sequence is not a finding about a named CDN. It is a way to examine a decision boundary deliberately exposed by RFC 8007. A standard can permit limited reporting without granting the next operator permission to call uncertainty success.

One collection, two kinds of closure

RFC 8007 was published in December 2016 as an IETF Standards Track specification; the RFC Editor record lists Proposed Standard. It specifies the trigger part of the CDNI control interface, through which an upstream CDN asks a downstream CDN to acquire, invalidate or purge metadata or content.

It does not define the whole commercial relationship, every configuration procedure or a universal CDN management plane. The broader framework distributes control, metadata, routing and logging functions. The trigger interface gives one partner a way to request certain work and inspect its reported state.

The downstream CDN provides a collection of status resources for the requesting upstream. Filtered collections are optional, but an implementation that offers them must expose their links. The Complete collection includes successful work and processed triggers for which no further status updates will be made.

The individual complete state has a stronger meaning: the triggered command completed successfully. The individual processed state says it was accepted and no further status update will be made, including cases in which completion cannot be confirmed.

Neither the collection name nor the absence of another report removes that distinction. Processed is not universally failure. It is also not universally success, a declaration that nothing happened or a guarantee that nothing more will happen. It describes the limits of the available reporting promise.

This makes the collection useful for an observer deciding which resources still need status tracking. It makes collection membership insufficient, by itself, for an operator deciding whether a result-dependent action is safe. The observer's work can close before the prerequisite for somebody else's work has been proved.

An accepted request is a resource, not an outcome

An accepted trigger creates a status resource and returns its location with HTTP 201. That response gives the upstream something to inspect. It does not turn the requested operation into an accomplished fact.

The resource's location is returned by the service. An upstream must not infer its structure or guess the mapping between resource names and URLs. Once used, a status-resource URI must not be reused, even after the resource is removed. Identity continuity matters when a later result is attached to an earlier request.

A downstream capable of tracking progress can report pending, then active, then complete or failed. If it cannot track and report that progress, it must disclose the limitation through processed and put the resource in the Complete collection. It should supply an estimated completion time where appropriate.

There are also legitimate no-work cases. A purge might refer to data the downstream has not acquired. A pre-positioning request might concern a valid object already available. Such triggers may correctly be processed or complete. A successful status is therefore not a measurement of how many bytes moved or were erased.

The request, its scope, its individual result and the dependent business decision are separate records of meaning. Collapsing them into a single green collection counter makes operations easier to summarise but harder to govern.

The result must survive the cascade

CDNI permits a downstream CDN to delegate delivery further. A trigger affecting those descendants must be forwarded. A parent must not report complete until the trigger is complete in all its affected downstream CDNs.

If a descendant reports processed, intermediate CDNs must propagate processed rather than announce complete. The interface does not allow a parent to upgrade limited observation into confirmed success merely because its own local work finished.

Failure can be reported as soon as a CDN or descendant fails. Individual error descriptions identify affected requested URLs or patterns. A request can still be active for some targets while errors are already available for others. One error is not evidence that every target failed; silence about a target is not automatically evidence that it succeeded.

That matters for selective continuation. A publisher may have independent work with a sufficient result and dependent work whose prerequisite remains uncertain. A blanket halt can be as crude as a blanket success declaration. The proper boundary follows the requested operation and the evidence available for its affected scope.

The CDNI requirements, an Informational document, had already called for completion reporting appropriate to the action, including success or failure. The trigger specification supplies a concrete vocabulary that preserves a limited-reporting case rather than hiding it.

Purge is not invalidation

Pre-positioning asks the downstream to acquire metadata or content. Invalidation requires revalidation before affected data is reused; it need not erase the stored material. Purge requires the specified data no longer to be held after servicing the request, although it can later be reacquired when needed.

Those differences are present in the current IANA trigger registrations. A result that is adequate for one action need not describe the same physical outcome as another.

RFC 8007 explicitly permits invalidation to be reported complete when affected surrogates are offline, provided they do not reuse the affected data without revalidation when they return. That is a future-use restriction, not proof that each offline storage device was physically emptied.

Purge and pre-positioning can instead be processed when offline caches will finish the work on returning to service. If work is abandoned, an error should be reported. An operator must distinguish an assured future revalidation rule from unconfirmed erasure or acquisition.

None of these states establishes that every copy on the Internet disappeared. Nor can a later status change recall content already delivered. The relevant promise concerns the requested data and the interconnected delivery arrangement, not all downstream human possession.

The next load can be caught by the old purge

Execution timing, start and pacing are controlled by the downstream. Invalidation and purge must cover data acquired before acceptance. They should not affect data acquired afterwards, but the upstream cannot count on that exclusion always being achieved.

The treatment of acquisition already underway is also implementation-dependent. A publisher cannot infer a clean global cutover simply from the order in which it sent two requests.

RFC 8007 therefore recommends completing invalidation or purge before initiating replacement pre-positioning at the same URLs. If the requests run in parallel, new material may be fetched and then immediately invalidated or purged by the earlier work.

A diamond distribution arrangement adds another complication. The same content can arrive through multiple legitimate upstream paths, and repeated commands can be scheduled separately. A replacement following one completed purge may encounter another branch's still-running purge. Reacquisition can restore availability, but it does not mean the first release decision had an instantaneous, universal completion guarantee.

This is why the imagined publisher needs to name its prerequisite. Has the relevant purge completed successfully? Is an estimate sufficient under a knowingly accepted local arrangement? Is the replacement independent of the uncertain target? Each answer leads to a different continuation decision. The Complete collection answers none of those questions solely through its name.

An estimate does not convert itself into evidence

The optional etime property estimates when the downstream expects to complete the activity. It can help the upstream plan when to pre-position replacement material. It is not an attestation that the work succeeded at that instant.

The status resource's creation, modification and estimated-completion times are determined by the downstream. This trigger interface explicitly imposes no clock-synchronisation requirement between interconnected CDNs. Sorting numbers from different operators does not, by itself, establish cross-network causal order.

A locally negotiated schedule may account for clock differences and uncertainty. That is an operating arrangement, not a new mandatory field or an excuse to relabel processed as complete. The distinction survives even if both parties happen to have well-synchronised clocks.

Conditional HTTP requests help an observer avoid repeatedly downloading unchanged representations. RFC 8007 recommends ETags for resources and collections. HTTP semantics and caching rules explain those tools, but an unchanged representation is not a new result.

A 304 response to a processed resource can truthfully say that the report has not changed. It cannot supply the completion evidence that the reporting promise stopped providing. Faster observation does not repair an intentionally limited observation contract.

Cancellation closes no historical loop

The service must respond appropriately to a cancellation command, but implementing actual cancellation is optional. A response can indicate inactive work, acceptance while work remains active or unsupported cancellation. A pending request can race the start of execution.

Stopping active or processed work is not guaranteed immediately. Cancellation does not restore erased content or undo acquisition already performed. A trigger already complete or failed must not be retrospectively changed to cancelled.

Wire values also deserve care. Verified erratum 5053 corrects the status strings to cancelling and cancelled; 5054 corrects the error code to ecancelled. Editorial erratum 5064 distinguishes an explicit cancellation example from status deletion. Readable English spelling must not silently alter a protocol value.

Deleting a status resource leaves no resource to inspect and removes its collection references. Its effect resembles cancellation, not rollback. A later failed GET can mean the evidence has been removed; it does not establish which outcome occurred before removal.

Automatic retention has the same evidential boundary. Where stale records are deleted, the advertised retention duration matters. Keeping terminal records for at least 24 hours is recommended, not an unconditional mandatory minimum. An upstream should obtain needed results before their reporting window closes.

Protected exchange is not successful actuation

The trigger service must restrict a requesting upstream to its own data. The standard's diamond case acknowledges potentially legitimate multiple acquisition paths; it does not authorise arbitrary cross-tenant interference.

Status collections belong to their requesting upstream and are not exposed to other CDNs. TLS and remote authentication protect the exchange unless alternative security protects the information. Access-control mechanisms remain downstream-specific, and commercial trust is outside the protocol.

Current TLS recommendations supersede the earlier guidance cited by the original specification. Protected transport can establish that a report came through the intended protected relationship. It cannot establish that every requested cache action succeeded.

The framework, metadata interface and logging interface provide complementary operating surfaces. They are not interchangeable receipts. A healthy delivery observation, routing decision or log entry at one point cannot certify every offline descendant's data state.

Sources

The analysis uses primary specifications and the verified corrections above; it does not measure implementation coverage.