Zusammenfassung

  • RFC 9553 wählt einen PatchObject über einen Sprach-Tag, kopiert die Basis-Card ohne localizations und verwendet die vollständig gepatchte Kopie als lokalisierte Variante.
  • Die atomare Ablehnung verhindert halbe Änderungen, bestätigt aber weder Autor, offiziellen Alias, Feldberechtigung noch die Aktualität der Kontaktdaten.
  • Eine belastbare Spur bindet Basis-Fingerprint, Sprachauswahl, Patch, Autorisierung, Ausgabe und nachgelagerte Nutzung getrennt zusammen.

Der Bildschirm sieht selbständig aus

Nach der Lokalisierung enthält die Seite weiterhin alle Felder. Der Leser sieht keinen Patch, sondern eine vollständige Karte. Daraus entsteht leicht die Annahme, jede Sprache besitze einen eigenen geprüften Ursprung.

RFC 9553 beschreibt localizations als Abbildung von RFC-5646-Sprach-Tags auf PatchObjects. Die Anwendung bestimmt den Tag, nimmt den passenden Patch, erzeugt eine Kopie der Card ohne localizations, wendet alle Änderungen an und kann language in der Kopie setzen. Diese Kopie wird als lokalisierte Variante des Originals verwendet.

Sie erhält keine neue uid, keine eigene Versionsgeschichte und keine zusätzliche Tatsachenprüfung. Unveränderte Felder stammen aus der Basis; veränderte Felder aus dem Patch und der Auswahlregel.

Wird nur die Ausgabe als eigener Datensatz gespeichert, verschwindet diese Abhängigkeit. Bei einem falschen Titel lässt sich nicht mehr erkennen, ob Basis, Patch, Fallback oder Cache veraltet war. Eine reproduzierbare Projektion wird zur undurchsichtigen Kopie.

Atomar bedeutet strukturell konsistent

PatchObject verwendet einen Teil von JSON Pointer mit implizitem führendem Schrägstrich. Alle Pfadbestandteile vor dem letzten müssen vorhanden sein. Ein bestehendes Array-Element darf ersetzt werden; darf nicht einfügen oder löschen. Ein Pfad darf nicht Präfix eines anderen sein. Der Wert muss Typ und Regeln der Ziel-Property erfüllen; null darf nur optionale Properties entfernen.

Ist eine Änderung ungültig, muss der gesamte PatchObject abgelehnt werden. Teilanwendung ist verboten. So entsteht nicht versehentlich ein Name aus der neuen Variante neben einer Adresse, deren Patch unbemerkt scheiterte.

Das Ergebnis beantwortet aber nur die Strukturfrage. Ein beruflicher Titel kann falsch und dennoch ein gültiger String sein. Eine erfundene Schreibweise kann korrektes JSON sein. Eine E-Mail des Angreifers kann das Schema erfüllen.

Der Betrieb braucht deshalb getrennte Zustände: parsebar, modellkonform, auf diese Basis anwendbar, Herkunft authentifiziert, Feldänderung autorisiert, Identitätsname freigegeben, Inhalt aktuell und Kontakt tatsächlich erreicht. „Lokalisiert“ ist keine Obermenge dieser Urteile.

Ein Pfad gehört zu einer Basisgeneration

RFC 9553 zeigt den vollständigen Ersatz von name und den gezielten Pfad titles/t1/name. Die zweite Form bewahrt die anderen Mitglieder von t1, setzt jedoch voraus, dass Struktur und Schlüssel ihre Bedeutung behalten haben.

Id-Schlüssel in Maps müssen über Versionen desselben JSContact-Objekts erhalten bleiben. Das stabilisiert Patches. Derselbe Id-Wert in anderen Maps oder Cards begründet laut RFC dennoch keine semantische Verbindung. t1 ist eine lokale Koordinate, keine globale Objektidentität.

Ein für Fingerprint A geprüfter Patch kann gegen B weiter gültig sein, obwohl t1 inzwischen eine andere Rolle bezeichnet. Er kann scheitern, wenn der Schlüssel fehlt. Er kann unverändert richtig sein, wenn sich nur ein unabhängiges Feld änderte. Der Validator erkennt den Strukturbruch, nicht automatisch die Bedeutungsänderung.

updated nennt den letzten Änderungszeitpunkt der Card-Daten. Es nennt nicht Feld, Autor, Quelle, Vorwert oder erneute Prüfung der Lokalisierungen. prodId benennt ein Produkt, keinen Unterzeichner. version bezeichnet die registrierte JSContact-Modellversion, nicht die Geschäftsrevision dieser Karte.

Darum gehören Basis-Fingerprint, Patch-Fingerprint und Gültigkeitsintervall in denselben Beleg. Ein formal passender Pfad kann sonst eine alte Aussage konservieren.

Der Sprach-Tag bestätigt keinen amtlichen Namen

RFC 5646 kann Sprache, Schrift und Region beschreiben. RFC 9553 beginnt mit der Bestimmung eines Tags, legt aber nicht die gesamte Aushandlung eines Produkts fest. Regionale Rückfälle, Schriftpräferenz und die Rückkehr zur Hauptsprache sind Produktpolitik.

Ein syntaktisch richtiger Tag sagt nichts über den Status des Textes. Der fremdsprachige Organisationsname kann amtlich, üblich, übersetzt, transliteriert, redaktionell praktisch oder erfunden sein. Bei Personen kann eine andere Schrift einen belegten Originalnamen oder eine unautorisierte Neubildung darstellen.

PatchObject transportiert die Alternative; es macht sie nicht zum offiziellen Alias. Änderungen geschützter Namen sollten eine offizielle mehrsprachige Quelle, eine Bestätigung des Subjekts oder eine geprüfte Transliterationsregel tragen. Ohne diese Evidenz existiert nur eine Anzeigeoption.

Auch Anschrift und Titel brauchen semantische Prüfung. Eine neue Reihenfolge kann korrekt sein; eine andere Jurisdiktion oder Rangstufe ist keine reine Darstellung.

Der Angriff kann sprachlich überzeugend sein

Die Security Considerations nennen Kontaktdaten hochsensibel: Sie können Identität, Ort, Zugangsdaten, Beschäftigung, Interessen und soziale Beziehungen offenlegen. Genannt werden Abhören, Replay, Einfügen, Löschen, Ändern und On-Path-Angriffe.

Das konkrete Beispiel betrifft Identitätsmacht: Ein Angreifer übernimmt den Namen eines anderen und setzt seine eigenen Kontaktdaten ein. Eine flüssig lokalisierte Fälschung ist besonders glaubwürdig. Vertraute Schrift und regionale Form lenken von der Frage ab, wer Telefon oder Mailbox kontrolliert.

Systeme mit realen Folgen müssen empfangene Daten authentifizieren und sicherstellen, dass Änderungen von einer berechtigten Stelle kommen. Der RFC grenzt sich zugleich ab: Er definiert das Format; API, Speicherung und Übertragung müssen die Sicherheitsarbeit leisten.

TLS kann den liefernden Dienst beweisen, nicht dessen Recht über jedes Feld. Eine Signatur kann den Patch zuordnen, nicht die Zustimmung der genannten Person. Schema-Prüfung stoppt ungültige Pointer, nicht eine korrekt typisierte Lüge.

IANA registriert Bedeutung, nicht Instanzwahrheit

RFC 9553 registriert Version 1.0 und schafft Register für Versionen, Properties, Typen und Enumerationswerte. Since Version und Until Version koordinieren, wann ein Element gültig ist.

Diese Autorität dient der Interoperabilität. Sie sagt, ob eine Property definiert ist, nicht ob ihr konkreter Wert stimmt. „Gültiges JSContact“ sollte Gültigkeit unter einem benannten Modell und Registerstand bedeuten, nicht „verifizierter Kontakt“.

Wer das zweite Label aus dem ersten ableitet, verwandelt Format-Governance in Identitätsprüfung.

Eine kleine Herkunftskette genügt

Der Beleg hält uid, Modellversion, Basis-Fingerprint und Geschäftsrevision; Anfrage oder Regel der Sprachauswahl; exakten Patch, Herkunft und Berechtigungsumfang; atomaren Prüfstatus; Ausgabe-Fingerprint, Zeit und Verbraucher fest.

Bei Personen- oder Organisationsnamen kommt die Alias-Freigabe hinzu. Löst eine lokalisierte E-Mail, Telefonnummer, Anschrift oder Rolle eine Automation aus, wird auch Handlung und Ergebnis festgehalten. Rendering ist keine Zustellung.

Nach einer Basisänderung lässt sich der Patch als unberührt, prüfpflichtig oder ungültig klassifizieren. Neun unabhängige Wahrheitskopien sind nicht erforderlich.

Lokalisierung verbessert Zugänglichkeit, wenn sie erklärbare Projektion bleibt. Sie wird riskant, sobald die Darstellung die Linie zwischen Fakt, Änderung, Berechtigung und Wirkung verdeckt.

Quellen