Groupe de travail Réseau	M. Garcia-Martin, Ericsson
Request for Comments: 5547	M. Isomaki, Nokia
Catégorie : Sur la voie de la normalisation	G. Camarillo, Ericsson
	S. Loreto, Ericsson
	P. Kyzivat, Cisco Systems
Traduction Claude Brière de L'Isle	mai 2009

Mécanisme d'offre/réponse du protocole de description de session (SDP) pour permettre les transferts de fichiers

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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.

Résumé
Le présent document fournit un mécanisme pour négocier le transfert d'un ou plusieurs fichiers entre deux points d'extrémité en utilisant le modèle d'offre/réponse du protocole de description de session (SDP, Session Description Protocol) spécifié dans la RFC 3264. SDP est étendu pour décrire les attributs des fichiers à transférer. L'offreur peut décrire les fichiers qu'il veut envoyer ou les fichiers qu'il voudrait recevoir. Le répondeur peut accepter ou rejeter l'offre séparément pour chaque fichier individuel. Le transfert d'un ou plusieurs fichiers est initié après une négociation réussie. Le protocole de relais de session de messages (MSRP, Message Session Relay Protocol) est défini comme mécanisme par défaut pour porter réellement les fichiers entre les points d'extrémité. Les conventions sur la façon d'utiliser MSRP pour le transfert de fichier sont aussi fournies dans ce document.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Définitions	3
4. Vue d'ensemble du fonctionnement	3
5. Sélecteur de fichier	4
6. Extensions à SDP	4
7. Types de disposition de fichiers	8
8. Fonctionnement du protocole	8
8.1 Attribut "file-transfer-id"	8
8.2 Comportement de l'offreur	10
8.3 Comportement du répondeur	11
8.4 Interruption d'une opération de transffert de fichier en cours	13
8.5 Indication de la capacité d'offre/réponse de transfert de fichier	15
8.6 Réutilisation de lignes "m=" existantes dans SDP	15
8.7 Utilisation de MSRP	15
8.8 Considérations sur l'attribut "file-icon"	16
9. Exemples	16
9.1 L'offreur envoie un fichier au répondeur	16
9.2 L'offreur demande un fichier au répondeur et un second transfert de fichier	19
9.3 Exemple d'une indication Capability	23
10. Considérations sur la sécurité	24
11. Considérations relatives à l'IANA	25
11.1 Enregistrement des nouveaux attributs SDP	25
12. Remerciements	26
13. Références	26
13.1 Références normatives	26
13.2 Références pour information	27
Appendice A. Solutions de remplacement considérées	27
Adresse des auteurs	28
 	1.	Introduction

L'offre/réponse du protocole de description de session (SDP, Session Description Protocol) [RFC3264] fournit un mécanisme pour que deux points d'extrémité arrivent à une vue commune d'une session multimédia entre eux. Ces sessions contiennent souvent des flux de supports en temps réel comme de la voix et de la vidéo, mais ne s'y limitent pas. Fondamentalement, tout type de composant de support peut être pris en charge, pour autant que soit spécifié comment le négocier au sein de l'échange d'offre/réponse SDP.

Le protocole de relais de session de message (MSRP, Message Session Relay Protocol) [RFC4975] est un protocole pour transmettre des messages instantanés (IM, Instant Message) dans le contexte d'une session. La spécification du protocole décrit l'usage de SDP pour établir une session MSRP. En plus des messages de texte, MSRP est capable de porter du contenu arbitraire (binaire) d'extensions multi objets de messagerie Internet (MIME, Multipurpose Internet Mail Extensions) [RFC2045] comme des images ou vidéos.

Il y a de nombreux cas où les points d'extrémité impliqués dans une session multimédia voudraient échanger des fichiers dans le contexte de cette session. Avec MSRP, il est possible d'incorporer des fichiers comme objets MIME dans le flux de messages instantanés. MSRP a aussi d'autres caractéristiques qui sont utiles pour le transfert de fichier. Le tronçonnage de message permet le partage de la même connexion de transport entre le transfert d'un grand fichier et l'échange interactif d'IM sans bloquer l'IM. Les relais MSRP [RFC4976] fournissent un mécanisme pour la traversée de traducteur d'adresse réseau (NAT, Network Address Translator). Finalement, MIME sécurisé (S/MIME) [RFC3851] peut être utilisé pour assurer l'intégrité et la confidentialité du contenu transféré.

Cependant, le protocole MSRP de base ne satisfait pas directement toutes les exigences pour les services de transfert de fichier au sein des sessions multimédia. Quatre principales caractéristiques manquent :

o	Le receveur doit être capable de distinguer le "transfert de fichier" d'un "fichier attaché à un IM", permettant au receveur de traiter différemment les deux cas.

o	Il doit être possible à l'envoyeur d'envoyer la demande pour un transfert de fichier. Il doit être possible au receveur de l'accepter ou de le refuser, en utilisant les méta informations dans la demande. Le transfert réel doit avoir lieu seulement après l'acceptation du receveur.

o	Il doit être possible à l'envoyeur de passer des méta informations sur le fichier avant le transfert réel. Ceci doit être capable d'inclure au moins le type de contenu, la taille, le hachage, et le nom du fichier, ainsi qu'une courte description (lisible par l'homme).

o	Il doit être possible au receveur de demander un fichier à l'envoyeur, en fournissant des méta informations sur le fichier.  L'envoyeur doit être capable de décider si il envoie un fichier correspondant à la demande.

Le reste de ce document est organisé comme suit. La Section 3 définit quelques termes utilisés dans le document. La Section 4 donne une vue d'ensemble du fonctionnement. La Section 5 introduit le concept de sélecteur de fichier. La syntaxe et la sémantique détaillée des nouveaux attributs SDP et les conventions sur la façon dont les attributs existants sont utilisés est définie à la Section 6. La Section 7 discute des types de disposition de fichier. La Section 8 décrit le fonctionnement du protocole impliquant SDP et MSRP. Finalement, des exemples sont donnés à la Section 9.

 	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],.

 	3.	Définitions

Pour les besoins du présent document, les définitions suivantes spécifiées dans la [RFC3264] s'appliquent :
o	Réponse
o	Répondeur
o	Offre
o	Offreur

De plus, on définit les termes suivants :

Envoyeur de fichier : point d'extrémité qui veut envoyer un fichier au receveur de fichier.

Receveur de fichier : point d'extrémité qui veut recevoir un fichier de l'envoyeur de fichier.

Sélecteur de fichier : couple d'attributs de fichier que l'offreur SDP inclut dans le SDP afin de choisir un fichier chez le répondeur SDP. Ceci est décrit plus en détails à la Section 5.

Fonctionnement poussé : opération de transfert de fichier où l'offreur SDP prend le rôle de l'envoyeur de fichier et le répondeur SDP prend le rôle de receveur de fichier.

Fonctionnement tiré : opération de transfert de fichier où l'offreur SDP prend le rôle de receveur de fichier et le répondeur SDP prend le rôle d'envoyeur de fichier.

 	4.	Vue d'ensemble du fonctionnement

Un offreur SDP crée un corps SDP qui contient la description d'un ou plusieurs fichiers que l'offreur veut envoyer ou recevoir. L'offreur envoie l'offre SDP au point d'extrémité distant. Le répondeur SDP peut accepter ou rejeter le transfert de chacun de ces fichiers séparément.

Le transfert de fichier réel est effectué en utilisant le protocole de relais de session de message (MSRP) [RFC4975]. Chaque ligne SDP "m=" décrit un flux de supports MSRP utilisé pour transférer un seul fichier à la fois. C'est-à-dire, le transfert simultané de plusieurs fichiers exige plusieurs lignes "m=" et flux de supports MSRP correspondants. On devrait noter que plusieurs flux de supports MSRP peuvent partager une seule connexion de couche transport, de sorte que ce mécanisme ne va pas conduire à une utilisation excessive des ressources de transport.

Chaque ligne "m=" pour un flux de supports MSRP est accompagné de quelques attributs décrivant le fichier à transférer. Si l'envoyeur de fichier génère l'offre SDP, les attributs décrivent un fichier local à envoyer (poussé) et le receveur de fichier peut utiliser cette information pour accepter ou rejeter le transfert. Cependant, si l'offre SDP est générée par le receveur de fichier, les attributs sont destinés à caractériser un fichier particulier que le receveur de fichier veut obtenir (tirer) de l'envoyeur de fichier. Il est possible que l'envoyeur de fichier n'ait pas de fichier correspondant ou ne veuille pas envoyer le fichier, et dans ce cas l'offre est rejetée.

Les attributs décrivant chaque fichier sont fournis dans SDP par un ensemble de nouveaux attributs SDP, dont la plupart ont été directement empruntés de MIME. De cette façon, les agents d'utilisateur peuvent décider d'accepter ou non un certain transfert de fichier sur la base du nom du fichier, de sa taille, description, hachage, icône (par exemple, si le fichier est image) etc.

Les attributs SDP de direction (par exemple, "sendonly", "recvonly") sont utilisés pour indiquer la direction du transfert, c'est-à-dire, si l'offreur SDP veut envoyer ou recevoir le fichier. En supposant que le répondeur accepte le transfert de fichier, le transfert réel des fichiers a lieu avec le MSRP ordinaire. Noter que les attributs "sendonly" et "recvonly" se réfèrent à la direction des demandes MSRP SEND et donc n'empêchent pas d'autres éléments de protocole (comme des réponses 200, des demandes REPORT, etc.).

En principe, le transfert de fichier peut fonctionner même avec un point d'extrémité qui prend seulement en charge le MSRP régulier sans comprendre les extensions définies ici, dans un cas particulier où le point d'extrémité est à la fois le répondeur SDP et le receveur de fichier. Le point d'extrémité MSRP régulier répond à l'offre comme il répondrait à toute offre MSRP ordinaire sans prêter attention aux attributs d'extension. Dans ce scénario, l'expérience de l'utilisateur serait cependant réduite, car le receveur ne saurait pas (par les moyens du protocole) la raison de la session et ne serait pas capable de l'accepter/rejeter sur la base des attributs du fichier.

 	5.	Sélecteur de fichier

Quand le receveur de fichier génère l'offre SDP, cette offre SDP doit identifier sans ambiguïté le fichier demandé à l'envoyeur de fichier. À cette fin, on introduit la notion de sélecteur de fichier, qui est un couple composé d'un ou plusieurs des sélecteurs individuels suivants : le nom, la taille, le type, et le hachage du fichier. Le sélecteur de fichier peut inclure un nombre quelconque de sélecteurs, de sorte que tous les quatre n'ont pas toujours besoin d'être présents.

L'objet du sélecteur de fichier est de fournir assez d'informations sur le fichier à l'entité distante, afin que les deux entités, locale et distante puissent se référer au même fichier. Le sélecteur de fichier est codé dans un attribut de support "file-selector" dans SDP. La syntaxe formelle de l'attribut de support "file-selector" est décrite à la Figure 1.

Le processus de choix de fichier est appliqué à tous les fichiers disponibles chez l'hôte. Le processus choisit les fichiers qui correspondent à chacun des sélecteurs présents dans l'attribut "file-selector". Le résultat peut être zéro, un, ou plusieurs fichiers, selon la présence des sélecteurs mentionnés dans le SDP et selon les fichiers disponibles chez un hôte. Le mécanisme de transfert de fichier spécifié dans le présent document exige qu'un sélecteur de fichier résulte finalement au plus en un seul fichier choisi. Normalement, si le sélecteur hachage est connu, il suffit pour produire un sélecteur de fichier qui pointe sur exactement zéro ou un fichier. Cependant, un sélecteur de fichier qui choisit un unique fichier n'est pas toujours connu de l'offreur. Parfois, seulement le nom, la taille, ou le type de fichier est connu, de sorte que le sélecteur de fichier peut finir par choisir plus d'un fichier, ce qui n'est pas désiré. Le contraire est aussi vrai : si le sélecteur de fichier contient un sélecteur hachage et un sélecteur nom, il y a un risque que l'hôte distant ait renommé le fichier, et dans ce cas, bien qu'existe un fichier dont le hachage calculé égale le sélecteur hachage, le nom du fichier ne correspond pas à celui du sélecteur nom. Donc, dans ce cas, le processus de sélection de fichier va résulter en la sélection de zéro fichier.

La présente spécification utilise l'algorithme n° 1 de hachage sûr (SHA-1, Secure Hash Algorithm 1) [RFC3174]. Si de futurs besoins exigeaient d'ajouter la prise en charge d'algorithmes de hachage différents, ils seront spécifiés comme des extensions au présent document.

Les mises en œuvre conformes à cette spécification DOIVENT prendre en charge l'attribut "file-selector" et PEUVENT prendre en charge tout autre attribut spécifié dans le présent document. Les offres et réponses SDP pour le transfert de fichier DOIVENT contenir un attribut de support "file-selector" qui choisit le fichier à transférer et PEUVENT contenir tout autre attribut spécifié dans le présent document.

L'attribut de support "file-selector" est aussi utile pour apprendre la prise en charge de la capacité d'offre/réponse de transfert de fichier que spécifie le présent document. Ceci est expliqué plus en détails au paragraphe 8.5.

 	6.	Extensions à SDP

On définit un certain nombre de nouveaux attributs SDP [RFC4566] qui fournissent les informations requises pour décrire le transfert d'un fichier avec MSRP. Ce sont tous des attributs seulement de niveau support dans SDP. Voici la syntaxe ABNF formelle [RFC5234] de ces nouveaux attributs. Elle est construite par dessus la grammaire de SDP [RFC4566], [RFC2045], [RFC2183], [RFC2392], et [RFC5322].

attribute =/ file-selector-attr / file-disp-attr / file-tr-id-attr / file-date-attr / file-icon-attr / file-range-attr
	; attribute est défini dans la RFC 4566.

file-selector-attr = "file-selector" [":" selector *(SP selector)]
selector = filename-selector / filesize-selector / filetype-selector / hash-selector

filename-selector = "name:"  DQUOTE filename-string DQUOTE 	; DQUOTE défini dans la RFC 5234
filename-string = 1*(filename-char/percent-encoded)
filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%x26-FF
	; tout octet sauf NUL, CR, LF, guillemets, ou pourcentage.
percent-encoded = "%" HEXDIG HEXDIG	; HEXDIG défini dans la RFC 5234

filesize-selector = "size:" filesize-value

filesize-value = integer	; integer défini dans la RFC 4566

filetype-selector = "type:" type "/" subtype *(";" ft-parameter)
ft-parameter = attribute "=" DQUOTE value-string DQUOTE 
; attribute est défini dans la RFC 2045 ; la libre insertion d'espaces linéaires n'est pas permise dans ce contexte.
; noter que value-string doit être re-codé quand on traduit de ceci en un en-tête Content-Type.
value-string = filename-string

hash-selector = "hash:" hash-algorithm ":" hash-value
hash-algorithm = token 	; voir le registre IANA Noms textuel de fonction de hachage.
	; seul "sha-1" est actuellement pris en charge.
hash-value = 2HEXDIG *(":" 2HEXDIG)
	; chaque octet en hexadécimal majuscule, séparé par deux-points.
	; HEXDIG défini dans la RFC 5234.

file-tr-id-attr  = "file-transfer-id:" file-tr-id-value
file-tr-id-value = token

file-disp-attr = "file-disposition:" file-disp-value
file-disp-value = token

file-date-attr  = "file-date:"  date-param *(SP date-param)

date-param = c-date-param / m-date-param / r-date-param
c-date-param = "creation:" DQUOTE date-time DQUOTE
m-date-param = "modification:" DQUOTE date-time DQUOTE
r-date-param = "read:" DQUOTE date-time DQUOTE
	; date-time est défini dans la RFC 5322.
	; les zones horaires numériques (+HHMM ou -HHMM) doivent être utilisées.
	; DQUOTE défini dans la RFC 5234.

file-icon-attr = "file-icon:" file-icon-value
file-icon-value = cid-url	; cid-url défini dans la RFC 2392.

file-range-attr = "file-range:" start-offset "-" stop-offset
start-offset = integer	; integer défini dans la RFC 4566.
stop-offset = integer / "*"

Figure 1 : Syntaxe de l'extension SDP

Quand il est utilisé pour une interrogation de capacité (voir le paragraphe 8.5) l'attribut "file-selector" NE DOIT PAS contenir de sélecteur, parce que sa présence indique simplement la conformité à la présente spécification.

Quand il est utilisé dans une offre ou réponse SDP, l'attribut "file-selector" DOIT contenir au moins un sélecteur. Les sélecteurs caractérisent le fichier à transférer. Il y a quatre sélecteurs dans cet attribut : "name", "size", "type", et 'hash".

Le sélecteur "name" dans l'attribut "file-selector" contient le nom de fichier du contenu enclos dans les guillemets. Le nom de fichier est codé en UTF-8 [RFC3629]. Sa valeur DEVRAIT être la même que celle du paramètre "filename" du champ d'en-tête Content-Disposition [RFC2183] qui serait signalé par le transfert de fichier réel. Si un nom de fichier contient des guillemets ou tout autre caractère que la syntaxe ne permet pas dans le sélecteur "name", ils DOIVENT être codés en pourcentage. Le sélecteur "name" NE DOIT PAS contenir de caractères qui peuvent être interprétés comme une structure de répertoire par le système d'exploitation local. Si de tels caractères sont présents dans le nom de fichier, ils DOIVENT être codés en pourcentage.

Noter que le sélecteur "name" pourrait encore contenir des caractères qui, bien que non significatifs pour le système d'exploitation local, pourrait être significatifs pour le système d'exploitation distant (par exemple, '\', '/', ':'). Donc, les mises en œuvre sont responsables du nettoyage des entrées reçues du point d'extrémité distant avant de faire un traitement local dans le système de fichiers local, tel que la création d'un fichier local. Entre autres choses, les mises en œuvre peuvent coder en pourcentage les caractères qui sont significatifs pour le système d'exploitation local avant de faire des appels au système de fichiers local.

Le sélecteur "size" dans l'attribut "file-selector" indique la taille du fichier en octets. La valeur de cet attribut DEVRAIT être la même que celle du paramètre "size" du champ d'en-tête Content-Disposition [RFC2183] qui serait signalé par le transfert de fichier réel. Noter que le sélecteur "size" inclut simplement la taille du fichier, et n'inclut aucun frais généraux potentiels ajoutés par une enveloppe, comme un message/cpim [RFC3862].

Le sélecteur "type" dans l'attribut "file-selector" contient le type et les sous types de supports MIME du contenu. En général, tout ce qui peut être exprimé dans un champ d'en-tête Content-Type (voir la [RFC2045]) peut aussi être exprimé avec les sélecteurs "type". Les valeurs de type de support MIME possibles sont celles mentionnées dans le registre de l'IANA pour les types de supports MIME [IANA]. Zéro, un ou plusieurs paramètres peuvent suivre. Quand on traduit les paramètres d'un en-tête Content-Type en un sélecteur "type", le paramètre doit être recodé avant son incorporation comme  paramètre de sélecteur "type" (voir la syntaxe ABNF de "ft-parameter").

Le sélecteur "hash" dans l'attribut "file-selector" fournit un calcul de hachage du fichier à transférer. Cela est couramment utilisé par les protocoles de transfert de fichier. Par exemple, FLUTE [RFC6726] utilise des hachages (appelés des résumés de message) pour vérifier le contenu du transfert. L'objet du sélecteur "hash" est double : d'un côté, dans les opérations poussées, il permet au receveur de fichier d'identifier un fichier distant par son hachage plutôt que par son nom de fichier, pourvu que le receveur de fichier ait appris le hachage du fichier distant par un mécanisme hors bande. De l'autre côté, dans des opérations poussées ou tirées, il permet au receveur de fichier de vérifier le contenu du fichier reçu, ou même d'éviter des transmission inutiles d'un fichier existant.

L'espace d'adresses de l'algorithme SHA-1 est assez grand pour éviter toute collision dans les calculs de hachage entre deux points d'extrémité. Quand on transfère des fichiers, le protocole réel de transfert de fichier devrait fournir une transmission de données fiable, afin que les vérifications des fichiers reçus réussissent toujours. Cependant, si les points d'extrémité ont besoin de protéger l'intégrité d'un fichier, ils devraient utiliser un autre mécanisme que le sélecteur "hash" spécifié dans le présent mémoire.

Le sélecteur "hash" inclut l'algorithme de hachage et sa valeur. Les algorithmes de hachage possibles sont ceux définis dans le registre IANA des noms textuels de fonction de hachage [IANA]. Les mises en œuvre de la présente spécification DOIVENT ajouter une chaîne de 160 bits résultant du calcul de l'algorithme US n° 1 de hachage sûr (SHA1, US Secure Hash Algorithm 1) [RFC3174] si le sélecteur "hash" est présent. Si le besoin s'en fait sentir, des extensions peuvent être conçues pour prendre en charge plusieurs algorithmes de hachage. Donc, les mises en œuvre conformes à la présente spécification DOIVENT être prêtes à recevoir des SDP contenant plus d'un seul sélecteur "hash" dans l'attribut "file-selector".

La valeur du sélecteur "hash" est la chaîne d'octets résultant de l'application de l'algorithme de hachage au contenu du fichier entier, même quand le transfert de fichier est limité à un nombre d'octets (c'est-à-dire, l'attribut "file-range" est indiqué).

L'attribut "file-transfer-id" fournit une identification unique au monde, choisie au hasard, du transfert de fichier réel. Il est utilisé pour distinguer une nouvelle demande de transfert de fichier d'une répétition du SDP (ou de la fraction du SDP qui traite la description de fichier). Cet attribut est décrit plus en détails au paragraphe 8.1.

L'attribut "file-disposition" fait une suggestion à l'autre point d'extrémité sur la disposition prévue du fichier. La Section 7 donne une discussion des valeurs possibles. La valeur de cet attribut DEVRAIT être la même que celle du paramètre de type de disposition du champ d'en-tête Content-Disposition [RFC2183] qui serait signalé par le protocole réel de transfert de fichier protocol.

L'attribut "file-date" indique les dates auxquelles le fichier a été créé, modifié, ou lu pour la dernière fois. Cet attribut PEUT contenir une combinaison des paramètres "creation", "modification", et "read", mais NE DOIT PAS contenir plus d'un de chaque type .

Le paramètre "creation" indique la date à laquelle le fichier a été créé. La valeur DOIT être une chaîne entre guillemets qui contient une représentation de la date de création du fichier dans le format "date-time" de la [RFC5322]. Les zones horaires  numériques (+HHMM ou -HHMM) DOIVENT être utilisées. La valeur de ce paramètre DEVRAIT être la même que celle du paramètre "creation-date" du champ d'en-tête Content-Disposition [RFC2183] qui serait signalé par le protocole réel de transfert de fichier.

Le paramètre "modification" indique la dernière date à laquelle le fichier a été modifié. La valeur DOIT être une chaîne entre guillemets qui contient une représentation de la date de la dernière modification du fichier dans le format "date-time" de la [RFC5322]. Les zones horaires numériques (+HHMM ou -HHMM) DOIVENT être utilisées. La valeur de ce paramètre DEVRAIT être la même que celle du paramètre "modification-date" du champ d'en-tête Content-Disposition [RFC2183] qui serait signalé par le protocole réel de transfert de fichier.

Le paramètre "read" indique la dernière date à laquelle le fichier a été lu. La valeur DOIT être une chaîne entre guillemets qui contient une représentation de la date de la dernière lecture du fichier dans le format "date-time" de la [RFC5322]. Les zones horaires  numériques (+HHMM ou -HHMM) DOIVENT être utilisées. La valeur de ce paramètre DEVRAIT être la même que celle du paramètre "read-date" du champ d'en-tête Content-Disposition [RFC2183] qui serait signalé par le protocole réel de transfert de fichier.

L'attribut "file-icon" peut être utile avec certains types de fichiers comme des images. Il permet à l'envoyeur de fichier d'inclure un pointeur sur un corps qui inclut une petite icône représentant le contenu du fichier à transférer, que le receveur de fichier peut utiliser pour déterminer si il veut recevoir un tel fichier. L'attribut "file-icon" contient un URI Content-ID, qui est spécifié dans la [RFC2392]. Le paragraphe 8.8 contient d'autres considérations sur l'attribut "file-icon".

L'attribut "file-range" fournit un mécanisme pour signaler un tronçon d'un fichier plutôt que le fichier complet. Cela permet des cas d'utilisation où un transfert de fichier peut être interrompu et repris, même peut-être en changeant un des points d'extrémité. L'attribut "file-range" contient le "start offset" (décalage de début) et le "stop offset" (décalage de fin) du fichier, séparés par un tiret "-". La valeur de "start offset" se réfère à la position d'octet du fichier où le transfert de fichier devrait commencer. Le premier octet d'un fichier est noté par le nombre ordinal "1". La valeur de "stop offset" se réfère à la position d'octet du fichier où le transfert de fichier devrait s'arrêter, cet octet inclus. La valeur de "stop offset" PEUT contenir une "*" si la taille totale du fichier n'est pas connue à l'avance. L'absence de cet attribut indique un fichier complet, c'est-à-dire, comme si l'attribut "file-range" avait été présent avec une valeur de "1-*". L'attribut "file-range" ne doit pas être confondu avec l'en-tête Byte-Range dans MSRP. Le premier indique la portion d'un fichier que l'application voudrait lire et passer à la pile MSRP pour le transporter. Du point de vue de MSRP, la portion du fichier est vue comme un message complet. Le dernier indique le nombre d'octets de ce message qui sont portés dans un tronçon et la taille totale du message. Donc, MSRP commence à compter le message livré à l'octet numéro 1, indépendamment de la position de cet octet dans le fichier.

Voici un exemple d'un corps SDP qui contient les extensions définies dans le présent mémoire :

   v=0
   o=alice 2890844526 2890844526 IN IP4 host.atlanta.exemple.com
   s=
   c=IN IP4 host.atlanta.exemple.com
   t=0 0
   m=message 7654 TCP/MSRP *
   i=Ceci est ma dernière photo
   a=sendonly
   a=accept-types:message/cpim
   a=accept-wrapped-types:*
   a=path:msrp://atlanta.exemple.com:7654/jshA7we;tcp
   a=file-selector:name:"My cool picture.jpg" type:image/jpeg
     size:32349 hash:sha-1:
     72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
   a=file-transfer-id:vBnG916bdberum2fFEABR1FR3ExZMUrd
   a=file-disposition:attachment
   a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
   a=file-icon:cid:id2@alicepc.exemple.com
   a=file-range:1-32349

Figure 2 : Exemple de SDP décrivant un transfert de fichier

Note : L'attribut "file-selector" dans la figure ci-dessus est partagé sur trois lignes pour les besoins du formatage. Les mises en œuvre réelles le coderont sur une seule ligne.

 	7.	Types de disposition de fichiers

L'offre/réponse SDP pour le transfert de fichier permet à l'envoyeur de fichier d'indiquer une disposition préférée du fichier à transférer dans un nouvel attribut "file-disposition". En principe, toute valeur mentionnée dans le registre de l'IANA pour les valeurs de disposition de contenu de messagerie [IANA] est acceptable ; cependant, la plupart d'entre elles peuvent n'être pas applicables.

Il y a deux dispositions de contenu intéressantes pour les opérations de transfert de fichier. D'un côté, l'envoyeur de fichier peut juste vouloir que le fichier soit rendu immédiatement dans l'appareil du receveur de fichier. D'un autre côté, l'envoyeur de fichier peut juste vouloir indiquer au receveur de fichier que le fichier ne devrait pas être rendu à la réception du fichier. L'agent d'utilisateur du receveur peut vouloir interagir avec l'utilisateur concernant la disposition du fichier ou il peut sauvegarder le fichier jusqu'à ce que l'utilisateur fasse une action. Dans tous les cas, les actions exactes dépendent de la mise en œuvre.

Pour indiquer qu'un fichier devrait être automatiquement rendu, le présent mémoire utilise la valeur existante "render" du type de disposition de contenu dans le nouvel attribut "file-disposition" dans SDP. Pour indiquer qu'un fichier ne devrait pas être automatiquement rendu, le présent mémoire utilise la valeur existante "attachment" du type Content-Disposition dans le nouvel attribut "file-disposition" dans SDP. La valeur par défaut est "render", c'est-à-dire, l'absence d'un attribut "file-disposition" dans le SDP a la même sémantique que "render".

La valeur de disposition "attachment" est spécifiée dans la [RFC2183] avec la définition suivante :
"Des parties de corps peuvent être désignées comme "attachment" pour indiquer qu'elles sont séparées du corps principal du message, et que leur affichage ne devrait pas être automatique, mais dépendant d'une autre action de l'utilisateur."

Dans le cas de la présente spécification, le type de disposition "attachment" est utilisé pour indiquer que l'affichage du fichier ne devrait pas être automatique, mais dépendant d'une autre action de l'utilisateur.

 	8.	Fonctionnement du protocole

Cette Section explique comment utiliser les paramètres définis à la Section 6 dans le contexte d'un échange offre/réponse [RFC3264]. De plus, elle explique aussi le comportement des points d'extrémité en utilisant MSRP.

Une session de transfert de fichier est initiée par l'offreur qui envoie une offre SDP au répondeur. Le répondeur accepte ou rejette la session de transfert de fichier et envoie une réponse SDP à l'offreur.

On peut différencier deux cas d'utilisation, selon que l'offreur est l'envoyeur ou le receveur de fichier :

1.	L'offreur est l'envoyeur de fichier, c'est-à-dire, l'offreur veut transmettre un fichier au répondeur. Par conséquent, le répondeur est le receveur de fichier. Dans ce cas, l'offre SDP contient un attribut "sendonly", et en conséquence la réponse SDP contient un attribut "recvonly".

2.	L'offreur est le receveur de fichier, c'est-à-dire, l'offreur veut aller chercher un fichier chez le répondeur. Par conséquent, le répondeur est l'envoyeur de fichier. Dans ce cas, l'offre SDP contient un attribut de session ou de support "recvonly", et par conséquent la réponse SDP contient un attribut de session ou de support "sendonly".

 	8.1	Attribut "file-transfer-id"
La présente spécification crée une extension au modèle d'offre/réponse SDP [RFC3264], et à cause de cela, il est supposé que le comportement existant SDP reste intact. Le comportement SDP exige, par exemple, que SDP soit envoyé à nouveau à la partie distante dans les situations où la description de supports ou peut-être d'autres paramètres SDP n'ont pas changé par rapport à un échange d'offre/réponse précédent. Considérons le temporisateur de session SIP [RFC4028], qui utilise des demandes re-INVITE pour rafraîchir les sessions. La RFC 4028 recommande d'envoyer un SDP non modifié dans un re-INVITE pour rafraîchir la session. Si ce re-INVITE contient un SDP qui décrit une opération de transfert de fichier et se produit alors que le transfert de fichier est encore en cours, il n'y aura pas de moyen de détecter si le créateur du SDP voulait interrompre l'opération de transfert de fichier en cours et en initier une nouvelle ou si la description de fichier SDP était incluse dans le SDP pour d'autres raisons (par exemple, le rafraîchissement du temporisateur de session).

Un scénario similaire se produit quand deux points d'extrémité ont réussi à s'accorder sur un transfert de fichier, qui est en cours quand un des points d'extrémité veut ajouter des flux de supports supplémentaires à la session existante. Dans ce cas, le point d'extrémité envoie une demande re-INVITE qui contient le SDP. Le SDP doit conserver les descriptions de supports pour le transfert de fichier en cours actuel et ajoute les nouvelles descriptions de supports. Le problème est que l'autre point d'extrémité n'est pas capable de déterminer si un nouveau transfert de fichier est ou non demandé.

Dans d'autres cas, un transfert de fichier a été achevé avec succès. Alors, si un point d'extrémité renvoie l'offre SDP avec le flux de supports pour le transfert de fichier, l'autre point d'extrémité ne va pas être capable de déterminer si un nouveau transfert de fichier devrait ou non commencer.

Pour traiter ces scénarios, la présente spécification définit l'attribut "file-transfer-id", qui contient un identifiant aléatoire unique au monde alloué à l'opération de transfert de fichier. L'identifiant de transfert de fichier aide les deux points d'extrémité à déterminer si l'offre SDP demande un nouveau transfert de fichier ou si elle est une répétition du SDP. Un nouveau transfert de fichier est celui qui, en cas d'acceptation, va provoquer le transfert réel d'un fichier. C'est normalement le cas des nouveaux échanges d'offre/réponse, ou dans les cas où un point d'extrémité veut interrompre le transfert de fichier existant et redémarrer une fois de plus le transfert de fichier. Par ailleurs, la répétition du SDP ne conduit pas au transfert d'un fichier réel, potentiellement parce que le transfert de fichier est encore en cours ou parce que il est déjà fini. C'est le cas des échanges d'offre/réponse répétés, qui peuvent être dus à un certain nombre de raisons (temporisateur de session, ajout/suppression d'autres types de supports dans le SDP, mise à jour dans SDP causée par des changements d'autres paramètres de session, etc.).

Les mises en œuvre conformes à la présente spécification DOIVENT inclure un attribut "file-transfer-id" dans les offres et réponses SDP. L'offreur SDP DOIT choisir un identifiant de transfert de fichier conforme à la syntaxe et l'ajouter à l'attribut "file-transfer-id". Le répondeur SDP DOIT copier la valeur de l'attribut "file-transfer-id" dans la réponse SDP.

L'identifiant de transfert de fichier DOIT être unique dans la session en cours (jamais utilisé avant dans cette session) et il est RECOMMANDÉ qu'il soit unique à travers les différentes sessions. Il est RECOMMANDÉ de choisir un identifiant aléatoire relativement long (par exemple, 32 caractères) pour éviter des duplications. Le répondeur SDP DOIT garder trace des identifiants du transfert de fichier proposé dans chaque session et copier la valeur de l'identifiant de transfert de fichier reçu dans la réponse SDP.

Si un transfert de fichier est suspendu et repris ultérieurement, la reprise est considérée comme un nouveau transfert de fichier (même quand le fichier à transférer est le même) ; donc, l'offreur SDP DOIT choisir un nouvel identifiant de transfert de fichier.

Si un point d'extrémité règle le numéro d'accès à zéro dans la description de support d'un transfert de fichier, par exemple, parce que il veut rejeter l'opération de transfert de fichier, alors la réponse SDP DOIT refléter la valeur de l'attribut "file-transfer-id" inclus dans l'offre SDP. Cela signifie effectivement que régler un flux de supports à zéro a une plus haute préséance que toute valeur que peut prendre l'attribut "file-transfer-id".

Par ailleurs, l'attribut "file-transfer-id" peut être utilisé pour interrompre et redémarrer un transfert de fichier en cours. Supposons que deux points d'extrémité s'accordent sur un transfert de fichier et que le transfert du fichier réel ait lieu. À un moment au milieu du transfert de fichier, un point d'extrémité envoie une nouvelle offre SDP, égale à l'initiale sauf pour la valeur de l'attribut "file-transfer-id", qui est une nouvelle valeur aléatoire unique au monde. Cela indique que l'offreur veut interrompre le transfert existant et en commencer un nouveau, en accord avec les paramètres SDP. Le répondeur SDP DEVRAIT interrompre le transfert de fichier en cours, conformément aux procédures du protocole de transfert de fichier (par exemple, MSRP) et commencer à envoyer le fichier une fois de plus à partir de l'octet initial demandé. Le paragraphe  8.4 discute plus en détails l'interruption d'un transfert de fichier.

Si un point d'extrémité crée une offre SDP où la valeur de l'attribut "file-transfer-id" ne change pas par rapport à un envoyé précédemment, mais si le sélecteur de fichier change de sorte qu'un nouveau fichier est choisi, cela est alors considéré comme une erreur, et le répondeur SDP DOIT interrompre l'opération de transfert de fichier (par exemple, en réglant le numéro d'accès à zéro dans la réponse SDP). Noter que les points d'extrémité PEUVENT changer l'attribut "file-selector" tant que le fichier choisi ne change pas (par exemple, en ajoutant un sélecteur de hachage) ; cependant, il est RECOMMANDÉ que les points d'extrémité ne changent pas la valeur de l'attribut "file-selector" si il est demandé de transférer le même fichier que décrit dans un précédent échange d'offre/réponse SDPe.

La Figure 3 résume la relation de l'attribut "file-transfer-id" avec le sélecteur de fichier dans les échanges SDP suivants.

                      \                |             |                 |
                       \ sélecteur de  |  fichier    |  même fichier   |
     "file-transfer-id" \    fichier   |  différent  |                 |
     ==================================+=============+=================+
                                       |  nouvelle   |   nouvelle      |
      changé                           | opération de| opération de    |
                                       |  transfert  |   transfert     |
     ----------------------------------+-------------+-----------------+
                                       |             | opération de    |
      inchangé                         |   erreur    | transfert de    |
                                       |             |fichier existante|
     ----------------------------------+-------------+-----------------+

Figure 3 : Relation de l'attribut "file-transfer-id" avec le éelecteur du fichier dans un échange SDP suivant

Dans un autre scénario, un point d'extrémité qui a réussi à transférer un fichier veut envoyer un SDP pour d'autres raisons que le transfert d'un fichier. L'offreur SDP crée une description SDP de fichier qui conserve la ligne de description de supports correspondant au transfert de fichier. L'offreur SDP DOIT alors régler le numéro d'accès à zéro et DOIT garder la même valeur de l'attribut "file-transfer-id'" qu'avait le transfert de fichier initial.

 	8.2	Comportement de l'offreur
Un offreur qui souhaite envoyer ou recevoir un ou plusieurs fichiers à ou d'un répondeur DOIT construire une description SDP [RFC4566] d'une session contenant une ligne "m=" par fichier. Quand MSRP est utilisé comme mécanisme de transfert, chaque ligne "m=" décrit aussi une seule session MSRP, conformément aux procédures de MSRP [RFC4975]. Toutes les lignes "m=" qui peuvent avoir été déjà présentes dans un précédent échange SDP sont normalement gardées non modifiées ; les nouvelles lignes "m=" sont ajoutées après coup (le paragraphe 8.6 décrit les cas où les lignes "m=" sont réutilisées). Tous les attributs de ligne de supports spécifiés et exigés par MSRP [RFC4975] (par exemple, "a=path", "a=accept-types", etc.) DOIVENT aussi être inclus.

 	8.2.1	L'offreur est un envoyeur de fichier
Dans une opération poussée, l'envoyeur de fichier crée une offre SDP décrivant le fichier à envoyer. L'envoyeur de fichier DOIT ajouter une ligne de supports d'attribut "file-selector" contenant au moins un des sélecteurs "type", "size", ou "hash" pour indiquer respectivement le type, la taille, ou le hachage du fichier. Si l'envoyeur de fichier souhaite commencer un nouveau transfert de fichier, l'envoyeur de fichier DOIT ajouter un attribut "file-transfer-id" contenant une nouvelle valeur d'identifiant aléatoire unique au monde. De plus, l'envoyeur de fichier DOIT ajouter un attribut "sendonly" de session ou supports à l'offre SDP. Ensuite l'envoyeur de fichier envoie l'offre SDP au receveur de fichier.

Tous les sélecteurs dans l'attribut "file-selector" pourraient n'être pas connus quand l'envoyeur de fichier crée l'offre SDP, par exemple, parce que l'hôte est encore en train de traiter le fichier.

Le sélecteur "hash" dans l'attribut "file-selector" contient des informations précieuses pour que le receveur de fichier identifie si le fichier est déjà disponible et n'a pas besoin d'être transmis.

L'envoyeur de fichier PEUT aussi ajouter un sélecteur "name" dans l'attribut "file-selector", et des attributs "file-icon", "file-disposition", et "file-date" qui décrivent plus le fichier à transférer. L'attribut "file-disposition" donne une suggestion de présentation (par exemple, l'envoyeur de fichier aimerait que le receveur de fichier rende ou non le fichier). Les trois attributs de date donnent au répondeur une indication de l'âge du fichier. L'envoyeur de fichier PEUT aussi ajouter un attribut "file-range" qui indique les décalages de début et de fin du fichier.

Quand l'envoyeur de fichier reçoit la réponse SDP, si le numéro d'accès de la réponse pour une demande de fichier n'est pas zéro, l'envoyeur de fichier commence le transfert du fichier conformément aux paramètres négociés dans SDP.

 	8.2.2	L'offreur est un receveur de fichier
Dans une opération tirée, le receveur de fichier crée l'offre SDP et l'envoie à l'envoyeur de fichier. Le receveur de fichier DOIT inclure un attribut "file-selector" et DOIT inclure, au moins, un des sélecteurs définis pour un tel attribut (c'est-à-dire, "name", "type", "size", ou "hash"). Dans de nombreux cas, si le hachage du fichier est connu, c'est assez pour identifier le fichier ; donc, l'offreur peut inclure seulement un sélecteur "hash". Cependant, en particulier dans les cas où le hachage du fichier est inconnu, le nom, la taille, et le type du fichier peuvent fournir une description du fichier à aller chercher. Si le receveur de fichier souhaite commencer un nouveau transfert de fichier, il DOIT ajouter un attribut "file-transfer-id" contenant une nouvelle valeur aléatoire unique au monde. Le receveur de fichier PEUT aussi ajouter un attribut "file-range" indiquant les décalages de début et de fin du fichier. Il n'est pas nécessaire que le receveur de fichier inclue d'autres attributs de fichier dans l'offre SDP ; donc, il est RECOMMANDÉ que les offreurs SDP n'incluent pas d'autre attribut de fichier défini par la présente spécification (autre que ceux obligatoires). De plus, le receveur de fichier DOIT ajouter un attribut "recvonly" de session ou de supports dans l'offre SDP. Ensuite, le receveur de fichier envoie l'offre SDP à l'envoyeur de fichier.

Quand le receveur de fichier reçoit la réponse SDP, si le numéro d'accès de la réponse pour une demande de fichier n'est pas zéro, alors le receveur de fichier devrait recevoir le fichier en utilisant le protocole indiqué dans la ligne "m=". Si la réponse SDP contient un algorithme de hachage pris en charge dans les sélecteur "hash" de l'attribut "file-selector", alors ce receveur de fichier DEVRAIT calculer le hachage du fichier après sa réception et le vérifier par rapport au hachage reçu dans la réponse. Si le hachage calculé ne correspond pas à celui contenu dans la réponse SDP, le receveur de fichier DEVRAIT considérer que le transfert de fichier a échoué et DEVRAIT en informer l'utilisateur. De même, le receveur de fichier DEVRAIT aussi vérifier que les autres sélecteurs déclarés dans le SDP correspondent aux propriétés du fichier, autrement, le receveur de fichier DEVRAIT considérer que le transfert de fichier a échoué et DEVRAIT informer l'utilisateur.

 	8.2.3	Offre SDP pour plusieurs fichiers
Un offreur qui souhaite envoyer ou recevoir plus d'un fichier génère une ligne "m=" par fichier avec les attributs de fichier décrits dans cette spécification. De cette façon, le répondeur peut rejeter des fichiers individuels en réglant le numéro d'accès de leurs lignes "m=" associées à zéro, selon les procédures régulières de SDP [RFC4566]. De même, le répondeur peut accepter chaque fichier individuel séparément en réglant le numéro d'accès de ses lignes "m=" associées à une valeur non zéro .Chaque fichier a son propre identifiant de transfert de fichier, qui identifie de façon univoque chaque transfert de fichier.

Utiliser une ligne "m=" par fichier implique que des fichiers différents sont transférés en utilisant différentes sessions MSRP. Cependant, toutes ces sessions MSRP peuvent être établies à fonctionner sur une seule connexion TCP, comme décrit au paragraphe 8.1 de la [RFC4975]. La même connexion TCP peut aussi être réutilisée pour des transferts de fichiers à la suite.

 	8.3	Comportement du répondeur
Si le répondeur souhaite rejeter un fichier offert par l'offreur, il règle à zéro le numéro d'accès de la ligne "m=" associée au fichier, selon les procédures régulières de SDP [RFC4566]. La réponse rejetée DOIT contenir des attributs "file-selector" et "file-transfer-id" dont les valeurs reflètent les valeurs correspondantes de l'offre SDP.

Si le répondeur décide d'accepter le fichier, il procède selon les procédures régulières de MSRP [RFC4975] et de SDP [RFC4566].

 	8.3.1	Le répondeur est un receveur de fichier
Dans une opération poussée, le répondeur SDP est le receveur de fichier. Quand le receveur de fichier obtient l'offre SDP, il examine d'abord le numéro d'accès. Si le numéro d'accès est réglé à zéro, l'opération de transfert de fichier est close, et aucunes données supplémentaires ne sont attendues sur le flux de supports. Puis, si le numéro d'accès est différent de zéro, le receveur de fichier inspecte l'attribut "file-transfer-id". Si la valeur de l'attribut "file- transfer-id" a été utilisée précédemment, alors la session existante reste sans changement ; peut-être le transfert de fichier est encore en cours, ou peut-être il est terminé, mais il n'y a pas de changement par rapport à l'état acuuel. Dans tous les cas, indépendamment du numéro d'accès, le répondeur SDP crée une réponse SDP régulière et l'envoie à l'offreur.

Si le numéro d'accès est différent de zéro et si l'offre SDP contient un nouvel attribut "file-transfer-id", alors il signale une demande d'un nouveau transfert de fichier. Le répondeur SDP extrait les attributs et paramètres qui décrivent le fichier et normalement demande la permission à l'utilisateur d'accepter ou rejeter la réception du fichier. Si l'opération de transfert de fichier est acceptée, le receveur de fichier DOIT créer une réponse SDP conforme aux procédures spécifiées dans la [RFC3264]. Si l'offre contient les sélecteurs "name", "type", ou "size" dans l'attribut "file-selector", le répondeur DOIT les copier dans la réponse. Le receveur de fichier copie la valeur de l'attribut "file-transfer-id" dans la réponse SDP. Ensuite le receveur de fichier DOIT ajouter un attribut de session ou de supports "recvonly" conformément aux procédures spécifiées dans la [RFC3264]. Le receveur de fichier NE DOIT PAS inclure d'attribut "file-icon", "file-disposition", ou "file-date" dans la réponse SDP.

Le receveur de fichier peut utiliser le hachage pour trouver si un fichier local avec le même hachage est déjà disponible, et dans ce cas, cela pourrait impliquer la réception d'un fichier dupliqué. Il appartient au répondeur de déterminer si le transfert de fichier est accepté ou non en cas de fichier dupliqué.

Si l'offre SDP contient un attribut "file-range" et si le receveur de fichier accepte de recevoir la gamme d'octets qui y est déclarée, le receveur de fichier DOIT inclure un attribut "file-range" dans la réponse SDP avec la même gamme de valeurs.  Si le receveur de fichier n'accepte pas la réception de cette gamme d'octets, il DEVRAIT rejeter le transfert du fichier.

Quand l'opération de transfert de fichier est achevée, le receveur de fichier calcule le hachage du fichier et DEVRAIT vérifier qu'elle correspond au hachage déclaré dans le SDP. Si elles ne correspondent pas, le receveur de fichier DEVRAIT considérer que le transfert de fichier a échoué et DEVRAIT en informer l'utilisateur. De même, le receveur de fichier DEVRAIT aussi vérifier que les autres sélecteurs déclarés dans le SDP correspondent aux propriétés du fichier ; autrement, le receveur de fichier DEVRAIT considérer que le transfert de fichier a échoué et DEVRAIT en informer l'utilisateur.

 	8.3.2	Le répondeur est un envoyeur de fichier
Dans une opération tirée, le répondeur est l'envoyeur de fichier. Dans ce cas, le répondeur SDP DOIT d'abord inspecter la valeur de l'attribut "file-transfer-id". Si il n'a pas été utilisé précédemment dans la session, alors l'acceptation du fichier DOIT provoquer le transfert du fichier sur le protocole négocié. Cependant, si la valeur a été précédemment utilisée par une autre opération de transfert de fichier dans la session, l'envoyeur de fichier NE DOIT PAS alors alerter l'utilisateur et NE DOIT PAS commencer un nouveau transfert du fichier. Qu'un transfert de fichier réel soit initié ou non, l'envoyeur de fichier DOIT créer une réponse SDP appropriée qui contienne l'attribut "file-transfer-id" avec la même valeur que reçue dans l'offre SDP, et ensuite il DOIT continuer le traitement de la réponse SDP.

L'envoyeur de fichier DOIT toujours créer une réponse SDP conforme aux procédures d'offre/réponse SDP spécifiées dans la [RFC3264]. L'envoyeur de fichier inspecte le sélecteur de fichier de l'offre SDP reçue, qui est codée dans la ligne d'attribut de support "file-selector". Ensuite, l'envoyeur de fichier applique le sélecteur de fichier, ce qui implique de choisir les fichiers qui correspondent un à un aux sélecteurs "name", "type", "size", et "hash" de la ligne d'attribut "file-selector" (si ils sont présents). Le sélecteur de fichier identifie zéro, un ou plusieurs fichiers candidats à envoyer. Si le sélecteur de fichier est incapable d'identifier un fichier, le répondeur DOIT alors rejeter le flux MSRP pour le transfert de fichier en réglant le numéro d'accès à zéro, et alors le répondeur DEVRAIT aussi rejeter le SDP selon les procédures de la [RFC3264], si c'est le seul flux décrit dans l'offre SDP.

Si le sélecteur de fichier pointe sur un seul fichier et si l'envoyeur de fichier décide d'accepter le transfert de fichier, l'envoyeur de fichier DOIT créer une réponse SDP qui contienne un attribut "sendonly", conformément aux procédures décrites dans la [RFC3264]. L'envoyeur de fichier DEVRAIT ajouter un sélecteur "hash" dans la réponse avec le hachage SHA-1 calculé en local sur le fichier complet. Si une valeur de hachage calculée par l'envoyeur de fichier diffère de celle spécifiée par le receveur de fichier, l'envoyeur de fichier peut soit envoyer le fichier sans cette valeur de hachage, soit rejeter la demande en réglant l'accès dans le flux de supports à zéro. L'envoyeur de fichier PEUT aussi inclure un sélecteur "type" dans la ligne de l'attribut "file-selector" de la réponse SDP. Le répondeur PEUT aussi inclure des attributs "file-icon" et "file-disposition" pour mieux décrire le fichier. Bien que le répondeur PUISSE aussi inclure des sélecteurs "name" et "size" dans l'attribut "file-selector", et un attribut "file-date", il est RECOMMANDÉ de ne pas les inclure dans la réponse SDP si le protocole de transfert de fichier réel (par exemple, MSRP [RFC4975]) peut s'accommoder d'un champ d'en-tête Content-Disposition [RFC2183] avec les paramètres équivalents.

L'idée d'ajouter des descripteurs de fichier à SDP est de donner un mécanisme permettant qu'un transfert de fichier puisse être accepté avant qu'il commence. Ajouter des attributs SDP qui sont autrement signalés plus tard dans le protocole de transfert de fichier dupliquerait simplement l'information, mais ne fournirait aucune information à l'offreur pour accepter ou rejeter le transfert de fichier (noter que l'offreur demande un fichier).

Enfin, si le sélecteur de fichier pointe sur plusieurs fichiers candidats, le répondeur PEUT utiliser des politiques locales, par exemple, consulter l'utilisateur, choisir un des fichiers pour être défini dans la réponse SDP. Si ce choix ne peut pas être fait, le répondeur DEVRAIT rejeter le flux de supports MSRP pour le transfert de fichier (en réglant le numéro d'accès à zéro).

Si le besoin s'en fait sentir, de futures spécifications pourront fournir un mécanisme convenable qui permette de choisir plusieurs fichiers ou, par exemple, de résoudre des ambiguïtés en retournant une liste de fichiers qui correspondent au sélecteur de fichier.

Si l'offre SDP contient un attribut "file-range" et si l'envoyeur de fichier accepte d'envoyer la gamme d'octets qui y est déclarée, l'envoyeur de fichier DOIT inclure un attribut "file-range" dans la réponse SDP avec la même gamme de valeurs. Si l'envoyeur de fichier n'accepte pas d'envoyer cette gamme d'octets, il DEVRAIT rejeter le transfert du fichier.

 	8.4	Interruption d'une opération de transffert de fichier en cours
L'envoyeur ou le receveur de fichier peut interrompre à tout moment un transfert de fichier en cours. Sauf noté autrement, l'entité qui interrompt une opération de transfert de fichier en cours DOIT suivre les procédures au niveau du support (par exemple, MSRP) et au niveau signalisation (offre/réponse SDP) comme décrit ci-dessous.

On suppose le scénario décrit à la Figure 4 où un envoyeur de fichier souhaite interrompre un transfert de fichier en cours sans initier un transfert de fichier de remplacement. On suppose qu'une demande MSRP SEND est en cours de transmission. L'envoyeur de fichier interrompt le message MSRP en incluant le caractère "#" dans le champ de continuation de la ligne de fin d'une demande SEND, conformément aux procédures de MSRP (voir le paragraphe 7.1 de la [RFC4975]). Comme un fichier est transmis par un message MSRP, interrompre le message MSRP interrompt effectivement le transfert de fichier. Le receveur de fichier accuse réception de la demande MSRP SEND avec une réponse 200. Ensuite l'envoyeur de fichier DEVRAIT clore la session MSRP en créant une nouvelle offre SDP qui règle le numéro d'accès à zéro dans la ligne "m=" qui décrit le transfert de fichier (voir le paragraphe 8.2 de la [RFC3264]). Cette offre SDP DOIT se conformer aux exigences du paragraphe 8.2.1. L'attribut "file-transfer-id" DOIT être le même attribut qui identifie le transfert en cours. Ensuite l'envoyeur de fichier envoie cette offre SDP au receveur de fichier.

Plutôt que de clore la session MSRP en réglant le numéro d'accès à zéro dans la ligne "m=" concernée, l'envoyeur de fichier pourrait aussi supprimer toute la session, par exemple, en envoyant une demande SIP BYE.

Noter qu'il est de la responsabilité de l'envoyeur de fichier de supprimer la session MSRP. Les mises en œuvre devraient être prêtes à faire face à de mauvais comportements et à mettre en œuvre des mesures pour éviter des états pendants. Par exemple, à l'expiration d'un temporisateur, le receveur de fichier peut clore la session MSRP interrompue en utilisant les procédures MSRP régulières.

Un receveur de fichier qui reçoit l'offre SDP ci-dessus crée une réponse SDP conformément aux procédures de l'offre/réponse SDP [RFC3264]. Cette réponse SDP DOIT se conformer aux exigences du paragraphe 8.3.1. Le receveur de fichier envoie ensuite cette réponse SDP à l'envoyeur de fichier.

                   Envoyeur de fichier        Receveur de fichier
                            |\                        |
                            | \                       |
                            |  \                      |
                            |   \                     |
                            |    \                    |
                            |     \                   |
             interruption-->|      \  MSRP SEND (#)   |
                            |       +---------------->|
                            | MSRP 200                |
                            |<------------------------|
                            | re-INVITE (offre SDP)   |
                            |------------------------>|
                            | SIP 200 OK (réponse SDP)|
                            |<------------------------|
                            | SIP ACK                 |
                            |------------------------>|
                            |                         |

Figure 4 : Envoyeur de fichier qui interrompt un transfert de fichier en cours

Quand le receveur de fichier veut interrompre le transfert de fichier, il y a deux scénarios possibles, selon la valeur de l'en-tête Failure-Report dans la demande MSRP SEND en cours. Supposons maintenant le scénario décrit à la Figure 5 où la demande MSRP SEND inclut un en-tête Failure-Report réglé à une valeur différente de "no". Quand le receveur de fichier souhaite interrompre le transfert de fichier en cours, le receveur de fichier génère une réponse MSRP 413  à la demande MSRP SEND en cours (voir le paragraphe 10.5 de la [RFC4975]). Le receveur de fichier DOIT alors clore la session MSRP en générant une nouvelle offre SDP qui règle le numéro d'accès à zéro dans la ligne "m=" concernée qui décrit le transfert de fichier (voir le paragraphe 8.2 de la [RFC3264]). Cette offre SDP DOIT se conformer aux exigences exprimées au paragraphe 8.2.2. L'attribut "file-transfer-id" DOIT être le même attribut que celui qui identifie le transfert en cours. Alors le receveur de fichier envoie cette offre SDP à l'envoyeur de fichier.

                Envoyeur de fichier        Receveur de fichier
                         |                         |
                         |\                        |
                         | \  MSRP SEND            |
                         |  \ Failure-Report: oui  |
                         |   \                     |
                         |    \                    |
                         |     \                   |
                         |      \                  |
                         |       \                 |
                         |        \                |
                         | MSRP 413                |<-interruption
                         |<------------------------|
                         |          \   (#)        |
                         |           +------------>|
                         | re-INVITE (offre SDP)   |
                         |<------------------------|
                         | SIP 200 OK (réponse SDP)|
                         |------------------------>|
                         | SIP ACK                 |
                         |<------------------------|
                         |                         |

Figure 5 : Le receveur de fichier interrompt un transfert de fichier en cours. Failure-Report réglé à une valeur différente de "no" dans MSRP

Dans un autre scénario, décrit à la Figure 6, un transfert de fichier a lieu, où la demande MSRP SEND contient un en-tête Failure-Report réglé à la valeur "no". Quand le receveur de fichier veut interrompre le transfert en cours, il DOIT clore la session MSRP en générant une nouvelle offre SDP qui règle le numéro d'accès à zéro dans la ligne "m=" concernée qui décrit le transfert de fichier (voir le paragraphe 8.2 de la [RFC3264]). Cette offre SDP DOIT se conformer aux exigences exprimées au paragraphe 8.2.2. L'attribut "file-transfer-id" DOIT être le même attribut que celui qui identifie le transfert en cours. Ensuite le receveur de fichier envoie cette offre SDP à l'envoyeur de fichier.

                Envoyeur de fichier        Receveur de fichier
                         |\                        |
                         | \  MSRP SEND            |
                         |  \ Failure-Report: no   |
                         |   \                     |
                         |    \                    |
                         |     \                   |
                         |      \                  |
                         |       \                 |
                         | re-INVITE (offre SDP)   |<-interruption
                         |<------------------------|
                         |          \   (#)        |
                         |           +------------>|
                         | MSRP 200                |
                         |<------------------------|
                         | SIP 200 OK (réponse SDP)|
                         |------------------------>|
                         | SIP ACK                 |
                         |<------------------------|
                         |                         |

Figure 6 : Le receveur de fichier interrompt un transfert de fichier. Failure-Report réglé à "no" dans MSRP

Un envoyeur de fichier qui reçoit une offre SDP réglant le numéro d'accès à zéro dans la ligne "m=" concernée pour un transfert de fichier, d'abord, si une demande MSRP SEND en cours est transmise, interrompt le message MSRP en incluant le caractère '#' dans le champ de continuation de la fin de ligne d'une demande SEND, conformément aux procédures de MSRP (voir le paragraphe 7.1 de la [RFC4975]). Dans la mesure où un fichier est transmis comme un seul message MSRP, interrompre le message MSRP interrompt effectivement le transfert de fichier. Ensuite l'envoyeur de fichier crée une réponse SDP conformément aux procédures d'offre/réponse SDP ([RFC3264]). Cette réponse SDP DOIT se conformer aux exigences du paragraphe 8.3.2. Ensuite l'envoyeur de fichier envoie cette réponse SDP au receveur de fichier.

 	8.5	Indication de la capacité d'offre/réponse de transfert de fichier
Le modèle d'offre/réponse SDP [RFC3264] fournit des dispositions pour indiquer une capacité à un autre point d'extrémité (voir la Section 9 de la [RFC3264]). Le mécanisme suppose un protocole de niveau supérieur, comme SIP [RFC3261], qui fournit une interrogation de capacité (comme avec une demande SIP OPTIONS). La [RFC3264] indique comment construire le SDP qui est inclus dans la réponse à une telle interrogation de capacités. À ce titre, la RFC 3264 indique qu'un point d'extrémité construit un corps SDP qui contient une ligne "m=" contenant le type de support (message, pour MSRP).  Un point d'extrémité qui met en œuvre les procédures spécifiées dans le présent document DEVRAIT aussi ajouter un attribut de support "file-selector" pour la ligne "m=message". l'attribut de support "file-selector" DOIT être vide, c'est-à-dire, il NE DOIT PAS contenir de sélecteur. Le point d'extrémité NE DOIT PAS ajouter d'autre attribut de fichier défini dans cette spécification.

 	8.6	Réutilisation de lignes "m=" existantes dans SDP
Le modèle d'offre/réponse SDP [RFC3264] donne des règles qui permettent aux offreurs et répondeurs SDP de modifier une ligne de supports existante, c'est-à-dire, de réutiliser une ligne de support existante avec des attributs différents. La même chose est aussi possible quand SDP signale une opération de transfert de fichier selon les règles du présent mémoire. Donc, les procédures définies dans la [RFC3264], en particulier celles définies au paragraphe 8.3, DOIVENT s'appliquer pour les opérations de transfert de fichier. Un point d'extrémité qui veut réutiliser une ligne "m=" existante pour commencer le transfert de fichier d'un autre fichier crée un attribut "file-selector" différent et choisit une nouvelle valeur aléatoire unique au monde de l'attribut "file-transfer-id".

Si l'offreur de fichier renvoie une offre SDP avec un accès différent de zéro, alors l'attribut "file-transfer-id" détermine si un nouveau transfert de fichier va commencer ou si le transfert de fichier n'a pas besoin de commencer. Si le répondeur SDP accepte le SDP, alors le transfert de fichier commence à partir de l'octet indiqué (si un attribut "file-range" est présent).

 	8.7	Utilisation de MSRP
Le service de transfert de fichier spécifié dans le présent document utilise les lignes "m=" de SDP pour décrire le transfert unidirectionnel d'un fichier. Par conséquent, chaque session MSRP établie suivant les procédures des paragraphes 8.2 et 8.3 est seulement utilisé pour transférer un seul fichier. Donc, les envoyeurs DOIVENT seulement utiliser la session MSRP dédiée pour envoyer le fichier décrit dans l'offre ou réponse SDP. C'est-à-dire, les envoyeurs NE DOIVENT PAS envoyer des fichiers supplémentaires sur la même session MSRP.

Le transfert de fichier peut être réalisé en utilisant une nouvelle session multimédia établie à cette fin. Autrement, un transfert de fichier peut être conduit au sein d'une session multimédia existante, sans égard au support utilisé dans cette session. On notera particulièrement qu'un transfert de fichier peut être fait au sein d'une session multimédia contenant une session MSRP utilisée pour la messagerie instantanée régulière. Si un transfert de fichier est initié au sein d'une session multimédia existante, l'offreur SDP NE DOIT PAS réutiliser une ligne "m=" existante qui est encore utilisée par MSRP (un MSRP régulier pour la messagerie instantanée ou un transfert de fichier en cours). Il DOIT plutôt ajouter une ligne "m=" supplémentaire ou autrement réutiliser une ligne "m=" qui n'est plus utilisée.

De plus, les mises en œuvre conformes à la présente spécification DOIVENT inclure un seul fichier dans un seul message MSRP. Noter que la spécification MSRP définit "message MSRP" comme une unité complète de MIME ou de contenu de texte, qui peut être partagée et livrée en plus d'une demande MSRP ; chaque portion du message complet est appelée un "tronçon". Donc, il est encore valide d'envoyer un fichier en plusieurs tronçons, mais du point de vue de MSRP, tous les tronçons ensemble forment un message MSRP : le message de présence commune et messagerie instantanée (CPIM, Common Presence and Instant Messaging) qui enveloppe le fichier. Quand le tronçonnage est utilisé, on devrait noter que MSRP n'exige pas d'attendre une réponse de classe 200 pour un tronçon avant d'envoyer le suivant. Donc, il est valide d'envoyer des demandes MSRP SEND en parallèle contenant des tronçons du même message MSRP (le fichier). Le paragraphe 9.1 contient un exemple d'un transfert de fichier utilisant des demandes MSRP en parallèle.

La spécification MSRP [RFC4975] définit un attribut "max-size" SDP. Cet attribut spécifie le nombre maximum d'octets d'un message MSRP que le créateur du SDP veut recevoir (noter encore la définition du "message MSRP"). Les receveurs de fichier PEUVENT ajouter un attribut "max-size" à la ligne "m=" MSRP qui spécifie le fichier, indiquant le nombre maximum d'octets d'un message MSRP. Les envoyeurs de fichier NE DOIVENT PAS excéder la limite "max-size" pour un message envoyé dans la session résultante.

En l'absence d'un attribut "file-range" dans le SDP, le transfert de fichier MSRP DOIT commencer par le premier octet du fichier et se terminer avec le dernier octet (c'est-à-dire, tout le fichier est transféré). Si un attribut "file-range" est présent dans le SDP, l'application d'envoyeur de fichier DOIT extraire la gamme indiquée d'octets du fichier (décalage d"octets de début et de fin, tous deux inclus). Ensuite l'application d'envoyeur de fichier PEUT envelopper ces octets dans une enveloppe appropriée. MSRP oblige les mises en œuvre à utiliser l'enveloppe message/cpim [RFC3862]. L'usage d'une enveloppe est négociée dans le SDP (voir le paragraphe 8.6 de la [RFC4975]). Enfin, l'application d'envoyeur de fichier livre le contenu (par exemple, le corps message/cpim) à MSRP pour le transport. MSRP va considérer le contenu livré comme un message entier, et va commencer à numéroter les octets à 1.

Noter que la disposition de contenu par défaut des corps MSRP est "render". Quand MSRP est utilisé pour transférer des fichier, l'en-tête Content-Disposition de MSRP peut aussi prendre la valeur "attachment" comme indiqué à la Section 7.

Une fois le transfert de fichier achevé, l'envoyeur de fichier DEVRAIT clore la session MSRP et DOIT se comporter conformément aux procédures de MSRP [RFC4975] pour la clôture des sessions MSRP. Noter que la gestion de session MSRP n'a pas de rapport avec la gestion de connexion TCP. En fait, MSRP permet que plusieurs sessions MSRP partagent la même connexion TCP.

 	8.8	Considérations sur l'attribut "file-icon"
La présente spécification permet à l'envoyeur d'un fichier d'inclure une petite vue préalable d'une image de fichier : une icône. Un attribut "file-icon" contient un URL Content-ID (CID) [RFC2392] pointant sur un corps supplémentaire qui contient l'icône réelle. Comme l'icône est envoyée comme un corps séparé avec le corps SDP, l'envoyeur de fichier DOIT envelopper le corps SDP et les corps d'icônes dans un corps MIME multipart/related. Donc, les mises en œuvre conformes à la présente spécification DOIVENT utiliser le type multipart/related MIME [RFC2387]. Quand on crée une enveloppe multipart/related MIME, le corps SDP DOIT être le corps racine, qui selon la [RFC2387] est identifié comme le premier corps dans l'enveloppe multipart/related MIME ou explicitement identifié par le paramètre "start". Selon la [RFC2387], le paramètre "type" DOIT être présent et pointer sur le corps racine, c'est-à-dire, le corps SDP.

Supposons qu'un point d'extrémité se comportant conformément à la présente spécification essaye d'envoyer un fichier à un point d'extrémité distant qui ne met en œuvre ni la présente spécification ni le corps multipart MIME. L'envoyeur de fichier envoie une offre SDP qui contient un coprs multipart/related MIME qui inclut une partie de corps SDP et une partie de corps icône. Le receveur de fichier, qui ne prend pas en charge les types MIME multipart, va rejeter l'offre SDP via un mécanisme de protocole supérieur (par exemple, SIP). Dans ce cas, il est RECOMMANDÉ que l'envoyeur de fichier supprime la partie de corps icône, crée un seul corps SDP (c'est-à-dire, sans multipart MIME) et renvoie l'offre SDP. Cela fournit une certaine rétro compatibilité avec les receveurs de fichier qui ne mettent pas en œuvre la présente spécification et augmente les chances d'avoir le SDP accepté chez le receveur de fichier.

Comme l'icône est envoyée au titre de la signalisation, il est RECOMMANDÉ de garder la taille des icônes restreinte au nombre d'octets minimum qui a une signification.

 	9.	Exemples
 	9.1	L'offreur envoie un fichier au répondeur
Cette Section montre un exemple de flux pour un scénario de transfert de fichier. L'exemple suppose que SIP [RFC3261] est utilisé pour transporter l'échange d'offre/réponse SDP, bien que les détails de SIP soient montrés abrégés pour rester concis.

Alice, l'offreur SDP, souhaite envoyer un fichier d'image à Bob (le répondeur). Le client d'agent d'utilisateur (UAC, User Agent Client) d'Alice crée une offre SDP unidirectionnelle qui contient la description du fichier qu'elle veut envoyer au serveur d'agent d'utilisateur (UAS; User Agent Server) de Bob. La description inclut aussi une icône représentant le contenu du fichier à transférer. La séquence du flux est montrée à la Figure 7.

                   UAC d'Alice                 UAC de Bob
                         |                         |
                         |(1) (SIP) INVITE         |
                         |------------------------>|
                         |(2) (SIP) 200 OK         |
                         |<------------------------|
                         |(3) (SIP) ACK            |
                         |------------------------>|
                         |                         |
                         |(4) (MSRP) SEND (tronçon)|
                         |------------------------>|
                         |(5) (MSRP) SEND (tronçon)|
                         |------------------------>|
                         |(6) (MSRP) 200 OK        |
                         |<------------------------|
                         |(7) (MSRP) 200 OK        |
                         |<------------------------|
                         |                         |
                         |(8) (SIP) BYE            |
                         |------------------------>|
                         |(9) (SIP) 200 OK         |
                         |<------------------------|
                         |                         |

Figure 7 : Diagramme de flux d'un offreur envoyant un fichier à un répondeur

F1 : Alice construit une description SDP du fichier à envoyer et l'attache à une demande SIP INVITE adressée à Bob.

INVITE sip:bob@exemple.com SIP/2.0
To: Bob <sip:bob@exemple.com>
From: Alice <sip:alice@exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.exemple.com>
Content-Type: multipart/related; type="application/sdp"; boundary="boundary71"
Content-Length: [longueur]

--boundary71
Content-Type: application/sdp
Content-Length: [longueur de SDP]

v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.exemple.com
s=
c=IN IP4 alicepc.exemple.com
t=0 0
m=message 7654 TCP/MSRP *
i=C'est ma dernière photo
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.exemple.com:7654/jshA7we;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
     size:4092 hachage:sha-1:
     72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
a=file-disposition:render
a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300"
a=file-icon:cid:id2@alicepc.exemple.com

--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id2@alicepc.exemple.com>
Content-Length: [longueur d'image]
Content-Disposition: icon

[...petite icône de prévue du fichier...]

--boundary71--

Figure 8 : Demande INVITE contenant une offre SDP de transfert de fichier

Note : le champ d'en-tête Content-Type et l'attribut "file-selector" dans la figure sont sur plusieurs lignes pour les nécessités du formatage. Une mise en œuvre réelle le code sur une seule ligne.

À partir de maintenant on omet les détails SIP pour faire bref.

F2 : Bob reçoit la demande INVITE, inspecte l'offre SDP et extrait le corps de l'icône, vérifie la date de création et la taille de fichier, et décide d'accepter le transfert de fichier. Donc Bob crée la réponse SDP suivante :

v=0
o=bob 2890844656 2890844656 IN IP4 bobpc.exemple.com
s=
c=IN IP4 bobpc.exemple.com
t=0 0
m=message 8888 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.exemple.com:8888/9di4ea;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
     size:4092 hash:sha-1:
     72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE

Figure 9: Réponse SDP acceptant l'offre SDP de transfert de fichier

Note : l'attribut "file-selector" dans la figure est sur trois lignes pour les nécessités de formatage. Une mise en œuvre réelle le code sur une seule ligne.

F4 : Alice ouvre une connexion TCP avec Bob et crée une demande MSRP SEND. Cette demande SEND contient le premier tronçon du fichier.

MSRP d93kswow SEND
To-Path: msrp://bobpc.exemple.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.exemple.com:7654/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2048/4385
Content-Type: message/cpim

To: Bob <sip:bob@exemple.com>
From: Alice <sip:alice@exemple.com>
DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool picture.jpg";
                      creation-date="Mon, 15 May 2006 15:01:31 +0300";
                      size=4092
Content-Type: image/jpeg

... premier ensemble d'octets de l'image JPEG ...
   -------d93kswow+

Figure 10 : Demande MSRP SEND contenant le premier tronçon du fichier réel

F5 : Alice envoie le second et dernier tronçon. Noter que MSRP permet d'envoyer des tronçons en parallèle, de sorte qu'il n'est pas besoin d'attendre la réponse 200 (OK) sur le tronçon précédent.

MSRP op2nc9a SEND
To-Path: msrp://bobpc.exemple.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.exemple.com:7654/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 2049-4385/4385
Content-Type: message/cpim

... second ensemble d'octets de l'image JPEG ...
   -------op2nc9a$

Figure 11 : Demande MSRP SEND contenant le second tronçon du fichier réel

F6 : Bob accuse réception du premier tronçon.

MSRP d93kswow 200 OK
To-Path: msrp://alicepc.exemple.com:7654/iau39;tcp
From-Path: msrp://bobpc.exemple.com:8888/9di4ea;tcp
Byte-Range: 1-2048/4385
-------d93kswow$

Figure 12 : Réponse MSRP 200 OK

F7 : Bob accuse réception du second tronçon.

MSRP op2nc9a 200 OK
To-Path: msrp://alicepc.exemple.com:7654/iau39;tcp
From-Path: msrp://bobpc.exemple.com:8888/9di4ea;tcp
Byte-Range: 2049-4385/4385
-------op2nc9a$

Figure 13 : Réponse MSRP 200 OK

F8 : Alice termine la session SIP en envoyant une demande SIP BYE.

F9 : Bob accuse réception de la demande BYE et envoie une réponse 200 (OK).

 	9.2	L'offreur demande un fichier au répondeur et un second transfert de fichier
Dans cet exemple, Alice, l'offreur SDP, souhaite d'abord aller chercher un fichier chez Bob, le répondeur SDP. Alice sait que Bob a un fichier spécifique qu'elle veut télécharger. Elle a appris le hachage du fichier par un mécanisme hors bande. Le sélecteur de hachage est suffisant pour produire un sélecteur de fichier qui pointe sur le fichier spécifique. Donc, Alice crée une offre SDP qui contient le descripteur du fichier. Bob accepte le transfert de fichier et envoie le fichier à Alice. Quand Alice a complètement reçu le fichier de Bob, elle entend envoyer un nouveau fichier image à Bob. Donc, Alice réutilise la ligne de prise en charge SDP existante avec des attributs différents et met à jour la description du nouveau fichier qu'elle veut envoyer au serveur d'agent d'utilisateur (UAS) de Bob. En particulier, Alice crée un nouvel identifiant de transfert de fichier car c'est une nouvelle opération de transfert de fichier. La Figure 14 montre la séquence de flux.

                   UAC d'Alice                 UAC de Bob
                         |                         |
                         |(1) (SIP) INVITE         |
                         |------------------------>|
                         |(2) (SIP) 200 OK         |
                         |<------------------------|
                         |(3) (SIP) ACK            |
                         |------------------------>|
                         |                         |
                         |(4) (MSRP) SEND (fichier)|
                         |<------------------------|
                         |(5) (MSRP) 200 OK        |
                         |------------------------>|
                         |                         |
                         |(6) (SIP) INVITE         |
                         |------------------------>|
                         |(7) (SIP) 200 OK         |
                         |<------------------------|
                         |(8) (SIP) ACK            |
                         |------------------------>|
                         |                         |
                         |(9) (MSRP) SEND (fichier)|
                         |------------------------>|
                         |(10) (MSRP) 200 OK       |
                         |<------------------------|
                         |                         |
                         |(11) (SIP) BYE           |
                         |<------------------------|
                         |(12) (SIP) 200 OK        |
                         |------------------------>|
                         |                         |

Figure 14 : Diagramme de flux d'un offreur demandant un fichier au répondeur et envoyant un fichier en réponse

F1: Alice construit une description SDP du fichier qu'elle veut recevoir et attache l'offre SDP à une demande SIP INVITE adressée à Bob.

INVITE sip:bob@exemple.com SIP/2.0
To: Bob <sip:bob@exemple.com>
From: Alice <sip:alice@exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Max-Forwards: 70
Date: Sun, 21 May 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.exemple.com>
Content-Type: application/sdp
Content-Length: [longueur du SDP]

v=0
o=alice 2890844526 2890844526 IN IP4 alicepc.exemple.com
s=
c=IN IP4 alicepc.exemple.com
t=0 0
m=message 7654 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://alicepc.exemple.com:7654/jshA7we;tcp
a=file-selector:hachage:sha-1:
     72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2

Figure 15 : Demande INVITE contenant une offre SDP pour un transfert de fichier

Note : l'attribut "file-selector" dans la figure est sur deux lignes pour les besoins du formatage. Une mise en œuvre réelle le coderait sur une seule ligne.

À partir d'ici on omet les détails de SIP, pour faire court.

F2 : Bob reçoit la demande INVITE, inspecte l'offre SDP, calcule le descripteur de fichier, et trouve un fichier local dont le hachage est égal à celui indiqué dans le SDP. Bob accepte le transfert de fichier et crée une réponse SDP comme suit :

v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.exemple.com
s=
c=IN IP4 bobpc.exemple.com
t=0 0
m=message 8888 TCP/MSRP *
a=sendonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.exemple.com:8888/9di4ea;tcp
a=file-selector:type:image/jpeg hachage:sha-1:
     72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2

Figure 16 : Réponse SDP acceptant l'offre SDP de transfert de fichier

Note : l'attribut "file-selector" dans la figure est sur deux lignes pour les besoins de formatage. Une mise en œuvre réelle le coderait sur une seule ligne.

F4 : Alice ouvre une connexion TCP avec Bob. Bob crée alors une demande MSRP SEND qui contient le fichier.

   MSRP d93kswow SEND
   To-Path: msrp://alicepc.exemple.com:7654/jshA7we;tcp
   From-Path: msrp://bobpc.exemple.com:8888/9di4ea;tcp
   Message-ID: 12339sdqwer
   Byte-Range: 1-2027/2027
   Content-Type: message/cpim

   To: Bob <sip:bob@exemple.com>
   From: Alice <sip:alice@exemple.com>
   DateTime: 2006-05-15T15:02:31-03:00
   Content-Disposition: render; filename="My cool photo.jpg";
                  creation-date="Mon, 15 May 2006 15:01:31 +0300";
                  modification-date="Mon, 15 May 2006 16:04:53 +0300";
                  read-date="Mon, 16 May 2006 09:12:27 +0300";
                  size=1931
   Content-Type: image/jpeg

   ...image JPEG binaire...
   -------d93kswow$

Figure 17 : Demande MSRP SEND contenant le fichier réel

F5 : Alice accsuse réception de la demande SEND.

   MSRP d93kswow 200 OK
   To-Path: msrp://bobpc.exemple.com:8888/9di4ea;tcp
   From-Path: msrp://alicepc.exemple.com:7654/jshA7we;tcp
   Byte-Range: 1-2027/2027
   -------d93kswow$

Figure 18 : Réponse MSRP 200 OK

F6 : Alice réutilise la ligne de prise en charge SDP existante en insérant la description du fichier à envoyer et l'attache à une demande SIP re-INVITE adressée à Bob. Alice réutilise le numéro d'accès TCP pour le flux MSRP, mais change la session MSRP et la valeur de "file-transfer-id" conformément à la présente spécification.

   INVITE sip:bob@exemple.com SIP/2.0
   To: Bob <sip:bob@exemple.com>;tag=1928323431
   From: Alice <sip:alice@exemple.com>;tag=1928301774
   Call-ID: a84b4c76e66710
   CSeq: 2 INVITE
   Max-Forwards: 70
   Date: Sun, 21 May 2006 13:02:33 GMT
   Contact: <sip:alice@alicepc.exemple.com>
   Content-Type: multipart/related; type="application/sdp";
                 boundary="boundary71"
   Content-Length: [longueur de multipart]

   --boundary71
   Content-Type: application/sdp
   Content-Length: [longueur de SDP]

   v=0
   o=alice 2890844526 2890844527 IN IP4 alicepc.exemple.com
   s=
   c=IN IP4 alicepc.exemple.com
   t=0 0
   m=message 7654 TCP/MSRP *
   i=C'est ma dernière photo
   a=sendonly
   a=accept-types:message/cpim
   a=accept-wrapped-types:*
   a=path:msrp://alicepc.exemple.com:7654/iau39;tcp
   a=file-selector:name:"sunset.jpg" type:image/jpeg
     size:4096 hachage:sha-1:
     58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
   a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
   a=file-disposition:render
   a=file-date:creation:"Sun, 21 May 2006 13:02:15 +0300"
   a=file-icon:cid:id3@alicepc.exemple.com

   --boundary71
   Content-Type: image/jpeg
   Content-Transfer-Encoding: binary
   Content-ID: <id3@alicepc.exemple.com>
   Content-Length: [longueur de l'image]
   Content-Disposition: icon

   [..petite prévue de l'icône...]

   --boundary71--

Figure 19 : Réutilisation du SDP dans un second transfert de fichier

Note : le champ d'en-tête Content-Type et l'attribut "file-selector" dans la figure sont sur plusieurs lignes pour les besoins du formatage. Une mise en œuvre réelle les coderaient sur une seule ligne.

F7 : Bob reçoit la demande re-INVITE, inspecte l'offre SDP et extrait le corps de l'icône, vérifie la date de création et la taille du fichier, et décide d'accepter le transfert de fichier. Donc Bob crée une réponse SDP où il réutilise le même numéro d'accès TCP, mais change sa session MSRP, conformément aux procédures de cette spécification.

   v=0
   o=bob 2890844656 2890855440 IN IP4 bobpc.exemple.com
   s=
   c=IN IP4 bobpc.exemple.com
   t=0 0
   m=message 8888 TCP/MSRP *
   a=recvonly
   a=accept-types:message/cpim
   a=accept-wrapped-types:*
   a=path:msrp://bobpc.exemple.com:8888/eh10dsk;tcp
   a=file-selector:name:"sunset.jpg" type:image/jpeg
     size:4096 hachage:sha-1:
     58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
   a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
   a=file-disposition:render

Figure 20 : Réponse SDP acceptant l'offre SDP de transfert de fichier

Note : l'attribut "file-selector" dans la figure est sur trois lignes pour les besoins du formatage. Une mise en œuvre réelle le coderait sur une seule ligne.

F9 : Si une connexion TCP vers Bob est déjà ouverte, Alice réutilise cette connexion TCP pour envoyer une demande MSRP SEND qui contient le fichier.

   MSRP d95ksxox SEND
   To-Path: msrp://bobpc.exemple.com:8888/eh10dsk;tcp
   From-Path: msrp://alicepc.exemple.com:7654/iau39;tcp
   Message-ID: 13449sdqwer
   Byte-Range: 1-2027/2027
   Content-Type: message/cpim

   To: Bob <sip:bob@exemple.com>
   From: Alice <sip:alice@exemple.com>
   DateTime: 2006-05-21T13:02:15-03:00
   Content-Disposition: render; filename="Sunset.jpg";
                      creation-date="Sun, 21 May 2006 13:02:15 -0300";
                      size=1931
   Content-Type: image/jpeg

   ...image JPEG binaire...
   -------d95ksxox+

Figure 21 : Demande MSRP SEND contenant le fichier réel

F10 : Bob accuse réception de la demande SEND.

   MSRP d95ksxox 200 OK
   To-Path: msrp://alicepc.exemple.com:7654/iau39;tcp
   From-Path: msrp://bobpc.exemple.com:8888/eh10dsk;tcp
   Byte-Range: 1-2027/2027
   -------d95ksxox$

Figure 22 : Réponse MSRP 200 OK

F11 : Bob termine alors la session SIP en envoyant une demande SIP BYE.

F12 : Alice accuse réception de la demande BYE et envoie une réponse 200 (OK).

 	9.3	Exemple d'une indication Capability
Alice envoie une demande OPTIONS à Bob (cette demande ne contient pas de SDP). Bob répond avec un 200 (OK) qui contient le SDP montré à la Figure 24. Le SDP indique prendre en charge les messages CPIM qui peuvent contenir d'autres types MIME. La taille maximum de message MSRP que le point d'extrémité peut recevoir est de 20000 octets. La présence de l'attribut "file-selector" indique la prise en charge du mécanisme d'offre/réponse pour le transfert de fichier.

                   UAC d'Alice                 UAC de Bob
                         |                        |
                         |(1) (SIP) OPTIONS       |
                         |----------------------->|
                         |(2) (SIP) 200 OK        |
                         |          avec SDP      |
                         |<-----------------------|
                         |                        |
                         |                        |

Figure 23 : Diagramme de flux d'une demande de capacités

v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.exemple.com
s=-
c=IN IP4 bobpc.exemple.com
t=0 0
m=message 0 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=max-size:20000
a=file-selector

Figure 24 : SDP de la réponse 200 (OK) à une demande OPTIONS

 	10.	Considérations sur la sécurité

Les attributs SDP définis dans la présente spécification identifient un fichier à transférer entre deux points d'extrémité. Un point d'extrémité peut offrir d'envoyer le fichier à l'autre point d'extrémité ou demander à recevoir le fichier de l'autre point d'extrémité. Dans le premier cas, un attaquant modifiant ces attributs SDP pourrait tromper le receveur en lui faisant croire que le fichier à transférer est un fichier différent. Dans le second cas, l'attaquant pourrait faire envoyer par l'envoyeur un fichier différent de celui demandé par le receveur. Par conséquent, il est RECOMMANDÉ que la protection de l'intégrité soit appliquée aux descriptions de session SDP portant les attributs spécifiés dans la présente spécification. De plus, il est RECOMMANDÉ que les envoyeurs vérifient les propriétés du fichier avec les sélecteurs qui le décrivent.

Les descriptions des fichiers à transférer entre des points d'extrémité peuvent révéler des informations que les points d'extrémité peuvent considérer comme confidentielles. Donc, il est RECOMMANDÉ que les descriptions de session SDP portant les attributs spécifiés dans la présente spécification soient chiffrées.

TLS et S/MIME sont les choix naturels pour fournir des échanges d'offre/réponse avec protection de l'intégrité et de la confidentialité.

Quand une offre SDP contient la description d'un fichier à envoyer ou recevoir, le répondeur SDP DOIT d'abord authentifier l'offreur SDP et ensuite il DOIT autoriser l'opération de transfert de fichier, normalement en accord avec une politique locale. Normalement, ces fonctions sont intégrées dans le protocole de niveau supérieur qui porte SDP (par exemple, SIP) et dans le protocole de transfert de fichier (par exemple, MSRP). Si SIP [RFC3261] et MSRP [RFC4975] sont utilisés, les mécanismes standard pour l'authentification et l'autorisation sont suffisants.

Il est possible qu'une mise en œuvre malveillante ou au mauvais comportement essaye d'épuiser les ressources du point d'extrémité distant, par exemple, la mémoire interne ou le système de fichiers, en envoyant de très gros fichiers. Pour se protéger contre cette attaque, une réponse SDP DEVRAIT d'abord vérifier l'identité de l'offreur SDP, et peut-être seulement accepter des transferts de fichiers provenant de sources de confiance. Les mécanismes pour vérifier l'identité de l'envoyeur de fichier dépendent du protocole de niveau supérieur qui porte le SDP, par exemple, SIP [RFC3261] et MSRP [RFC4975].

Il est aussi RECOMMANDÉ que les mises en œuvre prennent des mesures pour éviter des attaques d'épuisement de ressource, par exemple, en limitant la taille des fichiers reçus, en vérifiant qu'il y a assez d'espace dans le système de fichiers pour mémoriser le fichier avant sa réception, ou en limitant le nombre de transferts de fichiers simultanés.

Les receveurs de fichier DOIVENT aussi vérifier toutes les entrées, comme le nom du fichier local, avant de faire des appels au système de fichiers local pour mémoriser un fichier. C'est pour empêcher l'existence de caractères significatifs pour le système d'exploitation local qui pourraient l'endommager.

Une fois qu'un fichier a été transféré, le receveur de fichier doit en prendre soin. Normalement, un transfert de fichier est un mécanisme couramment utilisé pour transmettre des virus informatiques, des logiciels d'espionnage, des virus, et d'autres types de malgiciels. Les receveurs de fichiers devraient appliquer toutes les technologies de sécurité possibles (par exemple, anti-virus, anti-espionnage) pour diminuer le risque de dommages à leur hôte.

 	11.	Considérations relatives à l'IANA

L'IANA a enregistré un certain nombre d'attributs SDP conformément à ce qui suit.

 	11.1	Enregistrement des nouveaux attributs SDP
L'IANA a enregistré un certain nombre d'attributs seulement de niveau support dans le registre des paramètres du protocole de description de session [IANA]. Les données d'enregistrement, conformément à la [RFC4566], suivent.

 	11.1.1	Enregistrement de l'attribut file-selector
Contact : Miguel Garcia <miguel.a.garcia@ericsson.com>
Nom de l'attribut : file-selector
Forme longue du nom de l'attribut : File Selector
Type d'attribut : seulement de niveau support. Cet attribut est soumis à l'attribut "charset".
Description : cet attribut identifie sans ambiguïté un fichier en indiquant une combinaison du quadruplet composé du nom, de la taille, du type, et du hachage du fichier.
Spécification : RFC 5547

 	11.1.2	Enregistrement de l'attribut file-transfer-id
Contact : Miguel Garcia <miguel.a.garcia@ericsson.com>
Nom de l'attribut : file-transfer-id
Forme longue du nom de l'attribut : File Transfer Identifier
Type d'attribut : seulement de niveau support. Cet attribut est soumis à l'attribut "charset".
Description : cet attribut contient un identifiant univoque de l'opération de transfert de fichier dans la session.
Spécification :  RFC 5547

 	11.1.3	Enregistrement de l'attribut file-disposition
Contact : Miguel Garcia <miguel.a.garcia@ericsson.com>
Nom de l'attribut : file-disposition
Forme longue du nom de l'attribut : File Disposition
Type d'attribut : seulement de niveau support. Cet attribut n'est pas soumis à l'attribut "charset".
Description : cet attribut fait une suggestion à l'autre point d'extrémité sur la disposition prévue du fichier.
Spécification : RFC 5547

 	11.1.4	Enregistrement de l'attribut file-date
Contact : Miguel Garcia <miguel.a.garcia@ericsson.com>
Nom de l'attribut : file-date
Forme longue du nom de l'attribut :
Type d'attribut : seulement de niveau support. Cet attribut n'est pas soumis à l'attribut "charset".
Description : cet attribut indique les dates auxquelles le fichier a été créé, modifié, ou lu pour la dernière fois.
Spécification : RFC 5547

 	11.1.5	Enregistrement de l'attribut file-icon
Contact :  Miguel Garcia <miguel.a.garcia@ericsson.com>
Nom de l'attribut : file-icon
Forme longue du nom de l'attribut : File Icon
Type d'attribut : seulement de niveau support. Cet attribut n'est pas soumis à l'attribut "charset".
Description : pour les fichiers d'image, cet attribut contient un pointeur sur un corps qui inclut une petite icône de prévue représentant le contenu du fichier à transférer.
Spécification : RFC 5547

 	11.1.6	Enregistrement de l'attribut file-range
Contact : Miguel Garcia <miguel.a.garcia@ericsson.com>
Nom de l'attribut : file-range
Forme longue du nom de l'attribut : File Range
Type d'attribut : seulement de niveau support. Cet attribut n'est pas soumis à l'attribut "charset".
Description : cet attribut contient la gamme des octets du fichier transférés.
Spécification : RFC 5547

 	12.	Remerciements

Les auteurs tiennent à remercier Mats Stille, Nancy Greene, Adamu Haruna, et Arto Leppisaari de la discussion des concepts initiaux décrits dans le présent mémoire. Merci à Pekka Kuure de sa relecture des versions initiales de ce document et de la fourniture d'utiles commentaires. Joerg Ott, Jiwey Wang, Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, Richard Barnes, et Chris Newman ont discuté et fourni des commentaires et améliorations à ce document.

 	13.	Références
 	13.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.)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (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.)

[RFC3174]	D. Eastlake 3 et P. Jones, "Algorithme US de hachage sécurisé n° 1 (SHA1)", septembre 2001, DOI 10.17487/RFC3174. (Info, MàJ par 4634 et 6234)

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002, DOI 10.17487/RFC3264. (P.S.  ; MàJ par RFC8843, 9143)

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

[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)

[RFC3862]	G. Klyne, D. Atkins, "Format de message commun pour la présence et la messagerie instantanée (CPIM)", août 2004. (P.S.)

[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)

[RFC4975]	B. Campbell, R. Mahy, et C. Jennings, "Protocole de relais de session de message (MSRP)", septembre 2007. (P.S ; MàJ par RFC7977, RFC8873) 

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

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

 	13.2	Références pour information

[IANA]	IANA, "Internet Assigned Numbers Authority", <http://www.iana.org>.

[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)

[RFC4028]	S. Donovan, J. Rosenberg, "Temporisateurs de session dans le protocole d'initialisation de session (SIP)", avril 2005. (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.)

[RFC4976]	C. Jennings et autres, "Extensions de relais au protocole de relais de session de message (MSRP)", septembre 2007. (P.S.. ; MàJ par RFC7977 ; RFC  8553, RFC  8996 )

[RFC6726]	T. Paila, et autres, "FLUTE – Livraison de fichier sur transport unidirectionnel", novembre 2012. (Remplace la RFC3926) (P.S.)

 	Appendice A.	Solutions de remplacement considérées

Les exigences sont relatives à la description et la négociation de la session, non au mécanisme réel de transfert de fichier. Donc, il est naturel qu'afin de les satisfaire il soit suffisant de définir des extensions d'attribut et des conventions d'usage à SDP, alors que MSRP lui-même n'a pas besoin d'extensions et peut être utilisé tel quel. C'est effectivement l'approche retenue dans cette spécification. Un autre but a été de spécifier les extensions à SDP de telle façon que un point d'extrémité MSRP régulier qui ne les prend pas en charge pourrait quand même dans certains cas agir comme un point d'extrémité dans une session de transfert de fichier, bien qu'avec une fonctionnalité un peu réduite.

D'une certaine façon, le but de la présente spécification est similaire à celui du mécanisme de redirection de contenu dans le protocole d'initialisation de session (SIP) [RFC4483]. Les deux mécanismes permettent à un agent d'utilisateur de décider de télécharger ou non un fichier sur la base d'informations sur le fichier. Cependant, il y a des différences. Avec la redirection de contenu, il n'est pas possible à l'autre point d'extrémité d'accepter ou rejeter explicitement le transfert de fichier. Aussi, il n'est pas possible à un point d'extrémité de demander un fichier à un autre point d'extrémité. De plus, la redirection de contenu n'est pas liée au contexte d'une session de supports, qui est parfois une propriété désirable. Finalement, la redirection de contenu exige normalement une infrastructure de serveur, qui peut n'être pas toujours disponible. Il est possible aussi d'utiliser la redirection de contenu directement entre les points d'extrémité, mais dans ce cas il n'y a pas de définition sur la façon dont elle fonctionne pour des points d'extrémité derrière des NAT. Le niveau des exigences dans les mises en œuvre décide quelle solution satisfait les exigences.

Sur la base de l'argumentation ci-dessus, le présent document définit les extensions d'attribut SDP et les conventions d'usage nécessaires pour satisfaire les exigences sur les services de transfert de fichier avec le modèle d'offre/réponse SDP, en utilisant MSRP comme protocole de transfert au sein d'une session.

En principe, il est possible d'utiliser les extensions à SDP définies ici et de remplacer MSRP par tout autre protocole similaire qui peut porter les objets MIME. Cette sorte de spécification peut être écrite dans un document distinct si le besoin se fait sentir. Essentiellement, un tel protocole devrait être capable d'être négocié sur un échange d'offre/réponse SDP [RFC3264], être capable de décrire le fichier à transférer dans un échange d'offre/réponse SDP, être capable de porter des objets MIME entre deux points d'extrémité, et d'utiliser un protocole de transport fiable (par exemple, TCP).

La présente spécification définit un ensemble d'attributs SDP qui décrivent un fichier à transférer entre deux points d'extrémité. Les informations nécessaires pour décrire un fichier pourraient être codées de quelques façons différentes. Le groupe de travail MMUSIC a considéré quelques approches de remplacement avant de décider d'utiliser le codage décrit à la Section 6. En particulier, le groupe de travail a examiné le type MIME "external-body" et l'utilisation d'un seul attribut ou paramètre SDP.

Un "external-body" MIME pourrait éventuellement être utilisé pour décrire le fichier à transférer. En fait, beaucoup des paramètres SDP que définit cette spécification sont aussi pris en charge par les parties de corps "external-body". Le groupe de travail MMUSIC a décidé de ne pas utiliser les parties de corps "external-body" parce que un certain nombre de mises en œuvre d'offre/réponse existantes ne prennent pas en charge les corps multi parties.

Les informations portées dans les attributs SDP définis à la Section 6 pourraient éventuellement être codées dans un seul attribut SDP. Le groupe de travail MMUSIC a décidé de ne pas uivre cette approche parce que on s'attend à ce que les  mises en œuvre prennent en charge seulement un sous ensemble des paramètres définis à la Section 6. Ces mises en œuvre vont être capables d'utiliser les règles SDP normales afin d'ignorer les paramètres SDP non pris en charge. Si toutes les informations étaient codées dans un seul attribut SDP, ces règles, qui se rapportent à la rétro compatibilité, devraient être redéfinies spécifiquement pour ce paramètre.

 	Adresse des auteurs

Miguel A. Garcia-Martin	Markus Isomaki	
Ericsson	Nokia	
Calle Via de los Poblados 13	Keilalahdentie 2-4	
Madrid, ES  28033	Espoo  02150	
Espagne	Finlande	
mél : miguel.a.garcia@ericsson.com	mél : markus.isomaki@nokia.com	

Gonzalo Camarillo	Salvatore Loreto	Paul H. Kyzivat	
Ericsson	Ericsson	Cisco Systems	
Hirsalantie 11	Hirsalantie 11	1414 Massachusetts Avenue	
Jorvas  02420	Jorvas  02420	Boxborough, MA  01719	
Finlande	Finlande	USA	
mél : Gonzalo.Camarillo@ericsson.com	mél : Salvatore.Loreto@ericsson.com	mél : pkyzivat@cisco.com