Résumé

  • Un participant qui répond à une réunion prévue lundi par un COUNTER proposant mardi soumet, dans iTIP, une alternative complète : il ne réécrit pas l’entrée maîtresse détenue par l’organisateur.
  • Si l’organisateur accepte cette proposition, sa décision et l’envoi ultérieur d’un REQUEST révisé constituent des transitions distinctes, avec leurs propres responsabilités et effets.

Imaginons explicitement un cas hypothétique : une réunion est programmée lundi, mais un participant souhaite mardi. Dans le modèle défini par RFC 2446, ce participant peut envoyer un COUNTER. Le point essentiel est moins la nouvelle date que la frontière de contrôle : le COUNTER propose une autre représentation de l’événement, mais il ne transforme pas de lui-même l’objet maître conservé par l’organisateur.

Publié en novembre 1998 sur le Standards Track, RFC 2446 définissait l’« iCalendar Transport-Independent Interoperability Protocol », ou iTIP. RFC 2445 définissait les objets iCalendar eux-mêmes; RFC 2446 décrivait les transactions de programmation indépendantes du moyen de transport; RFC 2447 fournissait ensuite une liaison avec le courrier électronique. RFC 2446 a depuis été obsolété par RFC 5546, tandis que le format iCalendar de RFC 2445 a été remplacé par RFC 5545.

Cette séparation éclaire le fonctionnement du protocole. Selon RFC 2446, l’Organizer initie l’échange de programmation et les Attendees sont les participants invités. Ces rôles iTIP ne doivent pas être confondus avec le paramètre descriptif ROLE attaché à une propriété ATTENDEE. L’organisateur contrôle l’entrée maîtresse et son STATUS; chaque participant, lui, possède notamment son propre PARTSTAT. Le modèle ne transforme donc pas un message reçu en autorité générale sur l’état commun.

Les méthodes distinguent également les intentions. PUBLISH diffuse sans réponse interactive attendue. REQUEST demande le traitement d’un objet et peut susciter une réponse. REPLY communique l’état d’un participant. COUNTER propose une modification. DECLINECOUNTER rejette cette proposition. Dans le scénario hypothétique lundi-vers-mardi, le COUNTER peut transporter un VEVENT alternatif complet — ou, dans le domaine correspondant, un VTODO — sans devenir pour autant l’événement maître.

L’acceptation éventuelle par l’organisateur ouvre une autre étape. RFC 2446 prévoit qu’un organisateur qui accepte un contre-projet replanifie l’objet puis transmet un REQUEST révisé aux participants concernés. La proposition, la décision et la redistribution de l’état autoritatif ne sont donc pas une seule opération. Cette dissociation évite de confondre le contenu d’un message reçu avec une modification déjà autorisée et propagée.

SEQUENCE renforce cette distinction. RFC 2446 rattache sa progression aux révisions de l’organisateur, et non à une notion générale de consentement. REPLY, REFRESH, COUNTER, DECLINECOUNTER et un REQUEST utilisé pour la délégation ne l’incrémentent pas; ADD et CANCEL l’incrémentent. Une réponse peut en outre se rapporter à une révision plus ancienne. Lire SEQUENCE comme un simple compteur chronologique de « vérité » ou d’accord entre toutes les parties dépasserait donc ce que décrit la norme.

Le transfert d’une invitation montre la même discipline d’autorité. Envoyer l’invitation à une personne qui n’était pas invitée ne l’ajoute pas automatiquement à la liste maîtresse. RFC 2446 réserve cette décision à l’organisateur et indique que celui qui transfère l’objet ne doit pas en modifier les propriétés. Là encore, possession d’un message, capacité de le retransmettre et autorité pour changer l’état partagé restent des réalités différentes.

La livraison elle-même n’impose pas non plus un ordre parfait. Dans un environnement store-and-forward, RFC 2446 reconnaît qu’un CANCEL peut arriver avant le REQUEST auquel il se rapporte. Pour un CANCEL non corrélé portant un SEQUENCE non nul, le texte suggère qu’un système peut le conserver temporairement dans l’attente d’un message de séquence inférieure, puis le laisser expirer. L’existence d’un objet reçu ne prouve donc ni que son prédécesseur a été reçu, ni que tous les systèmes locaux ont convergé.

Enfin, les champs de rôle ne prouvent pas l’identité de l’expéditeur. RFC 2446 signale le risque d’usurpation et renvoie l’authentification et le chiffrement au transport. L’existence d’une méthode, d’un UID, d’un SEQUENCE ou d’un rôle déclaré doit ainsi rester distincte de l’identité authentifiée. RFC 1847 appartient au contexte historique des mécanismes MIME de sécurité, mais RFC 2446 ne permet pas d’assimiler les propriétés iTIP à une preuve cryptographique d’identité.

Cette lecture historique rejoint une méthode d’analyse plus générale : séparer le message transmis, l’autorité attribuée par le protocole, la décision, l’enregistrement local et l’événement réel. Les textes de Heng Lu sur les couches de réalité, la primauté du code en fonctionnement et la spécification minimale fournissent ici une grille d’analyse, sans constituer des travaux sur iTIP. Le protocole, à lui seul, ne permet d’inférer ni adoption réelle, ni comportement d’une implémentation particulière, ni livraison effective, ni présence à la réunion.

Sources

  1. RFC 2446 — iCalendar Transport-Independent Interoperability Protocol (iTIP)
  2. RFC Editor — Information on RFC 2446
  3. IETF Datatracker — RFC 2446
  4. RFC Editor — Errata Search for RFC 2446
  5. RFC 2445 — Internet Calendaring and Scheduling Core Object Specification (iCalendar)
  6. RFC 2447 — iCalendar Message-Based Interoperability Protocol (iMIP)
  7. RFC 5545 — Internet Calendaring and Scheduling Core Object Specification (iCalendar)
  8. RFC 5546 — iCalendar Transport-Independent Interoperability Protocol (iTIP)
  9. RFC 6047 — iCalendar Message-Based Interoperability Protocol (iMIP)
  10. RFC 1847 — Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
  11. IANA — iCalendar Element Registries
  12. Heng Lu — Running Code Primary: The Patch Needed to Preserve the Internet Original Design
  13. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption: Internet Coordination System
  14. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile