Zusammenfassung

  • IANA registriert einen Parameternamen und seine öffentliche Spezifikation, nicht die Wahrheit eines konkreten Wertes oder die Identität eines Anrufers.
  • Register, Syntax, Wert, Empfängerfähigkeit, Policy, Routing, Identität und Dienstergebnis brauchen eigene Nachweise.

Ein offizielles Feld kann eine unbewiesene Aussage tragen

Ein System sieht einen heutigen registrierten Namen wie verstat und stuft den Inhalt als Identitätsbeleg ein. Tatsächlich sagt die IANA-Zeile nur, dass der Name koordiniert ist und eine Referenz besitzt. Wer den Wert erzeugte und welche Prüfung dahinterstand, ist eine andere Frage.

RFC 5341 verlangt für neue Parameter Name, Wertklasse und dauerhafte öffentliche Spezifikation. Das verhindert Kollisionen. Es authentifiziert keine Nachricht und keinen Teilnehmer.

Ein registrierter Wert kann falsch formatiert, veraltet oder an einer nicht vertrauenswürdigen Grenze eingesetzt sein. Die Registrierung ist ein Vokabularbeleg, kein Vertrauensanker für Instanzen.

No Value und Constrained sind Wegweiser

No Value bezeichnet Flag-Syntax oder das Fehlen eines vordefinierten Wertevorrats. enumdi und npdi bleiben semantische Aussagen. Ein Parser darf sie weder als leer entfernen noch automatisch für wahr halten.

Constrained weist auf Einschränkungen hin, enthält sie aber nicht vollständig. Die Referenz bestimmt erlaubte Formen und Vergleich. Ein gültiger Name mit ungültigem Wert bleibt ungültig.

Das Register beantwortet, welcher Text zuständig ist. Ein Validator muss diesen Text anwenden und das Ergebnis protokollieren.

Der Telefonnummernname ist keine Wahlhandlung

RFC 3966 trennt Kennung und Wählfolge. Der tel URI benennt eine Ressource über eine Nummer; lokale Geräte und Netze erzeugen daraus Signalisierung. Der URI identifiziert kein einzelnes physisches Gerät und wählt nicht zwischen Sprache, Fax und Daten.

Auch phone-context ist ein Scope, kein Routennachweis. Zwei Seiten können denselben formal gültigen Kontext unterschiedlich konfigurieren. Nummernbesitz und Erreichbarkeit bleiben offen.

Nach Syntax folgen Capability, Policy, Routing, Signalisierung und Anwendung. Keines davon entsteht aus dem Registereintrag.

Unbekanntes Pflichtfeld ist ein kontrollierter Abbruch

Versteht ein Empfänger einen obligatorischen Parameter nicht, darf er den URI nicht verwenden. Eine IANA-Erweiterung installiert keine Funktion in alten Gateways. Der richtige Nachweis ist Parser- und Versionsfähigkeit.

Logs sollten Erkennung, Pflichtstatus, Wertprüfung und Disposition zeigen. Nur so ist korrekte Ablehnung von gefährlichem Ignorieren zu unterscheiden.

RFC 5341 schützt außerdem den Basisdienst bei fehlenden Erweiterungen. Macht ein Anbieter ein optionales Feld zur Zugangsvoraussetzung, ist das seine Produktpolitik und potenzieller Lock-in.

Das aktuelle Register hat keine rückwirkende Implementierungskraft

Die lebende Tabelle enthält spätere Einträge wie premium-rate und verstat. Software muss ihren Katalog aktualisieren. Eine Untersuchung darf die heutige Tabelle jedoch nicht als Beweis für gestrige Unterstützung verwenden.

Zeitpunkt, Snapshot, Referenz und Parser-Version gehören zusammen. Sonst wird „registriert“ zu einer zeitlosen Behauptung und überschreibt die tatsächliche Entwicklung.

Routing- und Trunk-Daten benötigen Provenienz

RFC 4694 koordiniert Portierungsparameter, RFC 4904 Trunkgruppenparameter. Das Register beweist weder Aktualität eines rn noch Autorisierung eines cic, Existenz eines Trunks oder Annahme durch den nächsten Hop.

Ebenso beweist enumdi keine ausgeführte ENUM-Abfrage und isub-encoding keine Gegenstellenfähigkeit. Quelle, Vertrauensgrenze, Zeit, Prüfung, Entscheidung und Ergebnis müssen erhalten bleiben.

Quellen und Beweisgrenze

Die Quellen belegen Standards, Historie und einen IANA-Snapshot, nicht aktuellen Anruf, Nummerninhaber, Identität, Produkt, Einsatz, Route, Preis oder Ergebnis.