Summary

  • draft-ietf-core-conditional-attributes-14 lets a CoAP client request a projected observation stream using thresholds, steps, bands, edges and timing controls; it does not turn a quiet stream into proof that the underlying resource remained unchanged or safe.
  • A reliable conclusion needs separate receipts for supported parameters, sampling and evaluation, trigger arithmetic, notification scheduling, delivery through proxies, message acknowledgement and downstream action.

The freezer that stopped speaking

Consider a battery-powered freezer sensor observed with c.gt, a minimum notification period and a maximum evaluation period. The client receives the initial state, then one alert as the sampled temperature crosses the threshold. After that, the stream goes quiet.

The comfortable interpretation is that the freezer returned to normal. The protocol permits several others. The value may have continued to rise: c.gt normally reports the crossing, not every later value above it. A short excursion may have happened between evaluations. A sample may have met the condition while c.pmin still suppressed another notification. A proxy may have retained a same-value heartbeat. The server may never have supported one of the requested parameters and, by design, may have processed the observation as if that unsupported parameter were absent.

All of these states can produce silence. They do not have the same operational meaning.

Revision 14 of Conditional Query Parameters for CoAP Observe was posted on 14 September 2026 and expires on 18 March 2027. It is an active CoRE Working Group Internet-Draft intended for the Standards Track. Its working-group state still records a revised draft needed after an issue raised during last call. It is not an RFC, a deployment census or a certificate that any named server implements these semantics.

The draft solves a real problem. Ordinary CoAP Observe can deliver representations as a resource changes. Constrained clients often do not want every update. Conditional parameters let the server maintain a separate resource-state projection and deliver only the subset that matches the client's conditions. The gain is efficiency. The price is that the absence of a message becomes a compound fact.

A projection is not the resource

The notification conditions divide into several families. c.gt and c.lt look for crossings above or below a limit relative to the last reported value. c.st looks for a change of at least a stated step. c.band converts the threshold pair into an in-band or out-of-band region. c.edge looks for one direction of boolean transition.

These are not interchangeable descriptions of the physical state. A value that crosses c.gt and then keeps climbing normally creates one threshold notification, not a continuous alarm stream. Without c.band, continued residence beyond the limit is quiet. A c.st observer compares each sampled value with the last value that was reported, not necessarily with every state the resource occupied between samples. Sampling and minimum-period constraints can make the difference between two notifications larger than the requested step.

The server also has no priority ladder among simultaneous conditions. If several conditions are met together, it sends one notification and updates the last-notification state and time. The wire record may therefore be a coalesced consequence of several facts. Counting one message as one physical event would reconstruct a history the protocol never promised to preserve.

Support can be partial without rejection

The discovery marker if="core.conditional" is helpful but deliberately broad. Advertising it does not guarantee support for a particular condition, and the draft defines no fine-grained discovery mechanism for the individual parameters. A resource may also support conditional parameters without advertising the interface marker at all.

The more surprising rule concerns a valid but unsupported parameter. The server must treat it as having no effect and continue processing the observation. It must not reject the request solely because that condition is unsupported. A 2.05 Content response with an Observe option can therefore prove registration while leaving the requested projection only partly active.

That is different from an invalid value. The wrong data type, a non-positive period or an impossible minimum/maximum relationship calls for 4.00 Bad Request. It is also different from refusing an observer registration because extremely small c.pmax or c.epmax values create amplification risk. In that case the server may answer the GET normally but omit the Observe option. The missing option, not the success-class response alone, tells the client that no observation relationship was established.

Operational tooling needs all three states: accepted and supported, accepted with some condition ignored, and not registered. Flattening them into “request succeeded” destroys the very control surface the extension exposes.

Three clocks sit behind one quiet interval

c.pmin limits how often notifications may be sent. The server may retain the last sample seen during that interval, and the parameter may or may not drive sampling. A trigger can therefore exist before the protocol permits the next message.

c.pmax asks for a maximum time between notifications even when the value has not changed. Yet the implementation section is explicit that equal minimum and maximum periods do not form a hard real-time scheduling contract. Delivery is best effort. Missing the requested instant is not automatically evidence of a protocol violation, and meeting it once is not a durable timing guarantee.

c.epmin and c.epmax govern condition evaluation rather than notification. The former says the client has no interest in more frequent evaluation; the latter limits how long the server may wait before evaluating again. Neither proves continuous observation. A physical value can cross and recross a boundary between two evaluations without ever appearing in a sampled sequence.

The essential distinction is simple: the resource has a state; the sensor samples it; the server evaluates a sampled value; a condition creates a notification obligation; scheduling decides when a message may be sent. One timestamp cannot stand in for all five.

Delivery adds another boundary

CoAP Observe is designed to work with caches and proxies. That architectural benefit complicates periodic evidence. Revision 14 warns that a proxy can interfere with c.pmax updates when the representation remains unchanged. It recommends a Max-Age no greater than c.pmax as mitigation. A server log saying “notification sent” is therefore not a client receipt.

c.con=true narrows one uncertainty. It requires a confirmable CoAP notification, so the exchange can obtain an acknowledgement under CoAP's reliability machinery. But the acknowledgement belongs to the message. It does not prove that a proxy exposed every earlier state, that the client application parsed the value, that an actuator ran, or that a freezer returned to its permitted range.

Tokens correlate requests and responses; Observe sequence values help clients order notifications; OSCORE can protect a CoAP exchange within its security context. Each is valuable. None turns sampled telemetry into continuous physical truth.

Cancellation identifies a projection

A conditional observation is bound to its complete URI. To cancel explicitly with a GET, the client must reproduce the original conditional query as well as the cancellation signal. /temperature?c.gt=8 and /temperature?c.gt=10 are different projections even when they observe the same resource.

This matters during configuration changes. Removing the dashboard row is not proof that the old observer disappeared. A valid cancellation receipt includes endpoint, token, complete projection URI and the response that closes the relation. Otherwise the server can continue spending energy or sending alarms under a condition no operator still remembers.

Eight receipts for one “no alarm” claim

A defensible monitoring record links eight stages:

  1. The exact resource and epoch advertised or otherwise established conditional capability.
  2. The request URI, token and returned Observe option established the intended projection.
  3. The server's supported parameter subset was known rather than inferred from a generic marker.
  4. Sampling source, quantization and evaluation cadence bounded what could be observed.
  5. Threshold, band, edge or step arithmetic was applied against the correct last reported value.
  6. Minimum/maximum periods and coalescing explained the notification schedule.
  7. The message crossed caches and proxies and reached the intended client.
  8. The application acted, and the physical or business outcome was independently observed.

Silence becomes evidence only when the expected clocks and paths are bounded. Without those receipts, it is merely an empty interval in one projected stream.

What the draft does—and does not—prove

The frozen record supports a protocol analysis, not a product verdict. It establishes the proposed parameter semantics, best-effort timing caveat, unsupported-parameter behavior, proxy warning and amplification-sensitive refusal. It does not establish adoption, a named implementation, an incident, a safety certification, a measured loss rate or a legal duty.

The referenced amplification document is itself an expired IRTF draft. It explains why observation parameters can magnify traffic and why a server may protect itself. It is not evidence that a particular deployment was attacked.

Read through Heng Lu's distinction between records and authority, the conditional stream is a useful coordination layer. It reports what one server chose to sample, evaluate and send. Authority over the operational conclusion remains with the systems that can prove the physical state and execute the response.

Sources