Zusammenfassung

  • draft-ietf-calext-vcard4-bis-00 legt zwingende und verbotene Zuordnungen für Karten und Eigenschaften fest, übergibt aber nicht entschiedene Fälle ausdrücklich dem Synchronisationssystem.
  • Ein normkonformes Endergebnis beweist deshalb den gespeicherten Zustand, nicht automatisch die Berechtigung oder Begründung jeder heuristischen Zusammenführung.

Normative Sprache verteilt Entscheidungsmacht

In technischen Spezifikationen wirken MUST und MAY wie Grammatik. Im Betrieb markieren sie jedoch unterschiedliche Verantwortung.

Wenn zwei vCards äquivalente UID besitzen, müssen sie zugeordnet werden. Wenn gleichnamige Eigenschaften auf bereits zugeordneten Karten denselben globalen PID-Wert haben, müssen auch sie zugeordnet werden. Eigenschaften verschiedener Namen dürfen nicht zugeordnet werden.

Für andere gleichnamige Eigenschaften gilt MAY: Das System darf sie nach eigenem Ermessen als dieselbe Eigenschaft behandeln.

An dieser Stelle endet keine Verantwortung. Sie wechselt nur den Träger. Die Arbeitsgruppe hat keinen universellen Algorithmus für alle Telefonnummern, Namen und Adressen festgelegt. Deshalb entscheidet die lokale Implementierung. Sie kann sich später nicht auf das MAY berufen, als hätte die Spezifikation ihre konkrete Entscheidung getroffen.

Erlaubnis ist kein Urteil. Normkonformität ist kein Entscheidungsprotokoll.

Revision 00 ist noch kein Standard

Revision 00 der vCard Format Specification trägt das Datum 2. Juli 2026 und läuft am 3. Januar 2027 ab. Sie ist ein Internet-Draft der CALENDAR-EXTENSIONS-Arbeitsgruppe mit Standards-Track-Ziel. Bei Annahme würde sie RFC 6350 ablösen. Derzeit ist sie weder RFC noch Implementierungs- oder Interoperabilitätsnachweis.

Der Entwurf beschreibt ein bedeutendes Austauschformat. Namen, Anschriften, Telefonnummern, Organisationen, Bilder, Schlüssel und Beziehungen brauchen eine gemeinsame Darstellung, wenn unabhängige Systeme zusammenarbeiten sollen.

Die gemeinsame Form beweist aber nicht den dargestellten Sachverhalt. Eine syntaktisch gültige Karte identifiziert keinen Menschen. Ein erfolgreiches Zusammenführen bestätigt keine aktuelle Telefonnummer. Zwei Systeme mit demselben Endzustand müssen nicht dieselbe Heuristik verwendet haben.

docs/heng-lu-note.md trennt in Running-Code Primacy Veröffentlichung, Implementierung, Prüfung, Einsatz und Ergebnis. Minimum Initial Specification begrenzt die gemeinsame Regel auf das notwendige Minimum und lässt spätere Entscheidungen lokal. vCard4-bis zeigt diese Architektur besonders deutlich.

UID bestimmt das Verfahren, nicht die Person

Synchronisation wird als intelligentes Zusammenführen zweier Darstellungen desselben Objekts definiert. Äquivalente UID zwingen die Karten in dasselbe Abgleichverfahren.

Gültige URI werden nach RFC 3986 verglichen. Sonst gilt Zeichenidentität nach Entfernung der vCard-Escapes. Dadurch bleibt eine geteilte Karte wiedererkennbar, auch wenn Kopien getrennt weiterbearbeitet wurden.

Die Kardinalität lautet jedoch *1: höchstens eine UID, nicht zwingend genau eine. Ohne entscheidende UID darf das System Karten nach Ermessen zuordnen. Und auch eine gleiche UID kann falsch kopiert oder missbräuchlich wiederverwendet worden sein.

UID besitzt somit Autorität über die Datensatzzuordnung. Sie bestätigt weder reale Identität noch Feldwahrheit noch Einwilligung zur Zusammenführung. Wer daraus mehr ableitet, macht aus einem Koordinationsschlüssel eine Identitätsinstanz.

PID trennt lokale Nummer und globale Bedeutung

Nach der Kartenzuordnung müssen einzelne Eigenschaften erkannt werden. Das erste PID-Feld benennt einen lokalen Wert. Das zweite ist eine kleine Quellennummer, die nur innerhalb dieser vCard-Instanz gilt.

CLIENTPIDMAP ordnet die Quellennummer einer URI zu und schafft globalen Kontext. Für jede verwendete Quelle ist ein Eintrag erforderlich; null ist unzulässig. Stimmen die lokalen Wertnummern überein und führen die Quellen über äquivalente URI in denselben Kontext, können die PID denselben globalen Wert darstellen.

Diese Indirektion verhindert, dass die Nummer 1 auf jedem Gerät fälschlich globale Eindeutigkeit beansprucht.

Eine URI ist dennoch keine Signatur. Der Eintrag beweist nicht, dass das bezeichnete Gerät den Wert erzeugt hat, die Zuordnung unverändert blieb oder die Quelle andere Angaben überschreiben durfte. CLIENTPIDMAP schafft Vergleichbarkeit, keine Verfügungsgewalt.

Die MUST-Regeln sind Schutzplanken

Eigenschaften nicht zugeordneter Karten dürfen nicht zusammengeführt werden. Unterschiedliche Eigenschaftsnamen ebenfalls nicht. Auf zugeordneten Karten müssen gleichnamige Eigenschaften mit Maximal-Kardinalität eins übereinstimmen. Gleichnamige Eigenschaften mit passendem PID müssen ebenfalls übereinstimmen.

Diese Regeln verhindern willkürliche Ähnlichkeitslogik. TEL wird nicht zu EMAIL. Ein Wert einer anderen Person wandert nicht wegen Textnähe in die aktuelle Karte. Eine bekannte Eigenschaftsidentität bleibt verbindlich.

Danach beginnt der Ermessensraum. Schreibweisen von Rufnummern, Adressvarianten oder unabhängig erfasste gleiche Werte sind nicht universell entscheidbar.

Die lokale Freiheit ist sinnvoll. Gefährlich wird sie erst, wenn die Implementierung ihren Entscheidungsweg nicht aufzeichnet. Mindestens Eingabewerte, Normalisierung, Regel- oder Modellversion, Konfidenz, Schwelle, Aktion und Akteur gehören in einen separaten Beleg.

Ein intelligenter Motor führt die Telefone zusammen

Im Beispiel gleichzeitiger Bearbeitung fügen zwei Geräte jeweils eine E-Mail-Adresse und eine Telefonnummer hinzu. Da die Quellen verschieden sind, tragen die neuen Eigenschaften verschiedene globale PID.

Die E-Mail-Adressen bleiben getrennt und werden beide übernommen. Auch die Telefone besitzen unterschiedliche PID, zeigen aber denselben Wert. Der Entwurf nimmt einen besonders intelligenten Motor an, der sie dennoch als dieselbe Eigenschaft erkennt und zusammenführt.

Das Ergebnis kann richtig sein. Es kann ebenso eine nicht codierte Differenz verdecken: Durchwahl, beruflicher Kontext, Vertrauensniveau, alte Quelle oder Wartungsverantwortung.

Die endgültige TEL-Eigenschaft behält beide PID. Sie zeigt, dass zwei Eigenschaftslinien vereinigt wurden. Sie zeigt nicht, warum. Wurde nur die Zeichenfolge verglichen? Eine internationale Nummer normalisiert? Ein Nutzer gefragt? Ein Modell eingesetzt?

Ein belastbarer Beleg hält Originalhashes, PID, CLIENTPIDMAP, normalisierte Werte, Entscheidungsregel, Konfidenz, Richtlinie und Zeitpunkt fest. Menschliche Bestätigung ist ein eigener Akt, nicht bloß ein höherer Modellscore.

Inkonsistente Quellkarten verlangen weniger Automation

CLIENTPIDMAP wird gesondert behandelt und nicht wie eine gewöhnliche Eigenschaft gematcht. Das System muss Konsistenz zwischen zugeordneten Karten herstellen. Bei Inkonsistenz bleibt das Ergebnis laut Revision 00 dem System überlassen und ist im Dokument nicht definiert.

Ursachen reichen von legitimer Umnummerierung über veraltete Kopien und Beschädigung bis zur böswilligen Quellenersetzung. Eine einzige globale Regel wäre nicht in jeder Vertrauensarchitektur sicher.

Nicht definiert bedeutet jedoch nicht beliebig überschreibbar. Ein verantwortliches System bewahrt beide Eingaben, stoppt irreversible Schritte, meldet einen Grund und ruft lokale Richtlinie auf. Ein persönliches Adressbuch kann nachfragen; ein Unternehmensverzeichnis kann quarantänisieren oder signierte Historie prüfen.

Wer still eine Karte auswählt und das Ergebnis anschließend als vCard-konform bezeichnet, verbirgt lokale Macht hinter der Spezifikation.

Kontextvereinfachung komprimiert auch Erklärbarkeit

Am Ende des Beispiels wird der globale Kontext vereinfacht. Weil nur zwei Geräte beteiligt waren, können Eigenschaften umnummeriert und ein Quellkontext entfernt werden. Die Karte wird kürzer.

Der Entwurf erklärt ausdrücklich, dass die Einzelheiten nicht spezifiziert sind. Das Beispiel zeigt eine Möglichkeit, deren Untersuchung lohnend erscheint. Es ist kein vollständiger Algorithmus.

Kompression ist betriebsnotwendig. Verteilte Systeme brauchen Snapshots, Garbage Collection und materialisierte Ansichten. Die portable Karte sollte nicht zwangsläufig ein unbegrenztes Ereignisprotokoll enthalten.

Aber die Betriebsansicht und der Auditbeleg müssen getrennt bleiben. Vor der Vereinfachung werden Eingabehashes, Quellkarten und Konflikte gespeichert. Die Transformation hält die Zuordnung alter zu neuer Nummern fest. Danach wird der Ausgabehash protokolliert.

Die kurze Karte beantwortet den aktuellen Zustand. Der lange Beleg erklärt den Weg. Wird nur die Karte behalten, ist sie kein nachträglich rekonstruierbares Entscheidungsbuch.

Sicherer Transport beantwortet eine andere Frage

vCard besitzt keine eingebaute Authentisierung oder Vertraulichkeit. Der Entwurf nennt Schutzmechanismen wie S/MIME. CardDAV stellt Sammlungs- und ETag-Kontext bereit; WebDAV Sync listet Änderungen seit einem Token.

Eine authentisierte Nachricht kann Bytes und einen Berechtigungsnachweis verbinden. Ein ETag identifiziert die bearbeitete Version. Ein Sync-Token begrenzt die geänderten Ressourcen.

Keiner dieser Belege entscheidet, ob zwei Telefone zusammengehören. Ein authentisierter Absender kann sich irren oder nur für manche Felder zuständig sein. Ein Schreibvorgang gegen den richtigen ETag kann eine falsche semantische Entscheidung enthalten.

Deshalb werden Transportidentität, Autorisierung, Ressourcenversion, Kartenzuordnung, Pflichtmatches, Ermessensmatches, Konfliktregel, gespeicherte Projektion und beobachtetes Ergebnis separat protokolliert.

SOURCE und REV bleiben grobe Signale

SOURCE kann auf eine Datenquelle verweisen, REV den letzten Aktualisierungszeitpunkt der Karte nennen. Beide helfen gegen veraltete Daten.

Eine Karte kann jedoch Unternehmens-E-Mail, selbst eingetragenes Mobiltelefon und importierten Notfallkontakt kombinieren. Eine Quelle und ein Zeitstempel beschreiben nicht Herkunft und Alter jeder Eigenschaft und nicht die Autorisierung einer bestimmten Zusammenführung.

Die Lösung ist nicht, vCard zum Event-Sourcing-Protokoll zu machen. Die entscheidende Anwendung bewahrt zusätzliche Evidenz. Die portable Darstellung bleibt schlank. Je größer die Wirkung einer Änderung, desto stärker der lokale Beleg.

Nicht nur Konvergenz messen

Ein System kann hundert Prozent Konvergenz erreichen und dennoch falsche Kontakte verbreiten. Deshalb müssen UID-Pflichtzuordnung und heuristische Kartenzuordnung getrennt werden, ebenso PID-Pflichtmatch und Ermessensmatch.

Hinzu kommen CLIENTPIDMAP-Konflikte, vom Nutzer rückgängig gemachte Zusammenführungen, gelöschte Alternativen, Vereinfachungen ohne Transformationstabelle sowie fehlgeschlagene Anrufe oder Nachrichten nach erfolgreicher Synchronisation.

Steigt die Rücknahmequote bei stabil hoher Konvergenz, repliziert die Automation fragile Entscheidungen schneller.

Die Stärke von vCard4-bis besteht darin, die Grenze sichtbar zu lassen. Das Format besitzt Syntax und bestimmte Identitätskanten. Das System besitzt die Heuristik. Die Anwendung besitzt Konfliktpolitik. Der Betreiber besitzt Einsatz und Audit. Die Wirklichkeit liefert später den Kontaktbeweis.

Das MAY ist somit keine Leerstelle. Es ist die Stelle, an der die Implementierung handeln darf und deshalb Rechenschaft schuldet.

Sources