Résumé

  • PARTSTAT=ACCEPTED qualifie la participation déclarée d’un utilisateur de calendrier ; il ne mesure pas ce que cette personne a fait pendant la réunion.
  • Une analyse fiable doit conserver séparément la réponse, son auteur effectif, la version de l’événement, sa livraison et l’observation de présence.

À 9 h 03, le tableau de bord annonce quarante-deux participants « acceptés ». La plateforme de visioconférence n'en compte que trente et un. La tentation est de chercher quel système se trompe. Il est possible qu'aucun ne se trompe : les deux nombres ne répondent tout simplement pas à la même question.

Dans la RFC 5545, PARTSTAT désigne l'état de participation associé à un utilisateur de calendrier. Pour un événement, le vocabulaire comprend notamment NEEDS-ACTION, ACCEPTED, DECLINED, TENTATIVE et DELEGATED. C'est un langage de coordination. Il rend les intentions exploitables avant la réunion ; il ne transforme pas le calendrier en capteur de présence.

Trois autorités, et non un seul fait

Le parcours de Cyrus Daboo dans les normes éclaire cette architecture. Il figure parmi les auteurs de CalDAV, RFC 4791, signe la RFC 5546 sur iTIP et cosigne la RFC 6638 sur la planification CalDAV. Son profil IETF recense un ensemble plus large de RFC. Le prix CalConnect de 2013 documente, à cette date, son rôle dans l'interopérabilité des calendriers.

La RFC 5546 répartit l'autorité avec soin. L'organisateur maîtrise l'objet de planification principal. Il place généralement un nouvel invité à NEEDS-ACTION. L'invité modifie le PARTSTAT de sa propre propriété ATTENDEE dans un message REPLY, puis l'organisateur intègre la réponse. Le STATUS de l'événement et le PARTSTAT d'un invité ne sont donc ni le même champ ni la même décision.

Une ligne ACCEPTED chez l'organisateur permet d'affirmer qu'une réponse positive est attachée à cette adresse dans cette copie. Elle ne dit pas encore qui a manipulé le client, si une modification ultérieure a rendu la réponse caduque, ni si quelqu'un s'est présenté.

Le nom de l'invité ne désigne pas toujours l'acteur

iTIP prévoit la délégation. Un invité peut confier à un autre utilisateur de calendrier le droit de participer pour lui. Le paramètre SENT-BY indique qu'un utilisateur a répondu au nom de l'invité ou de l'organisateur désigné. Une assistante, une boîte partagée ou un agent logiciel peuvent donc produire une réponse légitime.

Il faut alors distinguer l'adresse invitée, l'acteur qui a envoyé la réponse et la personne qui pourrait être présente. Réduire ces trois identités à une seule colonne n'est pas une simplification neutre : c'est supprimer les informations nécessaires pour attribuer l'acte.

Une acceptation appartient à une version

L'événement possède aussi une histoire. Dans la RFC 5546, SEQUENCE marque les révisions décidées par l'organisateur ; un REPLY ne l'incrémente pas. La réponse indique ainsi la version à laquelle l'invité répondait. Si l'heure, le lieu ou la portée de la réunion changent, une acceptation ancienne ne prouve même plus une intention actuelle.

Les séries récurrentes rendent l'erreur particulièrement visible. Une réponse générale peut coexister avec une exception RECURRENCE-ID refusée, déplacée ou supprimée. Copier l'acceptation de la série sur chaque occurrence revient à créer des présences qui n'ont jamais été déclarées.

Le serveur constate un traitement, pas un corps

La RFC 6638 décrit la « planification implicite » : enregistrer, modifier ou supprimer une ressource peut amener le serveur CalDAV à envoyer automatiquement les messages nécessaires. À la réception d'un REPLY, il peut mettre à jour le PARTSTAT de l'invité dans la ressource de l'organisateur. SCHEDULE-STATUS peut rendre compte de la livraison ou du traitement de planification.

Ces traces sont précieuses pour diagnostiquer le système. Mais une livraison réussie n'est pas la lecture humaine d'une invitation, et un traitement automatique n'est pas une présence. L'agent de planification peut être le SERVER, le CLIENT ou NONE. Son identité technique ne doit pas être attribuée à la personne nommée dans le calendrier.

Écrire ce que la preuve sait réellement

Certaines organisations ont un besoin valable de constater la présence : sécurité d'un site, formation certifiante, quorum ou service facturé. Il leur faut alors une source conçue pour cet événement et une définition contestable. Un badge peut être prêté ; une connexion peut rester ouverte ; un appel nominal peut se tromper. Chaque méthode établit un signal limité, jamais une présence absolue.

Le bon modèle ressemble à un registre à colonnes distinctes : adresse invitée, réponse, personne ou agent ayant répondu, version, occurrence, état de livraison, signal observé pendant l'événement, méthode, fenêtre temporelle et exception. ACCEPTED va dans la colonne « réponse ». Sans observation de l'événement, la colonne « présence » reste vide.

Ce vide protège la qualité de la preuve. Il ne demande pas à une donnée de calendrier de raconter une scène qu'elle n'a pas vue.