Résumé

  • RFC 5257 place des métadonnées persistantes à côté d’un message, avec des espaces .priv et .shared et des droits distincts ; cette proximité ne donne pas à la note la voix de l’expéditeur.
  • Lors d’une copie, toutes les annotations partagées admissibles suivent, mais seules les annotations privées de l’utilisateur courant suivent ; le même message peut donc changer de périmètre contextuel.

Le mot « validé » ne disait pas qui avait validé

Dans une boîte collective, un message portait une annotation partagée : « validé ». Le service financier y voyait l’accord du client. L’équipe support y voyait la décision d’un collègue. L’administrateur savait seulement que la valeur existait. L’interface avait placé le mot si près du message que son origine avait disparu.

RFC 5257 autorise précisément ce type de contexte : commentaire, autre objet, étiquette ou note sur une partie MIME. L’annotation est une entrée hiérarchique distincte, avec ses propres attributs. Elle se rattache au message mais n’entre ni dans son corps ni dans ses en-têtes d’auteur.

Le principe est simple : la proximité facilite le travail, elle ne crée pas l’autorité. Une note persistante peut infléchir le tri, la recherche et l’action sans jamais devenir une déclaration du correspondant.

Privé et partagé décrivent une surface de visibilité

Chaque attribut possède implicitement une version .priv et une version .shared. Une lecture peut demander les deux. Une écriture doit choisir. Cette obligation évite qu’un client dépose une note sans savoir si elle sera personnelle ou collective.

Le choix ne porte toutefois aucun jugement de valeur. .priv ne signifie ni chiffré, ni juridiquement privilégié, ni invisible à toute administration. .shared ne signifie ni revu, ni vrai, ni approuvé par l’organisation. Il s’agit d’une classe de visibilité dans le modèle du serveur.

Une information sensible déposée en partagé peut être exposée à d’autres utilisateurs autorisés. Une assignation opérationnelle déposée en privé peut ne jamais atteindre l’équipe. Le risque se trouve moins dans le mécanisme que dans l’effacement de cette classe au moment de l’affichage ou de l’export.

Un droit d’écriture n’est pas un mandat de représentation

Sans extension ACL, la lecture et l’écriture dépendent du mode de sélection de la boîte. Avec ACL, le droit r contrôle la lecture et l’écriture privées ainsi que la lecture partagée ; le droit n contrôle la création et la modification partagées.

Cette séparation autorise un rôle à tenir un état collectif sans lui donner toutes les autres capacités de la boîte. Mais elle ne transforme pas ce rôle en principal du message. La permission d’inscrire « approuvé » ne prouve pas que le client, l’auteur ou la direction a donné son accord.

Le reçu doit donc conserver l’identité de l’écrivain, son justificatif et l’ACL appliquée. La valeur finale seule répond à « que lisait-on ? ». Elle ne répond pas à « qui pouvait engager qui ? ».

Permanent ne veut pas dire immuable

Le RFC impose une conservation permanente plutôt qu’un état limité à la session. C’est indispensable aux clients déconnectés. Une reconnexion doit retrouver la note. Mais STORE peut remplacer une valeur, et NIL la supprime.

Une lecture absente retourne NIL, et une taille absente vaut zéro. Sans journal séparé, l’état final ne distingue pas une annotation jamais créée, supprimée volontairement ou omise lors d’une copie incompatible.

RFC 5257 recommande Conditional STORE pour détecter les modifications intervenues pendant qu’un client travaillait hors ligne. La détection d’un conflit protège contre certains écrasements aveugles. Elle ne choisit pas la bonne interprétation et ne contrôle pas la compétence métier de l’auteur.

La capacité générale ne promet pas chaque boîte

Le serveur annonce ANNOTATE-EXPERIMENT-1, puis la boîte précise sa réalité. NONE interdit les annotations. READ-ONLY interdit leur modification. NOPRIVATE ne garde que le partagé. Une valeur numérique indique la taille maximale ; un plafond de nombre peut aussi s’appliquer.

Une migration ne peut donc pas déduire du seul bandeau de capacité que toutes les notes suivront. La copie du message peut réussir tandis qu’une annotation trop grande, privée ou non prise en charge reste à la source. Ce désaccord doit être visible comme échec de contexte, pas absorbé par le succès du message.

COPY transporte un ensemble asymétrique

Lors d’un COPY, le serveur transporte toutes les annotations partagées et seulement les annotations privées de l’utilisateur courant, si la destination les autorise. Il lui est interdit de copier les notes privées d’autres utilisateurs.

Cette règle protège les frontières personnelles, mais elle prouve que deux exemplaires du même message n’ont pas forcément le même environnement. La note d’enquête du copieur suit ; celle d’un collègue ne suit pas. Les étiquettes collectives suivent sous réserve de capacité, de droits et de taille.

Une note partagée copiée n’acquiert pas pour autant l’autorité de l’auteur du message. Elle peut avoir été ajoutée bien plus tard, sous une ACL différente, puis transportée vers une nouvelle boîte. La copie conserve une valeur, pas le mandat qui lui est attribué.

La recherche amplifie ce qui n’a pas été vérifié

Les valeurs d’annotation peuvent entrer dans la recherche et le tri. Une étiquette peut sélectionner une file de risque ; un autre objet peut modifier l’ordre ; une donnée fournisseur peut déclencher une automatisation.

Plus la valeur a d’effet, plus sa provenance doit être forte. Une annotation peut respecter la syntaxe, les droits et la règle de copie tout en étant ancienne ou fausse. L’enregistrement d’un nom définit un espace d’interprétation, il ne valide pas chaque valeur.

RFC 5464 traite les métadonnées du serveur et de la boîte, non celles de chaque message. Cette séparation rappelle que la portée de la métadonnée décide de son sujet, de ses droits et de son mouvement.

Joindre un reçu à la note

Conservez boîte et UID, portée message ou partie, entrée, classe privée/partagée, identité et justificatif de l’écrivain, ACL et capacité, hachages avant/après, jeton de concurrence, résultat serveur, suppression, quota et taille. Pour une copie, ajoutez source, destination, acteur, inventaire copié ou omis et motif.

Affichez l’auteur, l’heure et la visibilité de l’annotation. Ne la rendez pas graphiquement identique au corps du message. « La valeur partagée était “validé” après cette écriture » est vérifiable. « L’expéditeur a validé » exige une autre chaîne d’autorité.

Sources