Zusammenfassung

  • RFC 9982 macht uid in einer JSContact-2.0-Card optional und verbietet, beim Konvertieren einer vCard ohne UID eine v2-uid zu generieren.
  • Eine Kennung macht einen Datensatz in einem Modell adressierbar. Sie belegt nicht allein reale Identität, Quellenprovenienz, eine noch gültige Beziehung, Einwilligung oder eine Berechtigung zum Zusammenführen.

Frühere JSContact-Regeln verlangten eine uid für jede Card. Das ist für Synchronisationsprotokolle mit stabilen Objektgriffen plausibel, widersprach aber der optionalen vCard-UID. Die alte Konvertierung musste ohne Quell-UID eine Kennung erzeugen. Wie sie entstand, war implementierungsspezifisch; weder verschiedene Programme noch Wiederholungen mussten denselben Wert liefern. Trotzdem konnte ein Empfänger die vorübergehende Kennung als Mitglied in members oder als Ziel in relatedTo verwenden. Aus einer Konvertierungsbequemlichkeit wurde so ein ungedeckter Beziehungsanspruch.

RFC 9982 behandelt die Lücke anders. Eine Card ohne uid ist in Version 2.0 gültig, kann aber nicht Mitglied oder Beziehungstarget sein. Damit wird nicht behauptet, der Kontakt sei unwahr oder wertlos. Es wird nur keine maschinenlesbare Verbindung erzeugt, für die dem Datensatz der erforderliche Anker fehlt. Die Fähigkeit, Inhalt zu transportieren, bleibt; die Fähigkeit, eine dauerhafte Referenz zu tragen, bleibt begrenzt.

Die Versionsregel verhindert besonders stille Fehlinterpretationen. Jede gültige 1.0-Card bleibt auch unter 2.0 gültig. Eine 2.0-Card ohne uid darf nicht allein deswegen verworfen werden. Konvertiert ein System eine vCard ohne UID in 2.0, muss es die Abwesenheit respektieren. Für 1.0 verlangte die Vorgängerregel noch eine erzeugte Kennung, deren Stabilität nicht interoperabel garantiert war. Ein erfolgreicher Transformationslauf kann daher Formatkonformität zeigen, nicht aber eine belastbare Entitätsgleichheit.

Auch eine vorhandene uid ist begrenzt. Sie ist keine Signatur, kein Identitätsnachweis, kein Rechtsname, kein Konto-Nachweis und kein Merge-Mandat. Die IANA-Registrierung von JSCOMPS vervollständigt das Register einer vCard-Parameterbeschreibung; sie bescheinigt weder Absicht noch Semantik einer konkreten Umwandlung. CardDAV oder JMAP Contacts können eine Kennung für ihre Verarbeitung verlangen, während RDAP sie nicht benötigt. Protokollbedarf darf nicht in eine Behauptung über die Welt übersetzt werden.

Die Haltung folgt Heng Lus Idee der minimalen gemeinsamen Spezifikation: Gemeinsame Form schafft Austausch, aber sie nimmt lokalen Stellen nicht die Entscheidung über Herkunft, Gleichheit, Beziehung und Schreibrecht ab.