Summary

  • Der CoRE-Pubsub-Entwurf in Revision 22 vom 2. November 2026 beschreibt einen CoAP-Broker für länger getrennte Clients. Publisher schreiben mit PUT; Abonnenten beobachten die Datenressource oder lesen deren letzte Darstellung. Der Entwurf befindet sich noch in der IESG-Bewertung.
  • Abschnitt 3.3 definiert den Abruf der neuesten Darstellung. Frühere Darstellungen und eine einstellbare Anzahl gespeicherter Versionen bleiben möglicher zukünftiger Arbeit vorbehalten.
  • Ein bestehendes Topic, ein akzeptiertes PUT und ein erfolgreiches Abonnement sind verschiedene Belege. Ohne Observe-Option in der Antwort kam das Abonnement nicht zustande, selbst wenn der Antwortcode erfolgreich aussieht.

Ein Temperaturfühler meldet einen gefährlichen Anstieg und eine Stunde später wieder einen normalen Wert. Das Wartungsterminal war in dieser Zeit offline. Nach der Rückkehr erhält es vom Broker den letzten normalen Wert. Für die Frage nach dem Jetzt ist das eine brauchbare Antwort. Für die Frage nach dem Alarm in der Zwischenzeit ist es keine Antwort. Die Anlage ist ein hypothetischer Testfall; der Entwurf beschreibt keinen konkreten Fabrikvorfall.

Der IETF-Entwurf stellt dem Fühler und dem Terminal einen Broker zur Seite. Er hält Topic-Sammlungen, Konfigurationsressourcen für einzelne Topics und getrennte Datenressourcen bereit. Der Publisher sendet PUT an die Daten-URI. Der Abonnent verwendet GET mit Observe: 0 nach dem Verfahren aus RFC 7641. Ein einfacher GET kann den derzeitigen Wert lesen. Die URI der Topic-Konfiguration und die URI der Daten müssen keinem gemeinsamen Pfadmuster folgen; die Eigenschaft topic-data zeigt die Datenadresse. So können Geräte Zustandsänderungen austauschen, ohne dauernd gleichzeitig online zu sein.

Der letzte Wert ist keine Ereignisliste

Schon „keine Daten“ hat mehrere Bedeutungen. Beim Erstellen eines Topics entsteht die Datenressource, aber noch keine Darstellung. Dafür sieht der Entwurf die vorgeschlagene Antwort 2.06 No Content vor. Fehlt die Ressource selbst, kommt gewöhnlich 4.04 Not Found. Gibt es einen veröffentlichten Wert, liefert GET die neueste Darstellung. Ein Leitstand, der alle drei Fälle als „kein Alarm“ färbt, verwischt die Lage des Topics noch bevor er nach einem Vorfall sucht.

Abschnitt 3.3 zieht die historische Grenze ausdrücklich: Nur die letzte Darstellung lässt sich mit diesem Verfahren abrufen. Eine spätere Spezifikation könnte auch ältere Versionen zugänglich machen und deren Anzahl festlegen. Darauf kann ein Betrieb heute keine lückenlose Ereignisrekonstruktion stützen. Wenn der Fühler erst Alarm und dann Entwarnung veröffentlicht, braucht der Betrieb ein zusätzliches dauerhaftes Protokoll, um die Zwischenzeit später zu prüfen.

Auch die Beobachtung muss wirklich zustande kommen. Eine Antwort 2.05 Content mit Observe bestätigt ein Abonnement und liefert den zuletzt veröffentlichten Wert. Ein noch leeres Topic kann mit 2.06 No Content plus Observe bestätigen und die erste Veröffentlichung später melden. Fehlt Observe, sollte der Client das Abonnement als gescheitert behandeln. Bei ausgeschöpftem max-subscribers lässt der Broker die Option weg. Wer nur den erfolgreichen Antwortcode liest, kann ein einmaliges Lesen mit laufender Überwachung verwechseln.

Topics haben zudem ein Ende. Das Löschen entfernt Konfigurations- und Datenressource; Beobachter erhalten eine letzte 4.04-Antwort. Ein optionales Ablaufdatum kann das automatisch auslösen. Eine Lücke kann daher durch Schlaf des Terminals, Ablehnung des Abonnements, eine noch leere Datenressource oder Löschung des Topics entstehen. Der jüngste Messwert unterscheidet diese Ursachen nicht.

Annahme beim Broker ist keine Handlung am anderen Ende

Ein erfolgreiches PUT wird nach dem CoAP-Modell in RFC 7252 gewöhnlich mit 2.04 Changed quittiert. Das belegt, dass der Broker die Aktualisierung angenommen hat. Es belegt weder die Zustellung an jeden Abonnenten noch eine Reaktion der Wartungsanwendung. Bei zu schnellen Veröffentlichungen kann 4.29 Too Many Requests folgen; Max-Age setzt die Wartezeit bis zum nächsten Versuch. Ein Ereignisjournal muss angenommene und abgewiesene Werte auseinanderhalten.

Der Entwurf verlangt geschützte Kommunikation zwischen Client und Broker. Für veröffentlichte Inhalte empfiehlt er zusätzlich Ende-zu-Ende-Schutz mit Authentifizierung der Quelle, damit Abonnenten den Absender prüfen können. Ein sicherer Kanal zum Broker macht den Sensorwert gegenüber dem Empfänger noch nicht automatisch authentisch. Selbst ein authentischer Wert ist noch keine Quittung dafür, dass ein Alarm angezeigt oder bearbeitet wurde.

Der Nutzen für schlafende Geräte ist erheblich: Nach der Rückkehr steht der zuletzt veröffentlichte Wert bereit. Der Entwurf verspricht aber keine vollständige Zwischenhistorie und enthält keine gemessene Einsatzbilanz. Entscheidend für einen Betreiber wäre eine geordnete Kette der angenommenen Veröffentlichungen, der Zustellungen und der Handlungen während der Unterbrechung. Ohne sie kann der normale Wert nur den letzten Broker-Eintrag erklären, nicht die verlorene Stunde entlasten.

CoRE-Pubsub-Entwurf · RFC 7641 · RFC 7252