Résumé

  • iMIP a raccordé le protocole de programmation iTIP au transport par courriel en définissant l’emplacement et le type MIME de l’objet calendrier.
  • Le texte destiné à un lecteur humain aidait les logiciels sans agenda ; il ne représentait pas un choix entre plusieurs événements.

Le message avait trois couches, pas une seule

Un courriel d’invitation semble souvent être une chose unique. Pourtant, son adresse d’expédition, son arbre MIME et les propriétés d’un événement n’ont ni le même rôle ni le même sens. RFC 2447, appelé iMIP, a précisé la jonction entre ces couches : les règles d’iTIP décrivaient l’échange de programmation, iCalendar décrivait les données, et le MIME fournissait leur enveloppe dans un message électronique. La norme ne demandait donc pas au champ « Objet » ou au logiciel de messagerie d’inventer la sémantique d’une réunion.

La partie structurée devait être de type text/calendar. Son paramètre MIME method devait correspondre à la propriété METHOD de l’objet iCalendar inclus. Cette redondance était délibérée : le conteneur annonçait quel type d’opération il transportait, tandis que l’objet portait les données du calendrier. Si plusieurs objets avaient des méthodes différentes, ils devaient être placés dans des parties calendrier distinctes d’un multipart/mixed. Sans cette séparation, un client aurait dû deviner si le paquet contenait plusieurs opérations ou une seule représentation contradictoire.

Le texte explicatif n’était pas une deuxième réunion

Les agents MIME pouvaient présenter le même message sous plusieurs formes. Un lecteur de courrier dépourvu de fonctions d’agenda pouvait afficher une partie en texte clair ; un client compatible pouvait traiter text/calendar. Dans multipart/alternative, les deux représentations visaient le même contenu de programmation. La fonction ressemblait à une légende accompagnant une carte : elle facilitait la lecture sans créer une autre carte.

Cette distinction interdit de placer deux horaires concurrents sous le label « alternatives » et d’espérer que le destinataire choisira le bon. Deux VEVENT légèrement différents ne sont pas deux rendus d’un seul objet. Si l’organisateur veut proposer une heure différente, l’opération relève d’iTIP ; la structure MIME ne remplace pas cette négociation. Le formatage d’une représentation et le choix du calendrier sont deux problèmes distincts.

RFC 2447 traitait aussi des détails qui paraissent secondaires jusqu’à ce qu’ils cassent l’interopérabilité. Un jeu de caractères devait être indiqué lorsque l’objet utilisait des caractères au-delà d’ASCII ; les encodages de transfert devaient protéger les octets du contenu selon les limites du transport. RFC 6047, qui a remplacé RFC 2447 en 2010, a actualisé ces règles pour le format de message et les mécanismes S/MIME alors en vigueur. Rien de cela ne prouve qu’un message a atteint sa boîte de destination : il s’agit de préserver et d’interpréter correctement les parties du paquet, pas de certifier le parcours postal.

Les pièces jointes rendaient cette frontière visible. Des propriétés iCalendar pouvaient désigner un contenu par un Content-ID ou un Message-ID. RFC 2447 recommandait de transmettre avec l’objet les parties MIME auxquelles il faisait référence, car la personne qui reçoit le message pouvait ne pas avoir accès à une ressource située ailleurs. Un identifiant indique où chercher ; il ne garantit ni que l’objet est présent, ni que le destinataire a le droit de l’ouvrir.

L’en-tête ne suffisait pas non plus à identifier le rôle de l’utilisateur du calendrier. Après un transfert, l’expéditeur du courriel peut différer de l’Organizer. Un logiciel de messagerie n’est pas tenu de recopier automatiquement ce rôle dans Reply-To. RFC 2447 demande donc aux implémentations de lire les propriétés ORGANIZER et ATTENDEE dans l’objet calendrier. RFC 2447 évoquait les multiparts sécurisés de RFC 1847 pour authentifier et protéger le contenu ; RFC 6047 a ensuite prescrit S/MIME pour l’authentification. Une signature ne couvre que le contenu protégé : elle n’atteste ni la réception, ni le traitement par le calendrier, ni un accord humain.

La chronologie est précise : RFC 2447 a été publiée comme norme de suivi en novembre 1998, puis remplacée par RFC 6047 en 2010. Cette évolution montre une liaison de transport révisable, pas le taux d’adoption des logiciels. Le principe durable reste plus modeste : l’objet calendrier porte la programmation, MIME décrit son emballage et le courrier achemine le paquet. Confondre ces trois niveaux fait passer un événement transmis pour un événement appliqué.

Sources