Groupe de travail Réseau	R. Gellens, Qualcomm	
Request for Comments : 4356	janvier 2006	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Transposition entre service de messagerie multimédia (MMS) et messagerie Internet

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

Notice de Copyright
Copyright (C) The Internet Society (2006).

Résumé
L'industrie du téléphone cellulaire a défini un service appelé service de messagerie multimédia (MMS, Multimedia Messaging Service). Ce service utilise des formats et protocoles similaires, mais différents sur des points clés, à ceux utilisés dans la messagerie Internet.

Une importante différence entre MMS et la messagerie Internet est que MMS utilise des en-têtes qui commencent par "X-Mms-" pour porter divers éléments d'information relatifs à l'agent d'utilisateur et au serveur.

Le présent document spécifie comment échanger des messages entre ces deux services, incluant la transposition des éléments d'information utilisés dans les en-têtes MMS X-Mms-* ainsi que les rapports de livraison et de disposition, de et vers ceux utilisés dans les en-têtes de message SMTP et Internet.
Table des matières
1. Introduction	1
1.1 Domaine d'application	1
1.2 Conventions utilisées dans ce document	2
1.3 Définitions	2
1.4 Abréviations	2
1.5 Hypothèses	3
2. Transposition entre MMS et messagerie Internet	3
2.1 Spécification de la transposition	3
3. Considérations sur la sécurité	13
4. Considérations relatives à l'IANA	13
5. Remerciements	13
6. Références normatives	14
7. Références pour information	14
Adresse de l'auteur	15
Déclaration complète de droits de reproduction	15

 	1.	Introduction
 	1.1	Domaine d'application
Le présent document décrit comment échanger des messages entre les systèmes du service de messagerie multimédia (MMS) (comme défini par [3GPP], [3GPP2], [OMA]) et les systèmes de messagerie Internet (c'est-à-dire, [RFC2821] et [RFC2822]). Cela inclut la traduction des formats de message, des éléments d'en-tête de message, des rapports de livraison de message [RFC3464], et des rapports de disposition de message [RFC3798].

L'architecture MMS [Stage_2] et ses spécifications [Stage_3] se réfèrent aux interfaces comme à des points de référence nommés MMx. Par exemple, MM1 est l'interface client-serveur, MM4 est l'interface serveur-serveur, et MM3 est une interface aux systèmes "externes" ou non MMS. La spécification du présent document peut être utilisée pour l'échange de messages entre tout système et protocole qui utilise les formats de message Internet et un système MMS ; du point de vue du système MMS, le point de référence MM3 est utilisé.

Le présent document inclut la prise en charge des messages vocaux spécifiés par le profil vocal pour la messagerie Internet [RFC3801]. La spécification VPIM permet l'échange de messages vocaux entre les systèmes de messagerie vocale qui utilisent le format de messagerie Internet [RFC2822] et sont transportés via la [RFC2821]. Donc, l'interface MMS MM3 prend en charge la capacité d'échanger des messages vocaux entre un système MMS et un système de messagerie vocale. Noter qu'une telle utilisation est distincte d'un support vocal qui fait partie d'un message multimédia composé par l'utilisateur.

Noter que MM3 peut aussi être utilisé pour inter fonctionner avec des systèmes "externes" (non MMS) autres que la messagerie Internet, comme le service de messages courts (SMS, Short Messaging Service) et l'accès à des magasins externes de messagerie (comme un système de messagerie vocale). La présente spécification ne traite pas de ces autres usages ou des sous interfaces de MM3 ; elle n'est concernée que par l'interfonctionnement avec la messagerie Internet et spécifiquement l'échange de messages.

Toutes les fonctions de MM3 étape 2 [Stage_2] sont prises en charge, sauf la tarification de réponse et la dissimulation de l'adresse de l'envoyeur.

 	1.2	Conventions utilisées dans ce document
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].

 	1.3	Définitions
Corps : portion du contenu d'un message [RFC2821] qui suit l'en-tête (c'est-à-dire, suivant la première ligne blanche). Le corps peut contenir des parties et des sous parties structurées, dont chacune peut avoir son propre en-tête et corps. Le corps contient des informations destinées au receveur du message (humain ou logiciel).

Contenu : portion d'un message SMTP qui est livré. Le contenu consiste en un en-tête et un corps.

Rapport de disposition /Notification de disposition de message : informations de rétroaction à un agent d'utilisateur d'origine par un agent d'utilisateur receveur sur le traitement d'un message original. Cela peut inclure la notification que le message a ou n'a pas été lu, a été supprimé non lu, etc.

Enveloppe : portion d'un message SMTP non incluse dans le contenu, c'est-à-dire, non dans l'en-tête ou dans le corps. Bien qu'une partie en puisse être copiée dans le contenu à la livraison, les informations d'enveloppe n'existent que lorsque le message est en transit, et contiennent des informations utilisées par les agents SMTP (agents de transfert de messagerie  (MTA, Mail Transfer Agent).

Passerelle : voir le paragraphe 2.3.8 de la [RFC2821].

En-tête : première partie du contenu d'un message SMTP. L'en-tête est séparé du corps par une ligne blanche. L'en-tête consiste en champs (comme "To:") aussi appelés champs d'en-tête ou en-têtes. L'en-tête de message contient des informations utilisées par les agents d'utilisateur.

Relais/serveur : un serveur MMS. Voir [Stage_2]. Pour les besoins du présent document, un relais/serveur MMS agit comme une passerelle quand il reçoit ou envoie des messages via la messagerie Internet.

Agent d'utilisateur : agent d'utilisateur MMS ou de messagerie électronique.

 	1.4	Abréviations
MSA (Message Submission Agent) : agent de soumission de message ; serveur qui accepte les messages provenant des agents d'utilisateur et les traite, les livrant en local ou les relayant à un MTA. Voir la [RFC2476].

MTA (Mail Transfer Agent) : agent de transfert de messagerie ; un serveur qui met en œuvre la [RFC2821].

 	1.5	Hypothèses
On suppose que le lecteur est déjà familier du contenu des documents du 3GPP2 Vue d'ensemble de la spécification MMS [Overview], des exigences d'étape 1 de MMS [Stage_1], des messages abstraits et architecture d'étape 2 [Stage_2], et des protocoles 3GPP/3GPP2 d'étape 3 [Stage_3]. On suppose aussi que le lecteur est familier de la messagerie Internet, en particulier des [RFC2821] et [RFC2822].

 	2.	Transposition entre MMS et messagerie Internet

Cette section définit l'inter fonctionnement entre les relais/serveurs MMS et les serveurs externes qui utilisent la [RFC2821] native. C'est-à-dire que les éléments d'information sont échangés en utilisant des champs d'en-tête standard de message Internet de la [RFC2822] comme ceux de la [RFC2076], et des éléments standard de la [RFC2821].

Les extensions à SMTP et à la messagerie Internet sont utilisées pour des caractéristiques comme les rapports de livraison, l'expiration de message, et la découverte de la prise en charge de serveur pour des caractéristiques facultatives.

 	2.1	Spécification de la transposition
 	2.1.1	De MMS à messagerie Internet
Quand il envoie un message à un système de messagerie Internet, le relais/serveur MMS DOIT convertir le message multimédia (MM) si nécessaire, et DOIT se conformer aux exigences de la [RFC2821].

Le relais/serveur MMS DEVRAIT utiliser les éléments d'information associés au MM pour définir les informations de contrôle (champs d'en-tête de message Internet et valeurs d'enveloppe SMTP) nécessaires pour le protocole de transfert.

Le paragraphe 2.1.3 fait la liste des transpositions entre les champs d'en-tête X-Mms-* et de message Internet et les valeurs SMTP.

Les MM de livraison et de rapport de lecture DEVRAIENT être convertis en format de rapport de message Internet standard (multipart/report). En plus de convertir les rapports de message Internet, le relais/serveur MMS DOIT générer des MM de rapport de livraison et de lecture pour les messages reçus comme approprié. Voir plus d'informations au paragraphe  2.1.4.

 	2.1.2	De messagerie Internet à MMS
Quand il reçoit un message d'un système de messagerie Internet, le relais/serveur MMS convertit les messages entrants au format de MM utilisé dans le système receveur.

Le relais/serveur MMS convertit les informations de contrôle reçues du serveur de messagerie Internet en les éléments d'information approprié d'un MM.

Le paragraphe 2.1.3 fait la liste des transpositions entre les en-têtes X-Mms-* et les champs d'en-tête de message Internet et les valeurs SMTP.

Le format standard des messages de rapport de message Internet (multipart/report) PEUT être converti pour livrer ou lire les MM de rapport, comme approprié. En plus de convertir les MM de rapport, les mises en œuvre conformes au présent document DOIVENT générer des rapports standard de livraison et disposition de message Internet pour les messages Internet reçus comme approprié. Voir plus d'informations au paragraphe 2.1.4.

 	2.1.3.	Transpositions d'éléments d'information MMS
Les transpositions entre les éléments de MMS et les éléments de message SMTP/Internet (paramètres de la [RFC2821], en-têtes de la [RFC2822], et champs de la [RFC3464]) sont résumés au tableau 1 ci-dessous, et détaillés dans les paragraphes suivants. Les "en-têtes MMS" proviennent de [OMA-MMS]. Noter que seuls les éléments d'information qui ont besoin d'être transposés figurent sur la liste. Les en-têtes de la [RFC2822] non cités ici DEVRAIENT être passés sans altération.

 	Tableau 1 : Transpositions d'éléments d'information
Élément d'information	Élément [RFC2821]	En-tête [RFC2822]	En-tête MMS	
Version MMS 3GPP	N/A	N/A	X-Mms-3GPP-MMS-Version:	
Type de message (de PDU) 	|N/A	N/A	X-Mms-Message-Type:	
Identifiant de transaction	N/A	N/A	X-Mms-Transaction-Id:	
Identifiant de message	N/A	Message-ID:	Message-ID:	
Adresses de réception	Adresses RCPT TO	To:, Cc:, ou omise (Bcc)	To:, Cc:, Bcc: 	
Adresse de l'envoyeur	Adresse MAIL FROM si générée par l'utilisateur ; DOIT régler MAIL FROM à nul ("<>") pour tous les MM générés automatiquement	From:  	From:	
Type de contenu	N/A	Content-Type: (Pour les messages vocaux conformes à la [RFC3801], voir la note 2)	Content-type:	
Classe de message	Class=auto: DOIT régler MAIL FROM à nul ("<>").	PEUT régler 'Precedence: bulk' sur class=auto 	X-Mms-Message-Class:	
Date et heure de soumission	N/A	Date:	Date:	
Heure d'expiration	DELIVER-BY [RFC2852]	N/A	X-Mms-Expiry:	
Première heure de livraison	(seulement pour soumission, pas pour relais)	N/A	X-Mms-Delivery-Time:	
Demande de rapport de livraison	DSN [RFC3461] DEVRAIT aussi spécifier l'adresse du receveur comme ORCPT ; DEVRAIT aussi spécifier ENVID	N/A	X-Mms-Delivery-Report:	
Importance ("priorité")	N/A	Importance: 	X-Mms-Priority:	
Visibilité de l'envoyeur	(non pris en charge actuellement)	(non pris en charge actuellement)	X-Mms-Sender-Visibility:	
Demande de réponse de lecture	N/A 	Disposition-Notification -To: [RFC3798]	X-Mms-Read-Reply:	
Permission de tarification de réponse	(non pris en charge actuellement)	(non pris en charge actuellement)	X-Mms-Reply-Charging:	
Fin de validité de permission de tarification de réponse	(non pris en charge actuellement)	(non pris en charge actuellement)	X-Mms-Reply-Charging-Deadline:	
Limitation de permission de tarification de réponse	(non pris en charge actuellement)	(non pris en charge actuellement)	X-Mms-Reply-Charging-Size:	
Demande d'usage de tarification de réponse	(non pris en charge actuellement)	(non pris en charge actuellement)	X-Mms-Reply-Charging-Id:	
Référence d'usage de tarification de réponse	(non pris en charge actuellement)	(non pris en charge actuellement)	X-Mms-Reply-Charging:	
Sujet	N/A	Subject:	Subject:	
Précédemment envoyé par	N/A	Resent-From:	X-Mms-Previously-Sent-By:	
Date d'envoi précédent	N/A	Resent-Date:	X-Mms-Previously-Sent-Date-and-Time:	
Trace de bond/hôte	N/A	Received:	(non pris en charge)	
Sensibilité	N/A	Sensitivity: voir Note 1	N/A	
Contenu	N/A	<corps du message>	<corps du message>	

Note 1 : L'élément d'en-tête 'Sensibilité' de la [RFC3801] indique la confidentialité demandée par l'origine du message (les valeurs sont "personnel" ou "privé") ; selon la [RFC3801], un receveur de message NE DOIT PAS transmettre un message avec un en-tête 'Sensibilité'. Comme la sensibilité n'est pas une caractéristique de MMS, aucun message contenant un en-tête 'Sensitivity:' NE DEVRAIT être envoyé à un système MMS.

Note 2 : La [RFC3801] spécifie comment les messages conformes sont identifiés.

 	2.1.3.2	Conversion des messages de format MMS en format Internet
Version MMS 3GPP : l'en-tête 'X-Mms-3GPP-MMS-Version:', si il est présent, DEVRAIT être retiré.

Type de message (de PDU) : l'en-tête 'X-Mms-Message-Type:', si il est présent, DEVRAIT être retiré.

Identifiant de transaction : l'en-tête 'X-Mms-Transaction-Id:', si il est présent, DEVRAIT être retiré.

Identifiant de message : l'en-tête 'Message-Id:' DOIT être conservé. Si il n'est pas présent, il DOIT être créé, avec une valeur unique, selon la [RFC2822]. Pour faciliter le cas où un message MMS traverse l'Internet avant de retourner à un système MMS, les mises en œuvre pourraient souhaiter conserver l'en-tête 'X-Mms-Message-Id:'. De tels systèmes devraient savoir que les en-têtes qui commencent par "X-" peuvent être supprimés durant le transit à travers les MTA de l'Internet.

Adresse du ou des receveurs : l'adresse de chaque receveur DOIT être transmise dans l'enveloppe de la [RFC2821] comme une valeur de RCPT TO. Tous les receveurs divulgués DEVRAIENT aussi apparaître dans un en-tête 'To:' ou 'Cc:'. Au moins un en-tête 'To:', 'Cc:', ou 'Bcc:' DOIT être présent. Si aucun n'est présent, un en-tête 'To:' DEVRAIT être créé en utilisant la syntaxe de groupe vide dont le nom donne une indication à un lecteur humain, par exemple, 'To: receveurs non divulgués:;'. L'en-tête 'To:' NE DEVRAIT PAS apparaître plus d'une fois. L'en-tête 'Cc:' NE DEVRAIT PAS apparaître plus d'une fois. Chaque adresse de receveur DOIT obéir aux restrictions de longueur de la [RFC2821]. Le format courant de message Internet exige que seuls des caractères US-ASCII de 7 bits soient présents dans les en-têtes. Les caractères qui ne sont pas de 7 bits dans un domaine d'adresse doivent être codés selon la [RFC3490]. Si il y a des caractères qui ne sont pas de 7 bits dans la partie locale d'une adresse, le message DOIT être rejeté. Des caractères autres que de 7 bits ailleurs dans un en-tête DOIVENT être codés conformément à la [RFC2047]. Tous les adresses de receveur dans l'enveloppe de la [RFC2821] doivent être pleinement qualifiés en accord avec la [RFC2821]. En particulier, les messages NE DOIVENT PAS être envoyés à un système de messagerie Internet avec un numéro E.164 non qualifié (c'est-à-dire, un numéro sans domaine) au lieu d'un nom de domaine pleinement qualifié. Toutes les adresses dans les en-têtes 'To:', 'Cc:', et 'Bcc:' DOIVENT être sous la forme de noms de domaine pleinement qualifié. Des numéros E.164 non qualifiés NE DOIVENT PAS être utilisés.

Adresse de l'envoyeur : l'adresse de l'envoyeur du message DEVRAIT apparaître dans l'en-tête 'From:'. L'adresse de l'envoyeur du message pour tout message généré par l'utilisateur ('X-Mms-Message-Class: Personal') DEVRAIT être transmise dans l'enveloppe [RFC2821] comme la valeur MAIL FROM. Les adresses de retour dans l'enveloppe de la [RFC2821] doivent être pleinement qualifiées en accord avec la [RFC2821]. En particulier, les messages NE DOIVENT PAS être envoyés à un système de messagerie Internet avec un numéro E.164 au lieu d'un nom de domaine pleinement qualifié. Noter que les numéros E.164 qualifiés, c'est-à-dire, ceux qui contiennent un numéro E.164 comme partie locale d'une adresse qui inclut aussi un domaine, sont acceptables. La ou les adresses dans l'en-tête 'From:' DEVRAIENT être sous la forme d'un domaine pleinement qualifié. Les numéros E.164 non qualifiés NE DEVRAIENT PAS être utilisés. À cause du risque de boucle de messagerie, il est critique que le MAIL FROM soit réglé à nul ("<>") pour tous les MM générés automatiquement (comme 'X-Mms-Message-Class:  Auto'). La valeur de MAIL FROM DOIT être réglée à nul pour tous les messages générés automatiquement. Cela inclut les rapports, les réponses "pas au bureau", etc. Le format courant de message Internet exige que seuls des caractères US-ASCII de 7 bits soient présents dans les en-têtes. Les caractères qui ne sont pas de 7 bits dans un domaine d'adresse doivent être codés selon la [RFC3490]. Si il y a des caractères non de 7 bits dans la partie locale d'une adresse, le message DOIT être rejeté. Les caractères non de 7 bits ailleurs dans un en-tête DOIVENT être codés en accord avec la [RFC2047]. Noter qu'il serait possible de définir une extension à la [RFC2821] pour permettre la transmission de caractères 8 bits non codés, mais en l'absence d'une telle extension, la [RFC2047] DOIT être utilisée. L'adresse de l'envoyeur DOIT obéir aux restrictions de longueur de la [RFC2821].

Type de contenu : l'en-tête 'Content-Type:' DEVRAIT être préservé.

Classe de message : l'en-tête 'X-Mms-Message-Class:' PEUT être conservé afin de fournir des informations sur la source du message. Un en-tête 'Precedence: bulk' PEUT être inséré pour class=auto ou class=advertisement. Voir 'Adresse de l'envoyeur' ci-dessus. (Class=personal et class=informational n'exigent pas de traitement particulier.)

Heure d'expiration : l'en-tête 'X-Mms-Expiry:', si il est présent, DEVRAIT être supprimé. Le temps restant jusqu'à ce que le message soit considéré comme expiré DEVRAIT être transmis dans l'enveloppe de la [RFC2821] en utilisant l'extension DELIVER-BY avec un by-mode de "R", comme spécifié dans la [RFC2852]. Noter que l'extension DELIVER-BY de la [RFC2821] porte le temps restant jusqu'à l'expiration ; chaque serveur décrémente la valeur de la durée pendant laquelle il a possédé le message. L'en-tète 'X-Mms-Expiry:' peut contenir le temps absolu auquel le message est considéré être expiré ou le temps relatif jusqu'à l'expiration du message.

Heure de livraison au plus tôt : l'en-tête 'X-Mms-Delivery-Time:', si il est présent, DEVRAIT être retiré.

Livraison future est une soumission de message (par exemple, de la [RFC2476]) et non une caractéristique de relais de message.

Demande de rapport de livraison : les demandes de notification d'état de livraison (DSN, Delivery Status Notification) DEVRAIENT être transmises dans l'enveloppe [RFC2821] en utilisant l'extension DSN comme spécifié dans la [RFC3461] pour demander une notification de "succès" ou "aucune" (selon la valeur de l'en-tête 'X-Mms-Delivery-Report'). Quand  l'extension NOTIFY est utilisée, l'adresse inchangée du receveur DEVRAIT être transmise comme valeur de ORCPT.

L'en-tête 'X-Mms-Delivery-Report:' , si présent, DEVRAIT être retiré.

Importance : la valeur d'importance de l'envoyeur du message (aussi appelée "priorité", bien que cela puisse être confondu avec les valeurs de classe de service) DEVRAIT être transmise en utilisant un en-tête 'Importance:'.

Les transpositions suggérées sont montrées au Tableau 2 :

Tableau 2 : Transpositions d'importance (de MMS à message Internet)

'X-Mms-Priority: High' 	'Importance: High'
'X-Mms-Priority: Normal'	[omettre]
'X-Mms-Priority: Low'	'Importance: Low'

Les messages d'importance normale devraient omettre l'en-tête 'Importance:'.

L'en-tête 'X-Mms-Priority:', si il est présent, DEVRAIT être supprimé.

Visibilité de l'envoyeur : il n'y a pas actuellement de prise en charge de la dissimulation de l'adresse de l'envoyeur. Un message qui contient un en-tête 'X-Mms-Sender-Visibility:' avec une valeur de 'Hide' DEVRAIT être rejeté. L'en-tête 'X-Mms-Sender-Visibility:', si il est présent, DEVRAIT être supprimé.

Demande de lecture de réponse : une demande de lecture de réponse DEVRAIT être transmise en utilisant un en-tête 'Disposition-Notification-To:' comme spécifié dans la [RFC3798]. L'en-tête 'X-Mms-Read-Reply:', si il est présent, DEVRAIT être supprimé.

Facturation de la réponse : la permission et l'acceptation de la facturation de la réponse sont des questions complexes qui exigent la prise en charge par l'agent d'utilisateur et le serveur. Une facturation de réponse mal appliquée peut causer une facturation incorrecte. Tant que les questions de sécurité n'auront pas été correctement analysées, la facturation de réponse NE DEVRAIT PAS être honorée quand on utilise cette interface.
Les en-têtes 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', 'X-Mms-Reply-Charging-Size:', et 'X-Mms-Reply-Charging-Id:' PEUVENT être supprimés. Les messages contenant une demande d'usage de facturation de la réponse (en-têtes 'X-Mms-Reply-Charging-Id:' et 'X-Mms-Reply-Charging: accepted' ou 'X-Mms-Reply-Charging: accepted (texte seulement)') DEVRAIT être rejetés.

Subject : l'en-tête 'Subject:' DOIT être préservé. Le format actuel de message de l'Internet exige que seuls des caractères US-ASCII de 7 bits soient présents. Les autres caractères DOIVENT être codés selon la [RFC2047]. Noter qu'il est possible qu'une extension à la [RFC2821] soit définie qui permettrait la transmission de caractères de 8 bits non codés, mais en l'absence d'une telle extension, la [RFC2047] DOIT être utilisée.

Renvoi : un message peut être renvoyé à un ou plusieurs nouveaux receveur. Il peut être renvoyé plus d'une fois, et à chaque fois de nouveaux en-têtes 'Resent-' sont ajoutés au dessus des en-têtes existants. Donc, si plus d'une série d'en-têtes 'Resent-' est présente, la série originale est la dernière ; la plus récente est la première.

Compteur de transmissions : un en-tête 'X-Mms-Forward-Counter:', si il est présent, DEVRAIT être supprimé. L'en-tête 'Resent-Count:' N'est PAS RECOMMANDÉ. Le contrôle de boucle est généralement fait en comptant les en-têtes 'Received', qui sont plus généraux que les en-têtes 'Resent-'.

Informations envoyées précédemment : MMS fait la liste de l'historique des renvois d'un message dans deux en-têtes : 'X-Mms-Previously-Sent-By:' et 'X-Mms-Previously-Sent-Date-and-Time:'. 'X-Mms-Previously-Sent-By:' contient un numéro suivi par une ou plusieurs adresses. 'X-Mms-Previously-Sent-Date-and-Time:' contient un numéro suivi par une date et heure. Avec les deux en-têtes, le numéro "0" est utilisé pour l'entrée qui correspond à la soumission originale du message, des valeurs plus élevées étant utilisées pour chaque renvoi suivant. Les informations du renvoi final (le plus récent) sont les en-têtes 'From:' et 'Date:'. Il y a aussi un 'X-Mms-Forward-Counter:' qui indique combien de fois le message a été renvoyé.

Tout en-tête 'X-Mms-Previously-Sent-By:', 'X-Mms-Previously-Sent-Date-and-Time:', et 'X-Mms-Forward-Counter:', si il est présent, DEVRAIT être retiré. Les informations contenues dans ces en-têtes DEVRAIENT être traduites en en-têtes de la [RFC2822] comme suit :

L'en-tête 'X-Mms-Previously-Sent-Date-and-Time:' dont la valeur commence par "0" DEVRAIT être utilisé pour créer un en-tête 'Date:', en convertissant la date et l'heure de HTTP-date [RFC2616] en date-time [RFC2822]. L'en-tête 'X-Mms-Previously-Sent-By:' dont la valeur commence par "0" DEVRAIT être utilisé pour créer un en-tête 'From:'.

Un en-tête 'To:' DEVRAIT être créé en utilisant la syntaxe de liste avec une valeur de "receveurs irrécupérables" et pas de boîte aux lettres.

Un en-tête 'Message-ID:' DEVRAIT être créé.

Tous les en-têtes 'X-Mms-Previously-Sent-Date-and-Time:' dont la valeur commence par "1" ou plus sont transposés en en-têtes 'Resent-Date:'. Tous les en-têtes 'X-Mms-Previously-Sent-By:' dont la valeur commence par "1" ou plus sont transposés en en-têtes 'Resent-By:'.

Les en-têtes 'From:', 'To:', 'Date:', et 'Message-ID:' sont transposés en en-têtes 'Resent-From:', 'Resent-To:', 'Resent-Date:', et 'Resent-Message-ID:' dans le bloc supérieur des en-têtes 'Resent-*'.

Exemple :

Le message MMS :

X-Mms-Forward-Counter: 2
X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT
X-Mms-Previously-Sent-By:   0, General Failure <mfail@example.mil>
X-Mms-Previously-Sent-Date-et-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By:   1, Colonel Corn <gcorn@example.mil>
Date:               Fri, 1 Apr 2005 18:02:03 -0800
From:               L. Eva Message <lem@example.org>
To:                 b1ff@mms.example.com
Message-ID:         <99887766.112233@mail.example.org>

est transposé en un message de messagerie Internet :

Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org>
Resent-To:   b1ff@mms.example.com
Resent-Message-ID:  <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 08:02:03 +0000
Resent-From: Colonel Corn <gcorn@example.mil>
Date:        Fri, 1 Apr 2005 06:02:03 +0000
From:        General Failure <mfail@example.mil>
To:          Colonel Corn <gcorn@example.mil>
Message-ID:  <000.000.000@gateway.example.org>

En-têtes 'Received:'  : Quand un message est passé de MMS à la messagerie Internet, un en-tête 'Received:' DOIT être ajouté conformément à la [RFC2821]. La clause "with" devrait spécifier "MMS". Un message PEUT être rejeté si le nombre d'en-têtes 'Received:' excède un maximum défini en local, qui DOIT se conformer au paragraphe 6.2 de la [RFC2821] et DEVRAIT être de pas moins de 100.

Confidentialité : Noter que les systèmes MMS ne prennent actuellement pas en charge le champ d'en-tête 'Privacy' décrit dans la [RFC3801].

Contenu : le contenu du message apparaît dans le corps du message. Noter que le format de message Internet exige que les terminaisons de ligne soient codées comme des octets CR LF US-ASCII ; donc, les codages de jeux de caractères qui n'ont pas cette propriété ne peuvent pas être utilisés dans les parties de corps text/*. (Ils peuvent être utilisés dans d'autres parties de corps, mais seulement quand ils sont convenablement codés ou quand la transmission binaire a été négociée, par exemple, voir la [RFC3030].) En particulier, MMS permet le codage UTF-16, tandis que le format de message Internet ne le permet pas. Le codage UTF-16 DOIT être traduit en UTF-8 ou un autre jeu de caractères et codage convenable pour les format/protocoles de message Internet.

 	2.1.3.3.	Conversion des messages du format Internet au format MMS
Version MMS 3GPP : un en-tête 'X-Mms-3GPP-MMS-Version:' DEVRAIT être ajouté.

Type (de PDU) de message : un en-tête 'X-Mms-Message-Type:' DEVRAIT être utilisé en accord avec l'interface MMS spécifique (par exemple, MM1, MM4).

Identifiant de transaction : un en-tête 'X-Mms-Transaction-Id:' DEVRAIT être utilisé en accord avec l'interface MMS spécifique (par exemple, MM1, MM4).

Identifiant de message : l'en-tête 'Message-Id:' DOIT être conservé. Si il n'est pas présent, il DOIT être créé, avec une valeur univoque.

Adresse du ou des receveurs : les en-têtes 'To:' et 'Cc:' DOIVENT être conservés. Chaque receveur contenu dans l'enveloppe de la [RFC2821] (valeurs de RCPT TO) DOIT être considéré comme un receveur du message. Les receveurs qui apparaissent dans les en-têtes d'adresse mais pas dans l'enveloppe de la [RFC2821] DOIVENT être ignorés. Les receveurs qui apparaissent dans l'enveloppe de la [RFC2821] mais pas dans les en-têtes sont considérés comme des receveurs "aveugles" (Bcc) ; ces receveurs NE DOIVENT PAS être ajoutés aux en-têtes de message (incluant les en-têtes d'adresse et de trace) sauf si il y a seulement un total d'un seul receveur.

Adresse d'envoyeur : l'en-tête 'From:' DOIT être conservé.

Type de contenu : L'en-tête 'Content-Type:' complet (incluant tout paramètre) DEVRAIT être conservé.

Classe de message : un en-tête 'X-Mms-Message-Class: personal' PEUT être créé pour tous les messages reçus avec un chemin de retour non nul (valeur de MAIL FROM dans l'enveloppe SMTP). Un en-tête 'X-Mms-Message-Class: auto' PEUT être créé pour les messages avec un chemin de retour nul.

Heure d'expiration : un en-tête 'X-Mms-Expiry:' DEVRAIT être créé si le message contient une heure relative d'expiration dans l'extension DELIVER-BY avec un "by-mode" de "R", comme spécifié dans la [RFC2852]. Si le by-mode est "N", une DSN "relayée" DOIT être produite conformément à la [RFC2852] et un en-tête 'X-Mms-Expiry:' NE DEVRAIT PAS être créé.

Demande de rapport de livraison : un en-tête 'X-Mms-Delivery-Report:' DEVRAIT être créé pour les messages qui demandent une notification d'état de livraison de 'succès' ou 'aucun' par l'utilisation de l'extension DSN comme spécifié dans la [RFC3461]. Les demandes de notifications de 'délai' ou d'actions non par défaut, comme que seuls les en-têtes de message soient retournés, ne peuvent pas être transposées en en-têtes MMS et DEVRAIENT donc être ignorées.

Importance : la valeur d'importance de l'envoyeur du message (aussi appelée "priorité", bien que ce puisse être confondu avec les valeurs de classe de service) est exprimée par un en-tête 'Importance:'. Historiquement certains clients ont utilisé l'en-tête plus ancien et non standard 'X-Priority:' à cette fin. Par suite, certains clients génèrent les deux.

Un en-tête 'X-Priority:' ou 'Importance:', si il est présent, DEVRAIT être remplacé par un en-tête 'X-Mms-Priority:'. Si les deux en-têtes sont présents, 'Importance:' DEVRAIT être utilisé. Les transpositions suggérées sont montrées au Tableau 3:

Tableau 3 : Transpositions de priorité (de message Internet à MMS)

'X-Priority: 1 (plus forte)'	'X-Mms-Priority: High'
'X-Priority: 2 (élevée)'	'X-Mms-Priority: High'
'Importance: High'	'X-Mms-Priority: High'
'X-Priority: 3 (normale)'	[omise]
'Importance: Normale'	[omise]
'X-Priority: 4 (faible)'	'X-Mms-Priority: Low'
'Importance: faible'	'X-Mms-Priority: Low'
'X-Priority: 5 (la plus faible)'	'X-Mms-Priority: Low'

Les messages d'importance normale DEVRAIENT omettre l'en-tête 'X-Mms-Priority:'.

Visibilité de l'envoyeur : la dissimulation de l'adresse de l'envoyeur n'est pas prise en charge actuellement.

Demande de lecture de la réponse : une demande de lecture de la réponse contenue dans un en-tête 'Disposition-Notification-To:' comme spécifié dans la [RFC3798] DEVRAIT être remplacée par un en-tête 'X-Mms-Read-Reply:'.

Sujet : l'en-tête 'Subject:' DOIT être préservé.

Renvoi : la transposition des en-têtes 'Resent-' et autres en-têtes de la [RFC2822] en en-têtes 'X-Mms-Previously-Sent-' DEVRAIT être faite comme suit :

L'en-tête original 'From:' est transposé en en-tête 'X-Mms-Previously-Sent-By:' avec une valeur de "0" en tête. La valeur de l'en-tête 'Resent-From:' supérieur est transposée en en-tête 'From:'. La valeur de chaque en-tête 'Resent-From:' suivant est transposée en en-tête 'X-Mms-Previously-Sent-By:' avec la plus grande valeur en tête suivante.

L'en-tête original 'Date:' est transposé en en-tête 'X-Mms-Previously-Sent-Date-and-Time:' avec une valeur de "0" en tête. Noter que la valeur est aussi convertie de la syntaxe date-time de la [RFC2822] en syntaxe HTTP-date de la [RFC2616]. La valeur de l'en-tête 'Resent-Date:' supérieur est transposée en en-tête 'Date:'. La valeur de chaque en-tête 'Date:' suivant est transposée en un en-tête 'X-Mms-Previously-Sent-Date-and-Time:' avec la plus grande valeur en tête suivante.

Si un ou plusieurs en-têtes 'Resent-Message-ID:' sont présents, le plus haut DEVRAIT être transposé en 'Message-ID:' ; autrement, l'en-tête 'Message-ID:' devrait être conservé.

Un en-tête 'X-Mms-Forward-Counter:' DEVRAIT être créé quand des en-têtes 'Resent-' ont été transposés en en-têtes 'X-Mms-Previously-Sent-'. Sa valeur DEVRAIT être le nombre de blocs 'Resent-' qui existaient avant la transposition.

Exemple :

Le message original :

Date:        Fri, 1 Apr 2005 14:02:03 -0800
From:        General Failure <mfail@example.mil>
To:          Colonel Corn <gcorn@example.mil>
Message-ID:  <msg123@mail.example.mil>

est renvoyé par Colonel Corn à L. Eva Message :

Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil>
Resent-To:   L. Eva Message <lem@example.org>
Resent-Message-ID:  <msg234@mail.example.mil>
Date:        Fri, 1 Apr 2005 14:02:03 -0800
From:        General Failure <mfail@example.mil>
To:          Colonel Corn <gcorn@example.mil>
Message-ID:  <msg123@mail.example.mil>

L. Eva renvoie alors à son appareil MMS :

Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org>
Resent-To:   b1ff@mms.example.com
Resent-Message-ID:  <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil>
Resent-To:   L. Eva Message <lem@example.org>
Resent-Message-ID:  <msg234@mail.example.mil>
Date:        Fri, 1 Apr 2005 14:02:03 -0800
From:        General Failure <mfail@example.mil>
To:          Colonel Corn <gcorn@example.mil>
Message-ID:  <msg123@mail.example.mil>

Cela serait transposé en un message MMS comme :

X-Mms-Forward-Counter: 2
X-Mms-Previously-Sent-Date-et-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT
X-Mms-Previously-Sent-By:   0, General Failure <mfail@example.mil>
X-Mms-Previously-Sent-Date-et-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By:   1, Colonel Corn <gcorn@example.mil>
Date:               Fri, 1 Apr 2005 18:02:03 -0800
From:               L. Eva Message <lem@example.org>
To:                 b1ff@mms.example.com
Message-ID:         <99887766.112233@mail.example.org>

Noter que les valeurs originales de 'From:' et 'Date:' ont été déplacées des en-têtes 'X-Mms-Previously-Sent-By:' et 'X-Mms-Previously-Sent-Date-and-Time:' avec une valeur en tête de "0". Les premières valeurs de 'Resent-From:' et 'Resent-Date:' ont été déplacées à un second ensemble d'en-têtes 'X-Mms- Previously-Sent-', avec une valeur en tête de "1". Le troisième ensemble d'en-têtes 'Resent-' a été déplacé aux en-têtes 'Date:', 'To:', et 'From:'.

Noter aussi que le format de la date et de l'heure diffère entre les en-têtes 'Date:' / 'Resent-Date:' et les en-têtes 'X-Mms-Previously-Sent-Date-and-Time:', en ce que le premier utilise HTTP-date [RFC2616] au lieu de date-time [RFC2822].

En-têtes 'Received:' : chaque système qui traite un message DEVRAIT ajouter un en-tête 'Received:' conformément à la [RFC2821]. Un message PEUT être rejeté si le nombre d'en-têtes 'Received:' excède un maximum défini en local, qui DOIT se conformer au paragraphe 6.2 de la [RFC2821] et ne DEVRAIT pas être de moins de 100.

Sensibilité : le champ d'en-tête 'Sensitivity:' (valeur = "personnel" ou "privé") [RFC3801] indique le désir que le générateur d'un message vocal envoie le contenu du message à la liste des receveurs originaux avec l'assurance que le message ne sera pas transmis plus loin par le système de messagerie ou le ou les receveurs réels du message. Comme la sensibilité n'est pas une caractéristique de MMS, tous les messages qui contiennent un en-tête 'Sensitivity:' NE DOIVENT PAS être envoyés à un système MMS. Le rapport associé de non livraison DOIT inclure le code d'état étendu de 5.6.0 de la [RFC3463] comme spécifié dans [RFC3801] ("Autre ou état de protocole indéfini") indiquant que la confidentialité n'a pas pu être assurée.

Contenu : le contenu du message apparaît dans le corps du message.

 	2.1.4	Génération et conversion de rapport
Les systèmes de messages Internet utilisent le type MIME multipart/report pour les rapports de livraison et de disposition comme spécifié dans la [RFC3462]. Ce format est un message MIME de deux ou trois parties ; une partie est un format structuré qui décrit les événements rapportés dans un format facile à analyser. Les rapports spécifiques ont un format construit sur celui de la [RFC3462]. Les rapports de livraison sont spécifiés dans la [RFC3464]. Les rapports de disposition de message, qui incluent les rapports de lecture, sont spécifiés dans la [RFC3798].

À l'opposé, les rapports MMS sont de texte pur, sans structure définie spécifiée. Cela rend difficile de convertir d'un rapport  MMS en rapport Internet standard.

Une mise en œuvre conforme à la présente spécification DOIT convertir les rapports reçus d'un côté (MMS ou messagerie Internet) destinés aux autres. De plus, les rapports DOIVENT être générés comme approprié pour les messages reçus de l'un et l'autre côté. Par exemple, si un MM à envoyer via la messagerie Internet n'est pas livrable, un MM d'état de livraison devra généré. De même, si un message Internet est reçu et qu'il ne peut pas être encore relayé ou délivré, un rapport d'état de livraison selon la [RFC3464] DOIT être généré.

Quand on crée des rapports de livraison ou de disposition à partir de rapports MMS , le rapport MMS devrait être analysé pour déterminer l'événement rapporté et l'heure, l'état, et les en-têtes du message (original) référencé. Ces éléments, une fois déterminés, sont utilisés pour remplir les sous parties du rapport de livraison ou de disposition. La première sous partie est du type text/plain, et contient une explication de l'événement lisible par l'homme. Ce texte peut inclure une déclaration que le rapport a été synthétisé sur la base d'un rapport MMS. La seconde sous partie est du type report/delivery-status (pour les rapports de livraison) ou report/disposition-notification (pour les rapports de disposition). Cette second partie contient des éléments structurés de l'événement. La troisième sous partie facultative est du type message/rfc822 et inclut les en-têtes et facultativement le corps du message référencé (original). Noter que, selon la [RFC3464], le champ 'DSN-Gateway:' dans les rapports de livraison DOIT être créé.

 	2.1.4.1	Transposition de rapport de livraison de MMS en message  Internet
Ci-dessous, le Tableau 4 transpose les éléments d'information des rapports de livraison MMS dans le format spécifié dans la [RFC3464].

Tableau 4 : Transpositions de rapport de livraison (MMS à message Internet)

Élément d'information	Élément de rapport de livraison MMS	Élément de la DSN	
ID du message dont l'état de livraison est rapporté	Message-Id: 	Message-ID:' préservé dans la troisième sous partie du rapport de livraison.	
Adresse de réception du message original (objet du rapport de livraison)	From:	Champ 'Final-Recipient' de la section par receveur.	
Adresse de destination du rapport	To:  	Valeur de champ d'en-tête 'To:' de niveau supérieur.	
Date et heure de traitement du message	Date: 	Valeur de champ d'en-tête 'Date:' de niveau supérieur.	
État de livraison du message original à chaque receveur	X-Mms-Status:	Champs 'Action' et 'Status' de la section par receveur.
Le champ 'Action' indique si le message a été livré.
Pour un échec de livraison, une valeur appropriée de 'Status' devra être incluse conformément à la [RFC3464].
Le champ Action est réglé à une des valeurs suivantes :
* livré (utilisé pour les valeurs d'état MMS 'restitué' et 'rejeté', selon le code 'Status')
* échec (utilisé pour les valeurs d'état MMS 'expiré' et 'injoignable')
* retardé PEUT être utilisé pour les valeurs d'état MMS 'différé'
* relayé (utilisé pour la valeur d'état MMS 'indéterminé')
* expansé (NE DEVRAIT PAS être utilisé)	

			

			

Texte d'état		Texte dans la première partie (partie lisible par l'homme).	

Quand un relais/serveur MMS génère une DSN en réponse à un message reçu en utilisant SMTP sur MM3 :
* Le champ d'en-tête 'To:' de niveau supérieur DEVRAIT être chemin de retour SMTP du message dont l'état est rapporté.
* Le champ d'en-tête 'From:' de niveau supérieur DEVRAIT être l'adresse du receveur que le rapport de livraison concerné.
* La première partie de la DSN DEVRAIT inclure le champ Texte d'état MM qui aurait été généré pour un rapport de livraison MM1.

 	2.1.4.2	Transposition de rapport de livraison de message Internet à MMS
Le Tableau 5 transpose les éléments d'information d'un rapport de livraison comme spécifié dans la [RFC3464] dans le format d'un rapport de livraison MMS. Noter qu'une seule DSN qui rapporte plusieurs receveurs va résulter en plusieurs rapports de livraison MMS.

Tableau 5 : Transpositions de rapport de livraison (message Internet en MMS)

Élément d'information	Élément de rapport de livraison MMS	Élément de notification d'état de livraison	
ID du message original (objet du rapport de livraison)	Message-Id:	En-tête 'Message-ID:' préservé dans la troisième sous partie du rapport.	
Adresse de réception du message original (objet du rapport de livraison)	From: 	Si disponible, le champ 'Original-Recipient' de la section par receveur devrait être utilisé ; autrement, le champ 'Final-Recipient' de la section par receveur est utilisé.	
Adresse de destination du rapport	To:	Valeur de champ d'en-tête 'To:' de niveau supérieur. Valeur prise de l'enveloppe de chemin de retour de la [RFC2821] du message objet du rapport, pas de son champ d'en-tête 'From:'.	
Date et heure de traitement du message	Date:	Valeur de champ d'en-tête 'Date:' de niveau supérieur.	
État de livraison du message original 	X-Mms-Status: 
Réglé à une des valeurs suivantes : 'restitué' (utilisé pour la valeur 'Action' 'délivré'). 
'injoignable' (utilisé pour la valeur 'Action' 'échec'). 
'transmis' (utilisé pour la valeur 'Action' 'relayé'). 
'différé' NE DOIT PAS être utilisé (on ignore les DSN avec la valeur de 'Action' 'retardé')	Champs 'Action' et 'Status' de la section par receveur.	
Texte d'état 		Texte en première partie (lisible par l'homme).	

 	2.1.4.3.	Transposition de rapport de lecture de MMS à message Internet
Le Tableau 6 ci-dessous transpose les éléments d'information des rapports de lecture MMS dans le format spécifié dans la [RFC3798].

 	Tableau 6 : Transpositions de rapport de lecture (MMS à message Internet)
Élément d'information	Élément de rapport de livraison MMS	Élément de notification de disposition	
ID du message original (objet du rapport de lecture)	Message-Id: 	En-tête 'Message-ID:' préservé dans la troisième partie du rapport.	
Adresse de réception du message original	From: 	Champ 'Final-Recipient'.	
Adresse de destination du rapport 	To:  	Valeur de champ d'en-tête 'To:' de niveau. supérieur. La valeur prise dans le champ d'en-tête 'Disposition-Notification-To:' du message objet du rapport, non de son champ d'en-tête 'From:'.	
Date et heure de traitement du message	Date: 	Valeur de champ d'en-tête 'Date:' de niveau supérieur.	
Disposition du message objet du rapport	X-Mms-Read-Status: 	Champ Disposition. Pour la valeur de X-MMS-Read-Status 'lu', on utilise la valeur de 'disposition-type' de 'affiché' ; pour la valeur de X-MMS-Read-Status 'Supprimé sans être lu', on utilise la valeur 'disposition-type' de 'supprimé').	
Texte l'état 		Texte en première partie (lisible par l'homme).	

Quand un relais/serveur MMS génère une notification de disposition en réponse à un message reçu en utilisant SMTP sur MM3 :
* Le champ d'en-tête 'To:' de niveau supérieur DEVRAIT avoir la valeur du champ d'en-tête 'Disposition-Notification-To:' du message dont la disposition est rapportée.
* Le champ d'en-tête 'From:' de niveau supérieur DEVRAIT être l'adresse du receveur concerné par le rapport de lecture.

 	2.1.4.4	Transposition de rapport de disposition de message Internet à MMS
Le Tableau 7 ci-dessous transpose les éléments d'information d'un rapport de disposition comme spécifié dans la [RFC3798] au format d'un rapport de lecture MMS.

 	Tableau 7 : Transposition de rapport de disposition (message Internet à MMS)
Élément d'information	Élément de rapport de lecture MMS	Élément de notification de disposition	
ID du message original (objet du rapport de disposition)	Message-Id: 	En-tête 'Message-ID:' préservé dans la troisième sous partie du rapport.	
Adresse de réception du message original	From:  	Champ 'Final-Recipient'.	
Adresse de destination du rapport	To:  	Valeur du champ d'en-tête 'To:' de niveau supérieur. Valeur prise du champ d'en-tête 'Disposition-Notification-To:' du message objet du rapport, non de son champ d'en-tête 'From:'.	
Date et heure de traitement du message	Date: 	Valeur du champ d'en-tête 'Date:' de niveau supérieur.	
Disposition du message objet du rapport	X-Mms-Read-Status:	Champ Disposition, réglé à une des valeurs suivantes : 'lu' (utilisé pour la valeur de type de disposition 'affiché') 'Supprimé sans être lu' (utilisé pour les types de disposition 'supprimé', 'refusé' et 'échec' quand le mode d'action est 'action automatique').	
Texte d'état		Texte en première partie (lisible par l'homme).	

 	2.1.5	Livraison de message
Dans la messagerie Internet, quand SMTP est utilisé et que des rapports de livraison sont demandés [RFC3461], la livraison est considérée comme étant l'acceptation d'un message par le serveur final, c'est-à-dire, le serveur le plus proche du receveur. Quand un relais/serveur MMS reçoit un message utilisant SMTP et qu'un rapport de livraison est demandé, le relais/serveur MMS PEUT considérer le message comme livré quand il a été envoyé à l'agent d'utilisateur MMS.

 	3.	Considérations sur la sécurité

MMS et la messagerie Internet ont tous deux leur propre ensemble de risques et considérations de sécurité. Le présent document spécifie comment échanger des messages entre ces deux environnements, de sorte qu'il est seulement approprié de discuter des considérations spécifiques de cette fonctionnalité, et non de celles inhérentes à l'un ou l'autre environnement.

Quand un message utilise des mécanisme de sécurité de bout en bout tels que ceux de la [RFC3156] ou de S/MIME [RFC3851], les serveurs DOIVENT veiller à ne pas détruire accidentellement l'intégrité du contenu protégé (par exemple, en altérant un texte dans la région couverte par une signature lors de la transposition entre MMS et la messagerie électronique). La [RFC2480] discute des problèmes de l'utilisation de ces mécanismes dans les passerelles.

Certaines caractéristiques de MMS contiennent par nature plus de risques que d'autres, incluant la facturation des réponses et la dissimulation de l'adresse de l'envoyeur. La prise en charge de ces mécanismes n'est pas incluse dans ce document.

 	4.	Considérations relatives à l'IANA

L'IANA a ajouté "MMS" comme un des "types de protocoles WITH" dans le registre "MAIL Parameters". La description est "service de messagerie multimédia" ; la référence est le présent document.

 	5.	Remerciements

Un certain nombre de personnes ont contribué au présent document, en particulier les membres du groupe de travail Lemonade de l'IETF, incluant Greg Vaudreuil. John Klensin a fait une relecture très serrée et utile. Greg White a relevé un grand nombre d'erreurs. Ted Hardie a été d'une grande aide. Alexey Melnikov et Chris Newman ont envoyé des commentaires très détaillés et utiles.

 	6.	Références normatives

[3GPP2]	Les spécifications 3GPP2 sont disponibles sur le site du 3GPP2 (projet en partenariat de troisième génération 2) à <http://www.3gpp2.org>.

[3GPP]	Les spécifications 3GPP sont disponibles sur le site du 3GPP (projet en partenariat de troisième génération) à <http://www.3gpp.org >

[OMA]	Les spécifications de l'OMA sont disponibles sur le site OMA à <http://www.openmobilealliance.org >.

[OMA-MMS]	OMA-WAP-MMS-ENC-V1_2-20040323-C

[RFC2047]	K. Moore, "MIME (Extensions de messagerie Internet multi-objets) Partie trois : extensions d'en-tête de message pour texte non ASCII", novembre 1996. (MàJ par RFC2184, RFC2231) (D.S.)

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

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

[RFC2821]	J. Klensin, éditeur, "Protocole simple de transfert de messagerie", STD 10, avril 2001. (Obsolète, voir RFC5321)

[RFC2822]	P. Resnick, "Format de message Internet", avril 2001. (Remplace la RFC0822, STD 11, Remplacée par RFC5322)

[RFC3461]	K. Moore, "Extension de service du protocole simple de transfert de messagerie (SMTP) pour les notifications d'état de livraison (DSN)", janvier 2003. (MàJ par RFC3798, RFC3885, RFC5337, RFC6533, RFC8098) (D.S.)

[RFC3462]	G. Vaudreuil, "Type de contenu Multipart/Report pour les rapports des messages administratifs du système de messagerie", janvier 2003. (Remplacée par RFC6522, STD 73)

[RFC3463]	G. Vaudreuil, "Codes d'état améliorés du système de messagerie", janvier 2003. (MàJ par RFC3886, RFC4468, RFC4865, RFC4954, RFC5248) (D.S.)

[RFC3464]	K. Moore, G. Vaudreuil, "Format extensible de message pour les notifications d'état de livraison", janvier 2003. (MàJ par RFC4865, RFC5337, RFC6533) (D.S.)

[RFC3490]	P. Faltstrom et autres, "Internationalisation des noms de domaine dans les applications (IDNA)", mars 2003. (Remplacée par les RFC5890 et 5891, P.S.)

[RFC3798]	T. Hansen et G. Vaudreuil, éd., "Notification de disposition de message", mai 2004. (MàJ par RFC5337, RFC6533) (D.S.; Rendue obsolète par RFC8098)

[Stage_3]	"MMS MM1 Stage 3 using OMA/WAP", X.S0016-310
	"MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-340
	"Multimedia Messaging Service: Functional description; Stage 2", TS 23.140 Release 5.

 	7.	Références pour information

[Overview]	"Multimedia Messaging Services (MMS) Overview", X.S0016-000

[RFC2076]	J. Palme, "En-têtes communs de message Internet", février 1997. (Information)

[RFC2476]	R. Gellens, J. Klensin, "Soumission de message", décembre 1998. (Obsolète, voir RFC4409) (P.S.)

[RFC2480]	N. Freed, "Les routeurs et le traitement de multiparties de sécurité MIME", janvier 1999. (P.S.)

[RFC2852]	D. Newman, "Extension de service SMTP Livraison par", juin 2000. (P.S.)

[RFC3030]	G. Vaudreuil, "Extensions de service SMTP pour la transmission de grands messages MIME binaires", décembre 2000. (P.S.)

[RFC3156]	M. Elkins et autres, "Sécurité MIME avec OpenPGP", août 2001.(P.S.)

[RFC3801]	G. Vaudreuil, G. Parsons, "Profil vocal pour la messagerie Internet - version 2 (VPIMv2)", juin 2004. (D.S.)

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

[Stage_1]	"Multimedia Messaging Services (MMS); Stage 1", Requirements, octobre 2002, S.R0064-0.

[Stage_2]	"Multimedia Messaging Service (MMS); Stage 2", Functional Specification, avril 2003, X.S0016-200.
	"Multimedia Messaging Service; Media formats et codecs", TS26.140 Release 5.

 	Adresse de l'auteur
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA  92121
USA
mél : randy@qualcomm.com 

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administratif (IASA) de l'IETF.