Résumé

  • La révision 00 de vCard4-bis définit des correspondances obligatoires entre fiches et propriétés, tout en laissant au moteur local les rapprochements que les identifiants ne résolvent pas.
  • Une fiche convergée décrit l'état courant. Elle ne devient un historique de provenance que si l'opérateur conserve, hors de la vCard compacte, les entrées, la règle, la décision et la transformation.

La compression arrive après la décision

À la fin de l'exemple de synchronisation de draft-ietf-calext-vcard4-bis-00, deux appareils possèdent le même contact. Plusieurs propriétés gardent encore la trace de deux contextes clients par leurs PID et leurs CLIENTPIDMAP. Le document montre alors qu'il est possible de simplifier ce contexte global : renuméroter les propriétés, supprimer une table devenue superflue et produire une fiche plus courte.

Pour le prochain échange, le résultat peut être équivalent. Pour une enquête ultérieure, il ne l'est pas nécessairement.

La fiche compacte sait encore quels numéros, adresses et noms l'application doit présenter. Elle ne dit plus forcément quel appareil a créé une valeur, quelle règle a réuni deux occurrences, quel conflit a été examiné ni quelle provenance a été abandonnée lors du raccourcissement. La spécification est explicite : les détails de cette simplification ne sont pas définis. L'exemple illustre une possibilité qui mériterait d'être étudiée.

Cette franchise est précieuse. Elle empêche de confondre un format d'échange avec un journal d'événements. Le problème apparaît seulement lorsqu'un opérateur efface le contexte puis affirme que la fiche résultante suffit à prouver la décision.

Un projet de norme, pas un résultat d'exploitation

La révision 00 est datée du 2 juillet 2026 et expire le 3 janvier 2027. Elle appartient au groupe CALENDAR EXTENSIONS, vise la filière de normalisation et remplacerait le RFC 6350 si elle était approuvée. À ce jour, elle reste un Internet-Draft. Ce n'est pas un RFC. Elle ne prouve ni l'adoption finale, ni la conformité d'un produit, ni l'identité réelle d'une personne représentée, ni la qualité d'une fusion exécutée en production.

Le format vCard résout pourtant un vrai problème d'infrastructure. Des logiciels indépendants doivent échanger des noms, des téléphones, des adresses, des organisations, des relations, des clés ou des références calendaires sans négocier un dialecte privé à chaque connexion. Une grammaire commune et des registres IANA rendent cet échange possible.

La doctrine de docs/heng-lu-note.md invite à ne pas diminuer cette coordination, mais à borner son autorité. Le texte publié, le parseur qui l'accepte, l'algorithme qui rapproche deux fiches, la politique qui arbitre un conflit et la réalité du contact sont des niveaux distincts. La norme donne une langue commune ; elle ne devient pas le mandataire permanent de toutes les décisions futures.

UID ferme une question et en laisse plusieurs ouvertes

Pour synchroniser deux représentations, il faut d'abord décider qu'elles concernent le même objet. vCard4-bis utilise UID comme arête déterministe. Deux fiches dont les UID sont équivalents doivent être rapprochées.

L'équivalence est encadrée. Deux URI valides suivent les règles du RFC 3986. Sinon, le contenu est comparé caractère par caractère après retrait de l'échappement vCard pour les valeurs textuelles. Cette précision évite qu'un moteur traite comme nouveaux tous les exemplaires d'un contact déjà partagé.

Mais la cardinalité de UID est *1 : au plus un, et non exactement un. En l'absence d'UID équivalents, le moteur peut encore rapprocher les fiches à sa discrétion. Et même un UID équivalent ne certifie pas la personne physique. Il ne prouve pas que l'émetteur avait le droit d'utiliser cet identifiant, que les deux auteurs parlaient réellement du même individu, ni que les données sont récentes.

UID fournit donc une identité de fiche dans la procédure. C'est une autorité étroite et utile. La transformer en identité civile, en consentement de fusion ou en vérité du contenu serait emprunter une autorité à un niveau qui ne la possède pas.

Un petit entier n'est global qu'à travers sa carte

Les propriétés répétées ont besoin de leur propre identité. Une fiche peut contenir plusieurs EMAIL ou plusieurs TEL. Le paramètre PID donne un numéro local à une valeur. Son second champ désigne une source, elle aussi par un petit entier local à l'instance de la fiche.

CLIENTPIDMAP relie ce numéro de source à une URI. Chaque source distincte utilisée par un PID doit avoir son entrée, et zéro est interdit. Deux PID peuvent représenter la même valeur globale lorsque leur numéro local correspond et que leurs numéros de source renvoient à des URI équivalentes.

Cette indirection est une bonne conception : elle évite de prétendre que le chiffre 1 est unique dans le monde. Deux appareils peuvent employer le même petit entier sans collision conceptuelle, car la carte indique le contexte global de chacun.

Il faut néanmoins résister à l'apparence d'une preuve cryptographique. Une URI de CLIENTPIDMAP est un nom de contexte, pas une signature. Elle ne démontre pas que l'appareil nommé a créé la propriété, que la carte n'a pas été modifiée ou que cette source pouvait écraser une autre. Elle sert à reconnaître, non à authentifier.

Les obligations dessinent la zone sûre

La section de synchronisation ne délègue pas tout. Les propriétés de fiches non rapprochées ne doivent pas être rapprochées. Deux propriétés de noms différents ne doivent pas l'être non plus. Sur des fiches déjà reconnues comme équivalentes, les propriétés portant le même nom et une cardinalité maximale de un doivent correspondre. Celles dont les PID représentent la même valeur globale doivent également correspondre.

Ces obligations protègent l'interopérabilité. Un numéro ne se transforme pas en adresse électronique parce qu'un fournisseur juge leurs chaînes proches. Une propriété issue d'une autre personne ne rejoint pas le contact courant par simple ressemblance. Une arête PID stable ne peut pas être ignorée au gré d'un classement propriétaire.

Puis vient le mot décisif : dans les autres cas, le moteur peut rapprocher des propriétés à sa discrétion. Le format reconnaît ainsi qu'un numéro écrit avec ou sans indicatif, deux graphies d'une adresse ou deux valeurs saisies hors ligne ne se laissent pas toujours résoudre par une règle universelle.

Dans la logique de la Spécification initiale minimale de Heng Lu, c'est une répartition saine : normaliser les invariants nécessaires, laisser les décisions contextuelles à l'acteur local. Mais celui qui exerce cette liberté doit porter la preuve de son choix. MAY ne signifie pas « sans reçu ».

Deux courriels demeurent ; deux téléphones se confondent

L'exemple des modifications simultanées montre exactement où commence le jugement.

Chaque appareil ajoute une nouvelle adresse électronique et un nouveau numéro de téléphone. Les nouvelles valeurs reçoivent des PID globaux distincts. Lors de la synchronisation, les deux adresses électroniques restent séparées et sont toutes deux copiées. Les deux téléphones ont eux aussi des PID différents, mais leur valeur visible est identique. Le moteur, qualifié de particulièrement intelligent, décide qu'il s'agit d'une seule propriété.

Cette décision est permise, non commandée. Elle peut être parfaite : les utilisateurs ont saisi deux fois le même numéro. Elle peut aussi gommer un contexte : ligne professionnelle et ligne d'astreinte, poste implicite, niveau de confiance différent, responsabilité de maintenance différente.

La fiche finale conserve les deux PID sur un seul TEL. Elle indique que deux identités de propriété ont convergé. Elle n'indique pas le comparateur utilisé, la normalisation appliquée, le seuil de confiance, l'avis humain éventuel ni la politique qui autorisait la fusion.

Un moteur responsable conserve ces éléments séparément : hachages des deux propriétés, PID et cartes d'origine, valeurs avant et après normalisation, version de la règle, décision, acteur et date. Si une personne confirme le rapprochement, sa confirmation ne doit pas se confondre avec la suggestion algorithmique.

L'incohérence de CLIENTPIDMAP n'a pas de résolution universelle

Les CLIENTPIDMAP ne sont pas rapprochées comme les autres propriétés. Le moteur doit assurer leur cohérence entre fiches reconnues. Si elles sont incohérentes, l'exemple précise que le résultat appartient au moteur et reste indéfini par le document.

Cette limite peut recouvrir plusieurs réalités : renumérotation légitime, copie ancienne, collision, corruption ou tentative de substitution de source. Une règle unique imposée à tous risquerait d'être fausse dans certains systèmes.

L'absence de règle universelle n'autorise pas un écrasement silencieux. Une politique locale peut mettre la fiche en quarantaine, conserver les deux contextes, demander une validation ou consulter un historique signé. Le minimum est de préserver les entrées conflictuelles et de produire un code de décision. Sinon, une implémentation transforme une zone non définie par la norme en pouvoir invisible, puis présente sa conformité vCard comme justification.

Un état matérialisé n'est pas un journal

La simplification du contexte global reprend un problème classique des systèmes distribués. Le journal complet grandit ; la vue matérialisée répond rapidement à la question courante. La compaction rend le service exploitable.

On peut donc raccourcir la vCard servie sans supprimer le reçu de fusion. Le produit garde une fiche nette pour les clients et, dans un registre append-only séparé, les hachages d'entrée, les cartes de source, la transformation de numérotation, les conflits et le hachage de sortie.

Les deux artefacts ont des fonctions différentes. La fiche dit : « voici l'état que nous servons ». Le reçu dit : « voici comment nous y sommes arrivés et sous quelle autorité ». Exiger que la vCard transporte tout l'historique alourdirait inutilement le format. Exiger que l'historique disparaisse avec la compaction rendrait les décisions irrévisables.

La discipline consiste à ne pas appeler l'un par le nom de l'autre.

Le transport sécurisé s'arrête avant la sémantique

Le projet rappelle que vCard n'offre en elle-même ni authentification ni confidentialité. Les fiches peuvent voyager dans des mécanismes protecteurs tels que S/MIME. CardDAV apporte son contexte de collection et ses validateurs ; la synchronisation WebDAV permet d'énumérer les ressources modifiées.

Ces couches apportent des reçus indispensables. Une enveloppe authentifiée relie un message à un principal dans une configuration de confiance. Un ETag identifie la version visée d'une ressource. Un jeton de synchronisation borne les changements depuis un état précédent.

Aucune ne décide que deux téléphones doivent fusionner. Un expéditeur authentifié peut se tromper ou ne pas disposer du mandat sur toutes les propriétés. Une version correctement adressée peut contenir une mauvaise décision sémantique. Une liste complète de ressources changées n'explique pas pourquoi une valeur a disparu.

Une chaîne d'audit utile enregistre donc séparément le principal de transport, l'autorisation, la version reçue, le motif du rapprochement de fiches, les correspondances obligatoires, les correspondances discrétionnaires, la politique de conflit et le résultat observé après utilisation.

SOURCE et REV ne remplacent pas une provenance par propriété

SOURCE aide à retrouver l'origine d'une fiche et REV peut indiquer sa dernière mise à jour. Ces champs sont précieux pour la fraîcheur. Ils ne suffisent pas lorsqu'une seule fiche combine un courriel d'annuaire, un mobile saisi par l'utilisateur et un contact d'urgence importé.

Une date globale ne raconte pas l'âge de chaque valeur. Une URI globale ne dit pas qui a autorisé un rapprochement particulier. Là encore, la solution n'est pas de transformer le format portable en système d'événements. C'est à l'application qui prend des décisions sensibles de conserver plus de preuve que l'objet d'échange minimal.

La responsabilité doit suivre l'impact. Un carnet personnel peut proposer une fusion réversible. Un annuaire d'entreprise, un contact d'urgence ou un système déclenchant automatiquement des communications doit isoler les cas incertains, conserver les alternatives et demander une validation proportionnée.

La norme la plus utile montre la fin de sa réponse

vCard4-bis est déterministe là où la compatibilité l'exige et prudent là où le contexte varie. UID ferme certaines décisions de fiche. PID et CLIENTPIDMAP ferment certaines décisions de propriété. Des interdictions empêchent les rapprochements absurdes. Le reste demeure une responsabilité locale, et la simplification finale demeure non spécifiée.

Cette répartition est une carte de l'autorité. Le format possède la syntaxe. Le moteur possède l'heuristique. L'application possède la politique de conflit. L'opérateur possède le déploiement et l'audit. L'utilisateur ou l'institution possède la décision d'agir. La réalité dira ensuite si le numéro joint la bonne personne.

Le résultat convergé est donc un reçu d'état, pas un reçu complet de décision. Il peut être parfaitement adapté au service tout en étant insuffisant pour expliquer la fusion.

La règle d'exploitation tient en une phrase : servez la fiche courte, conservez le reçu long.

Sources