Résumé

  • RFC 9982 rend le uid d’une Card JSContact facultatif en version 2.0 et interdit d’en inventer un lors de la conversion d’une vCard sans UID.
  • Un identifiant rend une fiche référable dans un modèle donné ; il ne prouve pas l’identité réelle, la provenance, le consentement, l’actualité d’une relation ou l’autorisation de fusionner.

La correction paraît modeste : JSContact 1.0 exigeait un uid, alors que vCard laisse UID facultatif. Ce décalage était embarrassant pour les représentations qui n’en ont pas besoin, mais surtout dangereux lors des conversions. L’ancienne règle devait produire un identifiant pour une vCard sans UID, sans garantir qu’un autre logiciel — ou la même conversion répétée — produirait la même valeur. Une relation ajoutée ensuite à partir de cette valeur pouvait sembler exacte dans une base et être sans fondement dans le monde décrit.

RFC 9982 apporte une réponse plus honnête. Une Card sans uid est valide en version 2.0, sauf exigence d’un autre document. Elle ne peut pas être désignée comme membre dans members, ni cible dans relatedTo. Le RFC ne décrète pas que le contact n’existe pas. Il dit qu’il manque à cette fiche le repère que le modèle exige avant de créer un lien machine. C’est une retenue utile : la donnée conserve son contenu sans acquérir, par accident, des relations qu’elle ne peut pas soutenir.

Cette retenue sépare des affirmations trop souvent confondues. Une chaîne peut rester stable dans un système local ; deux cartes peuvent avoir la même orthographe ; une conversion peut être techniquement réussie. Aucune de ces observations n’établit à elle seule que les cartes représentent la même personne, que la relation annoncée demeure valide, que la source était compétente pour l’affirmer ou que le destinataire a le droit de fusionner les dossiers. La propriété uid est une surface de données, non une pièce d’identité, une signature, une autorisation ou une preuve de consentement.

La version compte également. Tous les objets JSContact 1.0 valides restent acceptables sous 2.0, mais les objets 2.0 sans uid ne doivent pas être refusés comme invalides par défaut. Pour convertir une source sans UID, une implémentation doit donc respecter la version du résultat et ne pas injecter un fait absent. La correction du paramètre JSCOMPS dans le registre IANA améliore l’exactitude descriptive du format ; elle ne garantit pas que l’intention sémantique d’une conversion a été préservée.

La leçon est gouvernante. Les protocoles de carnet d’adresses peuvent exiger une clé afin de synchroniser des objets. RDAP peut ne pas en avoir l’usage. Ce besoin de protocole n’autorise pas un intermédiaire à fabriquer une identité. Dans la perspective de Heng Lu, une spécification commune doit rendre l’échange possible sans prétendre absorber les décisions locales de rapprochement, de relation et de mise à jour.