Équipe d'ingénierie de l'Internet (IETF)	A. Melnikov, éditeur, Isode Ltd		
Request for Comments : 6047			
RFC rendue obsolète : 2447	décembre 2010		
Caéegorie : Sur la voie de la normalisation			
ISSN: 2070-1721	Traduction Claude Brière de L'Isle		

Protocole d'interopérabilité iCalendar fondée sur le message (iMIP)

Résumé
Le présent document, "Protocole d'interopérabilité iCalendar fondée sur le message" (iMIP, iCalendar Message-Based Interoperability Protocol) spécifie un lien du protocole iCalendar d'inter fonctionnement indépendant du transport (iTIP, iCalendar Transport-independent Interoperability Protocol) aux transports fondés sur la messagerie électronique Internet. Les entrées de calendrier définies par le modèle d'objet iCalendar sont enveloppés en utilisant des constructions provenant de la [RFC5322] et de MIME [RFC2045], [RFC2046], [RFC2047], et [RFC2049], et ensuite transportées sur SMTP.

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc6047 

Notice de droits de reproduction
Copyright (c) 2010 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
1.1 Documents en rapport	2
1.2 Conventions de formatage	2
1.3 Terminologie	3
2. Lien de message au format MIME	3
2.1 Type de support MIME	3
2.2 Sécurité	3
2.3 Adresses de messagerie électronique	4
2.4 Champ d'en-tête Content-Type	4
2.5 Champ d'en-tête Content-Transfer-Encoding	4
2.6 Champ d'en-tête Content-Disposition	5
3. Considérations sur la sécurité	5
4. Exemples	6
4.1 Un seul composant avec une propriété ATTACH	6
4.2 Utilisation de multipart/alternative pour des clients à faible fidélité	7
4.3 Un seul composant avec une propriété ATTACH et un rattachement en ligne	7
4.4 Composants similaires multiples	8
4.5 Composants mixtes multiples	9
4.6 Composants détaillés avec une propriété ATTACH	10
5. Pratiques recommandées	11
5.1 Utilisation des identifiants de contenu et de message	11
6. Considérations relatives à l'IANA	11
7. Références	11
7.1 Références normatives	11
7.2 Référence pour information	12
Appendice A. Changements depuis la RFC 2447	12
Appendice B. Remerciements	13
Adresse de l'éditeur	13

 	1.	Introduction

Le présent document fournit les informations spécifiques du transport ("liens") nécessaires pour porter le protocole iCalendar d'inter fonctionnement indépendant du transport (iTIP, iCalendar Transport-independent Interoperability Protocol) [RFC5546] sur la messagerie électronique Internet (en utilisant MIME) comme défini dans les [RFC5322] et [RFC2045]. Donc, le présent document définit le protocole d'interopérabilité iCalendar fondée sur le message (iMIP, iCalendar Message-Based Interoperability Protocol).

 	1.1	Documents en rapport
Le lecteur aura besoin d'être familiarisé avec plusieurs autres mémoires qui, avec celui-ci, forment un cadre pour les normes de calendrier et de programmation de l'Internet.

Le présent document spécifie un lien de messagerie électronique Internet pour iTIP.

La [RFC5545] spécifie le cœur des objets, types de données, propriétés, et paramètres de propriété.

La [RFC5546] spécifie un protocole d'interopérabilité pour la programmation entre des mises en œuvre différentes.

Le présent mémoire ne tente pas de répéter la spécification des concepts ou définitions provenant de ces autres mémoires. Lorsque possible, des références sont faites aux mémoires qui fournissent la spécification de ces concepts ou définitions.

 	1.2	Conventions de formatage
Les mécanismes définis dans le présent mémoire sont définis en prose. Pour se référer aux éléments du modèle de calendrier et de programmation, d'objet central, ou de protocole d'interopérabilité défini dans les [RFC5545] et [RFC5546], des conventions de formatage ont été utilisées.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Les rôles de calendrier et de programmation sont mentionnés par des chaînes de texte entre guillemets avec le premier caractère de chaque mot en majuscule. Par exemple, "Organisateur" se réfère à un rôle de "Utilisateur de calendrier" dans le protocole de programmation défini par la [RFC5546].

Les composants de calendrier définis par la [RFC5545] sont mentionnés comme des chaînes de texte en majuscules entre guillemets. Tous les composants de calendrier commencent par la lettre "V". Par exemple, "VEVENT" se réfère au composant de calendrier événement , "VTODO" se réfère au composant de calendrier à faire , et "VJOURNAL" se réfère au composant de calendrier journal.

Les méthodes de programmation définies par la [RFC5546] sont mentionnées avec des chaînes de texte en majuscules entre guillemets. Par exemple, "REQUEST" se réfère à la méthode pour demander qu'un composant de calendrier de programmation soit créé ou modifié ; "REPLY" se réfère à la méthode qu'utilise le receveur d'une demande pour mettre à jour son état avec l'"Organisateur" du composant de calendrier.

Les propriétés définies par la [RFC5545] sont mentionnées avec des chaînes de texte en majuscules entre guillemets, précédées du mot "propriété". Par exemple, la propriété "PARTICIPANT" se réfère à la propriéte iCalendar utilisée pour porter l'adresse du calendrier d'un "Utilisateur de calendrier".

Les paramètres de propriétés définies par la [RFC5545] sont mentionnés par des chaînes de texte en minuscules entre guillemets, précédées par le terme "paramètre". Par exemple, le paramètre "value" se réfère au paramètre de propriété iCalendar utilisé pour outrepasser le type de données par défaut pour une valeur de propriété.

 	1.3	Terminologie
Les termes de messagerie électronique utilisés dans le présent mémoire sont définis dans les [RFC2045] et [RFC5322]. Les termes de calendrier et de programmation utilisés dans le présent mémoire sont définis dans les [RFC5545] et [RFC5546].

 	2.	Lien de message au format MIME

Cette section définit les liens de message au transport de messagerie électronique MIME.

Les paragraphes ci-dessous se réfèrent au "générateur" et au "receveur" d'un message iMIP. Dans le cas d'une méthode "request", le générateur est l'"Organisateur" et le receveur est un "Participant" à l'événement. Dans le cas d'une méthode "response", le générateur est un "Participant" et le receveur est l'"Organisateur" de l'événement.

Le champ d'en-tête "Reply-To" [RFC5322] contient normalement l'adresse de messagerie électronique du générateur du message de programmation. Cependant, cela ne peut pas être garanti parce que l'envoyeur du message iMIP pourrait n'être pas le générateur du message de programmation et l'agent d'utilisateur de messagerie (MUA, Mail User Agent) de l'envoyeur pourrait ne pas appliquer la sémantique de iMIP en traduisant l'adresse du générateur dans le champ d'en-tête de messagerie électronique "Reply-To".

 	2.1	Type de support MIME
Une entité MIME contenant des informations de contenu formatées en accord avec le présent document va être référencée comme un type de contenu "text/calendar" [RFC5545]. On suppose que ce type de contenu va être transporté à travers un transport de messagerie électronique MIME.

 	2.2	Sécurité
Ce paragraphe traite plusieurs aspects de sécurité incluant l'authentification, l'autorisation, et la confidentialité. L'authentification et la confidentialité peuvent être réalisées en utilisant MIME sécurisé (S/MIME) [RFC5750], [RFC5751], qui utilise le cadre de sécurité multiparties pour MIME [RFC1847].

 	2.2.1	Autorisation
Dans les messages iTIP [RFC5546], seul l'"Organisateur" est autorisé à modifier ou annuler les entrées de calendrier qu'il organise. C'est-à-dire, spoof@xyz.exemple.net n'a pas la permission de modifier ou annuler une réunion qui a été organisée par a@exemple.com. De plus, seul celui qui répond a l'autorisation d'indiquer son état à l'"Organisateur". C'est-à-dire, l'"Organisateur" DOIT ignorer un message iTIP venant de spoof@xyz.exemple.net qui refuse une invitation à une réunion pour b@exemple.com.

Les mises en œuvre de iMIP DEVRAIENT vérifier l'authenticité du créateur d'un objet iCalendar avant d'entreprendre une action. Les méthodes pour ce faire sont présentées plus loin dans ce document.

Le flux de messages de la [RFC1847] dans iTIP prend en charge quelqu'un qui travaille au nom d'un "Utilisateur de calendrier" par l'utilisation du paramètre "sent-by" qui est associé aux propriétés "ATTENDEE" et "ORGANIZER". Cependant, il n'y a pas de mécanisme pour vérifier si un "Utilisateur de calendrier" a autorisé ou non quelqu'un à travailler en son nom. Il appartient aux mises en œuvre de fournir des mécanismes pour que "l'Utilisateur de calendrier" prenne cette décision.

 	2.2.2	Authentification
L'authentification DOIT être effectuée en utilisant S/MIME [RFC5750], [RFC5751]. L'authentification n'est possible que sur les messages qui ont été signés. Les messages non authentifiés (c'est-à-dire, les messages non signés) ne peuvent pas être de confiance.

 	2.2.3	Confidentialité
Pour assurer la confidentialité en utilisant iMIP, les mises en œuvre DEVRAIENT utiliser le chiffrement spécifié dans S/MIME [RFC5750], [RFC5751]. iMIP n'interdit pas à un agent d'utilisateur de calendrier (CUA, Calendar User Agent) de transmettre des objets iCalendar à d'autres utilisateurs ou agents.

 	2.3	Adresses de messagerie électronique
L'adresse de calendrier spécifiée dans les propriétés "ORGANIZER" et "ATTENDEE" dans un objet iCalendar envoyé en utilisant iMIP DOIT être une spécification d'URI "mailto:" [RFC6068] appropriée pour l'"Organisateur" ou "Participant" correspondant de "VEVENT" ou "VTODO".

Parce que la [RFC5546] n'interdit pas aux "Participants" de transmettre des "VEVENT" ou "VTODO" aux autres, la valeur "Sender" de la [RFC5322] ne peut pas être égale à celle de l'"Organisateur". De plus, l'"Organisateur" ou "Participant" ne peut pas être fiablement déduit des valeurs de champ d'en-tête "Sender" ou "Reply-To" de la [RFC5322] d'un message iMIP. L'adresse pertinente DOIT être certifiée en ouvrant la partie de corps "text/calendar" MIME et en examinant les propriétés "ATTENDEE" et "ORGANIZER".

 	2.4	Champ d'en-tête Content-Type
Une partie de corps MIME contenant des informations de contenu qui se conforment au présent document DOIT avoir une valeur de "Content-Type" [RFC2045] de "text/calendar". Le champ d'en-tête "Content-Type" de la [RFC2045] DOIT aussi inclure le paramètre MIME "method". La valeur DOIT être la même (en ignorant la casse) que la valeur de la propriéte "METHOD" au sein de l'objet iCalendar.

Note 1 : un message MIME qui contient pusieurs objets iCalendar avec des valeurs différentes de "method" DOIT de plus être encapsulé avec une entité "multipart/mixed" MIME [RFC2046]. Cela permet que chaque objet iCalendar soit encapsulé dans sa propre entité "text/calendar" MIME.

Note 2 : une partie de corps MIME avec une valeur de "Content-Type" de "text/calendar" qui n'a pas de paramètre "method" n'est pas considérée comme étant une partie de corps iMIP et n'est donc pas soumise aux exigences spécifiées dans le présent document.

Noter que selon la [RFC5545] le jeu de caractères par défaut pour les objets iCalendar est UTF-8 [[RFC3629]. Cependant, le jeu de caractères par défaut pour une entité "text/*" MIME selon la [RFC2046] est US-ASCII. Donc, un paramètre "charset" MIME DOIT être présent si l'objet iCalendar contient des caractères qui ne peuvent pas être représentés dans le jeu de caractères US-ASCII et, comme spécifié dans la [RFC5545], il DOIT avoir la valeur "UTF-8".

Le paramètre facultatif "component" MIME définit le type de composant iCalendar contenu dans l'objet iCalendar.

Voici un exemple de ce champ d'en-tête avec une valeur qui indique un message d'événement :

Content-Type: text/calendar; method=REQUEST; charset=UTF-8; component=vevent

Le type de contenu "text/calendar" permet que le type de message de programmation soit inclus dans un message MIME avec d'autres informations de contenu (c'est-à-dire, "multipart/mixed") ou inclus dans un message MIME avec un texte en clair, lisible par l'homme, du message de programmation (c'est-à-dire, "multipart/alternative" [RFC2046]).

Afin de permettre que les informations dans le message de programmation soient comprises par les agents d'utilisateur MIME (UA, User Agent) qui ne prennent pas en charge le type de contenu "text/calendar", les messages de programmation DEVRAIENT être envoyés avec une autre forme des informations, lisibles par l'homme.

Noter que "multipart/alternative" NE DOIT PAS être utilisé pour représenter deux objets iCalendar légèrement différents, par exemple, deux "VEVENT" avec des temps de début alternés.

Les CUA peuvent utiliser d'autres paramètres MIME de champ d'en-tête "Content-Type", ainsi qu'un langage spécifié dans le champ d'en-tête Content-Language [RFC3282], pour prendre une partie "text/calendar" pour le traitement si un message "multipart/alternative" MIME contient plus d'une partie "text/calendar".

Tout UA receveur conforme à la présente spécification DOIT être capable de traiter les parties de corps "text/calendar" encloses dans un "multipart/*". Noter qu'un message MIME "multipart/mixed" peut inclure plusieurs composants "text/calendar". L'UA receveur DOIT être capable de les traiter tous.

 	2.5	Champ d'en-tête Content-Transfer-Encoding
Sauf si un message iMIP est transporté sur un transport 8-bits (comme SMTP [RFC1652]) un codage de transfert comme quoted-printable ou base64 [RFC2045] DOIT être utilisé pour les objets iCalendar contenant tout caractère qui ne peut pas être représenté dans le jeu de caractères US-ASCII. Par exemple :

From: user1@exemple.com
To: user2@exemple.com
Subject: Conférence téléphonique
Mime-Version: 1.0
Date: mercredi 07 mai 2008 21:30:25 +0400
Message-ID: <4821E731.5040506@laptop1.exemple.com>
Content-Type: text/calendar; method=REQUEST; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

BEGIN:VCALENDAR
PRODID:-//Exemple/ExempleCalendarClient//FR
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:user1@exemple.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:user1@exemple.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@exemple.com
DTSTAMP:20080507T170000Z
DTSTART:20080701T160000Z
DTEND:20080701T163000Z
SUMMARY:appel téléphonique pour discuter de votre récente visite
DESCRIPTION:=D1=82=D1=8B =D0=BA=D0=B0=D0=BA - =D0=B4=D0=BE=D0=    =B2=D0=BE=D0=BB=D0=B5=D0=BD=D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0=BE=D0=B9?
UID:calsvr.exemple.com-8739701987387998
SEQUENCE:0
STATUS:TENTATIVE
END:VEVENT
END:VCALENDAR

 	2.6	Champ d'en-tête Content-Disposition
Les mises en œuvre PEUVENT inclure un champ d'en-tête "Content-Disposition" pour définir un nom de fichier pour un objet iCalendar. Cependant, le traitement d'une partie MIME DOIT se fonder sur son "Content-Type" et non sur l'extension spécifiée dans le "Content-Disposition", car différents malgiciels de messagerie électronique sont connus pour amener les agents d'utilisateur à mal interpréter le contenu des messages en spécifiant une extension de fichier dans le champ d'en-tête  Content-Disposition qui ne correspond pas à la valeur du champ d'en-tête "Content-Type".

 	3.	Considérations sur la sécurité

Les menaces pour la sécurité auxquelles les applications doivent faire face lors de la mise en œuvre de iTIP sont détaillées dans la [RFC5546]. En particulier, deux menaces d'usurpation d'identité sont identifiées au paragraphe 6.1 de la [RFC5546]  : celle de l'identité de l'"Organisateur", et ce celle d'un "Participant". Pour traiter ces menaces, le générateur d'un objet iCalendar doit être authentifié par un receveur. Une fois authentifié, une détermination peut être faite de si le générateur est ou non autorisé à effectuer l'opération demandée. Les applications conformes DOIVENT prendre en charge la signature et le chiffrement des parties de corps "text/calendar" en utilisant un mécanisme fondé sur S/MIME [RFC5750], [RFC5751] afin de faciliter l'authentification du générateur de l'objet iCalendar (paragraphes 2.2.2 et 2.2.3). Les étapes du traitement d'un message iMIP signé sont décrites ci-dessous :

1.	En utilisant S/MIME, déterminer qui a signé la partie de corps "text/calendar" contenant l'objet iCalendar. C'est le "signataire". (Noter que l'adresse de messagerie électronique du signataire DOIT être spécifiée dans le champ rfc822Name de l'extension "autre nom de sujet" du certificat du signataire, comme spécifié au paragraphe 4.1.2.6 de la [RFC5280]). Noter que le signataire n'est pas nécessairement la personne qui envoie un message électronique, car il peut être transmis.

2.	Corréler le signataire à une propriété "ATTENDEE" ou à la propriété "ORGANIZER" dans l'objet iCalendar, sur la base de la méthode et du composant de calendrier spécifiés dans l'objet iCalendar, comme défini au paragraphe 1.4 de la [RFC5546]. Si le signataire ne peut pas être corrélé à une propriété "ATTENDEE"/"ORGANIZER", l'utilisateur qui contrôle "l'agent d'utilisateur de calendrier" doit être averti de manière active que l'objet iCalendar n'est pas de confiance, et encourager l'utilisateur à ignorer le message, mais on doit donner aux utilisateurs avertis l'option de (a) voir le certificat du signataire et la chaîne entière de certificats (si il en est) afin d'aider à décider si le signataire devrait être tenu pour l'envoyeur du message, et (b) permettre au CUA d'accepter et traiter l'objet iCalendar.

3.	Déterminer si le "ATTENDEE"/"ORGANIZER" est autorisé ou non à effectuer l'opération comme défini dans la [RFC5546]. Si les conditions ne sont réunies, ignorer le message.

4.	Si toutes les conditions ci-dessus sont satisfaites, le message peut être traité.

La signature S/MIME protège aussi contre les changements malveillants de messages en transit.

Si la confidentialité du calendrier est requise par l'envoyeur, les messages iMIP signés DEVRAIENT être chiffrés par un mécanisme fondé sur S/MIME [RFC5750], [RFC5751]. Si iMIP est utilisé au sein d'un seul domaine de gestion administrative (ADMD, ADministrative Management Domain) [RFC5598], le STARTTLS de SMTP [RFC3207] (avec le STARTTLS dans IMAP/POP [RFC2595]) PEUT aussi être utilisé pour assurer la confidentialité de calendrier.

Une fois qu'un message iMIP signé et/ou chiffré est reçu et vérifié avec succès (comme détaillé ci-dessus) par un CUA, le CUA DEVRAIT se souvenir de si l'envoyeur du message utilise la signature et/ou le chiffrement. Si un message iMIP non signé est reçu ultérieurement du même envoyeur, le CUA receveur DEVRAIT avertir l'utilisateur receveur d'une possible attaque par interposition et DEVRAIT ignorer le message, sauf décision contraire explicite de l'utilisateur.

Les mises en œuvre PEUVENT fournir des moyens pour que les utilisateurs désactivent la signature et le chiffrement.

Il est possible de recevoir des messages iMIP envoyés par quelqu'un qui travaille au nom d'un autre "Utilisateur de calendrier". Ceci est déterminé en examinant le paramètre "sent-by" dans la proprités "ORGANIZER" ou "ATTENDEE" pertinente. La [RFC5545] et la [RFC5546] ne fournissent pas de mécanisme pour vérifier qu'un "Utilisateur de calendrier" a autorisé quelqu'un d'autre à travailler en son nom. Pour traiter ce problème de sécurité, les mises en œuvre DOIVENT fournir des mécanismes pour que les "Utilisateurs de calendriers" prennent cette décision avant d'appliquer des changements provenant de quelqu'un qui travaille au nom d'un "Utilisateur de calendrier". Une façon de réaliser cela est de rejeter les messages iMIP envoyés par des utilisateurs autres que le "ORGANIZER" ou les "ATTENDEE". Autrement, le receveur pourrait avoir une liste des mandataires <sent-by, organizer> de confiance dans sa politique de sécurité locale. Et encore une autre façon est d'inviter l'utilisateur à donner confirmation.

Le calendrier fondé sur iMIP est fréquemment déployé au sein d'un seul ADMD, avec un filtrage de frontière employé pour restreindre les flux de messagerie de calendrier à l'intérieur de l'ADMD. Cela peut aider à minimiser les changements malveillants des messages de calendrier en transit, ainsi qu'à rendre les décisions d'autorisation moins risquées.

Une considération de sécurité associée à l'utilisation du champ d'en-tête Content-Disposition est décrite au paragraphe 2.6.

L'utilisation de S/MIME rend les considérations de sécurité discutées dans les [RFC5750] [RFC5751] pertinentes pour le présent document. Pour des considérations de sécurité supplémentaires concernant la vérification de certificat et de liste de révocation de certificat, voir la [RFC5280].

 	4.	Exemples
 	4.1	Un seul composant avec une propriété ATTACH
Ce message minimal montre comment un objet iCalendar se réfère à une pièce jointe. La  pièce jointe est accessible via son URL.

From: sman@netscape.exemple.com
To: stevesil@microsoft.exemple.com
Subject: Conférence téléphonique
Mime-Version: 1.0
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit

BEGIN:VCALENDAR
PRODID:-//Exemple/ExempleCalendarClient//FR
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:man@netscape.exemple.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:man@netscape.exemple.com
ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.exemple.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SUMMARY:Conférence téléphonique
DESCRIPTION:Prière de relire le document joint.
UID:calsvr.exemple.com-873970198738777
ATTACH:ftp://ftp.bar.exemple.com/pub/docs/foo.doc
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

 	4.2	Utilisation de multipart/alternative pour des clients à faible fidélité
Cet exemple montre comment un client peut émettre un message multi parties qui inclut une version de texte en clair et l'objet iCalendar complet. Les clients qui ne prennent pas en charge "text/calendar" vont quand même être capables de rendre la représentation de texte en clair.

From: foo1@exemple.com
To: foo2@exemple.com
Subject: Conférence téléphonique
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="01BD3665.3AF0D360"

--01BD3665.3AF0D360
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Voici une autre représentation d'un objet MIME "text/calendar" :

Quand: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT
où:
Organisateur: foo1@exemple.com
Sommaire: Conférence téléphonique

--01BD3665.3AF0D360
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit

BEGIN:VCALENDAR
PRODID:-//Exemple/ExempleCalendarClient//FR
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@exemple.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@exemple.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@exemple.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T170000Z
DTEND:19970701T173000Z
SUMMARY: Conférence téléphonique
UID:calsvr.exemple.com-8739701987387771
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
--01BD3665.3AF0D360

 	4.3	Un seul composant avec une propriété ATTACH et un rattachement en ligne
Cet exemple montre comment un message contenant un objet iCalendar fait référence à un document joint. La référence est faite en utilisant un identifiant de contenu (CID, Content-ID). Donc, l'objet iCalendar et le document sont conditionnés dans une encapsulation "multipart/related".

From: foo1@exemple.com
To: foo2@exemple.com
Subject: Conférence téléphonique
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-exemple-1"

--boundary-exemple-1

Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"

BEGIN:VCALENDAR
PRODID:-//Exemple/ExempleCalendarClient//FR
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@exemple.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@exemple.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@exemple.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T180000Z
DTEND:19970701T183000Z
SUMMARY: Conférence téléphonique
UID:calsvr.exemple.com-8739701987387771
ATTACH:cid:123456789@exemple.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

--boundary-exemple-1
Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="FieldReport.doc"
Content-ID: <123456789@exemple.com>

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAAAAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////...
--boundary-exemple-1--

 	4.4	Composants similaires multiples
Plusieur composants iCalendar du même type peuvent être inclus dans l'objet iCalendar quand la "METHOD" est la même pour chaque composant.

From: foo1@exemple.com
To: foo2@exemple.com
Subject: Summer Company Holidays
Mime-Version: 1.0
Content-Type: text/calendar; method=PUBLISH; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:PUBLISH
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@exemple.com
DTSTAMP:19970611T150000Z
DTSTART:19970701T150000Z
DTEND:19970701T230000Z
SUMMARY:Company Picnic
DESCRIPTION:Food et drink will être provided
UID:calsvr.exemple.com-873970198738777-1
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
ORGANIZER:mailto:foo1@exemple.com
DTSTAMP:19970611T190000Z
DTSTART:19970715T150000Z
DTEND:19970715T230000Z
SUMMARY:Company Bowling Tournament
DESCRIPTION:We have 10 lanes reserved
UID:calsvr.exemple.com-873970198738777-2
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

 	4.5	Composants mixtes multiples
Des types de composants différents doivent être encapsulés dans des objets iCalendar séparés.

From: foo1@exemple.com
To: foo2@exemple.com
Subject: Conférence téléphonique
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="--FEE3790DC7E35189CA67CE2C"

C'est un message multi parties en format MIME.

----FEE3790DC7E35189CA67CE2C
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event1.ics"

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@exemple.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@exemple.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@exemple.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SUMMARY:Phone Conference
DESCRIPTION:Discuss what happened at the last meeting
UID:calsvr.exemple.com-8739701987387772
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

----FEE3790DC7E35189CA67CE2C
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="todo1.ics"

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VTODO
DUE:19970701T160000Z
ORGANIZER:mailto:foo1@exemple.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@exemple.com
ATTENDEE;RSVP=YES:mailto:foo2@exemple.com
SUMMARY:Phone Conference
DESCRIPTION:Discuss a new location for the company picnic
UID:calsvr.exemple.com-td-8739701987387773
SEQUENCE:0
STATUS:NEEDS-ACTION
END:VEVENT
END:VCALENDAR

----FEE3790DC7E35189CA67CE2C

 	4.6	Composants détaillés avec une propriété ATTACH
Cet exemple montre le format d'un message contenant une réunion de groupe entre trois individus. L'encapsulation "multipart/related" est utilisée parce que l'objet iCalendar contient une propriété ATTACH qui utilise un CID pour faire référence à la pièce jointe.

From: foo1@exemple.com
MIME-Version: 1.0
To: foo2@exemple.com,foo3@exemple.com
Subject: REQUEST – Conférence téléphonique
Content-Type: multipart/related; boundary="--FEE3790DC7E35189CA67CE2C"

----FEE3790DC7E35189CA67CE2C
Content-Type: multipart/alternative; boundary="--00FEE3790DC7E35189CA67CE2C00"

----00FEE3790DC7E35189CA67CE2C00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Quand: 7/1/1997 10:00PM PDT - 7/1/97 10:30 PM PDT
où:
Organisateur: foo1@exemple.com
Sommaire: Discutons du document joint

----00FEE3790DC7E35189CA67CE2C00

Content-Type: text/calendar; method=REQUEST; charset=US-ASCII; Component=vevent
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"

BEGIN:VCALENDAR
PRODID:-//Exemple/ExempleCalendarClient//FR
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:foo1@exemple.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:foo1@exemple.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@exemple.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo3@exemple.com
DTSTAMP:19970611T190000Z
DTSTART:19970621T170000Z
DTEND:199706211T173000Z
SUMMARY: Discutons du document joint
UID:calsvr.exemple.com-873970198738777-8aa
ATTACH:cid:calsvr.exemple.com-12345aaa
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
----00FEE3790DC7E35189CA67CE2C00

----FEE3790DC7E35189CA67CE2C
Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="FieldReport.doc"
Content-ID: <calsvr.exemple.com-12345aaa>

R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94Xq
AG4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvd
riIH5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5i
ZnJY6J
...

----FEE3790DC7E35189CA67CE2C

 	5.	Pratiques recommandées

Cette Section mentionne une série de pratiques recommandées quand un transport de messagerie est utilisé pour échanger des objets iCalendar.

 	5.1	Utilisation des identifiants de contenu et de message
La [RFC5545] fait un usage fréquent des URI pour les types de données dans des propriétés telles que "DESCRIPTION", "ATTACH", "CONTACT", et autres. Deux formes d'URI sont l'identifiant de message (MID, Message ID) et l'identifiant de contenu (CID, Content-ID). Ils sont définis dans la [RFC2392]. Bien que la [RFC2392] permette les références aux messages ou parties de corps MIME dans d'autres entités ou mémorisations MIME, il est fortement RECOMMANDÉ que les mises en œuvre iMIP incluent tous les messages et parties de corps référencés dans une seule entité MIME. Dit simplement, si un objet iCalendar contient des références CID ou MID à d'autres messages ou parties de corps, les mises en œuvre devraient s'assurer que ces messages et/ou parties de corps sont transmis avec l'objet iCalendar. Si ils ne le sont pas, il n'est pas garanti que le CUA receveur aura accès à ces objets ou aura l'autorisation de les voir.

 	6.	Considérations relatives à l'IANA

Le type de support MIME "text/calendar" a été enregistré dans la [RFC5545].

 	7.	Références
 	7.1	Références normatives

[RFC1847]	J. Galvin, S. Murphy, S. Crocker, N. Freed, "Sécurité multiparties pour MIME : multipartie/signée et multipartie/chiffrée", octobre 1995. (P.S.)

[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2046]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support", novembre 1996. (D. S., MàJ par 2646, 3798, 5147, 6657, 8098)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2392]	E. Levinson, "Localisateur de ressource uniforme d'identifiant de contenu et d'identifiant de message", août 1998. (P.S.)

[RFC2595]	C. Newman, "Utilisation de TLS avec IMAP, POP3 et ACAP", juin 1999. (MàJ par RFC4616, 7817, 8314) (P.S.)

[RFC3207]	P. Hoffman, "Extension de service SMTP pour un SMTP sécurisé sur TLS", février 2002. (P.S., MàJ par RFC7817)

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003.

[RFC5280]	D. Cooper et autres, "Profil de certificat d'infrastructure de clé publique X.509 et de liste de révocation de certificat (CRL) pour l'Internet", mai 2008. (Remplace les RFC3280, RFC4325, RFC4630) (P.S. ; MàJ par RFC8398, 8399)

[RFC5322]	P. Resnick, éd., "Format du message Internet", octobre 2008. (Remplace RFC2822) (MàJ RFC4021) (D.S.)

[RFC5545]	B. Desruisseaux, "Spécification de calendrier Internet et d'objet central de programmation (iCalendar)", septembre  2009. (Remplace RFC2446, MàJ par RFC5546, 7529, 7953, 7986) (P. S)

[RFC5546]	C. Daboo, Ed., "Protocole iCalendar d'inter fonctionnement indépendant du transport (iTIP)", décembre 2009. (Remplace RFC2446, MàJ RFC5545) (P. S.) (MàJ par la RFC6637)

[RFC5750]	B. Ramsdell, S. Turner, "Traitement du certificat des extensions de messagerie Internet multi objets sécurisée (S/MIME) version 3.2", janvier 2010. (Remplace RFC3850). (P. S. ; Remplacée par RFC8550)

[RFC5751]	B. Ramsdell, S. Turner, "Spécification du message des extensions de messagerie Internet multi objets sécurisée (S/MIME) version 3.2", janvier 2010. (Remplace RFC3851). (P. S. ; Remplacée par RFC8551)

[RFC6068]	M. Duerst, L. Masinter, J. Zawinski, "Schéma d'URI 'mailto'", octobre 2010. (Remplace la RFC2368) (P.S.) 

 	7.2	Référence pour information

[RFC1652]	J. Klensin et autres, "Extensions de service SMTP pour transport MIME sur 8 bits", juillet 1994. (Remplacée par RFC6152) (D.S.)

[RFC3282]	H. Alvestrand, "En-têtes de langage de contenu", mai 2002. (D.S.)

[RFC5598]	D. Crocker, "Architecture de la messagerie Internet", juillet 2009. (Information) 

 	Appendice A. Changements depuis la RFC 2447

Mise à jour des références. Elles sont partagées en normatives et pour information.
Mise à jour des exemples pour utiliser les domaines exemple.com/exemple.net.
Correction de l'usage du langage de la RFC 2119.
Précision que charset=UTF-8 est exigé, sauf si le calendrier peut être entièrement représenté en US-ASCII.
Précision que les codages de transfert de contenu de 7 bits devraient être utilisés sauf si il est connu que l'objet de calendrier est transféré sur un transport 8 bits pur.
Précision que les extensions de fichier spécifiées dans le champ d'en-tête Content-Disposition ne sont pas à utiliser pour outrepasser le type MIME "Content-Type".
Interdiction de l'utilisation de "multipart/alternative" pour des représentations légèrement différentes du même calendier.
Précision du traitement du paramètre MIME "method" du champ d'en-tête "Content-Type".
Précision que dans un message iMIP une propriété ORGANIZER/ATTENDEE contient un URI mailto:.
Correction des exemples avec la propriété ATTENDEE pour utiliser "CUTYPE=" à la place de "TYPE=".
Précision que l'intégrité/confidentialité de message devrait être réalisée avec S/MIME.
Fourniture d'exemples supplémentaires.
Amélioration de la Section Considérations sur la sécurité.
Divers changements rédactionnels dans différentes sections du document.

 	Appendice B.	Remerciements

L'éditeur de ce document souhaite remercier Frank Dawson, Steve Mansour, et Steve Silverberg, les auteurs originaux de la RFC 2447, ainsi que les personnes suivantes qui ont participé au projet, à la relecture, et à la discussion du présent mémoire  : Reinhold Kainhofer, Cyrus Daboo, Bernard Desruisseaux, Eliot Lear, et Peter Saint-Andre.

 	Adresse de l'éditeur
Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex  TW12 2BX
UK
mél : Alexey.Melnikov@isode.com