RFC3458 Contexte de message pour messagerie Internet Burger & autres

Groupe de travail Réseau

E. Burger, SnowShore Networks

Request for Comments : 3458

E. Candell, Comverse

Catégorie : En cours de normalisation

C. Eliot, Microsoft Corporation


G. Klyne, Nine by Nine

Traduction Claude Brière de L’Isle

janvier 2003



Contexte de message pour la messagerie Internet



Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître 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 (2003). Tous droits réservés


Résumé

Le présent mémoire décrit un nouvel en-tête de message de la RFC2822, "Message-Context". Cet en-tête fournit des informations sur le contexte et les caractéristiques de présentation d’un message.


Un agent d’utilisateur (UA, user agent) receveur peut utiliser ces informations comme indication pour optimiser la présentation du message.


Table des Matières

1. Introduction 1

2. Conventions utilisées dans ce document 2

3. Motifs 2

4. Exigences fonctionnelles 3

5. Détermination du contexte du message 3

6. Champ de référence Message-Context 4

6.1 Syntaxe de Message-Context 4

6.2 Syntaxe de message-context-class 4

7. Considérations pour la sécurité 5

8. Considérations relatives à l’IANA 5

8.1 Enregistrements de type de contenu de message 6

8.2 Gabarit d’enregistrement 6

8.3 Enregistrement de contexte de message 6

9. Appendice : Scénarios de messagerie 6

9.1 Messagerie électronique Internet 6

9.2 Service de radio message 7

9.3 Télécopie 7

9.4 Messagerie vocale 8

9.5 Message multimédia 8

10. Références 8

10.1 Références normatives 8

10.2 Références pour information 8

11. Remerciements 9

12. Adresse des auteurs 9

13. Déclaration complète de droits de reproduction 9


1. Introduction


Le présent document décrit un mécanisme pour permettre aux envoyeurs d’un message Internet de transporter les informations de contexte du message. En prenant ces informations en compte, l’agent d’utilisateur receveur peut prendre des décisions qui améliorent la présentation du message pour l’utilisateur dans le contexte qu’attendent l’envoyeur et le receveur.


Dans ce document, le "contexte de message" porte des informations sur la façon dont l’utilisateur s’attend à interagir avec le message. Par exemple, un message peut être un message électronique, un message vocal, un message par télécopie, etc. Un UA intelligent peut avoir des comportements spécialisés sur la base du contexte du message.


Le présent document spécifie un en-tête de la [RFC2822] appelé "Message-Context".


Le mécanisme est, d’une certaine façon, similaire à l’utilisation de l’entité MIME Content-Disposition décrite dans la [RFC2183]. Content-Disposition donne des indices à l’agent d’utilisateur receveur sur la façon d’afficher une certaine partie de corps de message. Message-Context peut donner des indications à l’agent d’utilisateur receveur sur la présentation du message. Cela permet à l’UA receveur de présenter le message au receveur d’une façon significative et utile.


Les utilisations normales de ce mécanisme incluent :

o le choix d’un visionneur particulier pour un certain message,

o le choix d’une image indiquant la sorte de message dans l’affichage d’une liste de messages,

o d’arranger les messages dans un affichage de boîte aux lettres de réception,

o de filtrer les messages que l’UA présente lorsque l’usager a un accès limité.


2. Conventions utilisées dans ce document


Le présent document se réfère de façon générique à l’envoyeur d’un message au masculin (il/lui/son) et au receveur du message au féminin (elle/sa). Cette convention n’a qu’un aspect pratique et ne fait aucune hypothèse sur le genre d’un envoyeur ou receveur de message.


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


Note de formatage : Les notes, comme celle-ci, donnent des informations non essentielles supplémentaires que le lecteur peut sauter sans rien manquer d’essentiel. Le principal objet de ces notes non essentielles est de donner des informations sur les raisons du présent document, ou de replacer ce document dans le propre contexte ou évolution historique. Les lecteurs dont le seul objet est de construire une mise en œuvre conforme peuvent sauter de telles informations. Cependant, elles peuvent être utiles à ceux qui souhaitent comprendre pourquoi ont été faits certains choix de conception.


3. Motifs


Les systèmes de messagerie multimédia reçoivent des messages qu’un UA peut présenter de diverses façons. Par exemple, le message électronique traditionnel utilise de simples messages de texte que le receveur affiche et édite. Un UA peut imprimer automatiquement des images de télécopie. Un autre UA peut exécuter les messages vocaux sur un combiné téléphonique. De même, un ordinateur portable en réception peut traiter ou présenter des documents transférés sur messagerie électronique en utilisant une application locale. Des développements émergeants et futurs pourront livrer d’autres formes d’informations qui auront leurs propres caractéristiques pour la présentation à l’utilisateur, comme des messages vidéo et des radio messages.


Une caractéristique souvent demandée des systèmes de messagerie multimédia est de collecter les messages reçus dans une "boîte aux lettres universelle", et de les offrir à l’utilisateur dans une liste combinée.


Dans le contexte de la "messagerie unifiée", différents contextes de message peuvent avoir une sémantique impliquée différente. Par exemple, certains usagers peuvent percevoir la messagerie vocale comme ayant une connotation implicite d’urgence. Donc, ils peuvent souhaiter les collecter et les traiter avant les autres messages. Il en résulte un besoin pour l’agent récepteur de l’utilisateur final d’être capable d’identifier la messagerie vocale et de la distinguer des autres messages.


Les utilisations de cette sorte de caractéristiques de présentation pour chaque message sont de plusieurs ordres :

o affichage d’une indication à l’usager (par exemple, par une image convenablement évocatrice avec d’autres champs de résumé),

o auto-transmission d’un certain type de message dans un autre environnement de messagerie (par exemple, une page sur un service mobile de messages courts),

o établir des priorités et grouper les messages dans une liste d’affichage des messages entrants,

o suggérer un traitement par défaut approprié pour la présentation,

o suggérer un traitement par défaut approprié pour répondre, transmettre, etc. Un problème que rencontrent les systèmes de messagerie multimédia est qu’il n’est pas toujours facile de décider du contexte d’un message reçu. Par exemple, considérons les scénarios suivants.

o Un message qui contient des données audio et des images : est-ce un message de télécopie qui se trouve avoir des commentaires vocaux ? Est-ce un message vocal qui est accompagné de diagrammes supplémentaires ? Est-ce un message entièrement multimédia, dans lequel toutes les parties sont supposées avoir une égale signification ?

o un message contenant du texte et des données audio : est-ce un message électronique avec un accompagnement de musique MP3 ? Est-ce un message vocal qui se trouve avoir été généré avec un en-tête initial de texte pour le bénéfice des receveurs de message électronique qui ne disposent pas de capacités vocales ?


Le contexte de message se rapporte au contenu du support du message. Cependant, ce n’est pas la même chose. Comme on l’a montré ci-dessus, le type de support utilisé dans un message n’est pas suffisant pour indiquer le contexte du message. On ne peut pas déterminer à priori quel type de support utiliser dans les messages de remplacement (passerelle). Aussi, que faire si l’usager souhaite distinguer le texte de la messagerie traditionnelle des messages SMS ? Ils ont tous deux le même type de support, le texte, mais ils ont des contextes d’utilisateur différents.


4. Exigences fonctionnelles


Les objectifs énumérés ci-dessus conduisent aux exigences fonctionnelles suivantes.


Pour les receveurs :

o Identifier un message comme appartenant à une classe de message.

o Une classification incorrecte ou invalide du message ne doit pas résulter en l’échec du transfert ou l’incapacité à présenter un message.


Pour les envoyeurs :

o Spécifier les classes de message par le choix de l’utilisateur qui l’a généré d’outils d’identification de l’auteur ou par une simple interaction de l’usager.


Pour les deux :

o Spécifier un ensemble bien défini de classes de message pour rendre possible l’interopérabilité entre les agents d’utilisateur (UA, user agent) de messagerie.

o Les informations de classification de message doivent être interprétables d’une façon raisonnable par de nombreux systèmes d’agent d’utilisateur différents.

o Le mécanisme devrait être extensible pour permettre l’introduction de nouvelles sortes de messages.


Note : On ne spécifie intentionnellement pas le comportement de l’UA lorsque il transmet un message. Il est clair que l’UA, étant informé du contexte du message, devrait fournir un contexte de message significatif. Ce qu’il y a à faire pour les cas faciles est évident. Les messages que l’usager transmet simplement vont très vraisemblablement conserver leur contexte inchangé. Cependant, il sort du domaine d’application du présent document de spécifier le comportement de l’agent d’utilisateur pour les autres scénarios.


5. Détermination du contexte du message


Une méthode pour indiquer le contexte d’interprétation d’un message est d’examiner les types de supports dans le message. Cependant, cela exige que l’UA examine le message entier avant qu’il puisse faire cette détermination. Cette approche est particulièrement lourde pour les situations de messagerie multimédia, car les objets de messagerie vocaux et surtout de vidéo sont assez gros.


On a envisage d’indiquer le contexte de message en enregistrant un sous-type multipart/* MIME (Content-Type). Par exemple, le groupe de travail VPIM a enregistré multipart/voice-message pour indiquer qu’un message est principalement de la messagerie vocale [RFC2423]. Cependant, multipart/voice-message a une syntaxe identique à celle de multipart/mixed. La seule différence est que les agents de transfert de messagerie VPIM et les agents d’utilisateur reconnaissent qu’ils peuvent effectuer un traitement particulier du message du fait qu’il est un message vocal. De plus, Content-Type se réfère à un certaine partie de corps MIME, et non au message comme un tout.


On souhaite éviter d’examiner le message entier. De plus, on souhaite éviter d’avoir à créer plusieurs alias pour multipart/mixed chaque fois que quelqu’un identifie un nouveau type de contenu principal. Plusieurs alias pour multipart/mixed n’est pas souhaitable car cela retire la possibilité de spécifier un message comme multipart/alternate, multipart/parallel, ou multipart/encrypted, par exemple.


Comme le contexte de message est un attribut du message entier, il est logique de définir un nouvel attribut de message de niveau supérieur [RFC2822]. À cette fin, le présent document introduit l’attribut de message "Message-Context".


Message-Context ne sert qu’à identifier le contexte du message. Il ne fournit aucune indication du contenu que l’UA doit être capable de livrer. Il n’implique aucune disposition de message ou de notification de livraison. Des travaux sont en cours pour définir un contenu critique du message Internet [RFC3459] qu’on peut utiliser pour effectuer ces tâches.


Message-Context est seulement un indicateur. Il n’est pas prévu qu’il porte des informations critiques pour la présentation du message. On peut concevoir des situations loufoques, telles qu’un message marqué "message vocal" mais sans partie de corps audio. Dans ce cas, le fait que le contenu d’un message ne corresponde pas à son contexte ne signifie pas que le système receveur devrait générer un rapport d’erreur ou échouer à livrer ou traiter le message.


6. Champ de référence Message-Context


Le champ de référence Message-Context est un en-tête de niveau supérieur inséré par l’UA envoyeur pour indiquer le contexte du message.


Un agent d’utilisateur receveur NE DOIT PAS se reposer sur la valeur du contexte de message indiquée d’une façon qui empêche la présentation appropriée du message. Si la valeur est incorrecte ou ne correspond pas au contenu du message, l’agent d’utilisateur receveur DOIT quand même être capable d’afficher le contenu du message au moins aussi significativement qu’il l’aurait fait si aucune valeur de Message-Context n’était présente.


On peut envisager des situations où un message bien formé se trouve ne pas comporter le type de support qu’on attendrait d’après le message-context. Par exemple, considérons un système de messagerie vocale qui enregistre un message vocal et effectue aussi un traitement de transformation de parole en texte sur le message. Le message passe ensuite à travers une passerelle de contenu, comme un pare-feu, qui retire les parties de corps non critiques qui dépassent une certaine longueur. L’agent d’utilisateur receveur va recevoir un message dans le contexte message vocal qui a seulement une partie texte et pas de partie audio. Bien que le message n’ait pas de partie audio, il est quand même dans le contexte de message vocal.


Dit autrement, l’UA receveur peut utiliser le message-context pour déterminer si, quand, et éventuellement où afficher un message. Cependant, le contexte de message ne devrait pas affecter le rendu réel ou la présentation. Par exemple, si le message est dans le contexte message vocal, ne pas essayer alors de l’envoyer à un terminal de télécopie. À l’inverse, considérons le cas d’un message dans le contexte de message vocal qui se trouve livré à un terminal vocal multimédia avec une imprimante. Cependant, ce message a seulement un contenu de télécopie. Dans cette situation, le contexte "voice-message" ne devrait pas empêcher le terminal de rendre correctement le message.


6.1 Syntaxe de Message-Context

La syntaxe du champ Message-Context, décrite en utilisant l’ABNF [RFC2234] est la suivante. Noter que le nom du champ d’en-tête Message-Context et les valeurs de la classe du contexte de message ne sont pas sensibles à la casse.


"Message-Context" ":" message-context-class CRLF


6.2 Syntaxe de message-context-class

Le champ message-context-class indique le contexte du message. C’est une valeur enregistrée par l’IANA. Les valeurs actuelles pour message-context-class sont les suivantes.


message-context-class = ( "voice-message" / "fax-message" / "pager-message" / "multimedia-message" / "text-message" / "none" )


Note : Les valeurs pour Message-Context DOIVENT être enregistrées par l’IANA en suivant les consignes de la section Considérations relatives à l’IANA ci-dessous.


6.2.1 voice-message

La classe voice-message déclare que le message est un message vocal.


6.2.2 fax-message

La classe fax-message déclare que le message est une télécopie.


6.2.3 pager-message

La classe pager-message déclare que le message est un radio message, comme un message de radioavertisseur textuel ou numérique ou un messages traditionnel du service de messages courts (SMS).


6.2.4 multimedia-message

La classe multimedia-message déclare que le message est un message multimédia agrégé, comme un message spécifié par la [RFC2557]. Cela aide à identifier un message dans un contexte multimédia. Par exemple, une partie de données MIME multipart/related [RFC2387] et une partie ressource semblent les mêmes qu’une multipart/related multimédia MHTML. Cependant, leurs sémantiques sont assez différentes.


6.2.5 text-message

La classe text-message déclare que le message est un message Internet traditionnel. Un tel message consiste en texte, éventuellement d’un formatage élaboré, avec ou sans pièce jointe.


6.2.6 none

La classe none déclare qu’il n’y a pas d’informations de contexte pour ce message.


Si un message n’a pas de champ de référence Message-Context, un agent d’utilisateur receveur DOIT le traiter de la même manière que si le message avait une valeur "none".


7. Considérations pour la sécurité


L’intention de cet en-tête est d’être seulement un indicateur du contexte de message. On peut imaginer que quelqu’un crée un contexte de message "Application". Un agent d’utilisateur de conception minimale pourrait exécuter aveuglément un programme de messagerie fondé sur le Message-Context. Ne faites pas cela !


On peut envisager une attaque de déni de service en bombardant un receveur de messages qui ont un Message-Context qui ne correspond pas au profil des parties de corps réelles. C’est pourquoi le receveur examine le Message-Context comme une simple indication.


8. Considérations relatives à l’IANA


Le paragraphe 8.3 est un enregistrement pour un nouvel en-tête de message de niveau supérieur [RFC2822], "Message-Context".


Le présent document crée un ensemble extensible de types de contexte. Pour favoriser l’interopérabilité et la cohérence de l’interprétation des différents types, un répertoire central a été établi pour les types de contextes bien connus.


L’IANA a créé un répertoire pour les types de contextes appelé "Internet Message Context Types". Suivant les politiques mentionnées dans la [RFC2434], ce répertoire est "Spécification exigée" par une RFC. Le paragraphe 8.1 décrit les valeurs initiales pour ce registre.


Pour créer un nouveau type de contexte de message, on DOIT publier une RFC pour documenter le type. Dans la RFC, inclure une copie du gabarit d’enregistrement qui se trouve au paragraphe 8.2 du présent document. Mettre le gabarit dans la section des considérations relatives à l’IANA, en remplissant les champs appropriés. On DOIT décrire toutes les questions d’interopérabilité et de sécurité du document.


8.1 Enregistrements de type de contenu de message

Types de contenu de message Internet


Valeur

Description

Référence

voice-message

Indique un message dont le contenu principal est un message vocal. Le contenu principal est des données audio. Le contexte est usuellement un message enregistré à partir d’un appel téléphonique vocal.

Cette RFC

fax-message

Indique un message dont le contenu principal est une télécopie. Le contenu principal est des données d’image. Le contexte usuel est un message enregistré à partir d’un appel téléphonique de télécopie.

Cette RFC

pager-message

Indique un message dont le contenu principal est un radioappel. Le contenu principal est des données de texte. Le contexte est un message urgent d’une longueur normalement limitée.

Cette RFC

multimedia-message

Indique un message dont le contenu principal est un message multimédia. Le contenu principale est multimédia, très vraisemblablement MHTML. Le contexte est souvent un pourriel ou une lettre de nouvelles.

Cette RFC

text-message

Indique un message Internet classique, fondé sur le texte.

Cette RFC

None

Indique un contexte de message inconnu.

Cette RFC


8.2 Gabarit d’enregistrement

Dans le gabarit suivant, une barre verticale, "|", précède les instructions ou autre matériel utile. Assurez vous de remplacer "<classname>" par le nom de classe à définir.


Nom de classe de Message-Context : <classname>


Résumé de la classe de message :

| Inclure une brève (pas plus de 4 lignes) description ou résumé

| Exemples :

| "Les appareils Palmtop ont un affichage de 320 x 160 pixels, de sorte qu’on peut ..."

| "La télécopie couleur est si différente du noir & blanc que..."

Adresse personnelle & de messagerie à contacter pour plus d’informations : | Nom & mél


8.3 Enregistrement de contexte de message

To: iana@iana.org

Subject: Enregistrement d’un nouvel en-tête RFC 2822


Nom d’en-tête RFC 2822 : Message-Context


Valeurs admises pour ce paramètre : Prière de créer un nouveau registre pour les enregistrements de classe de contexte principale. Voir au paragraphe 8.1 du présent document les valeurs initiales.


Valeur répétée du paragraphe 3.6 de la RFC 2822 :

Champ Nombre minimum Nombre maximum Notes

Message-Context 0 1


Adresse personnelle & de messagerie à contacter pour plus d’informations : Eric Burger e.burger@ieee.org


9. Appendice : Scénarios de messagerie


La présente section n’est pas une partie normative de ce document. Elle est incluse ici comme perspective historique sur les questions de type de message multimédia.


Ces scénarios ne sont ni exhaustifs ni fixés. Par exemple, les messages électroniques étant normalement fondés sur le texte, cela ne signifie pas qu’ils ne puissent convoyer un message vocal. Cette grande mutabilité sert à souligner combien il est souhaitable de fournir une indication explicite du contexte du message.


9.1 Messagerie électronique Internet

La messagerie électronique Internet porte des informations de texte. Parfois, elle porte des données d’application informatiques de taille arbitraire.


Normalement, on utilise la messagerie électronique pour des messages non urgents, que le receveur va restituer et traiter au moment qui lui convient.


L’appareil normal pour recevoir et traiter les messages électroniques est un ordinateur personnel. Les ordinateurs personnels modernes ont généralement un affichage d’une taille raisonnable et un clavier alphanumérique. Les capacités audio, vidéo, et d’impression ne sont pas nécessairement disponibles.


On peut utilise la messagerie électronique pour des communications entre deux parties (un à un) un petit nombre de parties connues (un à quelques uns) ou, via une liste de distribution de messages, entre de plus grands nombres de parties non connues (un à beaucoup).


Une des caractéristiques sympathiques de la messagerie électronique est la façon dont elle permet au receveur de transmettre tout ou partie du message à une autre partie, avec ou sans commentaires supplémentaires. Il est assez courant qu’un message électronique contienne des morceaux de contenu provenant de plusieurs messages antérieurs. Des caractéristiques similaires s’appliquent lorsque on répond à un message électronique.


9.2 Service de radio message

On utilise un message de radio avertissement pour porter des notifications et des alertes. Pour leur plus grande partie, ces notifications sont des informations textuelles de taille limitée. La limite normale est de 160 caractères. Les gens utilisent des radio messageurs pour des messages relativement urgents, dont l’envoyeur souhaite que le receveur les voient et éventuellement leur réponde dans un bref délai. Les radio messages sont souvent utilisés comme moyen d’alerter les usagers sur quelque chose qui a besoin de leur attention. Par exemple, un système peut utiliser un radio messageur pour notifier à un abonné qu’il y a un message vocal qui exige son attention.


Des exemples d’appareils pour envoyer et recevoir des radio messages sont un téléphone mobile avec un affichage en petits caractères ou un messageur de texte. Les ordinateurs personnels et les assistants numériques personnels (PDA, personal digital assistant) peuvent aussi participer à la radio messagerie.


Actuellement, l’utilisation la plus courante des radio messages est juste entre deux parties (un à un).


Une méthode de livraison des radio messages est le service de messages courts (SMS, short text messaging service). Le SMS est une facilité qui a évolué pour être utilisée avec les téléphones mobiles, et a une taxe de transmission associée par message. Noter qu’ici, l’accent est mis sur l’aspect notification du SMS. Depuis le début, le SMS a été envisagé comme étant plus qu’un simple service de radio message. Les opérateurs peuvent utiliser le SMS pour approvisionner le téléphone, par exemple. Du point de vue de l’abonné, le SMS a considérablement évolué depuis son origine comme pur service de remplacement de la radio messagerie. Par exemple, avec le service généré par un mobile, les gens peuvent avoir des sessions de conversation bidirectionnelles par texte en utilisant le SMS avec un téléphone mobile. De plus, il y a des combinés à capacité SMS qui peuvent afficher des images. Cependant, pour les besoins du présent document, il faut toujours arriver à saisir l’essence d’un service de "notification ou d’alerte par un texte bref très urgent".


Les usagers envoient souvent des radio messages isolés, plutôt qu’au titre de plus longs échanges. Une de leurs utilisations est comme invite ou incitation à communiquer par une méthode plus pratique et de contenu plus riche, comme un appel téléphonique.


9.3 Télécopie

Les gens utilisent la télécopie pour transporter des informations d’image de taille modérée, normalement d’un petit nombre de pages. Parfois les gens utilisent la télécopie pour de plus gros documents.


La télécopie est une facilité qui utilise habituellement les circuits du téléphone commuté, avec une taxation à la durée de connexion. Le transfert de message a lieu en temps réel. Donc, les gens utilisent souvent la télécopie pour des communications urgentes.


L’appareil normal pour envoyer et recevoir une télécopie est un appareil qui contient un dispositif d’analyse et un dispositif d’impression, qui est connecté à une ligne téléphonique ou à un ordinateur de bureau.


La plupart des télécopies sont entre deux parties (un à un). Cependant, une portion significative du service de télécopie est de la diffusion entre plusieurs parties (un à beaucoup).


La plupart des échanges de télécopie sont isolés, plutôt que partie d’un échange plus long. Les données de télécopie ne sont normalement pas adaptés pour un traitement informatique ultérieur.


9.4 Messagerie vocale

Les gens utilisent la messagerie vocale pour porter des informations audio, presque exclusivement de la parole humaine.


La messagerie vocale est une facilité qui utilise normalement des circuits du téléphone commuté, avec de modestes taxes de temps de connexion, souvent utilisée pour des messages modérément urgents. Un usage courant est pour une invite ou incitation à communiquer par une méthode plus pratique, telle qu’un appel téléphonique. Dans la plupart des cas, mais pas tous, l’envoyeur d’un message vocal ne veut pas envoyer de message du tout. Il souhaitait plutôt avoir une conversation directe en temps réel.


L’appareil normal pour envoyer et recevoir un message vocal est un combiné téléphonique.


Les messages vocaux sont normalement envoyés entre seulement deux parties (un à un).


Les données de messagerie vocale ne conviennent généralement pas à un traitement informatique ultérieur.


9.5 Message multimédia

On définit un message multimédia comme un message qui contient plus d’un type de support de base (texte, image, audio, vidéo, modèles, application).


Un message multimédia a les caractéristiques suivantes.


Dans certains cas, un message multimédia est juste un message électronique avec une pièce jointe que présente une application d’affichage multimédia. Par exemple, je peux vous envoyer un MP3 de quelque chose que j’ai enregistré aujourd’hui dans mon garage.


Dans d’autres cas, un message multimédia représente une convergence entre deux des scénarios décrits ci-dessus, ou plus. Par exemple, un message vocal avec un diagramme d’accompagnement ou un message vidéo d’une tête en train de parler est un message multimédia.


Les caractéristiques vont varier un peu selon les intentions de l’envoyeur. Cela va à son tour affecter l’agent d’utilisateur ou l’application utilisée pour rendre le message.


10. Références

10.1 Références normatives


[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC6410)


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


[RFC2234] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)


[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)


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


10.2 Références pour information


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


[RFC2423] G. Vaudreuil, G. Parsons, "Enregistrement su sous-type MIME Message vocal VPIM", septembre 1998. (Obsolète, voir RFC3801) (P.S.)


[RFC2557] J. Palme, A. Hopmann et N. Shelness, "Encapsulation MIME de documents agrégés, tels que HTML (MHTML)", mars 1999.


[RFC3459] E. Burger, "Paramètres à contenu critique des extensions multi-usage de messagerie Internet (MIME)", janvier 2003. (P.S.) (MàJ RFC 3204, Mis à jour par RFC 5621)


11. Remerciements


Beaucoup des idées présentées ici trouvent leur origine dans une discussion évec Jutta Degener. Nous tenons à remercier Keith Moore pour son aide à resserrer nos explications. Dans la phase finale, nous avons reçu de bons conseils de Caleb Clausen et Dave Aronson. Antti Vaha-Sipila nous informé des avancées des SMS, et Stuart McRae a aidé à distiller l’essence du service de radio messagerie vis a vis du SMS. Des remerciements particuliers sont dus à Greg Vaudreuil pour avoir tiré la RFC 2557 de son chapeau.


12. Adresse des auteurs


Eric Burger

Emily Candell

Charles Eliot

SnowShore Networks, Inc.

Comverse Network Systems

Microsoft Corporation

285 Billerica Rd.

200 Quannapowitt Pkwy.

One Microsoft Way

Chelmsford, MA 01824-4120

Wakefield, MA 01880

Redmond WA 98052

USA

USA

USA

téléphone : +1 978 367 8403

téléphone : +1 781 213 2324

téléphone : +1 425 706 9760

mél : e.burger@ieee.org

mél : emily.candell@comverse.com

mél : charle@Microsoft.com


Graham Klyne

Nine by Nine

United Kingdom

mél : GK-IETF@ninebynine.org


13. Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2003). Tous droits réservés.


Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.


Le présent document et les informations y contenues sont fournies 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 ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.


Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

page - 9 -