Zusammenfassung

  • Ein Profil nach RFC 10050 ist eine benannte, versionierte Menge von Einschränkungen für registrierte JSContact-Eigenschaften, -Typen und -Werte. Es darf die Basisspezifikation nur verschärfen.
  • Die Card enthält keine allgemeine Profilerklärung. Weil eine Karte mehrere Profile zugleich erfüllen kann, muss das umgebende Protokoll das maßgebliche Profil samt Version auswählen und seine zusätzlichen Regeln anwenden.
  • Der IANA-Eintrag bewahrt die historische Identität eines Profils. Er ist jedoch keine inhaltliche Qualitäts-, Sicherheits- oder Eignungsbescheinigung.

Die gefährlichste Statusanzeige in einem Datenaustausch kann ein grünes Häkchen ohne Subjekt sein. Was war gültig: das JSON, die JSContact-Karte, ihre Übereinstimmung mit einem Profil oder die Nachricht im Geschäftsprotokoll? Jede Antwort beruht auf einer anderen Regelmenge.

Der im September 2026 als Proposed Standard veröffentlichte RFC 10050 ordnet diese Regelmengen. Er schafft keinen konkurrierenden Kontaktdatentyp. Er gibt eingeschränkten Nutzungen des allgemeinen JSContact-Modells eine beständige Identität und lässt die letzte Annahmeentscheidung bewusst außerhalb des Profils.

Ein Profil kann nur enger werden

RFC 9553 definiert das vielseitige Card-Modell. Eine Anwendung darf mittels Profil optionale Eigenschaften verlangen, sonst zulässige Eigenschaften ausschließen, Typen begrenzen oder Wertemengen verkleinern. Sie darf aber keine im Grundmodell ungültige Struktur erlauben.

Damit entsteht eine eindeutige Prüfkette: Gültigkeit nach RFC 9553, Konformität mit dem ausgewählten Profil und schließlich Gültigkeit nach dem verwendenden Protokoll. Die Ergebnisse sind verwandt, aber nicht austauschbar.

Ein Profil besitzt einen groß-/kleinschreibungssensitiven Namen und eine positive ganzzahlige Version. Dieses Paar bildet den stabilen Schlüssel im IANA-Register. Sein Inhalt wird nach der Registrierung nicht stillschweigend ersetzt. Änderungen erhalten eine höhere Version, ältere Fassungen bleiben sichtbar.

So behalten Protokollspuren ihre Bedeutung. Wenn eine gespeicherte Entscheidung Version 2 nennt, muss sie auch nach Veröffentlichung von Version 3 auf dieselben Einschränkungen zeigen. Andernfalls würden Auditdaten und Interoperabilitätstests rückwirkend ihre Grundlage wechseln.

Rekursion gehört zur Konformität

JSContact ist keine flache Tabelle. Eigenschaften können Objekte enthalten; ein erlaubter Typ kann weitere Eigenschaften einführen. RFC 10050 verlangt deshalb, die unterstützte Eigenschaftsmenge rekursiv bis zu ihrem Abschluss zu bestimmen.

Eine Zulassungsliste nur für die oberste Ebene kann eine unerlaubte Unterstruktur übersehen. Ein zu enger Validator kann dagegen eine verschachtelte Eigenschaft ablehnen, die über einen zugelassenen Typ erreichbar ist. JSON Pointer nach RFC 6901 benennen Stellen eindeutig, ersetzen aber nicht den vollständigen Durchlauf.

Ein belastbarer Nachweis umfasst daher Grundversion, Profilname und -version, Validatorversion, verfolgte Eigenschafts-/Typkanten und die konkrete Regel des Ergebnisses. Ein einzelnes true sagt nicht, wie tief geprüft wurde.

Warum die Karte kein allgemeines Profilfeld trägt

RFC 10050 fügt der Card kein universelles Feld zur Profilerklärung hinzu und schreibt keine einzige Transportform vor. Das einbettende Protokoll soll festlegen, wie Name und Version vermittelt oder ausgehandelt werden.

Eine Karte kann gleichzeitig in mehreren Profilteilmengen liegen. Ein internes Einzelkennzeichen wäre unvollständig; eine Liste würde noch immer nicht sagen, welches Profil für den aktuellen Austausch vereinbart wurde. Zudem ist eine Behauptung des Senders kein Prüfergebnis des Empfängers.

Das Protokoll kennt seine Aushandlung, zulässigen Versionen, Fehlerbehandlung und zusätzlichen Verbote. Daher muss es drei getrennte Tatsachen abbilden: Basiskonformität, Profilkonformität und Protokollgültigkeit. Ein Objekt kann die ersten beiden Hürden nehmen und an der dritten scheitern.

Registeridentität ohne Gütesiegel

Neue Profile folgen der Richtlinie Specification Required aus RFC 8126; Referenzänderungen benötigen Expert Review, und der IETF ist Change Controller. Designated Experts prüfen unter anderem Eindeutigkeit und Syntax des Namens, bekannte Eigenschaften und Typen, eine ausreichend stabile Spezifikation sowie die Erhöhung der Versionsnummer.

Sie müssen laut RFC 10050 nicht den eigentlichen Profilinhalt bewerten. Eine Registrierung bescheinigt weder Datenschutz noch Sicherheit oder Brancheneignung. Gerade bei Kontaktdaten bleibt die in RFC 9553 betonte Datenminimierung eine Entscheidung derjenigen, die das Profil einsetzen.

Zum Zeitpunkt dieser Untersuchung zeigte die IANA-Seite für JSContact im Profilabschnitt keine Registrierungen und noch keine zugewiesenen Experten. Als letzte Aktualisierung war der 28. Mai 2026 angegeben; die Referenz verwies noch auf einen Internet-Draft, also auf einen Stand vor Veröffentlichung des RFC im September. Das ist eine datierte Beobachtung, kein Vorwurf. Register und Publikation können verschiedene Aktualisierungszyklen haben.

Für den Betrieb ist sie ein Grund, die eigene Entscheidungsgrundlage zu sichern: Name und Version, Kopie oder Hash der referenzierten Spezifikation, Abrufzeit, JSContact-Basisversion, Validatorversion, Ergebnis des rekursiven Abschlusses, Übermittlung der Profilauswahl und zusätzliche Protokollregeln. Nur so bleibt eine alte Annahme reproduzierbar.

Quellen