Groupe de travail Réseau	G. Parsons, Nortel Networks	
Request for Comments : 4024	J. Maruszak	
Catégorie : Information		
Traduction Claude Brière de L'Isle	juillet 2005	

Comportement du client de messagerie vocale

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune forme de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2005). Tous droits réservés

Résumé
Le présent document définit le comportement attendu d'un client pour divers aspects d'un profil vocal pour la messagerie Internet (VPIM) ou tout message vocal et/ou de télécopie.

Table des Matières
1. Introduction	1
2. Conventions utilisées dans ce document	2
3. Icône de message	2
3.1. Mécanisme proposé	2
4. Colonne de numéros d'envoyeur	2
4.1 Mécanisme proposé	3
5. Taille de message	3
5.1 Mécanismes proposés	3
5.1.1 Contenu-durée d'en-tête MIME comme décrit dans la [RFC3803]	3
5.1.2 Longueur de message comme paramètre d'un champ d'en-tête Type de contenu existant de la [RFC2045]	3
5.1.3 Longueur de message indiquée au titre d'un champ d'en-tête existant de la [RFC2822]	3
6. Visionneur de support	4
6.1 Mécanisme proposé	4
7. Marquer le message comme lu	4
7.1 Mécanisme proposé	4
8. Considérations sur la sécurité	4
10. Références pour information	5
10. Remerciements	5
Adresse des auteurs	5
Déclaration complète de droits de reproduction	5

1.	Introduction

La messagerie Internet évolue vers une messagerie unifiée , le terme "messagerie électronique" ne se réfère plus à des messages seulement textuels. La "messagerie électronique" d'aujourd'hui est souvent multimédia. C'est-à-dire qu'ils peuvent avoir de nombreuses parties non textuelles. Ces parties peuvent être des pièces jointes ou peuvent contenir de la voix et/ou de la télécopie.

La voix, la télécopie, et le texte ont chacun leurs propres caractéristiques distinctes, qui sont intuitives pour l'usager. Par exemple, chacun de ces types de message exige un visionneur de support différent (un éditeur de texte pour le texte, une sortie audio pour la voix, et un afficheur d'image pour la télécopie) et les dimensions des tailles de messages sont aussi différentes pour les trois (kilo octets pour le texte, secondes pour la voix, et pages pour la télécopie). Par suite, un message qui inclut plus d'un de ces supports dans ses parties est appelé un message de supports mixtes.

Comment le client de messagerie répond, et agit, sur ces différences est appelé "comportement de client". Cela dépend du concept de "contexte de message" [RFC3458] (précédemment appelé contenu principal) qui définit si le message est un message vocal, une télécopie, ou un message de texte. Le client peut utiliser cet en-tête pour déterminer le comportement de client approprié pour un message particulier.

Traditionnellement, un "client" de messagerie se référait à une sorte d'interface visuelle (ou GUI, graphical user interface) qui était présentée sur l'ordinateur des utilisateurs. Cependant, comme la messagerie évolue vers des communications unifiées, la forme réelle du client de messagerie va vraisemblablement changer. La messagerie électronique d'aujourd'hui peut souvent être vue sur des appareils sans fil avec des écrans très limités ou même "vue" sur un téléphone (c'est-à-dire en écoutant les messages comme on écouterait un message vocal à travers une interface d'utilisateur telset (TUI, telset user interface).

L'intention du présent document est d'être général et de se référer à tous les types de clients de messagerie, car les attentes de comportement de l'usager sur la base du type de message ne sont pas supposées changer. Cependant, certains des concepts suivants peuvent tendre vers la GUI de client la plus courante.

2.	Conventions utilisées dans ce document

Dans les exemples, "C:" et "S:" indiquent les lignes envoyées respectivement par le client et le serveur.

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.	Icône de message

La méthode préférée pour distinguer entre le message vocal, de télécopie, et de texte sur une GUI de client est avec une indication visuelle, ou icône. Une invite vocale similaire ou "oreillette" serait utilisée pour les clients de TUI.

Comme il est possible que le message contienne plus d'un type de supports, l'icône devrait décrire le contenu principal du message, comme défini par l'en-tête "Message-Context". Des choix évidents pour les paires icône/message seraient un téléphone pour un message vocal, une machine de télécopie pour un message de télécopie, et une enveloppe pour un message de texte. Aussi évident pour l'oreillette serait une brève invite parlée comme "message vocal".

On pourrait faire un pas de plus en changeant l'icône de GUI pour indiquer que le message a été lu comme c'est fait actuellement dans certains clients de messagerie électronique (d'autres ne changent pas l'icône mais mettent simplement en gras le message dans la liste des messages pour indiquer qu'il n'a pas été lu). Par exemple, un téléphone avec le récepteur décroché pourrait indiquer que le message vocal a été exécuté. Un télécopieur avec du papier en bas, par opposition au papier au dessus, montrerait que la télécopie a été vue. Finalement, une enveloppe ouverte indique qu'un message de texte a été lu.

3.1.	Mécanisme proposé
Comme le choix de l'icône est déterminé par le type principal du message, le client devrait obtenir ces informations de l'en-tête de message "Message-Context ". Cet en-tête est défini dans la [RFC3458].

4.	Colonne de numéros d'envoyeur

Comme c'est le cas avec la plupart des clients de messagerie électronique à GUI d'aujourd'hui, les informations de message importantes sont organisées en colonnes lorsque elles sont présentées à l'utilisateur dans une liste résumée des messages. Les TUI présentent souvent des résumés encore plus brefs à l'utilisateur au début de la session. Les colonnes typiques du client de GUI incluent le sujet du message, et sa date de réception.

Un autre important élément d'information pour l'utilisateur est l'origine du message. Pour un message vocal ou de télécopie, l'origine est normalement respectivement un téléphone ou un télécopieur, dont chacun a un numéro de téléphone associé. Ce numéro de téléphone est critique pour l'usager si il souhaite rappeler l'envoyeur. Cela devrait être présenté avec précision à l'usager (sans en faire une adresse de messagerie électronique).

4.1	Mécanisme proposé
Au lieu de forcer la transformation du numéro de téléphone en adresse de messagerie électronique, un nouvel en-tête de message Internet peut être utilisé pour contenir le numéro de téléphone d'origine [RFC3939]. Si le message est indiqué comme étant un message vocal ou de télécopie selon la [RFC3458], le client devrait extraire le numéro, et l'afficher à l'usager dans une colonne séparée. Comme cet en-tête est défini comme ne contenant que les chiffres du numéro de téléphone, il appartient au client d'ajouter les caractères séparateurs utiles (par exemple, "-").

5.	Taille de message

Dans le cas de grosses pièces jointes, de petits clients (par exemple, une tablette) et des liaisons lentes (par exemple, sans fil) le client a aussi besoin de voir la longueur du message dans un format convenable avant de l'ouvrir.

Actuellement, la taille de message est normalement donnée en kilo octets (ko). C'est suffisant pour les messages de texte, mais bien que cela puisse donner une indication de la qualité de l'algorithme de compression, le nombre de ko n'est pas très utile pour savoir la taille d'un message vocal ou de télécopie. À la place, la taille devrait donner une indication de la longueur du message, c'est-à-dire, la durée (en secondes) d'un message vocal, et le nombre de pages d'une télécopie. Là encore, le message peut contenir plusieurs types, de sorte que la taille affichée devrait être celle du type de contenu principal, selon la [RFC3458].

5.1	Mécanismes proposés
Trois méthodes sont suggérées pour relayer ces informations, la première méthode étant la préférée :

5.1.1	Contenu-durée d'en-tête MIME comme décrit dans la [RFC3803]
Pour les messages vocaux, le champ Content-Duration de la partie de corps principal audio/* (comme indiqué par content-disposition selon la [RFC3801]) devrait être affiché comme la longueur du message. Si il y a plusieurs parties audio, une mise en œuvre peut afficher la taille du message comme un agrégat de la longueur de chacune.

Pour les messages de télécopie, un nouvel en-tête MIME, Content-Page-Length (longueur de page de contenu), pourrait être défini, similaire à Content-Duration à l'exception que le nombre de pages serait spécifié, plutôt que le nombre de secondes (par exemple, Content-Page-Length:3). Ceci serait créé à l'origine.

5.1.2	Longueur de message comme paramètre d'un champ d'en-tête Type de contenu existant de la [RFC2045]
Ceci serait créé à la source. Cette proposition de méthode permettrait que la longueur de message soit passée au client par défaut dans IMAP. Là encore, le client aurait à choisir entre afficher la longueur du message vocal principal ou une longueur agrégée.

Exemple de champ d'en-tête Content-Type :

Content-Type=audio/*; length=50
Content-Type=image/tiff; pages=3

5.1.3	Longueur de message indiquée au titre d'un champ d'en-tête existant de la [RFC2822]
Ce champ serait créé à la source et pourrait inclure les informations de longueur du message, mais comme il fait partie des en-têtes du message, il pourrait aussi être amendé à réception (par un processus local).Cette méthode permettrait que la longueur de message soit passée à tout client par défaut et n'exige aucune modification du client. Si elle est utilisée, ce champ indiquerait la longueur agrégée de toutes les pièces jointes.

L'avantage de ce mécanisme est qu'aucun nouvel en-tête n'est exigé et qu'il fonctionne avec les clients existants. L'inconvénient est qu'il surcharge le champ de sujet.

Exemple de champ d'en-tête Subject :
Subject=Voice Message (0:04)
Subject=Fax Message (3p)
Subject=Voice Message (0:14) with Fax (1p)

6.	Visionneur de support

Lorsque un message est initialement ouvert, le client devrait, pas défaut, ouvrir le visionneur de support approprié pour afficher le contenu principal du message. C'est-à-dire, un diffuseur audio pour les messages vocaux, un visionneur d'images pour la télécopie, et un éditeur de texte pour les messages de texte. Noter que sur une TUI, le visionneur rendrait le support sonore (ce qui aurait un effet variable selon le support et le processus disponible).

Lorsque il y a plus d'une partie de corps, il est évident que le visionneur approprié devrait être utilisé selon la partie de corps que choisit l'utilisateur.

Dans le cas où plusieurs visionneurs sont disponibles pour un seul type de support, l'usager devrait être invité à choisir le visionneur désiré à la première occasion où se rencontre le type de message. Ce visionneur devrait alors devenir le visionneur par défaut pour ce type de support. L'usager devrait avoir la capacité de changer à tout moment le visionneur par défaut pour un type de support.

Noter qu'il est possible que le visionneur de support ne fasse pas partie du client ou soit local pour l'hôte du client. Par exemple, un usager pourrait choisir d'exécuter un message vocal à partir d'une GUI et le message sera exécuté sur un téléphone (peut-être parce que l'usager n'a pas de haut-parleurs sur son ordinateur). De plus, un usager qui écoute une boîte de messagerie entrante unifiée sur une TUI pourrait choisir d'imprimer un message particulier sur un télécopieur du voisinage.

6.1	Mécanisme proposé
Comme mentionné, le visionneur par défaut affiché à l'usager devrait être approprié pour le type principal de message. Le client est capable de déterminer le type principal de message d'après l'en-tête "Message-Context" de la [RFC3458].

7.	Marquer le message comme lu

Évidemment, l'usager doit être capable de savoir quels messages il a lu, et ceux qu'il n'a pas lu. Ce dispositif contrôlerait aussi l'icône ou l'oreillette de message comme mentionné à la Section 1.

Avec la prolifération des messages vocaux et de télécopie, les clients devraient seulement indiquer que ces messages sont lus lorsque la partie de corps principale a été lue. Par exemple, un message vocal ne devrait pas être indiqué comme lu tant que la partie audio n'a pas été exécutée. Le comportement par défaut est actuellement de marquer un message comme lu lorsque la première partie du corps (normalement, le texte) est visionné.

7.1	Mécanisme proposé
Chez la plupart des clients, la mise en œuvre de cette caractéristique est un problème local.

Par exemple, dans le cas de IMAP4 [RFC3501], ces clients devraient établir le fanion \SEEN seulement après l'ouverture de la première pièce jointe du type de contenu principal. C'est-à-dire que si le contexte du message est un message vocal, le fanion \SEEN serait établi après l'ouverture du message vocal principal (indiqué par content-disposition [RFC3801] ou content-criticality [RFC3459]).

8.	Considérations sur la sécurité

Le comportement de client désirable décrit ici est destiné à donner à l'utilisateur une meilleure expérience. Cependant, la prise en charge du comportement proposé dans le présent document n'assure pas au client l'immunité contre les risques inhérents à l'état de client de la messagerie électronique. C'est-à-dire que le client n'est pas responsable du format du message reçu, il l'interprète seulement. Par suite, des messages peuvent être déguisés ou maquillés pour sembler être un message qu'il n'est pas pour provoquer le comportement désiré du client. Ceci peut être utilisé pour tromper l'utilisateur final, par exemple, et l'amener à penser qu'un message est un message vocal (à cause de l'icône) alors qu'il ne l'est pas.

10.	Références pour information

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

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

[RFC3458]	E. Burger et autres, "Contexte de message pour la messagerie Internet", janvier 2003. (MàJ par RFC3938) (P.S.)

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

[RFC3501]	M. Crispin, "Protocole d'accès au message Internet - version 4rev1", mars 2003. (MàJ par RFC4466, RFC4469, RFC4551, RFC5032, RFC5182) (P.S.)

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

[RFC3803]	G. Vaudreuil, G. Parsons, "Définition de l'en-tête MIME Durée de contenu", juin 2004. (D.S.)

[RFC3939]	G. Parsons, J. Maruszak, "Identification de l'appelant pour les messages vocaux", décembre 2004. (P.S.)

[Voice]	Parsons, G., "IMAP Voice Extensions", Travail en cours, juin 1999.

10.	Remerciements

Le présent travail a été inspiré par la discussion des "mécanismes proposés" pour IMAP qui étaient détaillés dans un travail en cours arrivé depuis à expiration intitulé "Extensions vocales à IMAP" [Voice]. Les auteurs tiennent à remercier tous ceux qui ont contribué à ce document. De plus, Cheryl Kinden, Derrick Dunne, et Jason Collins ont aidé à l'édition des précédentes révisions du présent document.

Adresse des auteurs

Glenn Parsons	Janusz Maruszak	
Nortel Networks	téléphone : +1-416-885-0221	
P.O. Box 3511, Station C	mél : jjmaruszak@sympatico.ca 	
Ottawa, ON  K1Y 4H7		
Canada		
téléphone : +1-613-763-7582		
mél : gparsons@nortel.com 		

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

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 qui y sont 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 ci encloses ne violent 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 pourraient ê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.

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