Zusammenfassung

  • draft-ietf-core-conditional-attributes-14 ergänzt CoAP Observe um Bedingungen und Zeitsteuerungen, erklärt aber ausdrücklich, dass gleiche Werte für c.pmin und c.pmax keine harte Echtzeitplanung erzeugen.
  • Eine belastbare Aussage über einen stillen oder verspäteten Strom braucht getrennte Belege für Unterstützung, Abtastung, Auswertung, Trigger, Versand, Proxy-Pfad, Empfang und ausgeführte Wirkung.

Ein scheinbar perfektes Metronom

Ein Betreiber konfiguriert c.pmin=60 und c.pmax=60. Zehn Minuten lang kommt jede Minute eine Darstellung. Das Dashboard lernt daraus eine Regel: Bleibt der nächste Puls aus, ist der Sensor ausgefallen. Als der elfte Puls sechs Sekunden spät eintrifft, eröffnet das System einen Vorfall.

Der Drahtmitschnitt kann die Verspätung beweisen. Er beweist aber nicht den behaupteten Vertragsbruch. Der aktuelle Entwurf sagt, dass selbst die Gleichheit beider Perioden keine harte Echtzeitplanung bedeutet; die Erfüllung ist Best Effort. Gleichzeitig könnte die Ursache an einer anderen Stelle liegen: verspätete Bedingungsauswertung, Sendewarteschlange, Proxy-Cache, Transportverlust oder Client-Verarbeitung. Eine gemeinsame rote Lampe verwischt diese Grenzen.

Revision 14 von Conditional Query Parameters for CoAP Observe wurde am 14. September 2026 veröffentlicht und läuft am 18. März 2027 ab. Es handelt sich um einen aktiven Internet-Draft der CoRE Working Group mit Standards-Track-Absicht. Der Datatracker vermerkt weiterhin, dass nach einer Frage aus dem Working Group Last Call eine überarbeitete Fassung benötigt wird. Das Dokument ist weder RFC noch Nachweis einer Implementierung oder eines realen Vorfalls.

Der Mechanismus ist sinnvoll: Ein eingeschränktes Gerät muss nicht jede Zustandsänderung übertragen. Der Server kann für einen Client eine bedingte Projektion des Ressourcenstatus führen und nur ausgewählte Änderungen melden. Die Einsparung bei Energie und Bandbreite ist real. Ebenso real ist der zusätzliche Beweisbedarf, wenn aus ausbleibenden Paketen eine Aussage über die Welt werden soll.

Fünf Bedingungen, fünf verschiedene Ausschnitte

c.gt und c.lt melden Übergänge über beziehungsweise unter einen Grenzwert, bezogen auf den zuletzt gemeldeten Wert. c.st sucht eine Mindestschrittweite. c.band macht aus zwei Grenzen einen Innen- oder Außenbereich. c.edge wählt eine Richtung einer booleschen Flanke.

Keine dieser Regeln bildet den vollständigen Verlauf der Ressource ab. Überschreitet ein Wert c.gt und steigt weiter, folgt normalerweise nicht bei jedem weiteren Anstieg eine neue Grenzwertmeldung. Eine kurze Überschreitung kann zwischen zwei Auswertungen liegen. Bei c.st wird gegen den zuletzt gemeldeten, nicht zwingend gegen jeden tatsächlich aufgetretenen Wert verglichen.

Treffen mehrere Bedingungen gleichzeitig zu, gibt es keine Priorität. Der Server sendet eine Benachrichtigung und aktualisiert den letzten Meldewert und -zeitpunkt. Eine Nachricht kann also mehrere Ursachen zusammenfassen. Wer aus elf Nachrichten elf physische Ereignisse rekonstruiert, fügt Information hinzu, die das Protokoll nicht zugesagt hat.

Ein Erfolg kann Teilunterstützung verbergen

Die Discovery-Markierung if="core.conditional" ist absichtlich grob. Sie garantiert keine bestimmte Einzelbedingung; umgekehrt kann eine Ressource Bedingungen unterstützen, ohne die Markierung zu veröffentlichen. Eine feingranulare Abfrage des unterstützten Parametersatzes definiert der Entwurf nicht.

Besonders wichtig ist die Behandlung eines syntaktisch gültigen, aber nicht unterstützten Parameters: Er soll keine Wirkung haben, die Beobachtung soll jedoch weiterverarbeitet werden. Eine 2.05 Content-Antwort mit Observe-Option kann somit eine Registrierung bestätigen, ohne zu bestätigen, dass jede verlangte Bedingung aktiv ist.

Davon zu unterscheiden sind ungültige Werte, etwa ein falscher Datentyp, eine nicht positive Periode oder eine unmögliche Minimum-Maximum-Kombination; sie führen zu 4.00 Bad Request. Noch einmal anders ist eine aus Verstärkungsschutz verweigerte Registrierung: Bei extrem kleinen c.pmax- oder c.epmax-Werten darf der Server den GET normal beantworten, aber die Observe-Option weglassen. Erst ihr Fehlen zeigt, dass keine Beobachtungsbeziehung entstand.

Drei Uhren statt eines Takts

c.pmin begrenzt, wie häufig Benachrichtigungen gesendet werden dürfen. Während dieser Sperrzeit kann ein Trigger bereits vorliegen; der Server kann am Ende nur den letzten erfassten Wert besitzen. Der Parameter muss nicht zugleich den Sensor abtasten.

c.pmax verlangt einen Höchstabstand zwischen Benachrichtigungen, auch bei unverändertem Zustand. Das ist die Uhr, die wie ein Herzschlag wirkt. Doch ihre Frist ist keine Garantie einer deterministischen Ausführung. Ein System, das daraus eine harte Deadline ableitet, verschärft den Standard lokal, ohne diesen zusätzlichen Vertrag sichtbar zu machen.

c.epmin und c.epmax steuern die Häufigkeit der Bedingungsauswertung. Sie regeln nicht unmittelbar den Versand. Zwischen zwei Auswertungen kann der physische Wert eine Grenze überschreiten und wieder zurückkehren. Ein später pünktlich gesendeter Puls kann dann wahrheitsgemäß den aktuellen Wert enthalten und trotzdem eine relevante Episode nie gesehen haben.

Ressourcenzeit, Abtastzeit, Auswertungszeit, Versandzeit und Empfangszeit sind daher verschiedene Größen. Das Dashboard darf sie nicht zu einem Zeitstempel zusammenfalten.

Der Proxy kann den Puls verschlucken

CoAP Observe ist mit Caches und Proxies entworfen. Revision 14 warnt ausdrücklich, dass ein Proxy periodische c.pmax-Aktualisierungen stören kann, wenn sich die Darstellung nicht ändert. Als Gegenmaßnahme wird ein Max-Age von höchstens c.pmax empfohlen. Ein Serverprotokoll „gesendet“ ist damit noch kein Client-Empfang.

c.con=true fordert Confirmable-Benachrichtigungen. Ein ACK begrenzt die Ungewissheit über den Nachrichtenaustausch, nicht über die gesamte Wirkungskette. Es beweist weder lückenlose Abtastung noch korrekte Anwendungslogik und schon gar nicht, dass ein Aktor schaltete oder eine Anlage in den zulässigen Bereich zurückkehrte.

Token, Observe-Sequenzwerte und OSCORE liefern jeweils wichtige, aber eng umrissene Aussagen: Korrelation, Reihenfolge und Schutz innerhalb eines Sicherheitskontexts. Keines davon erhebt eine selektive Telemetrieprojektion zur kontinuierlichen physischen Wahrheit.

Auch die Beendigung ist eine Identitätsfrage

Eine bedingte Beobachtung hängt an ihrer vollständigen URI. Zur expliziten Kündigung muss der Client die ursprünglichen bedingten Query-Parameter zusammen mit dem Kündigungssignal wiederholen. /temperature?c.gt=8 und /temperature?c.gt=10 sind zwei Projektionen derselben Ressource.

Darum ist das Entfernen eines Eintrags im Dashboard kein Beleg, dass der alte Beobachter verschwunden ist. Ein belastbarer Kündigungsnachweis enthält Endpunkt, Token, vollständige URI und die schließende Antwort. Andernfalls kann ein vergessener Beobachter weiter Energie und Bandbreite verbrauchen, während das Bedienbild bereits eine andere Konfiguration zeigt.

Die Belegkette für einen verpassten Puls

Vor der Aussage „der Echtzeitvertrag wurde verletzt“ sind mindestens acht Fragen zu beantworten:

  1. Welche Ressource und welche Server-Epoche boten die bedingte Fähigkeit an?
  2. Belegen URI, Token und Observe-Option genau diese Registrierung?
  3. Welche angefragten Parameter unterstützte der Server tatsächlich?
  4. Wann und mit welcher Auflösung wurde der Ressourcenwert abgetastet und ausgewertet?
  5. Welche Bedingung wurde gegen welchen letzten Meldewert wahr?
  6. Wie wirkten c.pmin, c.pmax, Zusammenfassung und Best-Effort-Planung auf den Versand?
  7. Durch welchen Cache- und Proxy-Pfad erreichte die Nachricht den vorgesehenen Client?
  8. Hat die Anwendung sie verarbeitet und die beabsichtigte Wirkung erzielt?

Nur wenn diese Ebenen getrennt sichtbar sind, kann ein verspäteter Puls einem verantwortlichen Teil zugeordnet werden. Andernfalls bezeichnet „zu spät“ lediglich die Abweichung einer Anzeige von ihrer lokalen Erwartung.

Was sich aus dem Entwurf nicht ableiten lässt

Die eingefrorenen Quellen tragen die Analyse der Parametersyntax, der vorgeschlagenen Semantik, des Best-Effort-Hinweises, der Proxy-Warnung und der Registrierungsgrenze. Sie belegen keine Verbreitung, keinen Produktfehler, keine Sicherheitszertifizierung, keine gemessene Verlustrate und keine rechtliche Pflicht. Der referenzierte Text zu Verstärkungsangriffen ist selbst ein abgelaufener IRTF-Draft und kein Nachweis eines Angriffs auf ein bestimmtes Netz.

Mit Heng Lus Unterscheidung zwischen Aufzeichnung und Autorität gelesen, ist der regelmäßige Observe-Puls eine wertvolle Aufzeichnung einer Serverentscheidung. Autorität über die Aussage „das System blieb sicher“ entsteht erst, wenn die physischen Mess- und Wirkungsebenen ihre eigenen Belege liefern.

Quellen