Messagerie vocale Internet (IVM)

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 (2005).

Résumé

Le présent document décrit le portage des messages de messagerie vocale sur la messagerie Internet au titre des l'infrastructure unifiée de messagerie.

Le concept de messagerie vocale Internet (IVM, Internet Voice Messaging) décrit dans le présent document n'est pas un format successeur de VPIMv2 (Profil vocal pour la messagerie Internet version 2) mais plutôt la spécification d'une solution de remplacement pour une application différente.

1. Introduction

Pour certaines formes de communication, les gens préfèrent communiquer au moyen de leur voix plutôt qu'en tapant sur un clavier. En permettant la mise en œuvre de la messagerie vocale d'une façon interopérable par dessus la messagerie Internet, la messagerie vocale et la messagerie électronique n'ont plus besoin de rester dans des mondes séparés et isolés, et les utilisateurs seront capables de choisir la forme de communication la plus appropriée. Cela va aussi permettre d'utiliser de nouveaux types d'appareils, sans clavier, pour participer à la messagerie électronique en déplacement, dans un environnement hostile, ou en dépit d'incapacités.

Il existe des systèmes de messagerie unifiée qui vont transmettre les messages de messagerie vocale sur l'Internet en utilisant SMTP/MIME, mais ces systèmes souffrent d'un manque d'interopérabilité à cause de divers aspects de ces messages qui n'ont pas encore été normalisés. De plus, les systèmes de messagerie vocale peuvent maintenant se conformer au profil vocal pour la messagerie Internet (VPIM v2, Voice Profile for Internet Messaging) (tel que défini dans la [RFC2421] et révisé dans la [RFC3801]) lors de la transmission de messages à des systèmes de messagerie vocale distants. VPIM v2 a été conçu pour permettre à deux systèmes de messagerie vocale d'échanger des messages, pas pour permettre à un système de messagerie vocale d'interopérer avec la tablette d'un client de messagerie vocale. Il n'est souvent pas raisonnable de s'attendre à ce qu'un message VPIM v2 soit utilisable pour un receveur de messagerie électronique. Le résultat est que les messages qui ne peuvent pas être traités par le receveur (par exemple, à cause du codage utilisé) ou apparaissent sous une forme affreuse à l'usager.

Le présent document propose donc un mécanisme standard pour représenter un message vocal au sein de SMTP/MIME, et un codage standard pour le contenu audio, que les systèmes unifiés de messagerie et les clients de messagerie électronique DOIVENT mettre en œuvre pour assurer l'interopérabilité. En utilisant une représentation SMTP/MIME standard et un codage audio largement mis en œuvre, cela va aussi permettre à la plupart des utilisateurs de clients de messagerie électronique qui ne mettent pas spécifiquement en œuvre le standard d'accéder quand même aux messages vocaux. De plus, le présent document décrit des caractéristiques qu'un client de messagerie électronique DEVRAIT mettre en œuvre pour permettre aux receveurs d'afficher les messages vocaux d'une manière plus amicale, sensible au contexte, pour l'utilisateur, et fournir intelligemment certaines des fonctionnalités supplémentaires qu'on trouve normalement dans les systèmes de messagerie vocale (comme de répondre par un message vocal plutôt qu'un message écrit). Finalement, on explique comment un client PEUT assurer un certain niveau d'interopérabilité avec VPIM v2.

Il est souhaitable que les clients de messagerie unifiée soient aussi capables d'interopérer pleinement avec les serveurs de messagerie vocale. Ceci est aujourd'hui possible, pourvu que le client mette en œuvre VPIM v2 [RFC3801], en plus de la présente spécification, et l'utilise pour construire des messages à envoyer à un serveur de messagerie vocale.

La définition du présent document se fonde sur le document d'exigences pour IVM [RFC3773]. Il fait référence à un travail distinct sur le contenu critique [RFC3459] et sur le contexte de message [RFC3458]. Les questions d'adressage et de répertoire sont discutées dans les documents en rapport [RFC3804], [RFC4237], [RFC4238].

On trouvera plus d'informations sur VPIM et les activités qui s'y rapportent à http://www.vpim.org ou à http://www.ema.org/vpim.

2. Conventions utilisées dans le présent 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].

3. Format de message

Les messages vocaux peuvent être créés explicitement par un usager (par exemple, en enregistrant un message vocal dans son client de messagerie) ou implicitement par un système de messagerie unifié (lorsque il enregistre un message téléphonique).

Tous les messages DOIVENT se conformer au format de messagerie Internet, tel que mis à jour par le groupe de travail DRUMS [RFC2822], et le format MIME [RFC2045].

Lors de la création d'un message vocal par un client qui prend en charge IVM, l'en-tête de message DOIT indiquer un contexte de message de "voice-message" (voir la [RFC3458]). Cependant, pour assurer l'interopérabilité avec les clients qui ne prennent pas explicitement IVM, un receveur NE DOIT PAS exiger sa présence afin de traiter correctement les messages vocaux.

L'agent receveur DOIT être capable de prendre en charge les messages multiparties [RFC2049]. Si l'agent d'utilisateur receveur identifie le message comme message vocal (d'après le contexte du message) il DEVRAIT le présenter à l'usager comme message vocal plutôt que comme un message de messagerie électronique avec une pièce jointe vocale (voir la [RFC4024]).

Tout type de contenu est permis dans un message, mais le type de contenu de niveau supérieur sur un message vocal nouveau, transmis ou de réponse DEVRAIT être multipart/mixte. Si le receveur est connu pour être conforme à VPIM v2, alors multipart/voice-message PEUT être utilisé à la place (auquel cas, toutes les dispositions de la [RFC3801] DOIVENT être mises en œuvre dans la construction du message).

Si le message a été créé comme message vocal, et n'est donc pas utile si le contenu audio est omis, alors la partie audio appropriée DOIT être indiquée comme contenu critique, via un paramètre de criticité de CRITICAL sur le Content-Disposition (voir la [RFC3459]). Des parties de corps supplémentaires importantes (comme le message audio original si un message vocal est transmis) PEUVENT aussi être indiquées via une criticité de CRITICAL. Les contenus qui ne sont pas essentiels pour communiquer la signification du message (par exemple, une vCard associée pour le générateur) PEUVENT être indiqués via une criticité de IGNORE.

Lors de la transmission de messages IVM, les clients DOIVENT préserver le type de contenu de toutes les parties de corps audio afin de s'assurer que le nouveau receveur est capable d'exécuter les messages transmis.

Le type de contenu de niveau supérieur, en générant un message de notification de livraison, DOIT être un multipart/report. Cela va permettre un traitement automatique de la notification de livraison, par exemple, afin que le traitement de texte en parole puisse rendre une notification de non livraison dans le langage approprié pour le receveur.

4. Transport

Le message DOIT être transmis conformément au protocole simple de transport de messagerie SMTP, tel que mis à jour par le groupe de travail DRUMS dans la [RFC2821].

Des notifications d'état de livraison PEUVENT être demandées [RFC3461] si la livraison du message est importante pour le générateur et un mécanisme existe pour lui retourner les indications d'état (ce qui peut n'être pas possible pour les générateurs de messages vocaux).

5. Adressage

Toute adresse de messagerie Internet valide peut être utilisée pour un message vocal.

Il est souhaitable d'être capable d'utiliser une bretelle d'entrée/sortie pour la livraison d'un message vocal à un usager, d'où vont découler des exigences spécifiques d'adressage, sur la base des sélecteurs de service définis dans la [RFC3191]. On trouvera une discussion plus approfondie sur les exigences d'adressage pour les messages vocaux dans le document sur l'adresse dans VPIM [RFC3804].

Il est souhaitable de permettre l'utilisation d'un service de répertoire pour transposer le numéro de téléphone E.164 du receveur en une adresse de boîte aux lettres SMTP. Un exposé sur la façon dont cela peut se réaliser en utilisant l'infrastructure ENUM figure dans la [RFC4238]. Une définition du schéma de LDAP VPIM que va utiliser un système se trouve dans la [RFC4237].

Si un message est créé et mémorisé par suite de la réponse à un appel, le nom et le numéro de l'appelant PEUVENT être mémorisés dans les en-têtes de message dans son format original conformément à la [RFC3939].

6. Notifications

Les notifications d'état de livraison DOIVENT être prises en charge. Toute non livraison de message DOIT résulter en une notification de non livraison (NDN non-delivery notification) si elle est demandée [RFC3461], [RFC3462], [RFC3463], [RFC3464]. Si le système receveur prend en charge la criticité du contenu et est incapable de traiter tous les types de support critiques au sein d'un message vocal (indiqué par la criticité du contenu) il DOIT alors notifier la non livraison du message entier conformément à la [RFC3459].

Les notifications de disposition de message (MDN, Message Disposition Notification) DEVRAIENT être prises en charge (mais conformément aux règles des MDN, l'usager DOIT avoir l'option de décider si les MDN sont retournées) selon la [RFC3798].

Si le receveur n'est pas capable d'afficher tous les composants de contenu critique indiqués, l'usager DEVRAIT alors avoir l'option de retourner une MDN appropriée (voir la [RFC3459]).

7. Contenu vocal

Les messages vocaux peuvent être contenus dans toute localisation au sein d'un message et DOIVENT toujours être contenus dans un type de contenu audio/basic, sauf si le générateur sait que le receveur peut traiter d'autres contenus. Précisément, Audio/32kadpcm PEUT être utilisé lorsque le receveur est connu pour prendre en charge VPIM v2 [RFC3801].

Le paramètre VOICE sur le Content-Disposition de VPIM v2 [RFC3801] DEVRAIT être utilisé pour identifier tous noms parlés ou sujets parlés (distinct du contenu de message vocal). Aussi, l'en-tête Content-Duration de la [RFC3803] DEVRAIT être utilisé pour indiquer la longueur audio.

Le nom parlé du générateur PEUT être inclus dans les messages comme contenu audio séparé, si il est connu, et DEVRAIT être indiqué par le paramètre Content-Disposition VOICE comme défini dans VPIM v2 [RFC3801]. Si il y a un seul receveur pour le message, le nom parlé PEUT aussi être inclus (conformément à VPIM v2). Un sujet parlé PEUT aussi être fourni (conformément à VPIM v2).

Une mise en œuvre d'envoi PEUT déterminer les capacités du receveur avant l'envoi d'un message et choisir un codec en conséquence (par exemple, en utilisant une forme de négociation de contenu). En l'absence d'une telle connaissance du receveur, les mises en œuvre d'envoi DOIVENT utiliser la loi µ G.711 brute, qui est indiquée avec un type de contenu MIME de "audio/basic" (et DEVRAIT utiliser un paramètre de nom de fichier qui se termine par ".au") [G711], [RFC2046]. Une mise en œuvre d'envoi PEUT prendre en charge l'interopérabilité avec VPIM v2 [RFC3801], auquel cas, elle DOIT être capable d'enregistrer G.726 (indiqué comme audio/32kadpcm) [G726], [RFC3802].

Les receveurs DOIVENT être capables d'exécuter un messages G.711 Loi µ brut, et PEUVENT être capables d'exécuter G.726 (indiqué comme audio/32kadpcm) pour assurer l'interopérabilité avec VPIM v2. Une mise en œuvre receveuse PEUT aussi être capable d'exécuter des messages codés avec d'autres codecs (soit naturellement, soit via transcodage).

Ces exigences sont résumées comme suit :

* = NE DOIT PAS, mais PEUT seulement si les capacités du receveur connaissent

8. Contenu de télécopie

Les contenus de télécopie DEVRAIENT être portés conformément à la [RFC2532].

9. Interopérabilité avec VPIM v2

L'interopérabilité entre les systèmes VPIM v2 et les systèmes IVM peut prendre un certaine nombre de formes différentes. Bien qu'une investigation précise de la façon dont la pleine interopérabilité pourrait être fournie entre les systèmes IVM et VPIM v2 sorte du domaine d'application du présent document, trois solutions possibles sont discutées ci-dessous.

9.1 Traitement des messages VPIM v2 dans un client IVM

Si un client conforme à IVM est capable de traiter un type de contenu de multipart/voice-message (en le traitant comme multipart/mixed) et d'exécuter un message audio codé selon G.726 en son sein (indiqué par un type de contenu de audio/32kadpcm) alors un message VPIM v2 qui se trouve acheminé à cet appareil sera au moins utilisable par le receveur.

Cela assure un niveau partiel d'interopérabilité qui va faciliter la vie des utilisateurs finaux. Cependant, il faudra veiller à s'assurer que toute tentative de réponse à un tel message ne résulte pas en un message VPIM v2 invalide envoyé à un système VPIM v2. Noter que répondre à un utilisateur de messagerie électronique qui a transmis un message VPIM v2 est cependant acceptable.

Une mise en œuvre conforme à IVM NE DOIT PAS envoyer un message non VPIM v2 à quelque chose qu'il sait être un système VPIM v2, sauf si il sait aussi que le système de destination peut traiter un tel message (même si les systèmes VPIM v2 sont encouragés à traiter les messages non VPIM v2 d'une manière accommodante). En général, on doit supposer que si un système envoie un message conforme à VPIM v2, c'est alors un système VPIM v2, et on peut donc seulement répondre par un message conforme à VPIM v2 (sauf si on sait par d'autres moyens que le system prend en charge IVM).

De plus, on devrait noter qu'un client IVM peut ne pas se conformer pleinement à VPIM v2, même si il prend en charge l'exécution d'un message G.726 (par exemple, il peut ne pas respecter le traitement du champ Sensitivity exigé par VPIM v2). C'est une des raison pour lesquelles les systèmes VPIM v2 peuvent choisir de ne pas acheminer les messages à des systèmes dont ils ne savent pas si ils sont conformes à VPIM v2.

9.2 Systèmes et clients en mode duel

Un système VPIM v2 pourrait être étendu pour être aussi capable de prendre en charge les messages conformes à IVM , et un client conforme à IVM pourrait être étendu à la mise en œuvre complète de VPIM v2 lorsque il correspond avec un système conforme à VPIM v2. Il est simplement question de mettre en œuvre les deux spécifications et de choisir celle qui est approprié, selon le contenu de message reçu ou les capacités du receveur. Cela assure une pleine interopérabilité des systèmes pertinents, pourvu que les capacités des utilisateurs ciblés puissent être déterminées.

Noter que le mécanisme pour déterminer si un certain receveur utilise un système ou client VPIM v2 est en dehors du champ d'application de la présente spécification. Divers mécanismes existent pour la découverte des capacités, qui pourraient être appliqués à ce problème, mais aucune solution standard n'a encore été définie.

9.3 Passerelles

Il serait possible de construire une passerelle reliant un ensemble d'utilisateurs VPIM v2 à un ensemble d'utilisateurs de IVM. Cette passerelle mettrait en œuvre la sémantique des deux mondes, et traduirait entre eux conformément à des politiques définies.

Par exemple, les messages VPIM v2 avec une sensibilité de Privé pourraient être rejetés au lieu d'être transmis à un receveur IVM, parce qu'il pourrait ne pas mettre en œuvre la sémantique d'un message Privé, tandis qu'un message IVM contenant un contenu non supporté dans VPIM v2 (par exemple, une image PNG) avec une criticité de CRITICAL, serait rejeté par la passerelle.

Une telle passerelle DOIT pleinement mettre en œuvre la présente spécification et la spécification VPIM v2 [RFC3801], sauf si elle sait d'une certaine façon que les générateurs/receveurs spécifiques prennent en charge des capacités qui vont au delà de celles exigées par ces normes.

10. Considérations sur la sécurité

Le présent document présente une passerelle facultative entre les systèmes IVM et VPIM. Les passerelles sont par nature des systèmes à pertes et toutes les informations ne peuvent pas être traduites avec précision. Ceci s'applique aussi bien au transcodage de la voix qu'à la traduction des caractéristiques. Deux exemples de traduction de caractéristiques sont donnés au paragraphe 9.3, mais il reste un risque que des passerelles différentes traitent différemment la traduction car elle n'est pas définie dans le présent document. Cela peut conduire à des comportements inattendus à travers les passerelles.

De plus, les passerelles présentent un point d'attaque supplémentaire pour ceux qui s'intéressent à la compromission d'un système de messagerie. Si une passerelle est compromise, des attaques "par interposition", conduites à partir de la passerelle compromise, peuvent être difficiles à détecter ou apparaître comme des transformations autorisées.

À côté du problème de la passerelle, on prévoit qu'il y aura de nouveaux problèmes de sécurité au delà de ceux identifiés dans VPIM v2 [RFC3801] et dans les autres RFC référencées par le présent document – en particulier SMTP [RFC2821], le format de message Internet [RFC2822], MIME [RFC2046], les contenus critiques [RFC3459], et le contexte de message [RFC3458].

11. Références

11.1. Références normatives

[RFC2045] N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2046] N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support", novembre 1996. (D. S., MàJ par 2646, 3798, 5147, 6657.)

[RFC2049] N. Freed, N. Borenstein, "Extensions multi-objets de la messagerie Internet (MIME) Partie cinq : critères de conformité et exemples", novembre 1996. (Remplace RFC1521, RFC1522, RFC1590) (D.S.)

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

[RFC2421] G. Vaudreuil, G. Parsons, "Profil vocal pour la messagerie Internet - version 2", septembre 1998. (Obsolète, voir RFC3801) (P.S.)

[RFC2532] L. Masinter, D. Wing, "Extension de télécopie avec la messagerie Internet", mars 1999. (P.S.)

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

[RFC3191] C. Allocchio, "Format minimal d'adresse GSTN dans la messagerie Internet", octobre 2001. (D.S.)

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

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

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

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

[RFC3802] G. Vaudreuil, G. Parsons, "Voix de qualité supérieure – enregistrement du sous-type MIME en modulation par impulsions et codage différentiel adaptatif à 32 kbit/s (MICDA)", 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.)

[RFC3804] G. Parsons, "Profil vocal pour l'adressage de la messagerie Internet (VPIM)", juin 2004. (P.S.)

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

[RFC4024] G. Parsons, J. Maruszak, "Comportement de client de messagerie vocale", juillet 2005. (Information)

[RFC4237] G. Vaudreuil, "Service d'annuaire de messagerie vocale", octobre 2005. (P.S.)

[RFC4238] G. Vaudreuil, "Service d'acheminement de messagerie vocale", octobre 2005. (P.S.)

11.2. Références pour information

[RFC3773] E. Candell, "Exigences de haut niveau pour la messagerie vocale Internet", juin 2004. (Information)

[G711] Recommandation UIT-T G.711 (1993), "Aspects généraux des systèmes de transmission numériques, équipement terminal - modulation par impulsions et codage (MIC) des fréquences vocales".

[G726] Recommandation UIT-T G.726 (1990), "Aspects généraux des systèmes de transmission numériques, équipement terminal - modulation par impulsions et codage différenteil adaptatif (MICDA) à 40, 32, 24, et 16 kbit/s"

Adresse des auteurs

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 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 le 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 actuellement fourni par l’Internet Society.