Summary

  • A CoRE working-group draft updated on 2 November 2026 proposes a CoAP broker for clients that may be offline for long periods. Publishers PUT state to a topic-data resource; subscribers observe it or GET the latest representation. Revision 22 is still an Internet-Draft in IESG evaluation.
  • The draft defines retrieval of the latest topic data. It leaves earlier representations and a broker history-retention count to future work. A subscriber reconnecting to a normal reading cannot recover a missed alarm from that response alone.
  • A successful publish, an existing topic and a 2.05 response are separate facts. The Observe option confirms subscription; source authentication and an application action require their own evidence.

Imagine a temperature sensor at a plant. At midday it publishes an alarm value. An hour later it publishes a normal reading. The maintenance terminal spent that hour offline. When it reconnects, the broker hands it the latest normal value it received. The terminal can display that record accurately. The missed alarm remains absent from the response. This hypothetical sequence tests the protocol's retrieval contract.

The IETF CoRE pubsub draft is built for that intermittent world. A broker hosts a collection of topics, each with a configuration resource and a separate topic-data resource. A publisher sends a CoAP PUT to the topic-data URI. A subscriber sends a GET with Observe: 0 to receive updates, using the mechanism in RFC 7641. It can also GET the current topic data without a standing observation. The broker stores and forwards state update representations between clients that need not be awake together.

Latest is a useful answer to a smaller question

Section 3.3 of the draft is admirably specific. A GET returns the latest published representation. If the topic-data resource exists but nobody has published to it, the draft uses a proposed 2.06 No Content response. If the resource does not exist, the answer is typically 4.04 Not Found. These outcomes should not be squeezed into one dashboard state called “nothing happened.” A topic can exist without a reading; a deleted topic can have no resource; an active topic can have a latest reading that says nothing about intervening values.

The draft states that its mechanism retrieves only the latest representation. Earlier representations and a property controlling how many the broker stores are examples of possible future work. Therefore, an operator that needs a timeline of excursions must specify and verify a separate history service, journal or application record. The broker can answer “what is the current stored value?” It does not supply the missing hour of state changes merely because it was online while the terminal was not.

There is a second boundary at subscription. When a client registers with Observe: 0, a 2.05 Content response with the Observe option signals the subscription and carries the current data. A newly created topic can instead answer with 2.06 No Content plus Observe and later send the first publication. If the response lacks Observe, the client must treat the subscription as unsuccessful even when it received a successful response code. For example, a broker at its configured max-subscribers limit omits Observe. A status-code-only dashboard could announce a successful subscription that never existed.

Topic lifetime is also controlled by the broker. Creating a topic creates its topic-data resource before any value exists. Deleting the topic removes both resources and ends existing observations with a final 4.04. An optional expiration date may delete it automatically. An operator looking at a gap must distinguish a sleeping client, a refused subscription, an empty resource and a deleted topic. The wire result and the topic configuration provide different parts of that answer.

The broker's receipt does not sign the sensor's story

A publisher's successful PUT normally receives 2.04 Changed. That says the broker accepted an update under the CoAP request-response model. It does not state that every subscriber received that update, kept it or acted on it. Under load the broker may return 4.29 Too Many Requests, with Max-Age setting when the publisher may retry. An incident ledger must retain rejected and accepted publications, not only a sensor's assertion that it sent them.

The draft's security section separates the broker connection from the content's origin. Client-to-broker communication must be secured. Published content should also have end-to-end protection that includes source authentication, allowing subscribers to verify who published it. A transport-secure connection to the broker cannot by itself make a third-party sensor reading authentic to the subscriber. Nor does an authentic reading prove the maintenance terminal raised an alert or that anyone intervened.

The proposed architecture therefore has a precise value. It lets devices with long connectivity breaks rendezvous around the latest known topic state. That is a meaningful service for constrained systems. It is a poor alibi for failing to retain events when operations depend on what happened while a subscriber slept. The draft reports a protocol design, not a measured deployment or a promise that every intermediate state survives.

For a consequential alert, the missing fact is an ordered record of accepted publications and subscriber deliveries across the outage, tied to the source's authenticated identity and the topic's lifetime. If a deployment can produce that record through an additional service, the operator can reconstruct the incident. If it cannot, the new normal value remains only the latest reading. The broker has answered exactly the question it was asked; the organization has asked it to remember a question nobody commissioned it to answer.

CoRE pubsub draft · RFC 7641 · RFC 7252