Zusammenfassung

  • RFC 9876 schließt eine Verfahrenslücke: Die semantische Kombination aus Media Type, Parametern und optionalem Content Coding wird geprüft, während knappe, allgemeine, dokumentarische und experimentelle Nummernbereiche eigene Regeln erhalten.
  • Eine Zuteilung schafft eine öffentliche Zuordnung. Sie testet keine produktiven Bytes, Parser, Aushandlung, Ressourcengrenzen, Fehlerpfade oder Übereinstimmung zwischen Herstellerimplementierungen.
  • Gute Governance verbindet einen Vergabebeleg mit einem Einsatzbeleg, ohne aus dem Registereintrag ein Produktzertifikat zu machen.

Ein Sensor sendet die Zahl 293. Der Empfänger schlägt sie nach und findet das zugehörige CoAP Content-Format. Der Nutzen liegt im Weggelassenen: kein langer Typname, keine wiederholten Parameter und kein separat ausgeschriebener Content Coding. In knappen Netzen ist diese Kompaktheit wertvoll.

Gefährlich wird es, wenn technische Kompression auch das Urteil verkürzt. „IANA hat die Nummer vergeben, also ist das Format interoperabel.“ „Ein Experte hat zugestimmt, also ist jede Nutzlast sicher.“ „Zwei Anbieter nennen denselben Identifier, also meinen ihre Produkte dasselbe.“

RFC 9876 trägt keine dieser Aussagen. Sie verbessert den gemeinsamen Ausgangspunkt, an dem unabhängige Implementierungen ihre Koordination beginnen.

Eine Zahl verbindet mehrere Register

RFC 7252 entwarf CoAP für Geräte mit wenig Speicher und Netze mit geringer Datenrate oder hohen Verlusten. Der numerische Content-Format-Identifier verdichtet eine Repräsentation. RFC 9876 verlangt, dass ein Eintrag Content Type, optionales Content Coding, den zugrunde liegenden Media Type, die Zahl und eine Referenz zur Semantik bindet.

Diese Elemente sind nicht austauschbar. Der Media Type benennt eine Familie. Parameter wählen ein Profil oder eine Bedeutung. Content Coding transformiert die Repräsentation. Da CoAP die Codierung nicht in einem separaten Feld überträgt, benötigt dieselbe Typfamilie mit anderer Codierung eine eigene Nummer.

Das frühere Verfahren verlangte nicht ausdrücklich, die semantische Gültigkeit dieser Kombination zu prüfen. Ein Antrag konnte formal plausibel aussehen und dennoch einen unbekannten Typ, erfundenen Parameter, unzulässigen Wert, nicht registrierte Codierung oder eine logisch doppelte Bedeutung enthalten. RFC 9876 erkennt an, dass die Prüfung mehrere Dokumente und Technologien umfasst und nicht allein dem Registrar zugemutet werden darf. Die meisten Bereiche erhalten daher Expert Review mit einer klaren Liste.

Die institutionelle Reparatur trennt die administrative Verarbeitbarkeit eines Antrags von der Bedeutung der beantragten Kombination.

Nummernbereiche sind Entscheidungspolitik

Der Raum 0–65535 ist kein einheitlicher Vorrat. 0–255 passt in ein Byte und ist knapp; Expert Review muss auch den Verbrauch dieses Raums beurteilen. 256–9999 erfordert IETF Review mit Expert Review oder IESG Approval mit Expert Review. 10000–19999 und 33000–64997 werden ebenfalls durch Experten geprüft.

Für 20000–32999 bleibt ein enger First-Come-First-Served-Weg: keine Parameter, kein Content Coding, ein registrierter oder genehmigter Media Type, der noch nicht im CoAP-Register steht. Komplexere Anträge müssen einen geprüften Bereich wählen.

64998 und 64999 sind für Dokumentation reserviert. 65000–65535 ist experimentell und darf nicht betrieblich eingesetzt werden. Beispiele und Versuche bekommen Raum, ohne durch Gewohnheit Produktionsautorität zu erwerben.

Eine kurze Nummer ist weder Eigentum noch Gütesiegel. Sie ist eine knappe Koordinationsressource. Eine längere Nummer ist nicht minderwertig. Der Bereich zeigt das Vergabeverfahren, nicht die Qualität der Software.

Was die Expertenliste ausschließt

Zuerst wird geprüft, ob die Kombination aus Content-Type und Content Coding bereits existiert. Danach muss der Media Type registriert, genehmigt oder in zulässigen Bereichen vorläufig sein. Parameternamen und Werte müssen definiert sein. Content Coding muss im HTTP-Register existieren oder genehmigt sein. Der Content Type wird in eine bevorzugte Schreibweise gebracht.

Normalisierung trennt Darstellung von Bedeutung. Groß-/Kleinschreibungsunabhängiges wird kleingeschrieben, Anführungszeichen werden nur bei Bedarf gesetzt, und das Semikolon erhält keine benachbarten Leerzeichen. RFC 9876 zeigt subtilere Dubletten: ein ausgeschriebener Standardwert kann seiner Auslassung entsprechen; identity kann dieselbe Bedeutung wie keine Codierung haben; unterschiedlich geschriebene URNs können semantisch identisch sein.

Die Prüfung geht über Zeichenketten hinaus, ist aber kein weltweites Prüflabor. Experten führen nicht jeden Encoder aus, attackieren nicht jeden Parser und messen nicht jedes Mikrocontroller-Limit. Registrierung fragt, ob die exakte Kombination unter der gewählten Politik in den gemeinsamen Namensraum gehört. Interoperabilität fragt, ob benannte Versionen unter definierten Bedingungen korrekt kommunizieren.

Wer beides vermischt, überträgt IANA und Experten eine Zertifizierungsrolle, die sie nicht kontrollieren, und erlaubt Herstellern, eigene Nachweise durch einen Registereintrag zu ersetzen.

Temporär ist ein Lebenszykluszustand

RFC 9876 macht vorläufige Zuteilungen sichtbar. Ein provisorischer Media Type kann frühe Arbeit ermöglichen und hält das verbundene Content-Format temporär. Nach erfolgreichem Verfahren und permanenter Registrierung kann IANA die Markierung entfernen. Scheitert das nötige Verfahren oder wird der provisorische Typ aufgegeben, kann der Eintrag entfernt und die Nummer wieder Unassigned werden.

Das aktuelle IANA-Register zeigt dieses Modell. Zum Erhebungszeitpunkt stehen dort etwa die temporären IDs 293 und 294 neben permanenten Einträgen, freien Bereichen und Reservierungen. Das belegt Zustand, nicht Verbreitung. Es verurteilt die Formate nicht und beweist keine Geräteunterstützung.

Ein Produkt mit temporärer ID muss den zugrunde liegenden Entwurf, den Medientyp-Eintrag, Fristen, den Übergang zur Dauerhaftigkeit und das Verhalten bei Rücknahme speichern. Nur die Zahl zu persistieren, vernichtet den Kontext für eine spätere Migration.

Der konkrete Bereich bleibt entscheidend. Wo weder ein abgeschlossenes Standardverfahren noch ein registrierendes Dokument erforderlich ist, löscht die Aufgabe eines Dokuments den Eintrag nicht automatisch. Aus „Entwurf abgelaufen“ darf keine universelle Widerrufsregel werden.

Zwei Belege verhindern Autoritätswäsche

Der Vergabebeleg enthält normalisierten Content Type, Media Type, Parameter, Content Coding, beantragten und vergebenen Bereich, Review-Politik, Entscheidung, semantische Referenz, Status, Termine und die Begründung für knappen Raum. Abgelehnte Äquivalenzen bleiben erhalten, damit andere Schreibweisen keine Dublette erzeugen.

Der Einsatzbeleg nennt Encoder- und Decoder-Versionen, geprüfte Profile, Bytes vor und nach Codierung, Aushandlung, unbekannte oder zurückgezogene IDs, Größen- und Rekursionsgrenzen, CoAP/HTTP-Übersetzung, Testvektoren, Fehler und Rollback.

Beide werden über ID und exakte Kombination verbunden, aber nicht verschmolzen. Die Vergabe kann korrekt sein, während ein bestimmter Decoder versagt. Beschaffung darf beide Nachweise verlangen, ohne zu behaupten, IANA habe das Gerät zertifiziert.

Dieses Zwei-Belege-Modell ist eine redaktionelle und betriebliche Empfehlung, kein Feld in RFC 9876, keine IANA-Forderung und keine Aussage über eine konkrete Installation.

Das Register muss seine eigene Macht spiegeln

Lu Hengs Minimum Initial Specification zeigt die passende Größe: stabile ID, exakte Kombination, semantische Referenz und prüfbares Verfahren reichen für unabhängiges Handeln. Nicht jeder Parser und jede Version müssen zentralisiert werden.

The Policy Mirror setzt die Grenze. Eine Zeile kann eine ordnungsgemäße Zuteilung spiegeln. Sie kann nicht Sicherheit aller Geräte, Marktverbreitung, Implementierungsqualität oder Kompatibilität zweier Endpunkte spiegeln. Dafür sind andere Autoritäten nötig.

RFC 9876 verbessert den Spiegel, weil ungültige Kombinationen und semantische Dubletten schwerer hineingelangen. Die nächste Pflicht der Betreiber ist, aus einer korrekt vergebenen Nummer kein unbewiesenes Betriebsversprechen zu machen.

Quellen