Network Working Group G

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.

Le présent document spécifie un profil restreint des protocoles de messagerie Internet multimédia à utiliser entre des plateformes de serveur de traitement vocal. Le profil est appelé profil vocal pour messagerie Internet (VPIM, Voice Profile for Internet Mail) dans le présent document. Ces plateformes ont historiquement été des ordinateurs spécialisés et n'ont souvent pas eu les mêmes facilités que celles qui sont normalement associées à un ordinateur traditionnel à capacité de messagerie électronique Internet. Par suite, VPIM spécifie aussi des fonctionnalités supplémentaires, en tant que de besoin. Ce profil est destiné à spécifier l'ensemble minimum commun de caractéristiques pour permettre l'interfonctionnement entre les systèmes qui s'y conforment.

Le présent document rend obsolète la RFC 2421 et décrit la version 2 du profil avec une meilleure précision. Aucun changement du protocole n'a été fait dans la présente révision. Une liste des changements par rapport à la RFC 2421 est notée dans l'Appendice F. L'Appendice A résume les profils de protocole de cette version de VPIM.

Table des Matières

1. Introduction

1.1 Limitations du système de messagerie vocale

1.2 Objectifs de conception

1.3 Applicabilité de VPIM

2. Langage des exigences

3. Restrictions du protocole

4. Format d'échange de message vocal

4.1 Formats d'adressage de message VPIM

4.2 Champs d'en-tête de message

4.3 Descriptions de contenu audio MIME

4.4 Types de contenu de message vocal

4.5 Autres contenus MIME

4.6 Notification d'état de livraison (DSN)

4.7 Notification de disposition de message (MDN)

4.8 Messages transmis

4.9 Messages de réponse

5. Protocole de transport de message

5.1 Protocole SMTP de base

5.2 Extension au service SMTP

5.3 Dégradation de ESMTP à SMTP

6. Résolution d'adresse de répertoire

7. Protocoles de gestion

7.1 Gestion de réseau

8. Exigences de conformité

9. Considérations sur la sécurité

9.1 Directive générale

9.2 Menaces et problèmes

9.3 Techniques de sécurité

10. Références normatives

11. Remerciements

12. Appendice A – Résumé des exigences de VPIM

13. Appendice B - Exemples de messages vocaux

14. Appendice C - Exemple de codes d'erreur d'erreur de traitement vocal

15. Appendice D - Exemple de types de disposition de traitement vocal

16. Appendice E – Enregistrement de l'IANA

16.1 Définition de paramètre Content-Disposition vocal

16.2 Définition du type de support MIME Multipart/Voice-Message

17. Appendice F – Historique des changements de la RFC 2421 (VPIMv2) à ce document

18. Adresse des auteurs

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

MIME est la norme de messagerie multimédia multi objets de l'Internet. Le présent document reconnaît explicitement ses capacités et fournit un mécanisme pour l'échange de diverses technologies de messagerie, principalement vocales et de télécopie.

La messagerie vocale a évolué d'un service de répondeur téléphonique à un paradigme à part entière de messagerie d'envoi, de réception, et de transmission de messages avec des caractéristiques uniques de message, de sémantique et de schémas d'usage. La messagerie vocale a été introduite sur des ordinateurs dédiés qui faisaient l'interface avec un commutateur téléphonique et fournissaient des services de répondeur d'appel et de messagerie vocale. Traditionnellement, les messages envoyés d'un système de messagerie vocale à un autre étaient transportés en utilisant des protocoles de réseautage analogiques fondés sur la signalisation DTMF et l'exécution en vocal analogique. Avec l'augmentation de la demande de réseautage est apparu le besoin d'un protocole standard de haute qualité pour connecter ces machines. VPIM a démontré avec succès son utilité comme nouveau standard. VPIM est largement mis en œuvre et a vu son déploiement dans les réseaux d'abonnés. Le présent document précise des ambiguïtés qui existaient dans la spécification antérieure et est cohérent avec la pratique mise en œuvre. Le profil est appelé profil vocal pour la messagerie Internet (VPIM, Voice Profile for Internet Mail) dans ce document.

Le présent document spécifie un profil restreint des protocoles de messagerie Internet multimédia à utiliser entre des plateformes de serveur de traitement vocal. Le profil est appelé profil vocal pour messagerie Internet (VPIM, Voice Profile for Internet Mail) dans le présent document. Ces plateformes ont historiquement été des ordinateurs spécialisés et n'ont souvent pas eu les mêmes facilités que celles qui sont normalement associées avec un ordinateur traditionnel à capacité de messagerie électronique Internet. Par suite, VPIM spécifie aussi des fonctionnalités supplémentaires, en tant que de besoin. Ce profil est destiné à spécifier l'ensemble minimum commun de caractéristiques pour permettre l'interfonctionnement entre les systèmes qui s'y conforment.

Les limitations typiques suivantes des plateformes de messagerie vocale ont été considérées pour la création de ce profil de base.

1) Les messages de texte ne sont normalement pas reçus et souvent ne peuvent pas être facilement affichés ou vus. Ils ne peuvent souvent être traités que via des dispositifs de texte à parole ou texte à télécopie qui ne sont actuellement pas présents dans beaucoup de ces machines.

2) Les machines de messagerie vocale agissent usuellement comme un agent de transfert de message intégré, un magasin de messages et un agent d'utilisateur. Il n'y a normalement pas de relais des messages. Les champs d'en-tête de la RFC0822 peuvent avoir une utilisation limitée dans le contexte des dispositifs limités de messagerie actuellement déployés.

3) Les mémorisations de messages vocaux ne sont généralement pas capables de préserver la pleine sémantique d'un message Internet. À ce titre, l'utilisation d'une machine de messagerie vocale comme passerelle n'est pas acceptée. En particulier, la mémorisation des listes de receveurs, les lignes "Received:", et "Message-ID:" peut être limitée.

4) les listes de diffusion de distribution/éclatement de style Internet ne sont généralement pas prises en charge. Les machines de messagerie vocale mettent souvent en œuvre seulement des listes d'alias locaux, avec un comportement d'erreur à l'envoyeur et de réponse à l'envoyeur. Des capacités de réponse à tous en utilisant une liste de personnes en copie (Cc) ne sont généralement pas disponibles.

5) Des rapports d'erreur doivent être analysables par la machine afin que des réponses utiles puissent être dites aux utilisateurs dont le seul mécanisme d'accès est un téléphone.

6) Le système de messagerie vocale limite généralement une entrée d'adresse à 16 ou moins de caractères numériques, et ne prend normalement pas en charge les noms de boîte aux lettres alphanumériques. Les caractères alphabétiques ne sont généralement pas utilisés pour l'identification de boîte aux lettres, car ils ne sont pas faciles à entrer sur un terminal téléphonique.

On devrait noter que les nouveaux systèmes se fondent d'origine sur SMTP/MIME et ne souffrent pas de ces limitations. En particulier, certains systèmes peuvent prendre en charge des supports autres que la voix et la télécopie.

Un des objectifs de ce profil est de faire aussi peu de restrictions et d'ajouts que possible aux protocoles existants de messagerie Internet tout en satisfaisant aux exigences d'interopérabilité avec la génération actuelle de systèmes de messagerie vocale. Cet objectif est motivé par le désir d'augmenter l'accessibilité à la messagerie numérique en permettant l'utilisation de logiciels de réseautage existants ayant fait leurs preuves, pour un développement rapide.

Cette spécification est destinée à être utilisée sur un réseau TCP/IP ; cependant, il est possible d'utiliser la suite de protocoles SMTP sur d'autres protocoles de transport. Les paramètres nécessaires du protocole pour une telle utilisation sortent du domaine d'application du présent document.

Ce profil est destiné à être assez robuste pour être utilisé dans un environnement, comme l'Internet mondial, où la base installée de passerelles ne comprend pas MIME. Une pleine fonctionnalité, comme des messages d'erreur fiables et un transport binaire, exigera un choix attentif des passerelles (par exemple, via les enregistrements MX) à utiliser comme agents de transmission VPIM. Rien dans le présent document n'empêche l'utilisation de paquetages de messagerie électronique MIME d'usage général pour lire et composer des messages VPIM. Bien qu'aucune configuration particulière ne soit requise pour recevoir les messages conformes à VPIM, il peut en être exigé pour générer des structures conformes.

On s'attend à ce qu'un administrateur de système qui peut effectuer une configuration de réseau TCP/IP puisse gérer un système de messagerie VPIM. Lors de l'utilisation d'une télécopie ou de plusieurs codages vocaux, il est suggéré que l'administrateur de système conserve une liste des capacités des machines de messagerie qui sont dans le réseau afin de réduire l'envoi des messages indélivrable à cause d'un manque de prise en charge de ces caractéristiques. La configuration, la mise en œuvre et la gestion de ces capacités de répertoires et de listes sont des affaires locales.

VPIM est destiné à l'échange de messages vocaux entre des systèmes traditionnels de messagerie vocale et des systèmes qui ont besoin d'interopérer avec de tels systèmes. VPIM est destiné à connecter des systèmes de messagerie vocale pour constituer des réseaux dédiés à la messagerie vocale. VPIM peut aussi être utilisé entre des serveurs de mémorisation de messages et des clients à capacité VPIM comme des serveurs de la Toile, des clients d'interface d'usager téléphonique (TUI), et graphique (GUI). VPIM n'est pas destiné ou optimisé pour télécharger à, ou envoyer depuis des clients de messagerie électronique commerciale.

La messagerie vocale Internet, qui fait l'objet d'une initiative de normalisation séparée, est destinée à permettre à des clients de messagerie électronique d'usage général d'envoyer et de recevoir un contenu vocal à travers des magasins de message d'usage général de façon interopérable. IVM peut aussi être un format convenable pour télécharger des messages vocaux depuis un serveur VPIM à un client de messagerie électronique commerciale. Il peut aussi être un format convenable pour la soumission d'un message vocal depuis un client d'usage général à un système VPIM.

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

Le présent protocole ne limite pas le nombre de receveurs par message. Lorsque possible, les mises en œuvre de serveur devraient ne pas restreindre le nombre de receveurs dans un seul message. On reconnaît qu'aucune mise en œuvre ne prend en charge un nombre illimité de receveurs, et que le nombre de receveurs supporté peut être assez faible.

Le présent protocole ne limite pas la longueur maximum de message. Les mises en œuvre devraient savoir que certaines machines seront incapables d'accepter des longueurs de message excessives. Un mécanisme est défini dans la [RFC1870] pour déclarer la taille maximum de message supportée.

Les sections qui suivent décrivent les restrictions et ajouts aux protocoles de messagerie Internet qui sont nécessaires pour se conformer à ce profil VPIM v2. Bien que diverses caractéristiques de SMTP, ESMTP et MIME soient décrites ici, les mises en œuvre se reporteront aux RFC pertinentes pour les détails. Le tableau de l'Appendice A résume les détails du protocole de ce profil.

Le format d'échange de message vocal est un profil de la suite de protocoles de la messagerie Internet. Tout message de messagerie Internet qui contient le format défini dans cette section est appelé un message VPIM dans le présent document. Par suite, le présent document suppose la compréhension des spécifications de la messagerie Internet. Précisément, VPIM fait référence à des composants qui sont dans le format de message standard pour les messages Internet [RFC822], les extensions de message multi objets Internet [RFC2049], la spécification de passerelle X.400 [X.400], et les notifications d'état de livraison et de disposition de message [RFC2034], [RFC3461], [RFC3462], [RFC3464], [RFC3798].

MIME, introduit dans la [RFC2045], est un format de corps de message d'utilisation générale qui est extensible pour porter une large gamme de parties de corps. Il pourvoit au codage des données binaires afin qu'elles puissent être transportées sur le protocole en mode texte à 7 bits SMTP. Ce codage de transport (noté par le champ MIME "Content-Transfer-Encoding:") s'ajoute au codage audio exigé pour générer un objet binaire.

MIME définit deux mécanismes de codage de transport pour transformer les données binaires en une représentation sur 7 bits, l'une conçue pour les données de type texte ("Quoted-Printable"), et une pour les données binaires arbitraires ("Base64"). Bien que le Base64 soit infiniment plus efficace pour les données audio, l'une ou l'autre va fonctionner. Lorsque le transport binaire est disponible, aucun codage de transport n'est nécessaire et les données peuvent être marquées comme "Binary".

Les adresses VPIM DEVRONT utiliser le format de la RFC0822 fondé sur le système des noms de domaine. Ce système de dénomination a deux composantes : la partie locale, utilisée pour le nom d'utilisateur ou l'identification de la boîte aux lettres, et la partie hôte, utilisée pour l'identification mondiale de la machine.

La partie locale de l'adresse devra être une chaîne US-ASCII qui identifie de façon univoque la boîte aux lettres sur un système de destination. Pour la messagerie vocale, la partie locale DEVRA être une chaîne imprimable contenant l'identifiant de boîte aux lettres de l'origine ou du receveur. Bien que les caractères alphabétiques et les longs identifiants de boîte aux lettres PUISSENT être permis, des parties locales numériques courtes DEVRAIENT être utilisées car la plupart des réseaux de messagerie vocale s'appuient sur des identifiants de boîte aux lettres numériques pour conserver la compatibilité avec le clavier téléphonique limité à 10 chiffres. Par suite, certains systèmes de messagerie vocale vont seulement être capables de traiter une partie locale numérique. La réception de parties locales alphanumériques sur ces systèmes peut résulter en ce que l'adresse soit transposée en un numéro localement unique (mais créant la confusion du receveur) ou, dans le pire des cas, l'adresse pourrait être supprimée, rendant le message inexécutable. De plus, il peut être difficile de créer des messages sur ces systèmes avec une partie locale alphanumérique sans des séquences de touches complexes ou certaines formes de recherches sur un répertoire (voir la Section 6). L'utilisation du système des noms de domaine devrait être transparente pour l'utilisateur. Il est de la responsabilité de la machine de messagerie locale de chercher le nom de domaine pleinement qualifié (FQDN, fully-qualified domain name) sur la base de l'adresse entrée par l'usager (voir la Section 6).

En l'absence d'un répertoire mondial, la spécification de la partie locale est supposée se conformer aux plans internationaux ou privés de numérotation téléphonique. Il est probable que les plans de numérotage privés vont prévaloir et leur définition est une affaire locale. Cependant, il est RECOMMANDÉ que les numéros de téléphone public soient notés conformément au plan de numérotage international décrit dans [E.164]. L'indication que la partie locale est un numéro de téléphone public est donnée par un "+" en tête (le "+" ne sera pas entré sur un clavier de téléphone, il est ajouté par le système comme un fanion). Comme les informations principales dans le schéma numérique sont contenues dans les chiffres, d'autres séparateurs de caractères (par exemple, "-") peuvent être ignorés (c'est-à-dire, pour permettre l"analyse de la boîte aux lettres numérique locale) ou peuvent être utilisés pour reconnaître des portions distinctes du numéro de téléphone (par exemple, le code de pays). La spécification de la partie locale d'une adresse VPIM peut être partagée en quatre groupes décrits ci-dessous :

- à utiliser comme plan de numérotage privé avec des extensions d'un nombre quelconque de chiffres, utilise "+" comme séparateur

- pour les numéros de téléphone internationaux conformes à E.164, maximum de 15 chiffres

- pour les numéros de téléphone internationaux conformes à E.164, maximum de 15 chiffres, avec une extension (par exemple, derrière un PABX) qui a un maximum de 15 chiffres.

Noter que ce format d'adresse est conçu pour être compatible avec l'usage courant au sein de l'industrie de la messagerie vocale. Il n'est pas compatible avec les formats d'adressage des RFC 2303-2304. On s'attend à ce que lorsque les services de téléphonie deviendront plus répandus sur l'Internet, ces formats d'adresse vont converger.

Des adresses spéciales pour représenter l'envoyeur sont fournies pour la compatibilité avec les conventions de la messagerie Internet. Ces adresses n'utilisent pas les adresses numériques locales, à la fois pour se conformer à la pratique courante de l'Internet et pour éviter un conflit avec les plans existants d'adressage numérique. Deux adresses spéciales sont RÉSERVÉES pour être utilisées comme suit :

Par convention, une boîte aux lettres spéciale appelée "postmaster" DOIT exister sur tous les systèmes. Cette adresse est utilisée pour les diagnostics et devrait être vérifiée régulièrement par le gestionnaire du système. Cette boîte aux lettres va très vraisemblablement recevoir des messages de texte, ce qui n'est pas normal sur une plateforme de traitement vocal. Le traitement spécifique de ces messages est un choix individuel de la mise en œuvre.

Si une réponse à un message n'est pas possible, comme un message de répondeur téléphonique, l'adresse spéciale "non-mail-user" DEVRAIT alors être utilisée comme adresse de l'origine. Tout nom en texte comme "Répondeur téléphonique", ou le numéro de téléphone si il est disponible, est permis. Cette adresse spéciale est utilisée comme jeton pour indiquer une origine injoignable. Une mise en œuvre conforme NE DOIT PAS permettre une réponse à une adresse de "non-mail-user". Pour la compatibilité avec la base installée d'agents d'utilisateurs de messagerie, les mises en œuvre DOIVENT rejeter le message reçu lorsque il est adressé à "non-mail-user". Le code d'état pour de telles notifications de non livraison (NDN) est 5.1.1 "Cette boîte aux lettres n'existe pas".

Il y a de nombreuses façon de traiter l'expansion d'une liste de distribution (DL) et aucune n'est 'standard'. Une mise en œuvre de VPIM PEUT prendre en charge les DL. Utiliser un simple alias est le comportement le plus proche de ce que font aujourd'hui de nombreux systèmes de messagerie vocale et c'est ce qui doit être utilisé avec les messages VPIM. Deux caractéristiques importantes lorsque on utilise des DL méritent une attention particulière :

Réponse à l'origine - (Adresse dans le champ "Reply-To:" ou "From" de la RFC0822)

Erreurs au soumettant - (Adresse dans le champ MAIL FROM de l'échange ESMTP ou le champ "Return-Path:" de la RFC0822.)

Certains protocoles propriétaires de messagerie vocale incluent seulement le receveur de la copie particulière dans l'enveloppe et n'incluent aucun "champ d'en-tête" excepté la date et des caractéristiques par message. La plupart des systèmes de messagerie vocale ne fournissent pas "d'informations d'en-tête" dans leurs files d'attente de messagerie et incluent seulement des informations de livraison. Par suite, les informations de receveur PEUVENT être dans le champ d'en-tête "To:" ou "Cc:". Si tous les receveurs ne peuvent pas être présentés, les champs d'en-tête de receveur DEVRAIENT alors être omis pour indiquer que la liste précise des destinataires (par exemple, à utiliser avec une facilité de réponse à tous) n'est pas connue.

Les messages Internet contiennent un bloc d'informations d'en-tête. Ce bloc d'en-tête contient les informations requises pour identifier l'envoyeur, la liste des destinataires, l'heure d'envoi du message, et d'autres informations destinées à être présentées à l'utilisateur. Sauf dans les cas de passerelle spécialisée et de liste de diffusion, les champs d'en-tête n'indiquent pas d'options de livraison pour le transport des messages.

Les processeurs de liste de distribution sont notés pour modifier ou ajouter aux champs d'en-tête des messages qui passent à travers eux. Les systèmes VPIM DOIVENT être capables d'accepter et ignorer les champs d'en-tête qui ne sont pas définis ici.

Règles d'envoi : L'adresse de domaine pleinement qualifié de l'origine (une adresse de boîte aux lettres suivie par le nom de domaine pleinement qualifié) DOIT être présente. Les systèmes conformes à ce profil DEVRAIENT fournir le nom personnel textuel de l'origine du message vocal dans une phrase entre chevrons, si le nom est disponible. Le texte des noms de boîtes aux lettres d'entreprise ou de position PEUT être fourni dans une simple chaîne. D'après la [RFC0822].

Les machines de messagerie vocale peuvent n'être pas capables de prendre en charge des attributs séparés pour les champs d'en-tête "From:" et le MAIL FROM SMTP, Les systèmes conformes à VPIM DEVRAIENT régler ces valeurs à la même adresse. L'utilisation d'adresses différentes de celle présente dans le champ d'en-tête "From:" peut avoir pour résultat un comportement imprévu.

Règles de réception ; L'utilisateur cité dans le champ "From:" DOIT être présenté dans l'enveloppe du message vocal du système de messagerie vocale comme l'origine du message, bien que la présentation exacte soit une décision de la mise en œuvre (par exemple, l'identifiant de la boîte aux lettres ou le texte du nom PEUT être présenté). L'adresse de "From:" DEVRAIT être utilisée pour les réponses (voir au paragraphe 4.9).

Le champ "To:" contient l'adresse du domaine pleinement qualifié du destinataire.

Règles d'envoi : Il PEUT y avoir un ou plusieurs champs "To:" dans tout message. Les systèmes DEVRAIENT fournir une liste de destinataires seulement si tous les destinataires sont disponibles. Les systèmes, comme des passerelles avec des protocoles ou des plateformes traditionnelles qui n'indiquent pas la liste complète des destinataires, PEUVENT fournir une ligne "To:". Parce que ces systèmes ne peuvent pas énumérer précisément tous les destinataires dans les en-têtes "To:", les destinataires NE DEVRAIENT PAS être énumérés.

Règles de réception : Les systèmes conformes à ce profil PEUVENT éliminer les adresses dans les champs "To:" si ils ne peuvent pas mémoriser l'information. Cela rendrait, bien sûr, impossible le dispositif "répondre à tous". Si elle est présente, l'adresse dans le champ "To:" PEUT être utilisée pour un message de réponse à tous les destinataires.

Le champ "Cc:" contient des adresses de domaine pleinement qualifiées de destinataires supplémentaires. De nombreux systèmes de messagerie vocale conservent seulement des informations d'enveloppe suffisantes pour la livraison du message et ne sont pas capables de mémoriser ou de fournir une liste complète des destinataires supplémentaires.

Règles d'envoi : Les mises en œuvre conformes PEUVENT envoyer des listes "Cc:" si tous les destinataires sont connus au moment de la génération. Sinon, les systèmes DEVRAIENT omettre les champs "Cc:" pour indiquer que la liste complète des destinataires n'est pas connue ou est indisponible. La liste des destinataires divulguée NE DOIT PAS inclure des destinataires cachés (c'est-à-dire, ceux à qui l'envoi est fait par une copie en aveugle).

Règles de réception : Les systèmes conformes au présent profil PEUVENT ajouter toutes les adresses dans le champ "Cc:" au champ "To:" ; d'autres PEUVENT éliminer les adresses dans les champs "Cc:". Si une liste d'adresses "Cc:" est présente, ces adresses PEUVENT être utilisées pour un message de réponse à tous les destinataires.

Le champ "Date:" contient la date et l'heure de l'envoi du message par l'origine.

Règles d'envoi : Le système envoyeur DOIT rapporter l'heure d'envoi du message. La zone horaire DOIT être présente et DEVRAIT être représentée par un décalage de zone horaire à quatre chiffres, comme -0500 pour l'heure standard de la zone Est des États-Unis. Ceci PEUT être complété par un nom de zone horaire entre parenthèses, par exemple, "-0700 (PDT)".

Si l'envoyeur VPIM relaye un message d'un système qui ne fournit pas d'horodatage, l'heure d'arrivée au système passerelle DEVRAIT être utilisée comme date.

Règles de réception : Les mises en œuvre conformes DEVRAIENT être capables de convertir les horodatages de la [RFC0822] en heure locale.

Le champ "Sender:" contient l'adresse réelle de l'origine si le message est envoyé par un agent au nom de l'auteur indiqué dans le champ "From:".

Règles d'envoi : Ce champ d'en-tête PEUT être envoyé par les systèmes conformes à VPIM.

Règles de réception : Si l'adresse dans le champ "Sender:" ne peut pas être préservée dans les files d'attentes de message du destinataire ou dans le protocole de prochain bond d'une passerelle, le champ PEUT être éliminé en silence.

Le champ "Return-path:" est ajouté par le serveur SMTP de livraison final. S'il est présent, il contient l'adresse du paramètre MAIL FROM de l'échange ESMTP (voir la [RFC0822]). Tous les messages d'erreur résultant d'échecs de livraison DOIVENT être envoyés à cette adresse. Noter que si le "Return-path:" est nul ("<>") (par exemple, un message de réponse d'appel ne va pas avoir de chemin de retour) des notifications d'état de livraison NE DOIVENT PAS être envoyées.

Règles de réception : Si le système receveur est incapable de mémoriser le chemin de retour (ou un MAIL FROM) à utiliser pour les erreurs de livraison suivantes (c'est-à-dire, c'est une passerelle avec un système ou protocole traditionnel) le système receveur doit autrement s'assurer que d'autres erreurs de livraison ne se produisent pas. Les systèmes qui ne prennent pas en charge le chemin de retour DOIVENT s'assurer qu'au moment où le message est acquitté (c'est-à-dire, lorsque un DSN va être envoyé) le message est livré à la boîte aux lettres ultime du destinataire. Des notifications de non livraison NE DEVRAIENT PAS être envoyées après cette livraison finale.

Règles d'envoi : Un identifiant de message unique au monde DOIT être généré pour chaque message envoyé d'une mise en œuvre conforme à VPIM.

Règles de réception : Lorsque il est fourni dans le message d'origine, il DOIT être utilisé lors de l'envoi d'un MDN. Cet identifiant PEUT être utilisé pour le traçage et l'audit. D'après la [RFC0822]

S'il est présent, l'en-tête "Reply-To:" fournit une adresse préférée pour envoyer les messages de réponse (voir le paragraphe 4.9). Normalement, les systèmes de messagerie vocale peuvent seulement prendre en charge une origine d'un message de sorte qu'il est vraisemblable que ce champ sera ignoré par le système receveur. D'après la [RFC0822]

Règles d'envoi : un système conforme NE DEVRAIT PAS envoyer d'en-tête "Reply-To:".

Règles de réception : si un champ "Reply-To:" est présent, un message reply-to-sender PEUT être envoyé à l'adresse spécifiée (c'est-à-dire, au lieu de l'adresse du champ "From:"). Si le système receveur (par exemple, une passerelle multi protocoles) ne prend en charge qu'une seule adresse d'origine, l'adresse du champ "From:" DOIT alors être utilisée et le champ "Reply-To:" PEUT être éliminé en silence.

Le champ "Received:" contient des informations de trace ajoutées au début d'un message RFC822 par les MTA. C'est le seul champ qui puisse être ajouté par un MTA. Les informations dans cet en-tête sont utiles pour le débogage lorsque on utilise un lecteur de message US-ASCII ou un outil d'analyse d'en-tête. D'après la [RFC0822]

Règles d'envoi : un système conforme à VPIM DOIT ajouter un champ "Received:". Lorsque on agit comme passerelle, les informations sur le système duquel le message a été reçu DEVRAIENT être incluses.

Règles de réception : un système conforme à VPIM NE DOIT PAS supprimer de champs "Received:" lors d'un relais de messages à d'autres MTA ou passerelles. Ces champs d'en-tête PEUVENT être ignorés ou supprimés lorsque le message est reçu à la destination finale.

Le champ "MIME-Version:" DOIT être présent pour indiquer que le message se conforme à [MIME1-5]. Les systèmes conformes à la présente spécification DEVRAIENT inclure un commentaire contenant les mots "(Voice 2.0)". La [RFC1911] définit une version antérieure de ce profil et utilise le jeton (Voice 1.0).

Cet identifiant est destiné seulement à l'information et NE DEVRAIT PAS être utilisé pour identifier sémantiquement le message comme étant VPIM. C'est plutôt la présence du type de contenu multipart/voice-message défini au paragraphe 18.2 qui DEVRAIT être utilisée si l'identification est nécessaire.

L'en-tête "Content-Type:" DOIT être présent pour déclarer le type de contenu inclus dans le message. Le contenu normal de niveau supérieur dans un message VPIM DEVRAIT être Multipart/Voice-Message. Les contenus admissibles sont détaillés à partir du paragraphe 4.4 du présent document. D'après la [RFC2046]

Comme la messagerie Internet était initialement spécifiée pour porter seulement du texte US-ASCII à 7 bits, il peut être nécessaire de coder les données de voix et de télécopie comme une représentation convenable pour cet environnement. L'en-tête "Content-Transfer-Encoding:" décrit cette transformation si elle est nécessaire.

Règles d'envoi : une mise en œuvre conforme au présent profil DEVRAIT envoyer des données audio et/ou de télécopie en forme "Binary" lorsque un transport de message binaire est disponible (voir la Section 5). Lorsque un transport binaire n'est pas disponible, les mises en œuvre DOIVENT coder les données audio et/ou télécopie comme "Base64".

Règles de réception : les mises en œuvre conformes DOIVENT reconnaître et décoder les codages standard, "Binary" (lorsque le support binaire est disponible), "7bit, "8bit", "Base64" et "Quoted-Printable" selon la [RFC2045]. La détection et le décodage de "Quoted-Printable", "7bit", et "8bit" DOIVENT être pris en charge afin de satisfaire aux exigences de MIME et pour préserver l'interopérabilité avec la gamme la plus complète possible d'appareils.

Le champ "Sensitivity:", s'il est présent, indique le niveau de confidentialité demandé. Si aucune confidentialité n'est demandée, ce champ est omis. La définition de cet en-tête est la suivante :

Règles d'envoi : une mise en œuvre conforme à VPIM PEUT inclure cet en-tête pour indiquer la sensibilité d'un message. Si un usager marque un message "Private", une mise en œuvre conforme DOIT envoyer seulement le niveau de sensibilité "Private". Il n'y a pas de sémantique spécifique de VPIM définie pour les valeurs "Personal" ou "Company-Confidential". Une mise en œuvre conforme NE DEVRAIT PAS envoyer les valeurs "Personal" ou "Company-Confidential". Si le message est de sensibilité "Normal", ce champ DEVRAIT être omis. D'après [X.400]

Règles de réception : si un champ "Sensitivity:" d'une valeur de "Private" est présent dans le message, un système conforme DOIT interdire au receveur de transmettre ce message à un tiers. Un système conforme DEVRAIT cependant permettre au receveur de répondre à un message sensible, mais NE DEVRAIT PAS inclure le contenu original du message. Celui qui répond PEUT régler la sensibilité du message de réponse.

Un système receveur PEUT ignorer les valeurs de sensibilité de "Personal" et "Company Confidential".

Si le système receveur ne prend pas en charge la confidentialité et si la sensibilité est "Private", une notification d'état de livraison négative DOIT être envoyée à l'origine avec le code d'état approprié (5.6.0) "Autre ou état de protocole indéfini" indiquant que la confidentialité ne pouvait pas être assurée. Le contenu de message DEVRAIT être retourné à l'envoyeur pour permettre un contexte vocal avec la notification. Une notification de non livraison d'un message confidentiel NE DEVRAIT PAS être étiquetée "confidentiel" car elle va être envoyée au générateur du message. D'après [X.400]

Un message sans confidentialité explicitement notée (c'est-à-dire, sans en-tête) ou avec une sensibilité de "Normal" ne reçoit pas de traitement particulier.

Indique l'importance à accorder par le système receveur. Si aucune importance particulière n'est demandée, cet en-tête PEUT être omis et la valeur de l'en-tête absent est supposée être "normal". D'après [X.400]

Règles d'envoi : les mises en œuvre conformes PEUVENT inclure cet en-tête pour indiquer l'importance d'un message.

Règles de réception : si le système receveur ne prend pas en charge "Importance:", l'attribut PEUT être éliminé en silence.

Le champ "Subject:" est souvent fourni par les systèmes de messagerie mais n'est pas largement pris en charge sur les plateformes de messagerie vocale. D'après la [RFC0822]

Règles d'envoi : pour la compatibilité avec les interfaces de boîte aux lettres fondées sur le texte, un champ de sujet textuel DEVRAIT être généré par une mise en œuvre conforme. Il est RECOMMANDÉ que les systèmes de messagerie vocale qui ne prennent en charge aucune interface d'utilisateur de texte (par exemple, accès seulement par téléphone) insèrent un en-tête générique de sujet de "Message VPIM" ou "Message vocal" pour le bénéfice des receveurs à capacité GUI.

Règles de réception : il est prévu que de nombreux systèmes uniquement vocaux soient incapables de mémoriser la ligne "subject ". Le sujet PEUT être éliminé par un système receveur.

Ce champ PEUT être présent pour faciliter l'identification du texte de ces parties de corps dans les lecteurs simples de messagerie électronique. Toutes valeurs peuvent être utilisées.

Règles d'envoi : Ce champ PEUT être ajouté à une partie de corps vocal pour offrir une description en forme libre du contenu vocal. Il est utile d'incorporer les valeurs de Content-Disposition avec des descriptions supplémentaires. Par exemple, ceci peut être utilisé pour indiquer le nom du produit ou des enregistrements de transcodage.

Règles de réception : ce champ PEUT être affiché au receveur. Cependant, comme il est seulement informatif, il PEUT être ignoré.

Ce champ DOIT être présent pour permettre d'analyser l'identification des parties de corps au sein d'un message vocal VPIM. Ceci est particulièrement utile si, comme c'est normal, plus d'un corps Audio/* survient dans un seul niveau (par exemple, Multipart/Voice-Message). Comme un message vocal VPIM est destiné à être exécuté automatiquement dans l'ordre dans lequel arrive le contenu audio, le contenu audio DOIT toujours être de disposition en ligne. Cependant, il est quand même utile d'inclure une valeur de nom de fichier, de sorte qu'il DEVRAIT être présent si cette information est disponible. D'après la [RFC2183]

Règles d'envoi : afin de distinguer entre les divers types de contenu audio dans un message vocal VPIM, un nouveau paramètre de disposition "voice" est défini auprès de l'IANA (voir le paragraphe 18.1) avec les valeurs de paramètre ci-dessous pour être utilisées comme approprié :

Audio-type-value := "Voice-Message" / "Voice-Message-Notification" / "Originator-Spoken-Name" /"Recipient-Spoken-Name" /"Spoken-Subject"

Voice-Message-Notification - notification de livraison parlée ou notification de disposition parlée,

Recipient-Spoken-Name - le nom parlé du ou des receveurs si le générateur en dispose,

Spoken-Subject - le sujet parlé du message, dit normalement par le générateur du message.

Noter qu'il DEVRAIT n'y avoir qu'une seule instance de chacun de ces types de contenu audio par niveau de message. Des instances supplémentaires d'un certain type (c'est-à-dire, valeur de paramètre) PEUVENT se produire dans un message vocal joint transmis ou de réponse. Si il y a plusieurs destinataires d'un certain message, recipient-spoken-name NE DOIT PAS être utilisé.

Règles de réception : les mises en œuvre DEVRAIENT utiliser cet en-tête. Cependant, celles qui ne comprennent pas le paramètre "voice" (ou l'en-tête "Content-Disposition:") peuvent en toute sécurité l'ignorer, et vont présenter les parties de corps audio dans l'ordre (mais elles ne seront pas capables de les distinguer). Si plus d'une instance de la valeur de type de paramètre "voice" se rencontre à un niveau (par exemple, plusieurs contenus étiquetés 'Voice-Message') ils DEVRAIENT alors être présentés ensemble.

L'en-tête "Content-Duration:" donne une indication de la longueur audio en secondes du segment.

Règles d'envoi : ce champ PEUT être présent pour permettre de spécifier la longueur de la partie de corps audio en secondes.

Règles de réception : l'utilisation de ce champ à réception est une question de mise en œuvre locale. D'après [RFC3803]

Ce champ PEUT être présent pour permettre de spécifier le langage parlé dans la partie de corps audio. Le codage est défini dans la [RFC3066].

Règles d'envoi : un système envoyeur PEUT ajouter un champ pour indiquer le langage de la voix. Sa détermination (par exemple, automatique ou choisi par l'usager) est une question de mise en œuvre locale.

Règles de réception : l'utilisation de ce champ à réception est une question de mise en œuvre locale. Il PEUT être utilisé comme conseil au receveur (par exemple, l'utilisateur final ou un processus de traduction automatique) sur le langage du message vocal.

Les types de contenus décrits dans ce paragraphe sont identifiés pour être utilisés au sein du contenu Multipart/Voice-Message. Ce contenu est appelé un "message VPIM" dans ce document et c'est la partie fondamentale d'un "message VPIM".

Seuls les contenus profilés peuvent être envoyés au sein d'une construction vocale de message VPIM (c'est-à-dire, le type de contenu Multipart/Voice-Message) pour former une structure simple ou plus complexe (plusieurs exemples sont donnés à l'Appendice B). La présence d'autres contenus au sein d'un message vocal VPIM n'est pas permise. En l'absence d'un accord bilatéral, les mises en œuvre conformes NE DOIVENT PAS créer un message contenant des contenus interdits. Dans l'esprit d'une acceptation libérale, une mise en œuvre conforme PEUT accepter et restituer un contenu prohibé. Les systèmes qui ne sont pas capables d'accepter ou restituer les contenus interdits PEUVENT éliminer le contenu interdit si nécessaire pour livrer le contenu acceptable. Lorsque plusieurs contenus sont présents au sein du Multipart/Voice-Message, ils DEVRAIENT être présentés à l'usager dans l'ordre dans lequel ils apparaissent dans le message.

Certains déploiements de mises en œuvre fondées sur l'interprétation courante de la spécification originale VPIM v2 rejettent les messages qui ont un contenu prohibé plutôt que d'éliminer le contenu non pris en charge. Pour l'interopérabilité avec ces systèmes, il est particulièrement important que les contenus prohibés ne soient pas envoyés au sein d'un Multipart/Voice-Message.

Cette structure MIME multipart fournit un mécanisme pour empaqueter un message vocal dans un conteneur qui est étiqueté comme conforme à VPIM v2. Le sous type est identique en sémantique et syntaxe à multipart/mixed, comme défini dans la [RFC2046]. À ce titre, elle peut être en toute sécurité interprétée comme multipart/mixed par les systèmes qui ne comprennent pas ce sous type (seule l'identification comme message vocal sera perdue).

En plus du paramètre de frontière exigé par MIME, un paramètre de version est aussi exigé pour ce sous type. C'est pour distinguer cette précision du sous type de la précédente définition dans la [RFC1911]. La valeur du paramètre version est de "2.0" si le contenu se conforme aux exigences de la présente spécification. Si d'autres révisions de ce type de contenu devaient être faites, elles DEVRONT être rétrocompatibles (c'est-à-dire que les systèmes qui mettront en œuvre la version n devront pouvoir lire la version 2, et les systèmes qui mettent en œuvre la version 2 doivent pouvoir lire les contenus de version 2 au sein de la version n).

Règles d'envoi : le type de contenu Multipart/Voice-Message DOIT contenir seulement le support et les types de contenu profilés spécifiés dans cette section (c'est-à-dire, Audio/*, Image/*, et Message/RFC822). Les plus courants seront le nom parlé, le sujet parlé, le message lui-même, et une télécopie jointe. Les messages transmis sont créés simplement en utilisant la construction Message/RFC822.

Les mises en œuvre conformes DOIVENT utiliser Multipart/Voice-Message dans un message VPIM. Dans la plupart des cas, ce type de contenu Multipart/Voice-Message sera au niveau supérieur mais peut être inclus dans un Message/RFC822 si le message est retransmis ou s'il est au sein d'un multipart/mixed lorsque plus d'un message est retransmis.

Règles de réception : les mises en œuvre conformes DOIVENT reconnaître le contenu Multipart/Voice-Message (qu'il soit un contenu de niveau supérieur ou qu'il soit contenu dans un Multipart/Mixed) et DOIVENT être capables de séparer les contenus (par exemple, le nom parlé ou le sujet parlé).

La sémantique de Multipart/Voice-Message (définie au paragraphe 18.2) est identique à celle de Multipart/Mixed et peut être interprétée comme telle par les systèmes qui ne reconnaissent pas de type de contenu.

Règles d'envoi : MIME exige la prise en charge de la partie de corps d'encapsulation de message Message/RFC822. Cette partie de corps DEVRAIT être utilisée au sein d'un Multipart/Voice-Message pour transmettre des messages complets (voir le paragraphe 4.8) ou pour répondre avec le contenu d'origine (voir le paragraphe 4.9). D'après [RFC2046]

Règles de réception : le système receveur DOIT accepter ce format et DEVRAIT traiter cette pièce jointe comme un message retransmis. Le système receveur PEUT écraser la structure de transmission (c'est-à-dire, retirer cette construction pour laisser plusieurs contenus vocaux ou même enchaîner les contenus vocaux pour tenir dans la boîte aux lettres d'un destinataire) si nécessaire.

Règles d'envoi : Une mise en œuvre conforme au présent profil DOIT envoyer Audio/32KADPCM par défaut pour la voix [RFC3802]. Ce codage est modérément compressé avec un débit de données de 32 kbit/s en utilisant des ressources de traitement modérées. Normalement, ce corps contient plusieurs minutes de contenu de message ; cependant, si il est utilisé pour le nom ou le sujet parlé, le contenu est supposé être considérablement plus court (c'est-à-dire respectivement d'environ 5 et 10 secondes).

Règles de réception : Les receveurs DOIVENT être capables d'accepter et décoder l'Audio/32KADPCM. Si une mise en œuvre peut seulement traiter un corps vocal, plusieurs corps vocaux (si c'est le cas) DEVRAIENT alors être enchaînés, et NE DOIVENT PAS être éliminés. S'il est enchaîné, le contenu DEVRAIT être dans le même ordre que celui dans lequel il apparaît dans le multipartie.

Un codage d'image courant pour la télécopie, connu comme TIFF-F, est un dérivé du format de fichier d'image étiquetée (TIFF, Tag Image File Format) qui est décrit dans plusieurs documents. Pour les besoins de VPIM, le profil F de TIFF pour la télécopie (TIFF-F) est défini dans la [RFC2306], et le type de contenu MIME Image/TIFF est défini dans la [RFC2302]. Bien qu'il y ait plusieurs formats de TIFF, seul TIFF-F est profilé pour être utilisé au sein de Multipart/Voice-Message. De plus, comme le format de fichier TIFF-F est utilisé en mode différé avec VPIM, l'image DOIT être codée de façon qu'il y ait seulement une bande d'image par page de télécopie.

Règles d'envoi : toutes les mises en œuvre de VPIM qui prennent en charge la télécopie DOIVENT générer des contenus de télécopie compatibles avec TIFF-F dans le sous type Image/TIFF en utilisant le codage application=faxbw par défaut. Si le message VPIM est une télécopie à annotation vocale, la mise en œuvre DEVRAIT envoyer ce contenu de télécopie en Multipart/Voice-Message. Si le message est une simple télécopie, une mise en œuvre PEUT l'envoyer sans utiliser le Multipart/Voice-Message pour être plus compatible avec les mises en œuvre seulement de télécopie (RFC 2305).

Bien que tout en-tête de corps MIME valide PUISSE être utilisé (par exemple, Content-Disposition pour indiquer le nom de fichier) aucun n'est spécifié comme ayant une sémantique particulière pour VPIM et PEUT être ignoré. Noter que le paramètre de type de contenu application=faxbw DOIT être inclus dans les messages sortants.

Règles de réception : tous les systèmes VPIM ne prennent pas en charge la télécopie, mais tous DEVRAIENT l'accepter au sein de multipart/voice-message. Au sein d'un Multipart/Voice-Message, un système receveur qui ne peut pas rendre un contenu de télécopie DEVRAIT accepter le contenu vocal d'un message VPIM et éliminer le contenu de télécopie. En dehors d'un Multipart/Voice-Message, un système receveur PEUT rejeter (avec la NDN appropriée) le message entier si il ne peut pas le mémoriser ou s'il n'est pas capable de rendre un message avec des pièces jointes de télécopie. Les systèmes VPIM conformes PEUVENT prendre en charge la télécopie en dehors de (ou sans) le Multipart/Voice-Message.

Certaines mises en œuvre déployées fondées sur une interprétation courante de la spécification VPIM v2 d'origine rejettent les messages avec un contenu de télécopie au sein de Multipart/Voice-Message plutôt que d'éliminer les contenus non pris en charge. Ces systèmes vont retourner le message à l'envoyeur avec une NDN indiquant la non prise en charge de la télécopie.

Les contenus MIME suivants (à l'exception de multipart/mixed au paragraphe 4.5.1) PEUVENT être inclus dans un message multipart/vocal. D'autres contenus NE DOIVENT PAS être inclus. Leur traitement est une question de mise en œuvre locale. Multipart/mixed est inclus pour promouvoir l'interopérabilité avec une plus large gamme de systèmes et aussi pour permettre la création de messages multimédia plus complexes (avec un message VPIM en une seule partie).

Ce type de contenu MIME courant permet d'enclore plusieurs parties de corps dans un seul message.

Règles d'envoi : un message vocal VPIM (c'est-à-dire, multipart/voice-message) PEUT être inclus au sein d'un message avec un type de contenu Multipart/Mixed de niveau supérieur. Normalement, ceci ne peut être utilisé que pour mêler des contenus non vocaux et non télécopie à un message vocal.

Règles de réception : un tel message n'est pas par lui-même un message VPIM, et le traitement d'une telle construction sort du domaine d'application du profil VPIM. Cependant, dans l'esprit de l'acceptation libérale, une mise en œuvre conforme DOIT accepter et rendre un message vocal VPIM contenu dans un Multipart/Mixed.

Règles d'envoi : ce contenu a été profilé dans la spécification d'origine de VPIM v2 comme moyen de transporter les informations de contact de l'envoyeur au destinataire. Cet usage n'a pas été largement adopté et n'est plus une caractéristique de VPIM v2. Les mises en œuvre conformes NE DEVRAIENT PAS envoyer le type de contenu Text/Directory.

Règles de réception : pour la compatibilité avec la spécification précédente de VPIM v2, le type de contenu Text/Directory DOIT être accepté par une mise en œuvre conforme, mais n'a pas besoin d'être mémorisé, traité, ou rendu au destinataire.

L'utilisation de tous autres codages que les codages exigés réduit l'interopérabilité en l'absence d'une connaissance explicite des capacités du destinataire. Une mise en œuvre conforme NE DEVRAIT PAS utiliser d'autre codage sauf si un identifiant univoque est enregistré auprès de l'IANA avant l'utilisation (voir la [RFC2048]). Les codages vocaux DEVRAIENT être enregistrés comme sous types de Audio. Les codages de télécopie DEVRAIENT être enregistrés comme sous types de Image.

Règles d'envoi : les formats propriétaires de codage vocal ou autres formats standard NE DEVRAIENT PAS être envoyés sous le présent profil sauf si l'envoyeur a des raisons valables de penser que le receveur va accepter ce codage. En pratique, cela exige des informations explicites de configuration par destination conservées soit dans un répertoire, un carnet d'adresses personnel, ou des tableaux de configuration de passerelle.

Règles de réception : les systèmes PEUVENT accepter d'autres types de contenu Audio/* ou Image/* si il peuvent les décoder. Les systèmes qui reçoivent des types de contenu Audio/* ou Image/* qu'ils ne sont pas capables de mettre en dépôt ou qu'ils sont incapables de rendre DOIVENT retourner le message (et DEVRAIENT inclure le contenu d'origine) au générateur avec une NDN indiquant que le support n'est pas accepté.

MIME exige la prise charge du type de contenu de base Text/Plain (avec le jeu de caractères US-ASCII). Ce type de contenu a une applicabilité limitée au sein de l'environnement de messagerie vocale. Cependant, parce que VPIM est un profil MIME, les exigences de MIME DEVRAIENT être satisfaites.

Règles d'envoi : les mises en œuvre VPIM conformes NE DEVRAIENT PAS envoyer le type de contenu Text/Plain. Les mises en œuvre PEUVENT envoyer le type de contenu Text/Plain en dehors de Multipart/Voice-Message.

Règles de réception : au sein d'un Multipart/Voice-Message, le type de contenu Text/Plain PEUT être éliminé du message, si nécessaire, pour livrer les composants audio/télécopie. Le receveur NE DEVRAIT PAS rejeter le message entier si le composant de texte ne peut pas être accepté ou rendu.

En dehors d'un Multipart/Voice-Message, les mises en œuvre conformes DOIVENT accepter Text/Plain ; cependant, un traitement spécifique est laissé à la décision de la mise en œuvre. D'après la [RFC2046]

Certaines mises en œuvre déployées fondées sur une interprétation commune de la spécification originale VPIM v2 rejettent les messages avec tout contenu de texte plutôt que d'éliminer les contenus non pris en charge. Ces systèmes vont retourner le message à l'envoyeur avec une NDN indiquant la non prise en charge du texte.

Une DSN est une notification de livraison (DSN positive), de non livraison (DSN négative), ou de retard temporaire de livraison (DSN retardée). Le type de contenu de niveau supérieur de DSN est un Multipart/Report, qui est défini dans la [RFC3462]. Le type de contenu qui distingue les DSN des autres types de notifications est Message/Delivery-Status, qui est défini dans la [RFC3464].

Règles d'envoi : Une mise en œuvre conforme à VPIM DOIT être capable d'envoyer des DSN qui se conforment aux [RFC3462] et [RFC3464]. Sauf demande contraire, une DSN de non livraison DOIT être envoyée lorsque se produit une forme quelconque de non livraison d'un message. Une mise en œuvre conforme à VPIM DEVRAIT fournir un état parlé de livraison dans la partie de corps "lisible par l'homme" de la DSN, mais PEUT fournir un état textuel.

Règles de réception : Une mise en œuvre conforme à VPIM DOIT être capable de recevoir des DSN qui se conforment aux [RFC3462] et [RFC3464]. Une mise en œuvre conforme à VPIM DOIT être capable de recevoir une DSN dont la partie de corps "lisible par l'homme" contient une phrase parlée d'état de livraison ou une description textuelle. Bien que l'utilisation ultérieure de la phrase ou du texte soit une question de mise en œuvre locale, l'intention de la DSN DOIT être présentée à l'utilisateur final.

Une MDN est une notification qui indique ce qui arrive à un message après qu'il a été déposé dans la boîte aux lettres du destinataire. Une MDN peut être positive (le message a été lu/exécuté/rendu/etc.) ou négative (le message a été supprimé avant que le receveur ait pu le voir, etc.). Le type de contenu de niveau supérieur d'une MDN est Multipart/Report, qui est défini dans la [RFC3462]. Le type de contenu qui distingue les MDN des autres types de notifications est Message/Disposition-Notification, qui est défini dans la [RFC3798].

Règles d'envoi : Une mise en œuvre conforme à VPIM DEVRAIT prendre en charge la capacité à demander des MDN. Cela se fait via l'utilisation du champ d'en-tête "Disposition-Notification-To:" comme défini dans la [RFC3798].

Une mise en œuvre conforme à VPIM DEVRAIT prendre en charge la capacité d'envoyer des MDN, mais ces MDN DOIVENT se conformer aux [RFC3462] et [RFC3798].

Lors de l'envoi d'une MDN, une mise en œuvre conforme à VPIM DEVRAIT fournir une disposition de message parlé dans la partie de corps "lisible par l'homme" de la MDN, mais elle PEUT fournir un état textuel.

Règles de réception : Une mise en œuvre conforme à VPIM DEVRAIT répondre à une demande de MDN par une réponse de MDN.

Une mise en œuvre conforme à VPIM DOIT être capable de recevoir des MDN qui se conforment aux [RFC3462] et [RFC3798], si elle est capable de demander des MDN. Si une mise en œuvre conforme à VPIM est capable de recevoir des MDN, elle DOIT être capable de recevoir une MDN dont la partie de corps "lisible par l'homme" contient une phrase de disposition de message parlé ou une description de disposition textuelle. Bien que l'utilisation ultérieure de la phrase ou du texte soit une question de mise en œuvre locale, l'intention de la MDN DOIT être présentée à l'utilisateur final.

VPIM v2 prend explicitement en charge la transmission d'un contenu vocal ou de télécopie avec annotation vocale ou de télécopie. Cependant, seules les deux constructions décrites ci-dessous sont acceptables dans un message VPIM. Comme seul le premier (c'est-à-dire, Message/RFC822) peut être reconnu comme message transmis (ou même plusieurs messages transmis) il est RECOMMANDÉ que cette construction soit utilisée chaque fois que possible.

Les messages VPIM transmis DEVRAIENT être envoyés comme Multipart/Voice-Message avec le message original entier inclus dans un type de contenu Message/RFC822 et l'annotation comme une partie de corps séparée Audio/* ou Image/*. Si les champs d'en-tête de la RFC822 ne sont pas disponibles pour le contenu transmis, des champs d'en-tête simulés avec les informations disponibles DEVRAIENT être construits pour indiquer l'horodatage d'envoi d'origine, et l'envoyeur d'origine comme indiqué dans le champ "From:". Noter qu'au moins un "From:", "Subject:", ou "Date:" DOIT être présent. Aussi, le contenu Message/RFC822 DOIT inclure au moins les champs d'en-tête "MIME-Version:", et "Content-Type:". D'après la [RFC2046]

En cas de perte des informations de transmission, le contenu audio entier PEUT être envoyé comme un seul segment Audio/* sans inclure aucune sémantique de transmission. Un exemple de cette perte est un message AMIS transmis à travers une passerelle AMIS à VPIM.

La prise en charge de plusieurs champs d'en-tête de l'origine dans un message de réponse n'est souvent pas possible sur les systèmes de messagerie vocale, de sorte qu'il peut être nécessaire de choisir seulement quand il y a une passerelle d'un message VPIM à un autre système de messages vocaux. Cependant, les mises en œuvre devraient noter que ceci rend impossible l'envoi de DSN, MDN, et réponses à leur destination appropriée.

Dans certains cas, il n'est pas possible de répondre à un message, comme avec un message créé par un répondeur téléphonique (c'est-à-dire, la messagerie vocale classique). Dans ce cas, le champ From: DEVRAIT contenir l'adresse spéciale "non-mail-user@domain" (voir au paragraphe 4.1.2). Le système VPIM receveur NE DEVRAIT PAS offrir l'option de répondre à cette sorte de message (sauf si un dispositif d'appel sortant est offert, ce qui sort du domaine d'application de VPIM).

Les messages sont transportés entre des machines de messagerie vocale en utilisant le protocole simple de transfert de messagerie Internet étendu (ESMTP, Internet Extended Simple Mail Transfer Protocol). Toutes les informations requises pour une bomme livraison du message sont incluses dans le dialogue ESMTP. Ces informations, incluant les adresses d'envoyeur et de destinataire, sont couramment appelées "l'enveloppe" du message. Ces informations sont équivalentes au bloc de contrôle de message dans de nombreux protocoles analogues de messagerie vocale.

ESMTP est un protocole de messagerie d'utilisation courante, conçu à la fois pour envoyer des messages et pour permettre l'élaboration des messages sur la console d'un terminal. Le protocole simple de transport de messagerie (SMTP, Simple Mail Transport Protocol) a été à l'origine créé pour l'échange de messages de texte en US-ASCII à 7 bits. Les messages de texte en binaire et à 8 bits ont traditionnellement été transportés en codant les messages en forme équivalente à du texte à 7 bits. La [RFC2821] a formalisé un mécanisme d'extension pour SMTP, et des RFC ultérieures ont défini le réseautage de texte à 8 bits, l'écoulement de commandes, le réseautage binaire, et des extensions pour permettre une déclaration de la taille du message pour une transmission efficace de grands messages comme ceux de la messagerie vocale pendant plusieurs minutes.

Les paragraphes qui suivent font la liste des commandes de ESMTP, des mots clés, et des paramètres qui sont exigés et de ceux qui sont facultatifs pour la conformité au présent profil.

Un système conforme DOIT mettre en œuvre toutes les commandes obligatoires de SMTP et ESMTP. Toute commande ou paramètre défini comme facultatif PEUT être pris en charge.

VPIM utilise un certain nombre d'extensions au service SMTP pour assurer un service de messagerie vocale entièrement constitué. Les extensions suivantes font partie du profil d'utilisation pour VPIM :

L'extension DSN définit un mécanisme qui permet à un client SMTP de spécifier (a) que des DSN devraient être générées dans certaines conditions, (b) si de telles DSN devraient retourner le contenu du message, et (c) des informations supplémentaires, à retourner avec une DSN, qui permettent à l'envoyeur d'identifier à la fois le ou les destinataires pour lesquels la DSN a été produite, et la transaction dans laquelle le message d'origine a été envoyé.

L'extension DSN DOIT être prise en charge par les mises en œuvre conformes à VPIM.

En plus, au delà des exigences de la [RFC3461], les mises en œuvre conformes DOIVENT prendre en charge le paramètre NOTIFY sur la commande RCPT pour permettre d'indiquer si le créateur demande une notification. Le paramètre RET DEVRAIT être pris en charge pour retourner le message d'origine avec la notification. Les paramètres ORCPT et ENVID PEUVENT aussi être pris en charge. D'après la [RFC3461]

L'extension SIZE définit un mécanisme par lequel un client et un serveur SMTP peuvent interagir pour donner au serveur l'opportunité de refuser d'accepter un message (peut-être temporairement) sur la base de l'estimation du client de la taille du message. D'après la [RFC1870]

L'extension SIZE DOIT être prise en charge par les mises en œuvre conformes à VPIM.

L'extension ENHANCEDSTATUSCODES définir un mécanisme par lequel un serveur SMTP augmente ses réponses des codes d'état de système de messagerie améliorée définis dans la [RFC1893]. Ces codes peuvent alors être utilisés pour fournir plus explications informatives sur les conditions d'erreur. D'après la [RFC2034]

L'extension ENHANCEDSTATUSCODES DEVRAIT être prise en charge par les mises en œuvre conformes à VPIM.

L'extension PIPELINING définit un mécanisme par lequel un serveur SMTP peut indiquer dans quelle mesure il est capable d'accepter plusieurs commandes dans une seule opération d'envoi TCP. Utiliser une seule opération d'envoi TCP pour plusieurs commandes peut améliorer significativement les performances de SMTP. D'après la [RFC2920]

L'extension PIPELINING DEVRAIT être prise en charge par les mises en œuvre conformes à VPIM.

L'extension CHUNKING définit un mécanisme qui permet à un client et un serveur SMTP de négocier l'utilisation de la commande de transfert de données de message "BDAT" (en remplacement de la commande DATA) pour l'envoi efficace de grands messages MIME. D'après la [RFC3030]

L'extension CHUNKING PEUT être prise en charge par les mises en œuvre conformes à VPIM.

L'extension BINARYMIME définit un mécanisme qui permet à un client et un serveur SMTP de négocier le transfert de données de message binaire non codé en utilisant la commande BDAT. D'après la [RFC3030]

L'extension BINARYMIME PEUT être prise en charge par les mises en œuvre conformes à VPIM. Noter que la [RFC3030] spécifie que si BINARYMIME doit être pris en charge, alors par définition, CHUNKING doit aussi être pris en charge.

Les extensions SMTP suggérées ou exigées pour la conformité à VPIM rentrent dans deux catégories. La première catégorie inclut des dispositifs qui augmentent l'efficacité du système de transport comme SIZE, BINARYMIME, et PIPELINING. Dans l'éventualité d'un repli sur un système de transport moins riche en fonctionnalités, ces dispositifs peuvent être abandonnés sans changement fonctionnel chez l'envoyeur ou le destinataire.

La seconde catégorie de dispositifs sont des extensions de transport en soutien de nouvelles fonctions. DSN et ENHANCEDSTATUSCODES fournissent des améliorations essentielles au traitement des notifications d'état de livraison pour amener la messagerie électronique au niveau de fiabilité attendu de la messagerie vocale. Pour assurer un niveau de service cohérent à travers un intranet ou dans l'Internet mondial, il est essentiel que ESMTP conforme à VPIM prenne en charge l'extension DSN à tous les bonds entre un système qui génère VPIM et le système receveur. Dans la situation où un "repli" est inévitable, un bond relais peut être forcé (par le prochain bond) de transmettre un message VPIM sans la demande ESMTP de notification d'état de livraison. Il est RECOMMANDÉ que le système qui se replie continue de tenter de livrer le message, mais il DOIT envoyer une notification d'état de livraison appropriée au créateur, par exemple, le message a quitté un hôte ESMTP et a été envoyé en relais à une destination sans capacité de DSN, et ceci peut être la dernière DSN reçue.

Il est de la responsabilité d'un système VPIM de fournit le nom de domaine pleinement qualifié (FQDN, fully- qualified domain name) du destinataire sur la base de l'adresse entrée par l'utilisateur (si l'adresse entrée n'est pas déjà un FQDN). Cela va normalement poser un problème aux systèmes qui offrent seulement une interface d'usager téléphonique. La transposition du numéro cible composé en une adresse de FQDN acheminable, permettant la livraison au système de destination, peut être réalisée par des moyens spécifiques de la mise en œuvre.

Pour faciliter une mise en antémémoire locale, une mise en œuvre peut souhaiter remplir les répertoires locaux avec les noms et prénoms, ainsi qu'avec les informations de nom parlé de l'envoyeur extraites des messages reçus. Les adresses ou les noms analysés à partir des champs d'en-tête des messages VPIM PEUVENT être utilisées pour remplir les répertoires.

Les protocoles Internet fournissent un mécanisme pour la gestion des systèmes de messagerie, à partir de la gestion du réseau physique jusqu'à la gestion des files d'attentes de messages. SNMP DEVRAIT être pris en charge sur une machine conforme à VPIM.

L'interface numérique avec les protocoles VM et TCP/IP PEUT être gérée. La MIB II PEUT être mise en œuvre pour fournir des statistiques de base et des rapports des performances des protocoles TCP et IP [RFC1213].

VPIM est une application de messagerie qui sera prise en charge dans plusieurs environnements et sur des appareils différents. Ces environnements incluent des systèmes traditionnels de traitement de la voix, des systèmes de messagerie vocale sur ordinateur portable, des relais de différé, et des passerelles de traduction de protocoles.

Afin de s'accommoder de tous les environnements, le présent document définit deux domaines de conformité : transport et contenu.

Les systèmes conformes au transport vont passer les messages VPIM en différé avec des notifications de livraison assurée et sans perte d'information. On s'attend à ce que la plupart des systèmes de messagerie en différé fondés sur la messagerie électronique Internet soient du VPIM conforme au transport.

Les systèmes à contenu conforme vont générer et interpréter les messages VPIM. La conformité dans la génération des messages VPIM indique que les restrictions du présent profil sont respectées. Seuls les contenus spécifiés dans ce profil ou les extensions agréées par accord bilatéral peuvent être envoyés. La conformité dans l'interprétation des messages VPIM indique que tous les types de contenu et constructions VPIM peuvent être reçus, que tous les types de contenu VPIM obligatoires peuvent être décodés et présentés au destinataire d'une manière appropriée, et que tout contenu irrestituable résulte en la notification appropriée.

Les systèmes d'extrémité VPIM sont supposés être à la fois conformes au transport et au contenu. Les systèmes de messagerie vocale et les passerelles de conversion de protocole sont considérés comme des systèmes d'extrémité.

Les systèmes relais sont supposés être conformes au transport afin de recevoir et envoyer des messages conformes. Cependant, ils doivent aussi créer des notifications d'état de livraison conformes à VPIM dans l'éventualité de problèmes de livraison.

Les clients de messagerie électronique sur micro ordinateur qui prennent VPIM en charge sont supposés être conformes en contenu. Les clients de messagerie électronique sur micro ordinateur utilisent divers protocoles et API pour échanger des messages avec la mémorisation locale des messages et le système de transport de message. Bien que ces clients puissent bénéficier des capacités de transport de VPIM, les exigences spécifiques client-serveur sortent du domaine d'application de ce document.

Le présent document est un profil des protocoles de messagerie Internet existants. Pour conserver l'interopérabilité avec la messagerie Internet, toute la sécurité à fournir devrait faire partie de l'infrastructure de sécurité Internet, plutôt qu'un nouveau mécanisme ou quelque autre mécanisme extérieur à l'infrastructure de l'Internet.

La messagerie Internet et la messagerie vocale ont toutes deux leur propre ensemble de menaces et de contre mesures. À ce titre, la présente spécification ne crée aucun problème de sécurité qui ne soit déjà existant dans les protocoles de la messagerie Internet et de messagerie vocale eux-mêmes. Cette section vise seulement l'ensemble de menaces supplémentaires qui résultent de l'intégration des deux services.

L'envoyeur réel du message vocal peut n'être pas celui qui est spécifié dans les champs d'en-tête "Sender:" ou "From:" du message ou de l'adresse MAIL FROM de l'enveloppe SMTP. Dans un environnement très contraint, des contrôles physiques et logiciels suffisants peuvent être capables d'assurer la prévention de ce problème. De plus, la reconnaissance de la voix de l'envoyeur peut donner l'assurance de l'identité de l'envoyeur sans considération de celle spécifiée dans "Sender:" ou "From;". On devrait reconnaître que les mises en œuvre de SMTP ne fournissent pas une authentification inhérente des envoyeurs de messages, ni que les sites n'ont d'obligation de fournir une telle authentification.

Allouer une adresse de messagerie électronique Internet à une boîte aux lettres vocale ouvre la possibilité de recevoir des messages non sollicités (de texte ou vocaux). Traditionnellement, les systèmes de messagerie vocale fonctionnaient dans des environnements clos et n'étaient pas susceptibles d'offrir l'accès à des envoyeurs inconnus. Les utilisateurs de messagerie vocale ont des attentes importantes en matière de confidentialité et peuvent considérer de tels messages comme une atteinte à la sécurité. De nombreux systèmes de messagerie Internet choisissent de bloquer tous les messages provenant de sources inconnues pour tenter de circonscrire ce problème.

Les utilisateurs de systèmes de messagerie vocale s'attendent à un niveau de confidentialité des messages qui est supérieur à celui fourni par la messagerie Internet sans ses améliorations de sécurité. Ces attentes en matière de confidentialité des utilisateurs DEVRAIENT être préservées autant que possible.

Des contrôles physiques et logiciels suffisants peuvent être acceptables dans des environnements contraints. De plus, le profil spécifié dans le présent document n'empêche en aucune façon l'utilisation d'un protocole d'objet ou de canal de sécurité Internet pour chiffrer, authentifier, ou assurer la non répudiation des messages.

[AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog Protocol Version 1, Issue 2, février 1992.

[AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital Protocol Version 1, Issue 3, août 1993.

[E164] Recommandation UIT-T E.164 (1991), "Fonctionnement du réseau téléphonique et RNIS , numérotation, acheminement et service mobile – plan de numérotage pour l'ère du RNIS".

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

[RFC0822] D. Crocker, "Norme pour le format des messages de texte de l'ARPA-Internet", STD 11, août 1982. (Obsolète, remplacée par la RFC5322)

[RFC1035] P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, novembre 1987. (MàJ par la RFC6604)

[RFC1652] J. Klensin et autres, "Extensions de service SMTP pour transport MIME sur 8 bits", juillet 1994. (Remplacée par RFC6152) (D.S.)

[RFC1911] G. Vaudreuil, "Profil vocal pour la messagerie Internet", février 1996. (Obsolète, voir RFC2421, RFC2422, RFC2423) (Expérimentale)

[RFC2048] N. Freed, J. Klensin et J. Postel, "Extensions multi-objets de la messagerie Internet (MIME) Partie 4 : Procédures d'enregistrement", BCP 13, novembre 1996. (Rendue obsolète par les RFC 4288-4289)

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

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

[RFC2306] G. Parsons, J. Rafferty, "Format de fichier d'image étiquetée (TIFF) – Profil F pour la télécopie", mars 1998. (Info.)

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

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

[RFC2425] T. Howes, M. Smith, F. Dawson, "Type de contenu MIME pour informations de répertoire", septembre 1998. (Obsolète, voir RFC6350) (P.S.)

[RFC2426] F. Dawson, T. Howes, "Profil de répertoire MIME vCard", septembre 1998. (Obsolète, voir RFC6350) (P.S.)

[RFC3066] H. Alvestrand, "Étiquettes pour l'identification des langues", BCP 47, janvier 2001. (Obsolète, voir la RFC4646.)

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

[RFC3802] G. Vaudreuil, G. Parsons, "Voix de qualité supérieure – enregistrement du sous-type MIME en modulation par impulsions et codage différentiel adaptatif (MICDA) à 32 kbit/s", juin 2004. (D.S.)

[X.400] Recommandation UIT-T X.400/ ISO/CEI 10021-1, "Traitement de message : Vue d'ensemble du système et du service", décembre 1988.

Les auteurs tiennent à remercier tout particulièrement l'association de la messagerie électronique (EMA, Electronic Messaging Association) et les membres du comité de la messagerie vocale, ainsi que le groupe de travail VPIM de l'IETF, pour leur soutien à la spécification de VPIM et les efforts qu'ils ont consenti pour assurer son succès.

Le tableau suivant résume le profil de VPIM version 2 détaillé dans le présent document. Comme dans de nombreux cas, il n'est pas possible de simplifier les qualifications pour la prise en charge de chaque caractéristique, le présent appendice est pour information. Il est recommandé au lecteur de lire l'explication complète de chaque caractéristique dans le paragraphe de référence. Le texte des paragraphes précédents est réputé d'autorité si un des éléments du tableau est ambigu.

- Caractéristique – désigne la caractéristique du protocole (noter que les retraits indiquent une hiérarchie de conformité, c'est-à-dire, la conformité d'une caractéristique inférieure n'est pertinente que si il y a conformité à la caractéristique supérieure).

- Zone – zone de conformité à laquelle chaque caractéristique s'applique : C – contenu, T - transport

- Statut – indique si la caractéristique est obligatoire, facultative, ou interdite. Les mots clés utilisés dans ce tableau sont à interpréter comme décrit dans la [RFC2119], bien que la liste suivante fasse un survol rapide des différents degrés de conformité :

- note – commentaire particulier sur la conformité pour une certaine caractéristique

1. DEVRAIT laisser blanc si tous les receveurs ne sont pas connus ou résolubles.

2. Si un message sensible est reçu par un système qui ne prend pas en charge la sensibilité, il DOIT alors être retourné à l'envoyeur avec une notification d'erreur appropriée. Aussi, un message sensible reçu NE DOIT être transmis à personne.

3. Si les champs d'en-tête supplémentaires ne sont pas compris ils PEUVENT être ignorés.

6. Les autres contenus non profilés DOIVENT seulement être envoyés par accord bilatéral.

8. Si le contenu de télécopie ne peut pas être présenté, il PEUT être abandonné.

Le message suivant est un message avec toutes ses caractéristiques, adressé à deux destinataires. Le message comporte le nom parlé de l'envoyeur, le sujet parlé et un bref segment de paroles. Le message est marqué comme important et confidentiel.

Le message suivant est un seul segment vocal retransmis. Le message transmis et le message transmetteur contiennent tous deux le nom parlé des envoyeurs.

L'exemple suivant est celui d'une DSN envoyée à l'expéditeur d'un message par une passerelle VPIM à VM1.company.com pour une boîte aux lettre qui n'existe pas.

L'exemple suivant est celui d'une MDN envoyée à l'espéditeur d'origine d'un message qui a été exécuté. Ce message VPIM de livraison a été reçu par une passerelle d'entreprise et relayé à une boîte aux lettres collective.

Les erreurs de traitement vocal courantes suivantes et leurs codes d'état correspondants sont données en exemples. Le texte après les codes d'erreur n'est destiné qu'à servir de référence pour décrire le code d'erreur. Les mises en œuvre devraient fournir des commentaires informatifs spécifiques de la mise en œuvre après le code d'erreur plutôt que le texte indiqué ci-dessous.

Les conditions de disposition de traitement vocal courantes suivantes et leurs MDN de disposition correspondantes (qui contiennent le mode de disposition, le type et les modificateurs, si applicables) sont données comme exemples. Les mises en œuvre devraient se reporter à la [RFC3798] pour une description complète du format des notifications de disposition de message.

Il n'y a pas de changement à l'enregistrement selon la [RFC2183] du paramètre de disposition de contenu vocal défini dans le document VPIM V2 antérieur, la RFC 2421. Il n'y a pas de changement à l'enregistrement selon la [RFC2048] du type de contenu Multipart/voice-message défini dans le document VPIM v2 antérieur, la RFC 2423.

Voice-Message-Notification - notification de livraison parlée ou notification de disposition parlée,

Recipient-Spoken-Name – nom parlé du receveur si disponible pour le créateur et présent si il y a seulement un destinataire,

Description : afin de distinguer entre les divers types de contenu audio dans un message vocal VPIM, un nouveau paramètre de disposition "voice" est défini avec les valeurs précédantes pour être utilisées comme approprié. Noter qu'il DEVRAIT y avoir seulement une instance de chacun de ces types de contenu audio par niveau de message. Des instances supplémentaires d'un certain type (c'est-à-dire, valeur de paramètre) peuvent se produire au sein d'un message vocal attaché en pièce jointe.

Paramètres exigés : boundary, version. L'utilisation de boundary est définie dans la [RFC2046]

Le paramètre version qui contient la valeur "2.0" si du contenu est inclus se conforme à [VPIM2R2]. L'absence de ce paramètre indique la conformité à la précédente version définie dans la [RFC1911].

Considérations de sécurité : cette définition identifie le contenu comme étant un message vocal. Dans certains environnements (mais vraisemblablement pas la majorité) la perte de l'anonymat du contenu peut poser un problème de sécurité.

Considérations d'interopérabilité : les systèmes développés pour se conformer à la [RFC1911] peuvent ne pas se conformer à cet enregistrement. Précisément, la version requise sera probablement absente, et dans ce cas le système receveur devrait quand même être capable d'accepter le message et être capable de traiter le contenu. L'identification de position VPIM v1 sera cependant probablement perdue.

Applications qui utilisent de type de support : principalement la messagerie vocale

Adresse personnelle & de messagerie à contacter pour plus d'informations : Glenn W. Parsons gparsons@nortelnetworks.com

17. Appendice F – Historique des changements de la RFC 2421 (VPIMv2) à ce document

Le profil mis à jour dans le présent document se fonde sur l'expérience de mise en œuvre et de déploiement opérationnel de plusieurs fabricants. Les changements sont classés en catégories générale, contenu, transport et conformité. Ils sont résumés ci-dessous :

- Diverses mises à jour rédactionnelles et de substance pour améliorer la lisibilité.

- Séparation des règles d'envoi des règles de réception pour être plus clair.

- Précision du comportement à réception des types de contenu non reconnus attendus de l'interfonctionnement entre les systèmes vocaux et de messagerie unifiée. (Par exemple, les contenus non audio non acceptés devraient être éliminés pour livrer le message audio.)

- Reformulation des exigence de sensibilité pour les aligner avec X.400. Élimination des dépendances aux documents MIXER.

- Réorganisation de la description du type de contenu pour la rendre plus claire.

- Changement du traitement des lignes reçues par une passerelle en "NE DEVRAIT PAS supprimer dans une passerelle". Dans les passerelles avec des systèmes comme AMIS, il n'est pas possible de préserver ces informations. Il est prévu que de tels systèmes soient capables de revendiquer la conformité.

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.

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 .

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

Groupe de travail Réseau	G. Vaudreuil, Lucent Technologies
Request for Comments : 3801	G. Parsons, Nortel Networks
RFC rendue obsolète : 2421	juin 2004
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle

				Statut
Caractéristique	§		zone	DOIT	DEVRAIT	PEUT	NE DVT PAS	NE DT PAS	note
Formats d'adressage de message :
Utiliser les noms d'hôte DNS	4.1		C	x
Utiliser seulement des nombres dans les identifiants de boîte aux lettres	4.1.1		C		x
Les numéros des identifiants de boîte aux lettres suivent E.164	4.1.1		C		x
Utiliser des identifiants alpha-numériques de boîte aux lettres	4.1.1		C			x
Prise en charge de postmaster@domain	4.1.2		C	x
Prise en charge de non-mail-user@domain	4.1.2		C		x
Prise en charge de listes de distribution	4.1.3		C			x
Champs d'en-tête de message
Envoi de messages sortants
From		4.2.1	C	x

Ajout d'un nom en texte	4.2.1		C		x
Même valeur que MAIL FROM	4.2.1		C		x
To	4.2.2		C		x				1
cc	4.2.3		C			x			1
Date	4.2.4		C	x
Sender	4.2.5		C			x
Return-Path	4.2.6		C					x
Message-ID	4.2.7		C	x
Reply-To	4.2.8		C				x
Received	4.2.9		C	x				\|
MIME Version: 1.0 (Voice 2.0)	4.2.10		C		x
Content-Type	4.2.11		C	x
Content-Transfer-Encoding	4.2.12		C	x
Sensitivity	4.2.13		C		x
Importance	4.2.14		C			x
Subject	4.2.15		C		x
Disposition-notification-to	4.7		C		x
Autres en-têtes	4.2		C			x
Réception de messages entrants
From		4.2.1	C	x
Présenter le nom personnel en texte		4.2.1	C			x
To		4.2.2	C	x
cc		4.2.3	C			x
Date		4.2.4	C	x
Conversion de date en heure locale		4.2.4	C		x

Sender	4.2.5	C			x
Return-Path	4.2.6	C		x
Message-ID	4.2.7	C			x
MDN demandée	4.2.7	C	x
Reply-To	4.2.8	C			x
Received	4.2.9	C			x
MIME Version: 1.0 (Voice 2.0)	4.2.10	C		x
Content Type	4.2.11	C	x
Content-Transfer-Encoding	4.2.12	C	x
Sensitivity	4.2.13	C	x					2
Importance	4.2.14	C			x
Subject	4.2.15	C			x
Disposition-notification-to	4.7	C		x
Autres en-têtes	4.2	C	x					3
Codage de contenu de message :
Envoi de contenus audio/télécopie sortants
7BIT	4.2.12	C					x
8BIT	4.2.12	C					x
Quoted Printable	4.2.12	C					x
Base64	4.2.12	C	x					4
Binary	4.2.12	C		x				5
Réception de contenu de message entrant
7BIT	4.2.12	C	x
8BIT	4.2.12	C	x
Quoted Printable	4.2.12	C	x
Base64	4.2.12	C	x
Binary	4.2.12	C	x					5
Types de contenu de message :
Envoi de messages sortants
Multipart/Voice-Message	4.4.1	C	x
Message/RFC822	4.4.2	C		x
Audio/32KADPCM	4.4.3	C	x
Content-Description	4.3.1	C			x
Content-Disposition	4.3.2	C	x
Content-Duration	4.3.3	C			x
Content-Language	4.3.4	C			x
Image/TIFF; application=faxbw	4.4.4	C	x					7
Text/Directory	4.5.2	C				x	\|	9
Text/plain	4.5.4	C				x
Audio/* ou Image/* (autres codages)	4.5.3	C				x
Autres contenus	4.5	C					x
Multipart/Mixed	4.5.1	C			x
Text/plain	4.5.4	C			x
Multipart/Report	4.6, 4.7	C	x
La partie lisible par l'homme est vocale	4.6, 4.7	C		x
La partie lisible par l'homme est du texte	4.6, 4.7	C			x
Message/Delivery-Status	4.6	C	x
Message/Disposition-Notification	4.7	C		x
Autres contenus	4.5	C				x		6
Réception de messages entrants
Multipart/Voice-Message	4.4.1	C	x
Message/RFC822	4.4.2	C	x
Audio/32KADPCM	4.4.3	C	x
Content-Description	4.3.1	C			x
Content-Disposition	4.3.2	C		x
Content-Duration	4.3.3	C			x
Content-Language	4.3.4	C			x
Image/TIFF; application=faxbw	4.4.4	C		x				8
Text/Directory	4.5.2	C	x					9
Text/plain	4.5.4	C			x
Audio/* ou Image/* (autres codages)	4.5.3	C			x
Autres contenus	4.5	C			x
Multipart/Mixed	4.5.1	C			x
Text/plain	4.5.4	C	x
Multipart/Report	4.6, 4.7	C	x
La partie lisible par l'homme est vocale	4.6, 4.7	C	x
La partie lisible par l'homme est du texte	4.6, 4.7	C	x
Message/Delivery-Status	4.6	C	x
Message/Disposition-Notification	4.7	C		x
Autres contenus	4.5	C			x			6
Messages transmis
Utiliser la construction Message/RFC822	4.8	C		x
Simuler les en-têtes si aucun n'est disponible	4.8	C		x
Messages de réponse	4.9	C	x
Envoyer à l'adresse Reply-To, sinon à From	4.2.8	C			x
Envoyer à non-mail-use	4.9	C				x
Notifications
Utiliser le format Multipart/Report	4.6, 4.7	C	x
Toujours envoyer une erreur en cas de non livraison	4.6	C	x
Envoyer les messages d'erreur à return-path	4.2.6	C	x
Protocole de transport de messages :
Commandes ESMTP de base
HELO	5.1	T	x
MAIL FROM	5.1	T	x
RCPT TO	5.1	T	x
DATA	5.1	T	x
TURN	5.1	T					x
QUIT	5.1	T	x
RSET	5.1	T	x
VRFY	5.1	T			x
EHLO	5.1	T	x
BDAT	5.1	T			x			5
Mots-clés & paramètres ESMTP
DSN	5.2.1	T	x
NOTIFY	5.2.1	T	x
RET	5.2.1	T		x
ENVID	5.2.1	T			x
ORCPT	5.2.1	T			x
SIZE	5.2.2	T	x
ENHANCEDSTATUSCODES	5.2.3	T		x
PIPELINING	5.2.4	T		x
CHUNKING	5.2.5	T			x
BINARYMIME	5.2.6	T			x
Repli sur ESMTP-SMTP
Envoi d'un rapport de livraison sur repli	5.3	T	x
Résolution d'adresse de répertoire
Fournir des facilités de résolution d'adresse	6	C		x
Utilisation d'en-têtes pour remplir le répertoire local	6	C			x
Protocoles de gestion :
Gestion de réseau	7.1	T			x

Condition d'erreur	Code d'erreur de la RFC1893
Échec de la livraison analogique à cause de l'occupation du système distant	4.4.1 Erreur de connexion persistante - occupé
Échec de la livraison analogique parce que le système distant sonne sans réponse	4.4.1 Erreur persistante de protocole – pas de réponse de l'hôte
Le système distant ne répond pas à la prise de contact AMIS-Analog ("D" en réponse à "C" au moment de la connexion)	5.5.5 Erreur persistante de protocole - mauvaise version
La boîte aus lettres n'existe pas	5.1.1 Erreur permanente de boîte aux lettres – n'existe pas
Boîte aux lettres pleine ou quota dépassé	4.2.2 Erreur permanente de boîte aux lettres – pleine
Disque plein	4.3.1 Erreur persistante du système – plein
Commande hors séquence	5.5.1 Erreur permanente de protocole – commande invalide
Erreur de trame	5.5.2 Erreur permanente de protocole – erreur de syntaxe
La boîte aus lettres ne prend pas en charge FAX	5.6.1 Erreur permanente de support - non pris en charge
La boîte aus lettres ne prend pas en charge TEXT	5.6.1 Erreur permanente de suppoprt - non pris en charge
L'envoyeur n'est pas autorisé	5.7.1 Erreur permanente de sécurité - envoyeur non autorisé
Message marqué confidentiel, mais le système n'a pas la capacité de confidentialité	5.3.3 Erreur permanente du système- caractéristique non prise en charge

Événement de notification	MDN de mode de disposition, type & modificateur
Message exécuté par le destinataire, accusé de réception retourné automatiquement	action manuelle/MDN envoyée automatiquement ; affiché
Message supprimé de la boîte aux lettre par l'usager sans l'écouter	action manuelle/MDN envoyée automatiquement ; supprimé
Message supprimé lorsque la boîte aux lettres a été supprimée par l'administrateur	action manuelle/MDN envoyée automatiquement ; supprimé/boîte aux lettres terminée
Message automatiquement supprimé lorsque plus ancien qu'un seuil fixé par l'administrateur	action automatique/MDN envoyée automatiquement ; supprimée/expirée
Message traité, mais le codage audio est inconnu – impossible de l'exécuter à l'usager	action manuelle/MDN envoyée automatiquement ; traitée/erreur Erreur : codage audio inconnu

Gregory M. Vaudreuil	Glenn W. Parsons
Lucent Technologies	Nortel Networks
7291 Williamson Rd	P.O. Box 3511, Station C
Dallas, TX 75214	Ottawa, ON K1Y 4H7
United States	Canada
mél : gregv@ieee.org	mél : gparsons@nortelnetworks.com