Groupe de travail Réseau	G. Camarillo, Ericsson	
Request for Comments: 5621	septembre 2009	
RFC mises à jour : 3204, 3261, 3459		
Catégorie : Sur la voie de la normalisation		
Traduction Claude Brière de L'Isle		

Traitement du corps de message dans le protocole d'initialisation de session (SIP)

Résumé
Le présent document spécifie comment les corps de message sont trtaités dans SIP. De plus, le présent document spécifie la prise en charge par l'agent d'utilisateur SIP des extensions multi-objets de messagerie Internet (MIME, Multipurpose Internet Mail Extensions) dans les corps de message.

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 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. 

Table des matières
1. Introduction	2
2. Terminologie	2
3. Codage de corps de message	2
3.1 Fondements du codage de corps de message	2
3.2 Comportement d'UA pour coder les corps de messages binaires	3
4. Corps de message "multipart"	3
4.1 Fondements des corps de message "multipart"	4
4.2 Prise en charge obligatoire des corps de message "multipart"	4
4.3 Comportement de l'UA pour générer des corps de message "multipart"	4
5. Corps de message "multipart/mixed"	4
6. Corps de message "multipart/alternative"	5
6.1 Fondements des corps de message "multipart/alternative"	5
6.2 Comportement d'UA pour générer des corps de message "multipart/alternative"	5
6.3 Comportement d'UA pour traiter des corps de message "multipart/alternative"	5
7. Corps de message "multipart/related"	5
7.1 Fondements des corps de message "multipart/related"	5
7.2 Comportement d'UA pour générer des corps de message "multipart/related"	6
7.3 Comportement d'UA pour traiter des corps de message "multipart/related"	6
8. Types de disposition	6
8.1 Fondements sur les types de contenu et de disposition dans SIP	6
8.2 Comportement de l'UA pour régler le paramètre "handling"	7
8.3 Comportement de l'UA pour traiter "multipart/alternative"	8
8.4 Comportement de l'UAS pour rapporter des corps de message non pris en charge	8
9. Traitement du corps de message	8
9.1 Fondements sur les références aux parties de corps de message	8
9.2 Comportement d'UA pour générer des références aux corps de message	8
9.3 Comportement d'UA pour traiter des corps de message	8
9.4 Type de disposition "by-reference"	9
10. Lignes directrices pour les auteurs d'extensions à SIP	9
11. Considérations sur la sécurité	9
12. Considérations relatives à l'IANA	10
12.1 Enregistrement du type de disposition "by-reference"	10
12.2 Mise à jour de l'enregistrement du paramètre "handling"	10
13. Remerciements	10
14. Références	10
14.1 Références normatives	10
14.2 Références pour information	11
Adresse de l'auteur	11

 	1.	Introduction

Le traitement du corps de message dans SIP était à l'origine spécifié dans la [RFC3261], qui s'appuyait sur des spécifications antérieures (par exemple, MIME) pour décrire certains domaines. Le présent document contient des matériaux de base sur la façon dont les corps sont traités dans SIP et du matériel normatif sur les domaines qui n'ont pas été spécifiés avant ou dont les spécifications doivent être complétées. Les paragraphes qui contiennent des matériaux de base sont clairement identifiés comme tels par leur titre. Le matériel des sections normatives se fonde sur l'expérience obtenue depuis la rédaction de la [RFC3261]. Les développements doivent mettre en œuvre ce qui est spécifié dans la [RFC3261] (et ses références) en plus de ce qui est spécifié dans le présent document.

 	2.	Terminologie

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 abréviations suivantes sont utilisées dans le présent document.
UA (User Agent) : agent d'utilisateur
UAC (User Agent Client) : client d'agent d'utilisateur
UAS (User Agent Server) : serveur d'agent d'utilisateur
URL (Uniform Resource Locator) : localisateur de ressource universelle

 	3.	Codage de corps de message

Cette section traite du codage des corps de message dans SIP.

 	3.1	Fondements du codage de corps de message
Les messages SIP [RFC3261] consistent en une ligne initiale (ligne de demande dans les demandes et ligne d'état dans les réponses) un ensemble de champs d'en-tête, et un corps de message facultatif. Le corps de message est décrit en utilisant les champs d'en-tête comme Content-Disposition, Content-Encoding, et Content-Type, qui fournissent des informations sur son contenu. La Figure 1 montre un message SIP qui porte un corps. Certains des champs de l'en-tête ne sont pas montrés au nom de la simplicité :

INVITE sip:conf-fact@exemple.com SIP/2.0
Content-Type: application/sdp
Content-Length: 192

v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.exemple.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000

Figure 1 : Message SIP portant un corps

Le corps de message d'un message SIP peut être divisé en diverses parties de corps. Les corps de message multi parties sont codés en utilisant le format des extensions multi-objets de messagerie Internet (MIME, Multipurpose Internet Mail Extensions) [RFC2045]. Les parties de corps sont aussi décrites en utilisant des champs d'en-tête comme Content-Disposition, Content-Encoding, et Content-Type, qui fournissent des informations sur le contenu d'une partie de corps particulière. La Figure 2 montre un message SIP qui porte deux parties de corps. Certains champs de l'en-tête ne sont pas montrés pour simplifier :

INVITE sip:conf-fact@exemple.com SIP/2.0
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 619

--boundary1
Content-Type: application/sdp

v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.exemple.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000

--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="sip:bill@exemple.com"/>
<entry uri="sip:randy@exemple.net"/>
<entry uri="sip:joe@exemple.org"/>
</list>
</resource-lists>
--boundary1--

Figure 2 : Message SIP portant un corps

SIP utilise S/MIME [RFC3851] pour protéger les corps de message. Comme spécifié dans la [RFC3261], les UAS qui ne peuvent pas déchiffrer un corps de message ou une partie de corps peuvent utiliser la réponse 493 (Indéchiffrable) pour rapporter l'erreur.

 	3.2	Comportement d'UA pour coder les corps de messages binaires
Les messages SIP peuvent porter des corps de message binaires comme des objets de signalisation traditionnels [RFC3204]. Les serveurs mandataires SIP sont en 8 bits sûr. C'est-à-dire, ils sont capables de traiter des corps binaires. Donc, il n'est pas besoin d'utiliser des codages comme le base64 pour transporter des corps binaires dans les messages SIP.  Par conséquent, les UA DEVRAIENT utiliser le codage de transfert binaire [RFC4289] pour toutes les charges utiles dans SIP, y compris les charges utiles binaires. Le seul cas où un UA PEUT utiliser un codage différent est quand il transfère des données d'application entre des applications qui traitent seulement un codage différent (par exemple, base64).

 	4.	Corps de message "multipart"

Cette section discute des corps de message "multi parties" et de leur traitement.

 	4.1	Fondements des corps de message "multipart"
La [RFC3261] ne rend pas obligatoire la prise en charge des corps de message "multi parties" dans le format MIME [RFC2046]. Cependant, depuis la rédaction de la [RFC3261], de nombreuses extensions de SIP reposent sur eux.

L'utilisation de corps MIME "multipart/mixed" est un outil utile pour construire des extensions à SIP. Un exemple d'une telle extension pourrait être l'inclusion d'informations de localisation dans une demande INVITE. Une telle demande INVITE utiliserait le type MIME "multipart/mixed" de la [RFC2046] pour porter deux parties de corps : une description de session et un objet de localisation. Un exemple d'une extension existante qui utilise "multipart/mixed" pour envoyer une description de session et un objet de signalisation traditionnel est défini dans la [RFC3204].

Un autre type MIME qui est utile pour construire des extensions SIP est "multipart/alternative" [RFC2046]. Chaque partie de corps au sein d'une "multipart/alternative" porte une version de remplacement des mêmes informations.

La transition de SDP à de nouveaux protocoles de description de session pourrait être mise en œuvre en utilisant des  corps "multipart/alternative". Les messages SIP (par exemple, des demandes INVITE) pourraient porter un corps "multipart/alternative" avec deux parties de corps : une description de session écrite en SDP et une description écrite dans un format de description de session plus récent. Les UA de receveur traditionnels vont utiliser la description de session écrite en SDP. Les nouveaux UA receveurs vont utiliser celle écrite dans le format le plus récent.

Les corps MIME incorporés sont déjà un autre outil utile pour construire et combiner les extensions SIP. En utilisant les extensions des exemples précédents, un UA qui prend en charge un nouveau format de description de session et qui a besoin d'inclure un objet de localisation dans une demande INVITE va inclure un corps "multipart/mixed" avec deux parties de corps : un objet de localisation et un "multipart/alternative". La partie de corps "multipart/alternative" va, à son tour, avoir deux parties de corps : une description de session écrite en SDP et une description de session écrite dans le nouveau format de description de session.

 	4.2	Prise en charge obligatoire des corps de message "multipart"
Pour que toutes les extensions fondées sur MIME fonctionnent, le receveur doit être capable de décoder les corps multi parties. Donc, les UA SIP DOIVENT prendre en charge l'analyse des corps MIME "multipart", y compris les parties de corps incorporées. De plus, les UA DOIVENT prendre en charge les types MIME "multipart/mixed' et "multipart/alternative". La prise en charge d'autres types MIME comme "multipart/related" est FACULTATIVE.

Noter que, par défaut, les sous types "multipart" inconnus sont traités comme "multipart/mixed". Noter aussi que les extensions SIP peuvent aussi inclure des corps MIME "multipart" dans les réponses. C'est pourquoi les UAC et les UAS doivent tous deux prendre en charge les corps "multipart".

Les UA SIP traditionnels sans soutien de corps "multipart" génèrent une réponse 415 (Type de support non pris en charge) quand ils reçoivent un corps "multipart" dans une demande. Un UAC qui envoie un corps "multipart" peut recevoir une telle réponse d'erreur quand il communique avec un UA SIP traditionnel d'avant la présente spécification.

Il a été observé sur le terrain qu'un certain nombre d'UA SIP traditionnels sans soutien des corps "multipart" ignorent simplement ces corps quand ils en reçoivent. Ces UA ne retournent aucune réponse d'erreur. Sans surprise, les UA SIP qui ne sont pas capables de rapporter ce type d'erreur ont causé de sérieux problèmes d'interopérabilité dans le passé.

 	4.3	Comportement de l'UA pour générer des corps de message "multipart"
Les UA DEVRAIENT éviter d'incorporer sans nécessité des parties de corps parce que le faire rend le traitement du corps plus laborieux pour le receveur. Cependant, la [RFC2046] déclare qu'un type de support "multipart" avec une seule partie de corps est utile dans certaines circonstances (par exemple, pour envoyer des types de supports non de texte). Dans tous les cas, les UA NE DEVRAIENT PAS incorporer une "multipart/mixed" dans une autre sauf si il y a besoin de référencer celle qui est incorporée (c'est-à-dire, en utilisant l'identifiant de contenu de la partie de corps incorporée). De plus, les UA NE DEVRAIENT PAS incorporer une "multipart/alternative" dans une autre.

Noter que les UA qui reçoivent des parties de corps incorporées sans nécessité les traitent comme si elles n'étaient pas incorporées.

 	5.	Corps de message "multipart/mixed"

Cette section ne spécifie pas de comportement supplémentaire sur la façon de générer et traiter les corps "multipart/mixed". Elle est simplement incluse pour être complet.

 	6.	Corps de message "multipart/alternative"

Cette section discute des corps de message "multipart/alternative" et de leur traitement.

 	6.1	Fondements des corps de message "multipart/alternative"
Chaque partie de corps au sein d'une "multipart/alternative" porte une version de remplacement des mêmes informations. Les parties de corps sont ordonnées de façon à ce que la dernière ait la plus riche représentation de l'information. Le receveur d'un corps "multipart/alternative" choisit la dernière partie de corps qu'il comprend.

Noter qu'au sein d'une partie de corps codée dans un format donné (c'est-à-dire, d'un type de contenu donné) il peut y avoir des éléments facultatifs qui peuvent fournir de plus riches informations au receveur dans le cas où le receveur les prend en charge. Par exemple, dans le protocole de description de session (SDP, Session Description Protocol) [RFC4566], ces éléments facultatifs sont codés dans des lignes "a". Ces types d'éléments facultatifs sont internes à une partie de corps et ne sont pas visibles au niveau MIME. C'est-à-dire, une partie de corps est comprise si le receveur comprend son type de contenu, sans considération de si les éléments facultatifs de la partie de corps sont ou non compris.

Noter aussi que chaque partie d'un corps "multipart/alternative" représente les mêmes données, mais la transposition entre deux parties quelconques n'est pas nécessairement sans perte d'informations. Par exemple, des informations peuvent être perdues quand on traduit du "text/html" en "text/plain". La [RFC2046] recommande que chaque partie devrait avoir une valeur d'identifiant de contenu différente dans le cas où le contenu d'information des deux parties n'est pas identique.

 	6.2	Comportement d'UA pour générer des corps de message "multipart/alternative"
Le paragraphe 8.2 rend obligatoire que les parties de corps de niveau supérieur au sein d'un "multipart/alternative" aient le même type de disposition.

Les types de disposition "session" et "early-session" [RFC3959] exigent que toutes les parties de corps d'un corps "multipart/alternative" aient des types de contenu différents. Par conséquent, pour les types de disposition "session" et "early-session", les UA NE DOIVENT PAS placer plus d'une partie de corps avec un type de contenu donné dans un corps "multipart/alternative". C'est-à-dire, pour "session" et "early-session", aucune partie de corps au sein d'un "multipart/alternative" ne peut avoir le même type de contenu qu'une autre partie de corps au sein du même "multipart/alternative".

 	6.3	Comportement d'UA pour ttraiter des corps de message "multipart/alternative"
Ce paragraphe ne spécifie aucun comportement supplémentaire concernant la façon de traiter les corps "multipart/alternative". Ce paragraphe est simplement inclus pour être complet.

 	7.	Corps de message "multipart/related"

Cette section discute des corps de message "multipart/related" et de leur traitement.

 	7.1	Fondements des corps de message "multipart/related"
Les objets composés dans MIME sont représentés en utilisant le type de contenu "multipart/related" [RFC2387]. Les parties de corps au sein d'un corps "multipart/related" particulier font toutes parties d'un objet composé et sont traitées comme telles. La partie de corps au sein d'un corps "multipart/related" qui a besoin d'être traitée en premier est appelée la partie de corps "racine". La partie de corps racine d'un corps "multipart/related" est identifiée par le paramètre "start", qui est un paramètre de champ d'en-tête Content-Type et contient un URL Content-ID pointant sur la partie de corps racine. Si le paramètre "start" n'est pas présent, la partie de corps racine est, par défaut, la première partie de corps du "multipart/related". Un exemple d'objet composé est une page de la Toile qui contient des images. La partie de corps html va être la racine. Les parties de corps restantes vont contenir les images. Un exemple d'une extension SIP utilisant "multipart/related" est spécifiée dans la [RFC4662].

 	7.2	Comportement d'UA pour générer des corps de message "multipart/related"
Ce paragraphe ne spécifie aucun comportement supplémentaire concernant la façon de générer des corps "multipart/related". Ce paragraphe est simplement inclus pour être complet.

 	7.3	Comportement d'UA pour traiter des corps de message "multipart/related"
Selon la [RFC2387], un UA qui traite un corps "multipart/related" le traite comme un objet composé en ignorant les types de disposition des parties de corps en son sein. Ignorer les types de disposition des parties individuelles du corps a un sens dans le contexte dans lequel "multipart/related" a été spécifié à l'origine. Par exemple, dans le cas d'une page de la Toile, le type implicite de disposition pour les images serait "inline", car les images sont affichées comme indiqué par le fichier html racine. Cependant, dans SIP, les types de disposition des parties individuelles du corps au sein d'un "multipart/related" jouent un rôle important et donc, doivent être pris en considération par l'UA qui traite le "multipart/related". Différentes extensions SIP qui utilisent le même type de disposition pour le corps "multipart/related" peuvent être distinguées par le type de disposition des parties de corps individuelles au sein du "multipart/related". Par conséquent, les UA SIP qui traitent un corps "multipart/related" avec un type de disposition donné DOIVENT traiter les types de disposition des parties de corps en son sein en accord avec l'extension SIP qui utilise le type de disposition du "multipart/related".

Noter que les UA qui ne comprennent pas "multipart/related" vont traiter les corps "multipart/related" comme des corps "multipart/mixed". Ces UA ne vont pas être capables de traiter un corps donné comme un objet composé. À la place, ils vont traiter les parties de corps en accord avec leur type de disposition comme si chaque partie de corps était indépendante de chaque autre.

 	8.	Types de disposition

Cette section traite des types de disposition dans les corps de message.

 	8.1	Fondements sur les types de contenu et de disposition dans SIP
Le champ d'en-tête Content-Disposition, défini dans la [RFC2183] et étendu par la [RFC3261], décrit comment traiter un corps de message SIP ou une partie de corps individuelle. Des exemples de types de disposition utilisés dans le champ d'en-tête SIP Content-Disposition sont "session" et "render".

Les [RFC3204] et [RFC3459] définissent le paramètre "handling" (traitement) pour le champ d'en-tête Content-Disposition. Ce paramètre décrit comment un UAS réagit si il reçoit un corps de message dont il ne comprend pas le type de contenu ou le type de disposition. Si le paramètre a la valeur "facultatif", l'UAS ignore le corps de message ; si le paramètre a la valeur "exigé", l'UAS retourne une réponse 415 (Type de support non pris en charge). La valeur par défaut pour le paramètre "handling" est "exigé'"  Voici un exemple de champ d'en-tête Content-Disposition :

Content-Disposition: signal; handling=facultatif

La [RFC3204] identifie deux situations où un UAS doit rejeter une demande avec une partie de corps dont le traitement est exigé :
1.	si il a un type de contenu inconnu,
2.	si il a un type de disposition inconnu.

Si l'UAS ne comprend pas le type de contenu de la partie de corps, il peut ajouter un champ d'en-tête Accept à sa réponse 415 (Type de support non pris en charge) faisant la liste des types de contenu que l'UAS ne comprend pas. Néanmoins, il n'y a pas de mécanisme pour qu'un UAS qui ne comprend pas le type de disposition d'une partie de corps informe l'UAC du type de disposition qui n'a pas été compris ni des types de disposition qui sont compris par l'UAS.

La raison de n'avoir pas un tel mécanisme est que les types de disposition sont normalement pris en charge au sein d'un contexte. En-dehors de ce contexte, un UA n'a pas besoin de prendre en charge le type de disposition. Par exemple, un UA peut prendre en charge le type de disposition "session" pour les parties de corps dans les demandes INVITE et UPDATE et leurs réponses. Cependant, le même UA ne va pas prendre en charge le type de disposition "session" dans les demandes MESSAGE.

Dans un autre exemple, un UA peut prendre en charge le type de disposition "render" pour les parties de corps "text/plain" et "text/html" dans les demandes MESSAGE. De plus, l'UA peut prendre en charge le type de disposition "session" pour les parties de corps "application/sdp" dans les demandes INVITE et UPDATE et leurs réponses. Cependant, l'UA pourrait ne pas prendre en charge le type de disposition "render" pour les parties de corps "application/sdp" dans les demandes MESSAGE, même si, dans des contextes différents, l'UA prenait en charge le type de disposition "render", le type de contenu "application/sdp", et la méthode MESSAGE.

Un contexte donné est généralement (mais pas nécessairement) défini par une méthode, un type de disposition, et un type de contenu. La prise en charge d'un contexte spécifique est généralement définie au sein d'une extension. Par exemple, l'extension pour la messagerie instantanée dans SIP [RFC3428] rend obligatoire la prise en charge de la méthode MESSAGE, du type de disposition "render", et du type de contenu "text/plain".

Noter qu'effectivement, les types de contenu sont aussi prise en charge au sein d'un contexte. Donc, l'utilisation du champ d'en-tête Accept dans une réponse 415 (Type de support non pris en charge) n'est pas suffisante pour décrire dans quels contextes un type particulier de contenu est pris en charge.

Donc, la prise en charge d'un type de disposition particulier au sein d'un contexte donné est normalement signalée par l'utilisation d'une méthode particulière ou d'une étiquette d'option dans un champ d'en-tête Supported ou Require. Quand la prise en charge d'un type de disposition particulier au sein d'un contexte est obligatoire, la prise en charge d'un type de contenu par défaut est aussi obligatoire (par exemple, un UA qui prend en charge le type de disposition "session" dans une demande INVITE a besoin de prendre en charge le type de contenu "application/sdp").

 	8.2	Comportement de l'UA pour régler le paramètre "handling"
Comme indiqué précédemment, le paramètre de Content-Disposition "handling" peut prendre deux valeurs : "exigé" ou "facultatif". Bien qu'il soit normalement facile à un UA de décider quel type de traitement exige une partie de corps individuelle, le réglage du paramètre "handling" de corps "multipart" requiert des considérations supplémentaires.

Si le traitement d'un corps "multipart/mixed" comme un tout est exigé pour la partie de corps ou message qui l'enclot, l'UA DOIT régler le paramètre "handling" du corps "multipart/mixed" à "exigé". Autrement, l'UA DOIT le régler à "facultatif". Les paramètres "handling" des parties de corps de niveau supérieur au sein du corps "multipart/mixed" sont réglés indépendamment du paramètre "handling" du corps "multipart/mixed". Si le traitement d'une partie de corps de niveau supérieur particulière est exigé, l'UA DOIT régler le paramètre "handling" de cette partie de corps à "exigé". Autrement, l'UA DOIT le régler à "facultatif".

Selon les règles précédentes, un corps "multipart/mixed" dont le traitement est facultatif peut contenir des parties de corps dont le traitement est exigé. Dans ce cas, il est exigé du receveur qu'il traite les parties de corps dont le traitement est exigé si et seulement si le receveur décide de traiter le corps "multipart/mixed" facultatif.

Selon aussi les règles précédentes, un corps "multipart/mixed" dont le traitement est exigé peut contenir seulement des parties de corps dont le traitement est facultatif. Dans ce cas, il est exigé du receveur qu'il traite le corps comme un tout mais, quand il le traite, le receveur peut décider (sur la base de sa politique locale) de ne traiter aucune partie de corps.

Le paramètre "handling" est un paramètre de disposition de contenu. Donc, afin de de régler ce paramètre, il est nécessaire de fournir le corps "multipart/mixed" avec un type de disposition. Selon la [RFC3261], le type de disposition par défaut pour "application/sdp" est "session" et pour les autres corps est "render". Les UA DEVRAIENT allouer aux corps "multipart/mixed" le type de disposition de "render".

Noter que le fait que les corps "multipart/mixed" aient un type de disposition par défaut de "render" n'implique pas qu'ils vont être rendus à l'utilisateur. La façon dont les parties de corps au sein de "multipart/mixed" sont traitées dépend des types de disposition des parties de corps individuelles. Le type de disposition réel du "multipart/mixed" n'est pas pertinent. Le type de disposition "render" a été choisi pour les corps "multipart/mixed" simplement parce que "render" est le type de disposition par défaut dans SIP.

Si le traitement d'un corps "multipart/alternative" comme un tout est exigé pour traiter sa partie de corps ou message englobant, l'UA DOIT régler le paramètre "handling" du corps "multipart/alternative" à "exigé". Autrement, l'UA DOIT le régler à "facultatif". L'UA DEVRAIT aussi régler le paramètre "handling" de toute partie de corps de niveau supérieur au sein de "multipart/alternative" à "facultatif".

Le receveur va traiter les parties de corps sur la base du paramètre de traitement du corps "multipart/alternative". Le receveur va ignorer les paramètres de traitement des parties de corps. C'est pourquoi les régler à "facultatif" est au niveau "DEVRAIT" et non "DOIT" -- leur valeur n'a pas de pertinence.

L'UA DOIT utiliser le même type de disposition pour le corps "multipart/alternative" et toutes ses parties de corps de niveau supérieur.

Si le traitement d'un corps "multipart/related" comme un tout est exigé pour le traitement de sa partie de corps ou message englobant, l'UA DOIT régler le paramètre "handling" du corps "multipart/related" à "exigé". Autrement, l'UA DOIT le régler à "facultatif". Les paramètres "handling" des parties de corps de niveau supérieur au sein du corps "multipart/related" sont réglés indépendamment du paramètre "handling" du corps "multipart/related". Si le traitement d'une partie de corps de niveau supérieur particulière est exigé, l'UA DOIT régler le paramètre "handling" de cette partie de corps à "exigé". Autrement, l'UA DOIT le régler à "facultatif". Si au moins une partie de corps de niveau supérieur au sein d'un corps "multipart/related" a un paramètre "handling" de "exigé", l'UA DEVRAIT régler le paramètre "handling" de la partie de corps racine à "exigé".

 	8.3	Comportement de l'UA pour traiter "multipart/alternative"
Le receveur d'un corps "multipart/alternative" DOIT traiter le corps sur la base de son paramètre de traitement. Le receveur DEVRAIT ignorer les paramètres de traitement des parties de corps au sein de "multipart/alternative".

 	8.4	Comportement de l'UAS pour rapporter des corps de message non pris en charge
Si un UAS ne peut pas traiter une demande parce que, dans le contexte donné, l'UAS ne prend pas en charge le type de contenu ou le type de disposition d'une partie de corps dont le traitement est exigé, l'UAS DEVRAIT retourner une réponse 415 (Type de support non pris en charge) même si l'UAS acceptait le type de contenu, le type de disposition, ou les deux dans un contexte différent.

Par conséquent, il est possible de recevoir une réponse 415 (Type de support non pris en charge) avec un champ d'en-tête Accept contenant tous les types de contenu utilisés dans la demande.

Si un UAS reçoit une demande avec une partie de corps dont le type de disposition n'est pas compatible avec la façon dont la partie de corps est supposée être traitée selon les autres parties du message SIP (par exemple, un champ d'en-tête Refer-To avec un URL Content-ID pointant sur une partie de corps dont le type de disposition est "session") l'UAS DEVRAIT retourner une réponse 415 (Type de support non pris en charge).

 	9.	Traitement du corps de message

Cette section discute du traitement des corps de message et comment ce traitement est influencé par la présence de références à eux.

 	9.1	Fondements sur les références aux parties de corps de message
Les URL Content-ID permettent de créer des références aux parties de corps. Un URL Content-ID donné [RFC2392], qui peut apparaître dans un champ d'en-tête ou au sein d'une partie de corps (par exemple, dans un attribut SDP) pointe sur une partie de corps particulière. La façon de traiter cette partie de corps est définie par le champ où l'URL Content-ID apparaît.  Par exemple, l'extension pour se référer à plusieurs ressources dans SIP [RFC5368] place un URL Content-ID dans un champ d'en-tête Refer-To. Un tel URL Content-ID pointe sur une partie de corps qui porte une liste d'URI. Dans un autre exemple, l'extension pour un transfert de fichier dans SDP [RFC5547] place un URL Content-ID dans un attribut SDP "file-icon". Cet URL Content-ID pointe sur une partie de corps qui porte une image (normalement petite).

 	9.2	Comportement d'UA pour générer des références aux corps de message
Les UA DOIVENT seulement inclure des références vers l'avant dans les messages SIP qu'ils génèrent. C'est-à-dire, un élément dans un message SIP ne peut faire référence à une partie de corps que si la partie de corps apparaît après l'élément.  Par conséquent, une partie de corps donnée peut seulement être référencée par une autre partie de corps qui apparaît avant elle ou par un champ d'en-tête. Avoir seulement des références vers l'avant permet aux receveurs de traiter les parties de corps lorsque ils les analysent. Il n'ont pas besoin d'analyser le reste du message afin de traiter une partie de corps.

Il a été envisagé de permettre seulement les références (vers l'avant) parmi les parties de corps qui appartenaient à la même enveloppe "multipart/related" [RFC2387]. Cependant, il a été finalement décidé que cette contrainte supplémentaire n'était pas nécessaire.

 	9.3	Comportement d'UA pour traiter des corps de message
Afin de traiter un corps de message ou une partie de corps, un UA a besoin de savoir si un champ d'en-tête SIP ou une autre partie de corps contient une référence au corps de message ou partie de corps (par exemple, un URL Content-ID qui pointe sur lui). Si la partie de corps n'est référencée d'aucune façon (par exemple, il n'y a pas de champs d'en-tête ou autres parties de corps avec un URL Content-ID pointant sur eux) l'UA traite la partie de corps comme indiqué par son type de disposition et le contexte dans lequel la partie de corps a été reçue.

Si le message SIP contient une référence à la partie de corps, l'UA traite la partie de corps conformément à la référence. Si le message SIP contient plus d'une référence à la partie de corps (par exemple, deux champs d'en-tête contiennent des URL Content-ID pointant sur la partie de corps) l'UA traite la partie de corps autant de fois qu'il y a de références.

Noter que, suivant les règles de la [RFC3204], si un UA ne comprend pas une partie de corps dont le traitement est facultatif, l'UA l'ignore. Noter aussi que le mécanisme de direction de contenu de SIP [RFC4483] permet aux UA de pointer sur des corps externes. Donc, un UA recevant un message SIP qui utilise une direction de contenu pourrait avoir besoin d'aller chercher une partie de corps (par exemple, en utilisant HTTP [RFC2616]) afin de la traiter.

 	9.4	Type de disposition "by-reference"
Selon les règles du paragraphe 9.3, si un message SIP contient une référence à une partie de corps, l'UA traite la partie de corps en accord avec la référence. Comme la référence fournit le contexte dans lequel la partie de corps doit être traitée, le type de disposition de la partie de corps n'est pas pertinent. Cependant, un UA qui a manqué une référence à une partie de corps (par exemple, parce que la référence était dans un champ d'en-tête que l'UA ne prend pas en charge) va tenter de traiter la partie de corps conformément à son seul type de disposition. Pour empêcher cela de se produire, on définit un nouveau type de disposition pour le champ d'en-tête Content-Disposition : "by-reference".

Une partie de corps dont le type de disposition est 'by-reference' doit être traité conformément à une référence à la partie de corps qui est située dans le même message SIP que la partie de corps (étant donné que SIP permet seulement des références vers l'avant, la référence va apparaître dans le même message SIP avant la partie de corps). Un receveur d'une partie de corps dont le type de disposition est "by-reference" qui ne peut pas trouver de référence à la partie de corps (par exemple, la référence était dans un champ d'en-tête que le receveur ne prend pas en charge et, donc, n'a pas traité) NE DOIT PAS traiter la partie de corps. Par conséquent, si le traitement de la partie de corps était exigé, l'UA doit rapporter une erreur.

Noter que les extensions qui précèdent la présente spécification utilisent des références à des parties de corps dont le type de disposition n'est pas "by-reference". Ces extensions utilisent des étiquettes d'option pour s'assurer que le receveur comprend toute l'extension et, donc, ne peut pas manquer la référence et tenter de traiter la partie de corps selon son seul type de disposition.

 	10.	Lignes directrices pour les auteurs d'extensions à SIP

Ces lignes directrices sont destinées aux auteurs d'extensions SIP qui impliquent, dans une certaine mesure, les corps de message ou parties de corps. Ces lignes directrices discutent des aspects que les auteurs de ces extensions doivent examiner quand ils les conçoivent.

La présente spécification rend obligatoire la prise en charge de "multipart/mixed" et "multipart/alternative". À présent, il n'y a pas d'extension SIP qui utilise des sous types "multipart" différents comme en parallèle [RFC2046] ou en résumé [RFC2046]. Si de telles extensions devaient être définies à l'avenir, leurs auteurs devraient s'assurer (par exemple, en utilisant une étiquette d'option ou d'autres moyens) que les entités qui reçoivent ces sous-types "multipart" sont capables de les traiter. Comme on l'a déclaré précédemment, les UA traitent les sous types "multipart" inconnus comme "multipart/mixed".

Les auteurs d'extensions SIP qui utilisent des corps "multipart/related" doivent exposer explicitement le traitement des types de disposition des parties de corps au sein du corps "multipart/related". Les auteurs qui souhaitent utiliser des corps "multipart/related" devraient se souvenir que les UA qui ne comprennent pas "multipart/related" vont le traiter comme "multipart/mixed". Si un tel traitement par un receveur n'est pas acceptable pour une extension particulière, les auteurs de cette extension devront s'assurer (par exemple, en utilisant une étiquette d'option ou par d'autres moyens) que les entités qui reçoivent le corps "multipart/related" sont capables de le traiter correctement.

Comme déclaré plus tôt, les extensions SIP peuvent aussi inclure des corps "multipart" MIME dans leurs réponses. Donc, une réponse peut être extrêmement complexe et l'UAC qui reçoit la réponse pourrait n'être pas capable de la traiter correctement. Parce que les UAC qui reçoivent une réponse ne peuvent pas rapporter les erreurs à l'UAS qui a généré la réponse (c'est-à-dire, des réponses d'erreur peuvent seulement être générées pour des demandes) les auteurs d'extensions SIP doivent s'assurer que les demandes indiquent clairement (par exemple, en utilisant une étiquette d'option ou par d'autres moyens) les capacités de l'UAC afin que les UAS puissent décider quoi inclure dans leurs réponses.

 	11.	Considérations sur la sécurité

Le présent document spécifie comment les entités SIP traitent les corps de message. La [RFC3261] discute des types d'informations codées dans les corps de message SIP et comment les entités SIP peuvent protéger ces informations. En plus de la sécurité bond par bond que SIP peut fournir, SIP peut aussi sécuriser les informations de bout en bout. Les corps de message SIP peuvent être chiffrés de bout en bout et l'intégrité protégée en utilisant S/MIME [RFC3851], comme décrit dans la [RFC3261].

 	12.	Considérations relatives à l'IANA

Le présent document contient deux actions qui ont été réalisées par l'IANA.

 	12.1	Enregistrement du type de disposition "by-reference"
Le présent document définit un nouveau champ d'en-tête Content-Disposition, le type de disposition "by-reference", paragraphe 9.4. Cette valeur a été enregistrée dans le registre IANA des valeurs de disposition de contenu de messagerie avec la description suivante :

by-reference : le corps doit être traité conformément à une référence au corps qui est située dans le même message SIP que le corps.

 	12.2	Mise à jour de l'enregistrement du paramètre "handling"
Des références à la présente spécification, à la [RFC3204], et à la [RFC3459] ont été ajoutées à l'entrée  pour le paramètre  "handling" de Content-Disposition dans le registre Paramètres de champ d'en-tête et valeurs de paramètres. L'entrée résultant est la suivante :

Champ d'en-tête	Nom de paramètre	Valeurs prédéfinies	Références
Content-Disposition	handling	oui	[RFC3204] [RFC3261] [RFC3459] [RFC5621]

 	13.	Remerciements

Les idées de ce document ont été à l'origine discutées avec Paul Kyzivat. Christer Holmberg, Francois Audet, Dan Wing, Adam Roach, Keith Drage, et Dale Worley ont fourni des commentaires sur lui. Dave Crocker a effectué une relecture attentive de tout le document.

 	14.	Références
 	14.1	Références normatives

[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. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC2183]	R. Troost, S. Dorner, K. Moore, éd., "Communication des informations de présentation dans les messages Internet : le champ d'en-tête Contenu-disposition", août 1997. (MàJ par RFC2184, RFC2231) (P.S.)

[RFC2387]	E. Levinson, "Type de contenu MIME Multiparti/Relatif", août 1998. (P.S.)

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

[RFC3204]	E. Zimmerer et autres, "Types de support MIME pour objets ISUP et QSIG", décembre 2001. (MàJ par RFC3459) (P.S.)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002, DOI 10.17487/RFC3261. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3459]	E. Burger, "Paramètres à contenu critique des extensions multi-usages de messagerie Internet (MIME)", janvier 2003. (P.S.)

[RFC3851]	B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version  3.1", juillet 2004. (Obsolète, voir RFC5751)

[RFC3959]	G. Camarillo, "Type de disposition Session précoce pour le protocole d'initialisation de session (SIP)", décembre 2004. (P.S.)

[RFC4483]	E. Burger, éd., "Mécanismes pour le contenu indirect dans les messages du protocole d'initialisation de session (SIP)", mai 2006. (P.S.)

 	14.2	Références pour information

[RFC2616]	R. Fielding et autres, "Protocole de transfert hypertexte -- HTTP/1.1", juin 1999. (D.S., MàJ par 2817, 6585)

[RFC3428]	B. Campbell et autres, "Extension de messagerie instantanée pour le protocole d'initialisation de session (SIP)", décembre  2002.

[RFC4289]	N. Freed, J. Klensin, "Extensions multi-objet de messagerie Internet (MIME) Partie quatre : Procédures d'enregistrement", décembre 2005. (Remplace RFC2048) (BCP0013)

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006, DOI 10.17487/RFC4566. (P.S.  ; remplacée par RFC8866)

[RFC4662]	A. B. Roach et autres, "Extension de notification d'événement du protocole d'initialisation de session (SIP) pour les listes de ressources", août 2006. (P.S.)

[RFC5368]	G. Camarillo et autres, "Référence à des ressources multiples dans le protocole d'initialisation de session (SIP)", octobre  2008. (P.S. ; MàJ par RFC8262)

[RFC5547]	M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat, "Mécanisme d'offre/réponse du protocole de description de session (SDP) pour activer le transfert de fichier", mai 2009. (P. S.)

 	Adresse de l'auteur

Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

mél : Gonzalo.Camarillo@ericsson.com