Négociation de contenu pour services de messagerie fondés sur la messagerie électronique

Statut de ce mémoire

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

Copyright

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

Résumé

Le présent mémoire décrit un mécanisme de négociation de contenu pour les services de télécopie, de messagerie vocale et autres services qui utilisent la messagerie électronique Internet.

Les services tels que la télécopie et la messagerie vocale ont besoin de composer avec les nouveaux formats de contenu de message, et ont donc besoin de s’assurer que le contenu de tout message peut être rendu par l’agent receveur. Le mécanisme décrit ici vise à satisfaire aux besoins d’une façon qui soit pleinement compatible avec le comportement actuel et les attentes de la messagerie électronique Internet.

1. Introduction

Le présent mémoire décrit un mécanisme pour la négociation de contenu fondé sur la messagerie électronique qui fournit une facilité de télécopie Internet comparable à celle de la télécopie traditionnelle, puuvant être utilisé par d’autres services de messagerie qui ont besoin de facilités similaires.

"Télécopie étendue en utilisant la messagerie Internet" [RFC2532] spécifie le transfert des données d’image utilisant les protocoles de messagerie électronique de l’Internet. "Indication des caractéristique de support prises en charge en utilisant les extensions à DSN et MDN" [RFC2530] décrit un mécanisme pour fournir à l’envoyeur les détails des capacités d’un receveur. Les informations de capacité ainsi fournies, si elles sont mémorisées par l’envoyeur, peuvent être utilisées dans des transferts ultérieurs entre les mêmes envoyeurs et receveurs.

De nombreuses communications sont uniques ou sont des transferts peu fréquents entre un certain envoyeur et un certain receveur, et ne peuvent pas bénéficier de cette approche "de faire mieux la prochaine fois".

Une autre facilité disponible dans la messagerie électronique (bien que non largement mise en œuvre) est que l’envoyeur utilise le 'multipart/alternative' [RFC2046] pour envoyer un message dans plusieurs formats différents, et permette au receveur de choisir. À part les inconvénients évidents sur l’utilisation de la bande passante du réseau, cette approche ne permet pas par elle-même à l’envoyeur de vraiment tailler sur mesure son message pour un certain receveur, ou d’obtenir confirmation qu’une des solutions de remplacement envoyées a été utilisable par le receveur.

Le présent mémoire décrit un mécanisme qui permet d’envoyer des formats de données meilleurs que le format de base dans la première communication entre un envoyeur et un receveur. Le même mécanisme peut aussi réaliser un transfert de message utilisable lorsque l’envoyeur a fondé la transmission initiale sur des informations incorrectes quant aux capacités du receveur. Il permet à l’envoyeur d’un message d’indiquer la disponibilité de formats de remplacement, et au receveur d’indiquer qu’un autre format devrait être fourni pour remplacer les données du message transmises à l’origine.

Lorsque l’envoyeur n’a pas les informations correctes sur les capacités d’un receveur, le mécanisme décrit ici peut entraîner un aller-retour de message supplémentaire. Un objectif important de ce mécanisme est de permettre que suffisamment d’informations soient fournies pour déterminer si l’aller-retour supplémentaire est ou non nécessaire.

1.1 Structure du document

La partie principale de ce mémoire traite des domaines suivants :

La Section 2 décrit certains des fondements, et définit les objectifs spécifiques qui sont traités dans la présente spécification.

La Section 3 décrit le cadre de négociation de contenu proposé, en indiquant les flux d’informations entre envoyeur et receveur.

La Section 4 contient une description détaillée de l’en-tête 'Content-alternative' qui est utilisé pour porter les informations sur les formats de remplacement disponibles. Cette description est destinée à rester indépendante du reste de cette spécification, en vue d’être utilisable en conjonction avec d’autres protocoles de négociation de contenu.

La Section 5 décrit un nouvel en-tête de message électronique, 'Original-Message-ID', qui est utilisé pour corréler les données de remplacement envoyées durant la négociation avec les données du message original, et pour distinguer la continuation d’une vieille transaction de message du début d’une nouvelle transaction.

La Section 6 décrit les extensions au cadre de notification de disposition de message (MDN, Message Disposition Notification) [RFC2298] qui prend en charge la négociation entre les parties communicantes.

1.2 Terminologie et conventions du document

1.2.1 Terminologie

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

Échange de capacités

Échange d’informations entre les parties communicantes qui indique les sortes d’informations qu’elles peuvent générer ou consommer.

Identification de capacités

Fourniture d’informations par un agent receveur qui indiquent les sortes de données de message qu’il peut accepter de présenter à un usager.

Négociation de contenu

Échange d’informations (métadonnées de négociation) qui conduit à la sélection de la représentation (variante) appropriée lors du transfert d’une ressource de données.

Transaction de message

Séquence d’échanges entre un envoyeur de message et un receveur qui accomplit le transfert des données du message.

La [RFC2703] introduit plusieurs autres termes qui se rapportent à la négociation de contenu.

1.2.2 Objectifs conceptuels

Dans l’exposé des objectifs de la négociation de contenu, la notation {1}, {2}, {3} est utilisée, selon la "Terminologie et les objectifs de la télécopie Internet" [RFC2542]. La signification associée à cette notation est :

{1} il y a un accord général sur le caractère critique de cette caractéristique dans toute définition de négociation de contenu pour la télécopie Internet.

{2} la plupart pensent que cette caractéristique est importante pour la négociation de contenu dans la télécopie Internet.

{3} on pense généralement que cette caractéristique est utile pour la négociation de contenu dans la télécopie Internet, mais que d’autres facteurs pourraient la supplanter ; une définition qui ne fournit pas cet élément est acceptable.

1.2.3 Autres conventions du document

Note : Des commentaires comme celui-ci donnent des informations supplémentaires non essentielles sur les raisons de ce document. De telles informations ne sont pas nécessaires pour construire une mise en œuvre conforme, mais peuvent aider ceux qui souhaitent comprendre la conception plus en profondeur.

2. Fondements et objectifs

2.1 Fondements

2.1.1 Télécopie et messagerie électronique

Un des objectifs de la tâche de définition d’un service de télécopie qui utilise la messagerie Internet a été de prendre les acquis du service de télécopie groupe 3 traditionnel dans un environnement de messagerie électronique. La télécopie groupe 3 traditionnelle repose très fortement sur l’idée que l’échange en ligne des informations divulgue les capacités d’un receveur à l’envoyeur avant qu’aucune donnée du message ne soit transmise.

À l’opposé, la messagerie électronique Internet a été développée pour fonctionner d’une façon différente, sans qu’on s’attende à ce que l’envoyeur et le receveur s’échangent des informations avant de transférer le message. Une conséquence de cela est que tous les messages électroniques doivent contenir des données de message significatives : les messages qui sont envoyés simplement pour tirer des informations d’un agent de traitement du message reçu ne sont généralement pas acceptables dans l’environnement de la messagerie Internet.

Pour garantir un certain niveau d’interopérabilité, la télécopie groupe 3 et la messagerie Internet s’appuient sur le fait que tous les receveurs sont capables de traiter un certain format de base (c’est-à-dire, respectivement, un format d’image de base ou du texte en ASCII). Le rôle de l’échange de capacités ou de la négociation de contenu est de permettre que des capacités meilleures que celles de base soient employées lorsque disponibles.

Un des défis relevés par la présente spécification est de savoir comment adapter l’environnement de la messagerie électronique pour fournir un service du genre de la télécopie. Un envoyeur ne doit pas faire d’hypothèses a priori sur la possibilité que le receveur reconnaisse quelque chose de plus qu’un simple message électronique. Il y a certaines utilisations importantes de la messagerie électronique qui sont fondamentalement incompatibles avec le modèle de télécopie comportant un passage de message et une négociation de contenu (en particulier les listes de diffusion). On a donc besoin d’un moyen pour reconnaître lorsque la négociation de contenu est possible, sans casser le modèle existant de la messagerie électronique.

2.1.2 Facilités actuelles de la télécopie Internet

"Télécopie étendue avec la messagerie électronique Internet" [RFC2532] prévoit une fourniture limitée d’informations de capacités du receveur à l’envoyeur d’un message, en utilisant une extension à la notification de disposition de message (MDN, Message Disposition Notification) [RFC2530], [RFC2298], en employant des étiquettes de caractéristiques du support [RFC2506] et des expressions de caractéristiques du support [RFC2533].

Ce mécanisme permet la divulgation des capacités du receveur après la réception et le traitement d’un message. Ces informations peuvent être utilisées pour des transmissions ultérieures au même receveur. Mais de nombreuses communications sont des messages uniques d’un certain envoyeur à un certain receveur, et ne peuvent pas en bénéficier.

2.2 Fermeture de la boucle

La messagerie Internet classique est un processus de "boucle ouverte" : aucune information n’est retournée au point d’où le message est envoyé. Cela a été malicieusement – mais justement — caractérisé comme "envoyer et prier", car il n’y a pas de confirmation.

Envoyer un message et obtenir confirmation qu’il a été reçu est un processus de "boucle fermée" : la confirmation renvoyée à l’envoyeur crée une boucle autour de laquelle sont passées les informations.

De nombreux agents de messagerie Internet ne sont pas conçus pour participer à un processus de boucle fermée, et ne sont donc pas chargés de répondre à la réception d’un message. Les ajouts ultérieurs aux normes de l’Internet, en particulier la notification d’état de livraison [RFC1891] et la notification de disposition de message [RFC2298], spécifient des moyens pour que certaines réponses de confirmation soient renvoyées à l’expéditeur, fermant ainsi la boucle. Cependant, la conformité à ces améliorations est facultatives et un plein déploiement est encore à prévoir.

DSN doit être pleinement mis en œuvre par la totalité de l’infrastructure ; de plus, lorsque il n’y a pas de prise en charge, le message est quand même envoyé à la façon de la boucle ouverte. Parfois, la transmission et la livraison devraient plutôt être interrompues et le fait rapporté à l’envoyeur.

À cause de considérations de confidentialité pour les utilisateurs finaux, l’usage de MDN est entièrement volontaire.

La négociation de contenu est une fonction de boucle fermée (pour les besoins de la présente proposition – voir le paragraphe 2.3, item (f)) et exige que le receveur d’un message fasse une réponse à l’envoyeur. Comme la négociation de contenu doit s’adapter à une fonction de boucle fermée dans l’environnement volontariste et à forte latence de la messagerie Internet, un défi pour la négociation de contenu dans la messagerie électronique est d’établir que des parties consentantes puissent reconnaître une situation de boucle fermée, et donc reconnaître leur responsabilité pour fermer la boucle.

Trois boucles différentes peuvent être identifiées dans une négociation de contenu :

Envoyeur Receveur

| |

Message initial ------>------------ v

| |

(1) ------------<--- Demande de données de remplacement

| |

Envoi du remplacement ->------------ (2)

| |

(3) ------------<--Confirmation de la réception de données utilisables

(1) L’envoyeur reçoit un accusé de réception du contenu négociable.

(2) Le receveur reçoit confirmation de la réception de sa demande de données.

(3) L’envoyeur reçoit la confirmation que les données reçues sont traitables, ou qu’elles ont été traitées.

Bien que le processus de négociation de contenu soit initiée par l’envoyeur, il n’est pas établi tant que la boucle (1) n’est pas close avec une indication que le receveur désire un contenu de remplacement.

Si le contenu envoyé avec le message d’origine par l’envoyeur est traitable par le receveur, et si une confirmation est envoyée, le processus entier est réduit à une simple boucle envoi/confirmation:

Envoyeur Receveur

| |

Message initial ------>------------ v

| |

(3) ----------<-- Confirmation de réception de données utilisables

2.3 Buts de la négociation de contenu

L’objectif principal {1} est de fournir un mécanisme qui permette d’utiliser des caractéristiques de contenu améliorées arbitraires avec les systèmes de télécopie Internet. Le mécanisme devrait {2} prendre en charge l’introduction de nouvelles caractéristiques à l’avenir, en particulier celles qui seront adoptées pour la télécopie groupe 3.

Les autres objectifs sont :

(a) Doit {1} interfonctionner avec les systèmes de télécopie Internet en mode simple existants.

(b) Doit {1} interfonctionner avec les clients de messagerie électronique existants. Le terme "interfonctionner" utilisé ci-dessus signifie que le mécanisme doit être introduit d’une façon qui peut être ignorée par les systèmes existants, et les systèmes améliorés pour utiliser le mécanisme de négociation se comporteront d’une façon attendue par les systèmes existants, (c’est-à-dire que les clients existants ne sont en aucune façon supposés participer ou être informés de la négociation de contenu).

(c) Doit {1} éviter la transmission de "non messages administratifs", (c’est-à-dire que seuls les messages qui contiennent un contenu significatif pour l’utilisateur final peuvent être envoyés sauf si on sait que le système receveur va les interpréter, et ne pas tenter de les afficher.) Cette exigence a été affirmée avec force par la communauté de la messagerie électronique. Cela signifie qu’un envoyeur ne doit pas supposer qu’un receveur peut comprendre les éléments de protocole d’échange de capacités, et doit donc toujours commencer par envoyer des données de message significatives.

(d) Éviter {1} d’avoir plusieurs rendus d’un message. Dans des situations où plusieurs versions d’un message sont transférées, le receveur doit être capable de décider fiablement sur une seule version à afficher.

(e) Minimiser {2} les allers-retours nécessaires pour achever une transmission. Idéalement {3} chaque transmission améliorée va résulter en le simple envoi des données que le receveur peut traiter, et à recevoir une réponse de confirmation.

(f) La solution adoptée ne devrait pas {3} transmettre plusieurs versions des mêmes données. En particulier, elle ne doit pas {1} s’appuyer sur l’envoi routinier de plusieurs instances des mêmes données dans un seul message.

Cela n’interdit pas d’envoyer plusieurs versions des mêmes données, mais ce ne doit pas être une exigence de le faire. Un envoyeur peut choisir d’envoyer plusieurs versions ensemble (par exemple, texte en clair et d’autres formats) mais le mécanisme d’échange de capacités choisi ne doit pas dépendre d’un tel comportement.

(g) La solution adoptée devrait {2} être cohérente avec, et applicable aux autres applications fondées sur la messagerie électronique de l’Internet ; par exemple, la messagerie électronique régulière, la messagerie vocale, la messagerie unifiée, etc.

(h) Permettre une récupération en douceur à partir d’informations d’antémémoires périmées. Un envoyeur peut utiliser des informations d’historique pour envoyer des données non de base avec un message initial. Si il se trouve que cela se révèle inutilisable par le receveur, il devrait cependant être possible {3} que les données de base, ou quelque autre format acceptable, soit sélectionnées et transférées.

(i) Le mécanisme défini devrait {2} fonctionner proprement en conjonction avec les mécanismes déjà définis pour la télécopie Internet en mode étendu (DSN et MDN étendu [RFC2530], etc.).

(j) Autant que possible, les mécanismes de messagerie électronique existants devraient {3} être utilisés plutôt que d’en inventer de nouveaux. (Il est clair que de nouveaux mécanismes seront nécessaires, mais ils devraient être définis avec précaution.)

(k) Le mécanisme devrait {2} pouvoir être mis en œuvre dans des appareils à faible mémoire. C’est-à-dire qu’il ne devrait pas dépendre de ce qu’une partie soit capable de mettre en mémoire tampon des quantités arbitraires de données de message.

(Il peut n’être pas possible de satisfaire complètement cet objectif dans un système envoyeur. Mais si l’envoyeur n’a pas assez de mémoire pour mettre un certain message en mémoire tampon, il peut choisir de ne pas offrir la négociation de contenu.)

3. Cadre de la négociation de contenu

La présente section commence par une présentation du processus de négociation, et apporte plus de détails sur chaque étape dans les paragraphes sui suivent.

1 L’envoyeur envoie les données du message initial avec une indication de formats de remplacement disponibles (paragraphe 3.1). Les données initiales PEUVENT être de base ou un pari sur ce que le receveur peut traiter.

2 Le receveur a trois options principales :

(a) ne pas reconnaître les formats facultatifs de remplacement, et accepter passivement les données comme elles sont envoyées (paragraphe 3.2.1) ;

(b) ne pas reconnaître les solutions de remplacement offertes, et accepter activement les données comme elles sont envoyées (paragraphe 3.2.2) ;

(c) reconnaître les solutions de remplacement offertes, et déterminer qu’il préfère recevoir un format de remplacement. Une réponse MDN est envoyée (i) indiquant que les données d’origine n’ont pas été traitées, et (ii) contenant des informations sur les capacités du receveur afin que l’envoyeur puisse choisir une solution de remplacement convenable (paragraphe 3.2.3).

Noter que seuls les receveurs désignés dans les en-têtes 'to:', 'cc:' ou 'bcc:' dans le message d’origine peuvent demander des formats de données de remplacement de cette façon. Les receveurs qui ne sont pas nommés dans les en-têtes du message d’origine NE DOIVENT PAS tenter d’initier la négociation de contenu.

Note : L’interdiction de l’initiation de la négociation par les receveurs autres que ceux explicitement mentionnées est destinée à éviter que l’envoyeur ait à s’occuper de demandes de négociation provenant de parties inattendues.

3 À réception d’une réponse MDN qui indique la préférence pour un format de données de remplacement, l’envoyeur DOIT choisir et transmettre les données de message qui correspondent aux capacités déclarées du receveur, ou envoyer une indication que la requête du receveur ne peut pas être honorée. Lorsque il envoie les données de remplacement, l’envoyeur supprime l’indication que des données de remplacement sont disponibles, afin que le processus de négociation ne se fasse pas en boucle.

4 À réception des données finales de la part de l’envoyeur, le receveur envoie une réponse MDN indiquant l’acceptation (ou autre) des données reçues.

Note : Le receveur ne choisit pas le format précis des données à recevoir ; ce choix appartient à l’envoyeur. On trouve que cette approche est plus simple que d’avoir le receveur qui choisit la solution, parce qu’elle repose sur des mécanismes déjà existants dans la messagerie électronique et suit les mêmes schémas que la télécopie groupe 3 traditionnelle. De plus, elle a à faire à des situations où la gamme des alternatives peut être difficile à décrire.

Cette approche est similaire à celle de la négociation pilotée par le serveur dans HTTP qui utilise les en-têtes "Accept" [RFC2616]. Elle est distincte du style de négociation pilotée par l’agent fourni pour HTTP au titre de la négociation transparente de contenu [RFC2295], ou qui pourrait être construite dans la messagerie électronique en utilisant les types MIME "multipart/alternative" et "message/external-body" [RFC2046].

3.1 Envoi de données avec l’indication de solutions de remplacement

Un envoyeur qui est prêt à fournir des formats de remplacement de données de message DOIT envoyer les éléments de message suivants :

(a) un format des données de message par défaut,

(b) une identification de message, sous la forme d’un en-tête Message-ID,

(c) un ou des en-têtes 'Content-features' (caractéristiques du contenu) appropriés [RFC2938] décrivant les données de message par défaut envoyées,

(d) une demande de notification de disposition de message [RFC2298],

(e) une indication qu’il est prêt à envoyer des données de message différentes, en utilisant un champ d’option MDN 'Alternative-available' (alternative disponible) (Section 6), et

(f) une indication des formats de données de remplacement disponibles, sous la forme d’un ou plusieurs en-têtes 'Content-alternative' (contenu de remplacement) (Voir à la Section 4 “En-tête 'Content-alternative'"). Note : On peut spécifier plus d’un en-tête Content-alternative ; voir plus d’informations au paragraphe 3.1.3.

Ayant indiqué la disponibilité de formats de données de remplacement, l’envoyeur est supposé détenir les informations nécessaires pendant quelques temps, laissant au receveur l’opportunité de demander de telles données. Mais, sauf si il l’indique (voir la Section 6) l’envoyeur n’est pas supposé détenir ces informations indéfiniment ; la durée exacte pendant laquelle de telles informations devraient être conservées n’est pas spécifiée ici. Donc, il existe une possibilité qu’une demande d’informations de remplacement arrive trop tard, et que l’envoyeur doive alors indiquer que les données ne sont plus disponibles. Si le transfert du message n’est pas achevé dans un intervalle de temps prédéterminé (par exemple, en utilisant [21]) l’envoyeur devrait normalement conserver les données pendant au moins cette période.

3.1.1 Choix d’un format de données par défaut

Le format normal par défaut est text/plain. C’est le format envoyé sauf si l’envoyeur a une connaissance à priori ou l’espoir qu’un autre format de contenu est pris en charge par le receveur. Certaines utilisations de messagerie électronique présupposent d’autres formats par défaut (par exemple, la télécopie Internet [RFC2532] a le profil TIFF S [RFC2301] comme format par défaut ; voir la section 7 du présent document).

La [RFC2532] "Télécopie étendue avec la messagerie Internet" et la [RFC2530] "Indication des caractéristiques de support prises en charge en utilisant les extensions à DSN et MDN" indiquent un mécanisme possible pour qu’un envoyeur ait une connaissance à priori des capacités du receveur. La présente spécification s’appuie sur le mécanisme qui y est décrit.

Comme toujours, l’envoyeur peut collecter des informations sur le receveur par d’autres moyens qui sortent du domaine d’application du présent document (par exemple, un service de répertoire ou le protocole RESCAP suggéré).

3.1.2 Demande MDN qui indique des formats de données de remplacement

Lorsque un envoyeur indique qu’il est prêt à envoyer des données de message de remplacement, il DOIT demander une notification de disposition de message (MDN) [RFC2298].

Il indique qu’il est prêt à envoyer les données de message de remplacement en incluant l’option MDN 'Alternative-available' (voir la Section 6) avec la demande MDN. La présence de cette option de demande MDN indique simplement que l’envoyeur est prêt à envoyer un format de données différent si il a des informations plus précises ou plus à jour sur les capacités du receveur. Par elle-même, cette option n’indique pas si le remplacement va vraisemblablement être meilleur ou pire que les données envoyées par défaut -- ces informations sont fournies par le ou les en-têtes "Content-alternative" (voir à la Section 4).

Lorsque il utilise l’option 'Alternative-available' dans une demande MDN, le message DOIT aussi contenir un en-tête 'Message-ID:' avec un identifiant de message univoque.

3.1.3 Informations sur les formats de données de remplacement

Un envoyeur peut fournir des informations sur les données de remplacement de message disponibles en appliquant un ou plusieurs en-têtes 'Content-alternative' aux parties de corps de message pour lesquelles des données de remplacement sont disponibles, chacune indiquant des caractéristiques de support [RFC2506], [RFC2533] d’une solution de remplacement disponible.

L’objet de ces informations est de permettre à un receveur de décider si une des solutions de remplacement disponibles est préférable, ou a des chances d’être préférable, aux données de message fournies par défaut.

Il n’est pas exigé que toutes les solutions de remplacement disponibles soient décrites de cette façon, mais l’envoyeur devrait inclure assez d’informations pour permettre à un receveur de déterminer si il peut ou non attendre des données de message plus utiles si il choisit d’indiquer une préférence pour une solution de remplacement qui correspond à ses capacités.

Des formats de remplacement vont souvent être une variante du type de contenu envoyé à l’origine. Lorsque des types de contenu différents peuvent être fournis, ils devraient être indiqués dans un en-tête Content-alternative correspondant en utilisant l’étiquette de caractéristique de support 'type' [RFC2913] (voir l’exemple 8.4).

Note : L’envoyeur n’est pas nécessairement supposé décrire tous les formats de remplacement disponibles – bien sûr, lorsque le contenu est généré au vol plutôt que simplement choisi dans une énumération de possibilités, cela peut être irréalisable. L’envoyeur est supposé utiliser un ou plusieurs en-têtes 'Content-alternative' pour indiquer la gamme de formats de remplacement raisonnablement disponibles.

Le format final réellement envoyé sera toujours choisi par l’envoyeur, sur la base des capacités du receveur. Les en-têtes 'Content-alternative' ne sont fournis ici que pour permettre au receveur de prendre une décision raisonnable sur la demande d’un format de remplacement qui corresponde mieux à ses capacités.

Note : Cet en-tête est destiné à être utilisable indépendamment de l’extension MDN qui indique que l’envoyeur est prêt à envoyer des formats de remplacement. Il pourrait être utilisé avec un protocole différent n’ayant rien à voir avec la messagerie électronique ou MDN. Donc, l’en-tête 'Content-alternative' fournit des informations sur les formats de remplacement des données sans réellement indiquer si ou comment elles pourraient être obtenues.

De plus, l’en-tête 'Content-alternative' s’applique à une partie de corps MIME, lorsque l’option MDN 'Alternative-available' s’applique à la totalité du message.

La Section "Exemples" du présent mémoire montre comment les en-têtes MIME 'Content-features:' et 'Content-alternative:' peuvent être utilisés pour décrire le contenu fourni et les solutions de remplacement disponibles.

3.2 Options de receveur

Un système capable de négociation qui reçoit des données de message sans une indication de formats de données de remplacement DOIT traiter ce message de la même façon qu’un système de télécopie ou un agent d’utilisateur de messagerie électronique standard.

Lorsque on lui donne une indication d’options de formats de données de remplacement, le receveur a trois options principales :

(a) ne pas reconnaître les solutions de remplacement : accepter passivement ce qui est fourni,

(b) ne pas préférer les solutions de remplacement : accepter activement ce qui est fourni, ou

(c) préférer un format de remplacement.

3.2.1 Solutions de remplacement non reconnues

Cela correspond au cas où le receveur est un simple receveur de télécopie en mode Internet [RFC2305], ou un agent d’utilisateur de messagerie électronique traditionnel.

Le receveur ne reconnaît pas les solutions de remplacement offertes, ou choisit de ne pas les reconnaître, et accepte simplement les données comme elles sont envoyées. Une réponse MDN standard [RFC2298] ou une réponse MDN étendue [RFC2530] PEUT être générée par le receveur de l’offre d’options.

3.2.2 Solutions de remplacement non désirées

Le receveur reconnaît les solutions de remplacement offertes, mais choisit spécifiquement d’accepter des données originellement offertes. Une réponse MDN DEVRAIT être envoyée qui indique l’acceptation des données et contienne aussi les capacités du receveur.

Ce comportement est le même que celui défini pour un receveur de télécopie Internet étendue [RFC2532], [RFC2530].

3.2.3 Solution de remplacement préférée

Ce cas étend le comportement de la télécopie Internet étendue [RFC2532], [RFC2530] pour permettre une forme de remplacement des données pour que le message en cours soit transféré. Cette option peut être suivie SEULEMENT si le message d’origine contient une option MDN 'Alternative-available' (les données de remplacement renvoyées peuvent ne pas utiliser cette option). De plus, cette option ne peut être suivie QUE si le receveur est explicitement mentionné dans les en-têtes du message ('to:', 'cc:' ou 'bcc:').

Le receveur reconnaît que les données de remplacement sont disponibles, et détermine, sur la base des informations fournies qu’un format de remplacement serait préférable. Une réponse MDN [RFC2298] est envoyée, qui DOIT contenir ce qui suit :

o un modificateur de disposition 'Alternative-preferred' (Section 6) indiquant qu’un format de données autre que celui envoyé à l’origine est préféré,

o un champ 'Original-Message-ID:' [RFC2298] avec l’identifiant de message provenant du message reçu, et

o les capacités du receveur, selon la [RFC2530].

À l’envoi d’une telle réponse MDN, le receveur PEUT éliminer les données du message fourni, dans l’attente de l’envoi de données de remplacement. Mais si l’envoyeur a indiqué une durée de vie limitée pour les données de remplacement, et si les données originales reçues rentrent dans les capacités d’affichage du receveur, le receveur NE DEVRAIT PAS les éliminer. Avec une mémoire insuffisante pour conserver les données originales pendant une période de temps dans laquelle les données de remplacement devraient raisonnablement être reçues, le receveur DEVRAIT accepter et éliminer les données originales. Dans le cas où les données originales excèdent les capacités d’affichage du receveur, il DEVRAIT alors éliminer les données originales et demander un format de remplacement.

Note : Les règles ci-dessus sont destinées à s’assurer que le cadre de négociation de contenu n’aboutit pas à la perte des données qui seraient autrement reçues et affichées.

Ayant demandé les données de remplacement et n’ayant pas affiché les données originales, le receveur DOIT se souvenir de ce fait et être prêt à prendre une action corrective si les données de remplacement ne sont pas reçues dans un délai raisonnable (par exemple, si la réponse MDN ou la transmission des données de remplacement est perdue dans le transit).

L’action corrective pourrait être une des suivantes :

(a) renvoyer la réponse MDN, et continuer d’attendre les données de remplacement,

(b) présenter les données d’origine fournies (si elles sont encore disponibles) ou

(c) générer une réponse d’erreur indiquant la perte des données.

Si on conclut que les données de remplacement ne viendront pas, l’option préférée est (b), mais cela peut n’être pas possible pour les receveurs qui ont une mémoire limitée.

Voir à l’Appendice A un exposé complémentaire sur les options de comportement du receveur.

Note : Un indicateur de contrôle d’antémémoire sur les capacités du receveur a été envisage, mais n’est pas inclus dans la présente spécification. (Parfois, un receveur peut vouloir n’offrir certaines capacités que dans certaines circonstances, et ne souhaite pas qu’elles soient retenues pour une utilisation future; par exemple, ne pas vouloir recevoir des images couleur pour les communications de routine.)

Note : Le receveur n’a en fait pas à choisir un format de données spécifique offert par l’envoyeur. Le choix final du format des données est toujours fait par l’envoyeur, sur la base des capacités déclarées du receveur. Cette approche :

(a) correspond plus au style de la négociation de contenu de T.30,

(b) assure une intégration correcte avec la spécification actuelle de télécopie Internet en mode étendu,

(c) s’appuie de façon cohérente sur les mécanismes existants de messagerie électronique, et

(d) permet des cas (par exemple, des contenus générés de façon dynamique) où il n’est pas possible à l’envoyeur d’énumérer les solutions de remplacement disponibles.

3.3 Envoi de données de remplacement du message

Ayant offert de fournir des données de remplacement en incluant une option 'Alternative-available' avec la demande MDN originale, et à réception d’une réponse MDN indiquant 'Alternative-preferred', l’envoyeur DEVRAIT transmettre les données de remplacement de message qui correspondent le mieux aux capacités déclarées du receveur. (Dans le cas exceptionnel où la réponse demandant un format de données de remplacement ne contiendrait aucune des capacités du receveur, un format de base devrait être choisi.)

Si une partie des données disponibles du message qui correspondent le mieux aux capacités du receveur est la même que celles envoyées à l’origine, elle DOIT quand même être retransmise parce que le receveur peut avoir éliminé les données originales. Toutes les données envoyées par suite de la réception d’une réponse 'Alternative-preferred' devraient inclure une demande MDN mais NE DEVRAIENT PAS inclure un modificateur de notification de disposition 'Alternative-available'.

Si l’envoyeur n’est plus capable d’envoyer de données de message pour une raison quelconque, il DOIT envoyer un message au receveur indiquant l’échec du transfert. Il DEVRAIT aussi générer un rapport pour le receveur indiquant l’échec, contenant une demande MDN et incluant un modificateur de notification de disposition 'Alternative-not-available'.

Tout message envoyé à un receveur en réponse à une demande de données de remplacement DOIT inclure un en-tête 'Original-Message-ID:' (Section 5) contenant la valeur de l’identifiant de message d’origine provenant du message notification de disposition reçu (qui est le 'Message-ID:' provenant du message original). Cet en-tête sert à corréler le message renvoyé (ou le message d’échec) avec le message original, et aussi à distinguer un message renvoyé de l’original.

3.4 Confirmation de réception des données de message renvoyées

Lorsque les données renvoyées sont reçues (ce qui est indiqué par la présence d’un champ d’en-tête 'original-message-ID:') le receveur traite ces données et génère une réponse MDN indiquant la disposition finale des données reçues, et indiquant aussi les capacités qui peuvent être utilisées pour les messages futurs, conformément aux [RFC2530] et [RFC2532].

Si le renvoi indique que les données de remplacement ne sont plus disponibles (en incluant un modificateur de notification de disposition 'Alternative-not-available') et si le receveur détient toujours les données originales envoyées, il devrait afficher ou traiter les données originales et envoyer une réponse MDN indiquant la disposition finale de ces données. Donc, la réponse à une indication 'Alternative-not-available' peut être une notification de disposition réussie.

Si le renvoi indique que les données de remplacement ne sont plus disponibles (en incluant un modificateur de notification de disposition 'Alternative-not-available') et si le receveur a éliminé les données originales envoyées, il DEVRAIT :

(a) afficher ou traiter le message d’échec reçu, OU

(b) construire et afficher un message indiquant que les données du message ont été perdues, indiquant de préférence l’envoyeur, l’heure, le sujet, l’identifiant de message et les autres informations qui peuvent aider l’utilisateur receveur à identifier le message manquant,

et envoyer une réponse de disposition de message indiquant une disposition de message finale de "supprimé".

4. En-tête Content-alternative:

L’en-tête 'Content-alternative:' est un en-tête MIME qui peut être attaché à une partie de corps MIME pour indiquer la disponibilité de certaines formes de remplacement des données qu’il contient. Cet en-tête n’indique pas, par lui-même, comment on peut accéder à la forme de remplacement des données.

En utilisant la notation ABNF de la [RFC2234], la syntaxe d’un en-tête 'Content-alternative' est définie comme :

Content-alternative-header = "Content-alternative" ":" Alternative-feature-expression

Alternative-feature-expression = <comme défini pour 'Filter' par la [RFC2533]>

Plus d’un en-tête 'Content-alternative:' peut être appliqué à une partie de corps MIME, auquel cas, chacun est pris pour décrire un format séparé de données de remplacement qui est disponible.

Un en-tête Content-alternative est utilisé avec des données encapsulées dans MIME, et est interprété dans ce contexte. L’intention est d’indiquer de possibles variations de ces données, et il n’est pas nécessaire que ce soit une description autonome complète de données disponibles spécifiques. Suffisamment d’informations devraient être fournies pour qu’un receveur soit capable de décider si la solution de remplacement ainsi décrite (a) va vraisemblablement être une amélioration par rapport aux données actuellement fournies, et (b) seront vraisemblablement traitables par le receveur.

Donc, quand il interprète une valeur d’en-tête Content-alternative, un receveur peut supposer que les caractéristiques non explicitement mentionnées ne sont pas différentes dans la solution de remplacement indiquée de celle des données fournies. Par exemple, si un en-tête Content-alternative ne mentionne pas un type de contenu MIME de remplacement, le receveur peut supposer que la solution de remplacement disponible utilise le même type de contenu que les données fournies.

Voir aussi l’exemple du paragraphe 8.4.

5. En-tête de message Original-Message-ID

L’en-tête 'Original-Message-ID' (identifiant du message d’origine) est utilisé pour corréler tout message de réponse ou renvoyé avec le message original auquel il se rapporte (voir aussi les paragraphes 3.2.3 et 3.3). Un renvoi est distinct du message original, il DOIT donc avoir sa propre valeur unique d’identifiant de message (selon le paragraphe 3.6.4 de la [RFC2822]).

La syntaxe de cet en-tête est :

"Original-Message-ID" ":" msg-id

où 'msg-id' est défini par la [RFC2822] comme :

msg-id = "<" id-left "@" id-right ">"

La valeur 'msg-id' donnée doit être identique à celle fournie dans l’en-tête Message-ID: du message original pour lequel le message actuel est une réponse ou un renvoi.

6. Extension MDN pour des données de remplacement

On définit ici deux extensions au protocole de notification de disposition de message (MDN) [RFC2298] pour permettre à un envoyeur d’indiquer qu’il est prêt à envoyer des formats de données de message de remplacement, et pour permettre à un receveur d’indiquer une préférence pour un certain format de remplacement.

L’indication des solutions de remplacement disponibles ou préférées n’est pas couverte ici. Cette fonctionnalité est fournie par l’en-tête MIME 'Content-alternative' (voir à la Section 4 “En-tête 'Content-alternative'") et dans la [RFC2530].

6.1 Indication qu’il est prêt à envoyer les données de remplacement

Un envoyeur qui souhaite indiquer qu’il est prêt à envoyer des formats de données de message de remplacement doit demander une réponse MDN en utilisant l’en-tête MDN 'Disposition-Notification-To:' [RFC2298].

La demande MDN est accompagnée d’un en-tête 'Disposition-Notification-Options:' qui contient le paramètre 'Alternative-available' avec une valeur d’importance de 'facultatif’. (La signification de 'facultatif' est que les agents receveurs qui ne connaissent pas cette option ne génèrent pas de réponse d’échec inappropriée.)

La présente spécification définit une valeur pour 'attribut' à utiliser dans un en-tête MDN 'Disposition-Notification-Options:' [RFC2298] :

attribut =/ "Alternative-available"

Donc, un envoyeur inclut les en-têtes suivants pour indiquer que des données de remplacement de message sont disponibles :

Disposition-Notification-To: <adresse de l’envoyeur>

Disposition-Notification-Options:

Alternative-available = facultatif, <durée de vie>

où <durée de vie> est "transitoire" ou "permanent", indiquant si les données de remplacement seront rendues disponibles juste pour un court instant ou pour une durée indéfinie. Une valeur de "permanent" indique que les données sont détenues pour une mémorisation de long terme et qu’on peut s’attendre à ce qu’elles soient disponibles pendant au moins plusieurs jours, et probablement des semaines ou des mois. Une valeur de "transitoire" indique que les données de remplacement peuvent être éliminées à tout moment, bien qu’elles doivent normalement être détenues pour la durée attendue d’une transaction de message.

Note : le paramètre <durée de vie> est fourni pour aider les receveurs à faible capacité de mémoire (qui ne sont pas capables de mémoriser les données reçues) à éviter des pertes d’informations à travers les demandes de format de données de remplacement qui peuvent devenir indisponibles.

Un message envoyé avec une demande de MDN avec une option 'Alternative-available' DOIT aussi contenir un champ d’en-tête 'Message-ID:' [RFC2822].

6.2 Indication d’une préférence pour les données de remplacement

La spécification MDN [RFC2298] définit un certain nombre d’options de disposition de message qui peuvent être rapportées par le receveur d’un message :

disposition-type = "affiché" / "réparti" / "traité" / "supprimé" / "refusé" / "échec"

disposition-modifier = ( "erreur" / "avertissement" ) / ( "remplacé" / "expiré" / "boîte-aux-lettres-terminée" )
/ disposition-modifier-extension

La présente spécification définit une valeur supplémentaire pour 'disposition-modifier-extension' :

disposition-modifier-extension =/ "Alternative-préferée"

Lorsque un receveur demande qu’un format de remplacement soit envoyé, il envoie un message notification de disposition contenant le champ disposition suivant :

Disposition: <mode-action>/<mode-envoi>, supprimé/alternative-préférée

Par exemple, une réponse générée automatiquement pourrait contenir :

Disposition: action-automatique/MDN-envoyée-automatiquement, supprimé/alternative-préférée

Une réponse MDN contenant un modificateur de disposition 'alternative-préférée' DOIT aussi contenir un champ 'Original-message-ID:' [RFC2298] avec la valeur de 'Message-ID:' provenant du message original.

Une réponse MDN qui contient un modificateur de disposition 'alternative-préférée' DEVRAIT aussi contenir un champ 'Caractéristiques-de-support-acceptées:' [RFC2530] indiquant les capacités que l’envoyeur devrait utiliser pour choisir une forme de remplacement des données du message. Si ce champ n’est pas fourni, l’envoyeur devrait supposer des capacités de caractéristiques de base. Les capacités de receveur fournies avec une notification de disposition alternative-préférée NE DOIVENT PAS être mises en antémémoire : elles ne peuvent s’appliquer qu’à la transaction en cours.

6.3 Indication que les données de remplacement ne sont plus disponibles

Un envoyeur qui reçoit une demande pour des données de remplacement qui ne sont plus disponibles, ou qui est incapable de fournir les données de remplacement qui correspondent aux capacités du receveur, DOIT répondre en indiquant ce fait, et en envoyant un message contenant les données qui décrivent l’échec.

Un tel message DOIT spécifier l’en-tête MDN 'Disposition-Notification-To:' de la [RFC2298], accompagné d’un en-tête 'Disposition-Notification-Options:' contenant le paramètre 'Alternative-non-disponible' avec une valeur d’importance de 'exigé'.

La présente spécification définit une valeur pour 'attribut' à utiliser dans un en-tête MDN 'Disposition-Notification-Options:' de la [RFC2298] :

attribut =/ "Alternative-non-disponible"

Donc, un envoyeur inclut les en-têtes suivants pour indiquer que les données de remplacement de message précédemment offertes ne sont plus disponibles :

Disposition-Notification-To: <adresse-de-l’envoyeur>

Disposition-Notification-Options: Alternative-non-disponible=exigé,(VRAI)

Un message envoyé avec une demande d’une MDN avec une option 'Alternative-non-disponible' DOIT aussi contenir un en-tête 'Original-message-ID:' de la Section 5 contenant la valeur provenant de l’en-tête 'Message-ID:' du message original.

6.4 Indication de perte des données d’origine

La présente spécification définit une valeur supplémentaire pour 'disposition-modifier-extension':

disposition-modifier-extension = / "original-perdu"

Lorsque un receveur perd les données de message parce qu’il manque de mémoire pour mémoriser l’original alors qu’il attend que des données de remplacement soient envoyées, il envoie une notification de disposition de message contenant le champ suivant :

Disposition: <mode-action>/<mode-envoi>, supprimé/original-perdu

Par exemple, une réponse générée automatiquement pourrait contenir :

Disposition: action-automatique/MDN-envoyée-automatiquement, supprimé/original-perdu

Une réponse MDN contenant un modificateur de disposition 'original-perdu' DOIT aussi contenir un champ 'Original-message-ID:' [RFC2298] avec la valeur de 'Message-ID:' provenant du message renvoyé, ou du message original (si aucun renvoi n’a été reçu).

6.5 Envoi automatique de réponses MDN

En envoyant une réponse MDN qui demande des données de remplacement, les aspects de sécurité mentionnés aux paragraphes 2.1 et 6.2 de la [RFC2298] concernant les réponses MDN automatiques doivent être respectés. En particulier, un système capable d’effectuer la négociation de contenu DOIT avoir une option pour que son utilisateur désactive les réponses de négociation, soit en général, soit message par message, soit les deux.

7. Considérations pour la télécopie Internet

La télécopie Internet est une application qui utilise la messagerie électronique pour échanger des images de document (voir la [RFC2305] et la [RFC2532]).

Les deux parties envoyeur et receveur de la présente spécification impliquent l’usage des expressions de caractéristiques du support. Dans le contexte de la télécopie Internet, toutes ces expressions DEVRAIENT employer les étiquettes de caractéristiques définies par le "Schéma de caractéristique de contenu pour la télécopie Internet" [RFC2879]. Dans un contexte de messagerie électronique plus large, toute caractéristique de support valide PEUT être utilisée.

Pour la télécopie Internet [RFC2305], "image/tiff" est le type de contenu supposé pour les données du message. En particulier, tous les appareils de télécopie Internet sont supposés être capables d’envoyer et recevoir les capacités du profil S de TIFF (Section 3 de la [RFC2301]). Lors d’une communication entre des appareils de télécopie Internet, cette capacité peut être présumée. Mais quand on a affaire à des appareils qui vont au delà de ces capacités définies pour la télécopie Internet (par exemple, des agents génériques de messagerie électronique avec des capacités de télécopie) il serait préférable de ne pas présupposer les capacités de télécopie, et que les parties à la négociation soient explicites sur cet aspect de leurs capacités.

Il serait préférable même que les appareils de télécopie Internet ne présupposent pas qu’ils sont en communication avec un autre de ces appareils. Lorsque on utilise la messagerie Internet, il n’y a pas de façon fiable d’établir ce fait. Donc, pour tout appareil de télécopie Internet dont on peut raisonnablement s’attendre à ce qu’il échange des messages avec tout autre agent de messagerie électronique, il est RECOMMANDÉ que les capacités de télécopie Internet (comme le traitement du format de base image/tiff) ne soient pas supposées mais déclarées explicitement.

En particulier, l’en-tête 'Media-Accept-Features:' (caractéristiques acceptées du support) dans les réponses MDN de receveurs DEVRAIENT explicitement indiquer (type="image/tiff") et les capacités TIFF de base, plutôt que de juste supposer qu’elles sont comprises.

8. Exemples

8.1 Envoi d’images de télécopie Internet améliorée

Un envoyeur de télécopie Internet a une image de profil F (A4, 400x400dpi, MMR) à envoyer à un receveur. La configuration de base pour la télécopie Internet est 200x200 dpi et la compression d’image MH.

Message initial de l’envoyeur :

Date: mercredi 20 septembre 1995 00:18:00 -0400 (EDT)

From: Jane Sender <Jane_Sender@example.com>

Message-Id: <199509200019.12345@example.com>

Subject: Négociation de contenu de télécopie Internet en mode plein

To: Tom Recipient <Tom_Recipient@example.org>

Disposition-Notification-To: Jane_Sender@example.com

Disposition-Notification-Options: Alternative-available=optional,permanent

MIME-Version: 1.0

Content-Type: multipart/mixed; boundary="RAA14128.773615765/ example.com"

--RAA14128.773615765/ example.com

Content-type: image/tiff

Content-Transfer-Encoding: base64

Content-features:

(& (color=Binary)

(image-file-structure=TIFF-minimal)

(dpi=200)

(dpi-xyratio=1)

(paper-size=A4)

(image-coding=MH)

(MRC-mode=0)

(ua-media=stationery) )

Content-alternative:

(& (color=Binary)

(image-file-structure=TIFF-limited)

(dpi=400)

(dpi-xyratio=1)

(paper-size=A4)

(image-coding=MMR)

(MRC-mode=0)

(ua-media=stationery) )

[Le message TIFF-FX Profile-S vient ici]

--RAA14128.773615765/ example.com--

Le receveur envoie la réponse MDN au message initial :

Date: mercredi 20 septembre 1995 00:19:00 -0400 (EDT)

From: Tom Recipient <Tom_Recipient@example.org>

Message-Id: <199509200020.12345@example.org>

Subject: Re: Négociation de contenu de télécopie Internet en mode plein

To: Jane Sender <Jane_Sender@example.com>

MIME-Version: 1.0

Content-Type: multipart/report;

report-type=disposition-notification;

boundary="RAA14128.773615766/example.org"

--RAA14128.773615766/example.org

Le message envoyé le 20 septembre 1995 à 00:18:00 -0400 (EDT) à Tom Recipient <Tom_Recipient@example.org> avec pour sujet "Négociation de contenu de télécopie Internet en mode plein" a été reçu. Une forme de remplacement des données du message est demandée.

--RAA14128.773615766/example.org

Content-Type: message/disposition-notification

Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode

Original-Recipient: rfc822;Tom-Recipient@example.org

Final-Recipient: rfc822;Tom-Recipient@example.org

Original-Message-ID: <199509200019.12345@example.com>

Disposition: automatic-action/MDN-sent-automatically;

deleted/alternative-preferred

Media-Accept-Features:

(& (type="image/tiff")

(color=Binary)

(image-file-structure=TIFF)

(| (& (dpi=200) (dpi-xyratio=200/100) )

(& (dpi=200) (dpi-xyratio=1) )

(& (dpi=400) (dpi-xyratio=1) ) )

(| (image-coding=[MH,MR,MMR])

(& (image-coding=JBIG)

(image-coding-constraint=JBIG-T85)

(JBIG-stripe-size=128) ) )

(MRC-mode=0)

(paper-size=[A4,B4])

(ua-media=stationery) )

--RAA14128.773615766/example.org--

Message de l”envoyeur avec contenu amélioré :

Date: mercredi 20 septembre 1995 00:21:00 -0400 (EDT)

From: Jane Sender <Jane_Sender@example.com>

Message-Id: <199509200021.12345@example.com>

Original-Message-Id: <199509200019.12345@example.com>

Subject: Négociation de contenu de télécopie Internet en mode plein

To: Tom Recipient <Tom_Recipient@example.org>

Disposition-Notification-To: Jane_Sender@example.com

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="RAA14128.773615768/ example.com"

--RAA14128.773615768/ example.com

Content-type: image/tiff

Content-Transfer-Encoding: base64

[Le message TIFF-FX profil-F vient ici]

--RAA14128.773615768/ example.com--

Le receveur envoie une confirmation MDN de contenu de message amélioré :

Date: mercredi 20 septembre 1995 00:22:00 -0400 (EDT)

From: Tom Recipient <Tom_Recipient@example.org>

Message-Id: <199509200022.12345@example.org>

Subject: Re: Négociation de contenu de télécopie Internet en mode plein

To: Jane Sender <Jane_Sender@example.com>

MIME-Version: 1.0

Content-Type: multipart/report;

report-type=disposition-notification;

boundary="RAA14128.773615769/example.org"

--RAA14128.773615769/example.org

Le message envoyé le 20 septembre 1995 à 00:21:00 -0400 (EDT) à Tom Recipient <Tom_Recipient@example.org> avec le sujet " Négociation de contenu de télécopie Internet en mode plein" a été traité en télécopie Internet mode plein.

--RAA14128.773615769/example.org

Content-Type: message/disposition-notification

Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode

Original-Recipient: rfc822;Tom-Recipient@example.org

Final-Recipient: rfc822;Tom-Recipient@example.org

Original-Message-ID: <199509200021.12345@example.com>

Disposition: automatic-action/MDN-sent-automatically; processed

Media-Accept-Features:

(& (type="image/tiff")

(color=Binary)

(image-file-structure=TIFF)

(| (& (dpi=200) (dpi-xyratio=200/100) )

(& (dpi=200) (dpi-xyratio=1) )

(& (dpi=400) (dpi-xyratio=1) ) )

(| (image-coding=[MH,MR,MMR])

(& (image-coding=JBIG)

(image-coding-constraint=JBIG-T85)

(JBIG-stripe-size=128) ) )

(MRC-mode=0)

(paper-size=[A4,B4])

(ua-media=stationery) )

--RAA14128.773615769/example.org--

8.2 Télécopie Internet avec données initiales utilisables

Cet exemple montre comment dans l’exemple précédent le second transfert entre les systèmes et les suivants pourraient être conduits. En utilisant les connaissances acquises de l’échange précédent, l’envoyeur inclut des données de profil-F avec son premier contact.

Message initial de l’envoyeur :

Date: mercredi 20 septembre 1995 00:19:00 -0400 (EDT)

From: Jane Sender <Jane_Sender@example.com>

Message-Id: <199509200019.12345@example.com>

Subject: Négociation de contenu de télécopie Internet en mode plein

To: Tom Recipient <Tom_Recipient@example.org>

Disposition-Notification-To: Jane_Sender@example.com

Disposition-Notification-Options:

Alternative-available=optional,permanent

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="RAA14128.773615765/ example.com"

--RAA14128.773615765/ example.com

Content-type: image/tiff

Content-Transfer-Encoding: base64

Content-features:

(& (color=Binary)

(image-file-structure=TIFF-limited)

(dpi=400)

(dpi-xyratio=1)

(paper-size=A4)

(image-coding=MMR)

(MRC-mode=0)

(ua-media=stationery) )

Content-alternative:

(& (color=Binary)

(image-file-structure=TIFF-minimal)

(dpi=200)

(dpi-xyratio=1)

(paper-size=A4)

(image-coding=MH)

(MRC-mode=0)

(ua-media=stationery) )

[Le message TIFF-FX Profil-F vient ici]

--RAA14128.773615765/ example.com--

Le receveur envoie une confirmation MDN du contenu de message reçu :

Date: mercredi 20 septembre 1995 00:22:00 -0400 (EDT)

From: Tom Recipient <Tom_Recipient@example.org>

Message-Id: <199509200022.12345@example.org>

Subject: Re: Négociation de contenu de télécopie Internet en mode plein

To: Jane Sender <Jane_Sender@example.com>

MIME-Version: 1.0

Content-Type: multipart/report;

report-type=disposition-notification;

boundary="RAA14128.773615769/example.org"

--RAA14128.773615769/example.org

Le message envoyé le 20 septembre 1995 à 00:19:00 -0400 (EDT) à Tom Recipient <Tom_Recipient@example.org> avec le sujet "Transmission d’image de télécopie Internet en mode plein" a été traité en télécopie Internet mode plein.

--RAA14128.773615769/example.org

Content-Type: message/disposition-notification

Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode

Original-Recipient: rfc822;Tom-Recipient@example.org

Final-Recipient: rfc822;Tom-Recipient@example.org

Original-Message-ID: <199509200021.12345@example.com>

Disposition: automatic-action/MDN-sent-automatically; processed

Media-Accept-Features:

(& (type="image/tiff")

(color=Binary)

(image-file-structure=TIFF)

(| (& (dpi=200) (dpi-xyratio=200/100) )

(& (dpi=200) (dpi-xyratio=1) )

(& (dpi=400) (dpi-xyratio=1) ) )

(| (image-coding=[MH,MR,MMR])

(& (image-coding=JBIG)

(image-coding-constraint=JBIG-T85)

(JBIG-stripe-size=128) ) )

(MRC-mode=0)

(paper-size=[A4,B4])

(ua-media=stationery) )

--RAA14128.773615769/example.org--

8.3 Négociation de capacités inférieures du receveur

Dans cet exemple, l’envoyeur a incorrectement supposé que le receveur a une capacité supérieure, et doit renvoyer des capacités de données inférieures en réponse à la réponse du receveur montrant une capacité moindre.

Une télécopie Internet envoie une image de profil-F (A4, 400x400 dpi, MMR). Lorsque le receveur ne peut pas traiter cela, il revient au profil-S de base. Comme c’est un format de base, il n’est pas nécessaire de déclarer cette capacité avec le message original. Lorsque un receveur se trouve face à des données provenant d’un envoyeur négociateur qu’il ne peut pas traiter, il ne peut pas faire mieux que répondre avec une description de ses capacités réelles et laisser l’envoyeur déterminer le résultat.

Message initial de l’envoyeur :

Date: mercredi 20 septembre 1995 00:18:00 -0400 (EDT)

From: Jane Sender <Jane_Sender@example.com>

Message-Id: <199509200019.12345@example.com>

Subject: Échec de négociation de télécopie Internet en mode plein

To: Tom Recipient <Tom_Recipient@example.org>

Disposition-Notification-To: Jane_Sender@example.com

Disposition-Notification-Options:

Alternative-available=optional,permanent

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="RAA14128.773615765/ example.com"

--RAA14128.773615765/ example.com

Content-type: image/tiff

Content-Transfer-Encoding: base64

Content-features:

(& (color=Binary)

(image-file-structure=TIFF-limited)

(dpi=400)

(dpi-xyratio=1)

(paper-size=A4)

(image-coding=MMR)

(MRC-mode=0)

(ua-media=stationery) )

[Le message TIFF-FX Profil-F vient ici]

--RAA14128.773615765/ example.com--

Le receveur envoie la réponse MDN au message initial :

Date: mercredi 20 septembre 1995 00:19:00 -0400 (EDT)

From: Tom Recipient <Tom_Recipient@example.org>

Message-Id: <199509200020.12345@example.org>

Subject: Re: Échec de négociation de télécopie Internet en mode plein

To: Jane Sender <Jane_Sender@example.com>

MIME-Version: 1.0

Content-Type: multipart/report;

report-type=disposition-notification;

boundary="RAA14128.773615766/example.org"

--RAA14128.773615766/example.org

Le message envoyé le 20 septembre 1995 à 00:18:00 -0400 (EDT) à Tom Recipient <Tom_Recipient@example.org> avec l’objet "Négociation de contenu de télécopie Internet en mode plein" a été reçu. Une forme de remplacement des données du message est demandée.

--RAA14128.773615766/example.org

Content-Type: message/disposition-notification

Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode

Original-Recipient: rfc822;Tom-Recipient@example.org

Final-Recipient: rfc822;Tom-Recipient@example.org

Original-Message-ID: <199509200019.12345@example.com>

Disposition: automatic-action/MDN-sent-automatically;

deleted/alternative-preferred

Media-Accept-Features:

(& (type="image/tiff")

(color=Binary)

(image-file-structure=TIFF-minimal)

(dpi=200)

(dpi-xyratio=1)

(paper-size=A4)

(image-coding=MH)

(MRC-mode=0)

(ua-media=stationery) )

--RAA14128.773615766/example.org--

Message de l’envoyeur avec contenu de base :

Date: mercredi 20 septembre 1995 00:21:00 -0400 (EDT)

From: Jane Sender <Jane_Sender@example.com>

Message-Id: <199509200021.12345@example.com>

Original-Message-Id: <199509200019.12345@example.com>

Subject: Transmission d’image de télécopie Internet en mode plein

To: Tom Recipient <Tom_Recipient@example.org>

Disposition-Notification-To: Jane_Sender@example.com

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="RAA14128.773615768/ example.com"

--RAA14128.773615768/ example.com

Content-type: image/tiff

Content-Transfer-Encoding: base64

[Le message TIFF-FX profil-S vient ici]

--RAA14128.773615768/ example.com--

Le receveur envoie une confirmation MDN de contenu de message appauvri :

Date: mercredi 20 septembre 1995 00:22:00 -0400 (EDT)

From: Tom Recipient <Tom_Recipient@example.org>

Message-Id: <199509200022.12345@example.org>

Subject: Re: Transmission d’image de télécopie Internet en mode plein

To: Jane Sender <Jane_Sender@example.com>

MIME-Version: 1.0

Content-Type: multipart/report;

report-type=disposition-notification;

boundary="RAA14128.773615769/example.org"

--RAA14128.773615769/example.org

Le message envoyé le 20 septembre 1995 à 00:21:00 -0400 (EDT) à Tom Recipient <Tom_Recipient@example.org> avec l’objet "Transmission d’image de télécopie Internet en mode plein" a été traité en télécopie Internet mode plein.

--RAA14128.773615769/example.org

Content-Type: message/disposition-notification

Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode

Original-Recipient: rfc822;Tom-Recipient@example.org

Final-Recipient: rfc822;Tom-Recipient@example.org

Original-Message-ID: <199509200021.12345@example.com>

Disposition: automatic-action/MDN-sent-automatically; processed

Media-Accept-Features:

(& (color=Binary)

(image-file-structure=TIFF-minimal)

(dpi=200)

(dpi-xyratio=1)

(paper-size=A4)

(image-coding=MH)

(MRC-mode=0)

(ua-media=stationery) )

--RAA14128.773615769/example.org--

8.4 Envoi d’un type de contenu de remplacement

Comme on l’a noté à la Section 4, l’envoyeur peut offrir les données en utilisant un type de contenu MIME différent. Cet exemple montre une image de profil-F (A4, 400x400 dpi, MMR) et un document PDF à couleur limitée offert comme alternative à une image/TIFF de base.

Message initial de l’envoyeur :

(Noter que le type de contenu MIME n’est pas spécifié pour la solution de remplacement image/tiff, qui est la même que celle fournie, mais est mentionnée pour la solution de remplacement application/pdf.)

Date: mercredi 20 septembre 1995 00:18:00 -0400 (EDT)

From: Jane Sender <Jane_Sender@example.com>

Message-Id: <199509200019.12345@example.com>

Subject: Négociation de contenu de télécopie Internet en mode plein

To: Tom Recipient <Tom_Recipient@example.org>

Disposition-Notification-To: Jane_Sender@example.com

Disposition-Notification-Options: Alternative-available=optional,permanent

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="RAA14128.773615765/ example.com"

--RAA14128.773615765/ example.com

Content-type: image/tiff

Content-Transfer-Encoding: base64

Content-features:

(& (color=Binary)

(image-file-structure=TIFF-minimal)

(dpi=200)

(dpi-xyratio=1)

(paper-size=A4)

(image-coding=MH)

(MRC-mode=0)

(ua-media=stationery) )

Content-alternative:

(& (color=Binary)

(image-file-structure=TIFF-limited)

(dpi=400)

(dpi-xyratio=1)

(paper-size=A4)

(image-coding=MMR)

(MRC-mode=0)

(ua-media=stationery) )

Content-alternative:

(& (type="application/pdf")

(color=Limited)

(dpi=400)

(paper-size=A4)

(ua-media=stationery) )

[Le message TIFF-FX Profil-S vient ici]

--RAA14128.773615765/ example.com--

Le receveur envoie une réponse MDN au message initial :

(Noter que cette réponse indique la capacité à traiter les types de contenu MIME PDF mais seulement avec la couleur binaire.)

Date: mercredi 20 septembre 1995 00:19:00 -0400 (EDT)

From: Tom Recipient <Tom_Recipient@example.org>

Message-Id: <199509200020.12345@example.org>

Subject: Re: Négociation de contenu de télécopie Internet en mode plein

To: Jane Sender <Jane_Sender@example.com>

MIME-Version: 1.0

Content-Type: multipart/report;

report-type=disposition-notification;

boundary="RAA14128.773615766/example.org"

--RAA14128.773615766/example.org

Le message envoyé le 20 septembre 1995 à 00:18:00 -0400 (EDT) à Tom Recipient <Tom_Recipient@example.org> avec pour sujet "Négociation de contenu de télécopie Internet en mode plein" a été reçu. Une autre forme des données du message est demandée.

--RAA14128.773615766/example.org

Content-Type: message/disposition-notification

Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode

Original-Recipient: rfc822;Tom-Recipient@example.org

Final-Recipient: rfc822;Tom-Recipient@example.org

Original-Message-ID: <199509200019.12345@example.com>

Disposition: automatic-action/MDN-sent-automatically; deleted/alternative-preferred

Media-Accept-Features:

(| (& (type="image/tiff")

(color=Binary)

(image-file-structure=TIFF-minimal)

(dpi=200)

(dpi-xyratio=1)

(image-coding=MH)

(MRC-mode=0)

(paper-size=A4)

(ua-media=stationery) )

(& (type="application/pdf")

(color=Binary)

(dpi-xyratio=1)

(dpi=[200,400])

(paper-size=[A4,B4])

(ua-media=stationery) ) )

--RAA14128.773615766/example.org--

Renvoi avec un type de contenu de remplacement :

Date: mercredi 20 septembre 1995 00:21:00 -0400 (EDT)

From: Jane Sender <Jane_Sender@example.com>

Message-Id: <199509200021.12345@example.com>

Original-Message-Id: <199509200019.12345@example.com>

Subject: Négociation de contenu de télécopie Internet en mode plein

To: Tom Recipient <Tom_Recipient@example.org>

Disposition-Notification-To: Jane_Sender@example.com

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="RAA14128.773615768/ example.com"

--RAA14128.773615768/ example.com

Content-type: application/pdf

Content-Transfer-Encoding: base64

[Les données en PDF viennent ici]

--RAA14128.773615768/ example.com--

Le receveur envoie la confirmation MDN du contenu de message amélioré :

(indiquant aussi la capacité PDF pour les messages futurs.)

Date: mercredi 20 septembre 1995 00:22:00 -0400 (EDT)

From: Tom Recipient <Tom_Recipient@example.org>

Message-Id: <199509200022.12345@example.org>

Subject: Re: Négociation de contenu de télécopie Internet en mode plein

To: Jane Sender <Jane_Sender@example.com>

MIME-Version: 1.0

Content-Type: multipart/report;

report-type=disposition-notification;

boundary="RAA14128.773615769/example.org"

--RAA14128.773615769/example.org

Le message envoyé le 20 septembre 1995 à 00:21:00 -0400 (EDT) à Tom Recipient <Tom_Recipient@example.org> avec le sujet " Transmission d’image FAX Internet en mode plein " a été traité en mode plein FAX Internet.

--RAA14128.773615769/example.org

Content-Type: message/disposition-notification

Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode

Original-Recipient: rfc822;Tom-Recipient@example.org

Final-Recipient: rfc822;Tom-Recipient@example.org

Original-Message-ID: <199509200021.12345@example.com>

Disposition: automatic-action/MDN-sent-automatically; processed

Media-Accept-Features:

(| (& (type="image/tiff")

(color=Binary)

(image-file-structure=TIFF-minimal)

(dpi=200)

(dpi-xyratio=1)

(image-coding=MH)

(MRC-mode=0)

(paper-size=A4)

(ua-media=stationery) )

(& (type="application/pdf")

(color=Binary)

(dpi-xyratio=1)

(dpi=[200,400])

(paper-size=[A4,B4])

(ua-media=stationery) ) )

--RAA14128.773615769/example.org--

9. Considérations relatives à l’IANA

9.1 Nouveaux en-têtes de message

La présente spécification définit de nouveaux en-têtes de message email/MIME :

Content-alternative

Original-Message-ID

À ce titre, comme il n’y a pas de registre des en-têtes de messagerie électronique, c’est une mise à jour des spécifications des [RFC2822] et [RFC 2045].

9.2 Extensions MDN

La présente spécification définit des extensions au protocole de notification de disposition de message (MDN). Les paragraphes ci-dessous sont les gabarits d’enregistrement de ces extensions, comme requis par la section 10 de la [RFC2298].

9.2.1 Option de notification 'Alternative-available'

(a) Nom de l’option de notification de disposition : Alternative-available

(b) Syntaxe : (voir le paragraphe 6.1 de ce document)

(c) Codage de caractères : Seuls les caractères US-ASCII sont utilisés

(d) Sémantique : (voir le paragraphe 6.1 de ce document)

9.2.2 Option de notification 'Alternative-not-available'

(a) Nom de l’option de notification de disposition : Alternative-not-available

(b) Syntaxe : (voir le paragraphe 6.1 de ce document)

(c) Codage de caractères : Seuls les caractères US-ASCII sont utilisés

(d) Sémantique : (voir le paragraphe 6.3 de ce document)

9.2.3 Modificateur de disposition 'Alternative-preferred'

(a) Nom du modificateur de disposition : Alternative-preferred

(b) Sémantique : (voir le paragraphe 6.2 de ce document)

9.2.4 Modificateur de disposition 'Original-lost'

(a) Nom du modificateur de disposition : Original-lost

(b) Sémantique : (voir le paragraphe 6.4 de ce document)

10. Considérations d’internationalisation

La présente spécification traite des échanges de protocole entre les agents d’utilisateur de messagerie, et à ce titre ne traite pas principalement de texte lisible par l’homme. Mais tous les agents d’utilisateur ne peuvent pas traiter automatiquement les éléments de protocole définis ici, et peuvent tenter d’afficher du texte provenant des éléments de protocole à l’utilisateur.

Le principal candidat pour ce traitement est le texte qui accompagne une réponse de notification de disposition qui demande des informations de remplacement. En utilisation normale, la conception du protocole assure que le receveur peut traiter automatiquement cette réponse ; exceptionnellement, un agent receveur peut l’afficher à un utilisateur.

11. Considérations pour la sécurité

Les considérations pour la sécurité de la présente spécification peuvent être divisées en deux domaines principaux :

o Problèmes de confidentialité avec la génération de réponse MDN automatique : voir le paragraphe 6.5 de ce document, et la section Considérations pour la sécurité de la [RFC2298].

o Risques de négociation : voir la section considérations sur la sécurité de transaction. Si des données de remplacement arrivent ensuite, elles peuvent être ignorées ou éventuellement affichées ou imprimées. Une MDN d’achèvement réussie peut être renvoyée à l’envoyeur.

12. Remerciements

La structure de base de la négociation décrite a été documentée pour la première fois dans un projet de M. Toru Maeda de Canon.

Des commentaires utiles sur des projets antérieurs ont été fournis par M. Hiroshi Tamura, Ted Hardie et Larry Masinter.

13. Références

[RFC1891] K. Moore, "Extension de service SMTP pour les notifications d'état de livraison", janvier 1996. (Obsolète, voir RFC3461) (P.S.)

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

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

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

[RFC2295] K. Holtman, A. Mutz, "Négociation de contenu transparent dans HTTP", mars 1998. (Expérimentale)

[RFC2298] R. Fajman, "Format de message extensible pour les notifications de disposition de message", mars 1998. (Obsolète, voir RFC3798) (P.S.)

[RFC2301] L. McIntyre et autres, "Format de fichier pour la télécopie Internet", mars 1998. (Obsolète, voir RFC3949) (P.S.)

[RFC2305] K. Toyoda, H. Ohno, J. Murai, D. Wing, "Mode simple de télécopie utilisant la messagerie Internet", mars 1998. (Obsolète, voir RFC3965) (P.S.)

[RFC2506] K. Holtman, A. Mutz, T. Hardie, "Procédure d'enregistrement d'étiquette de caractéristique de support", mars 1999. (BCP0031)

[RFC2530] D. Wing, "Indication des caractéristiques de support acceptées en utilisant les extensions de DSN et de MDN", mars 1999. (P.S.)

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

[RFC2533] G. Klyne, "Syntaxe de description des ensembles de caractéristiques des supports", mars 1999. (MàJ par RFC2738, RFC2938) (P.S.)

[RFC2542] L. Masinter, "Terminologie et objectifs de la télécopie Internet", mars 1999. (Information)

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

[RFC2703] G. Klyne, "Cadre de négociation de contenu indépendant du protocole", septembre 1999. (Information)

[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. (STD 11, Obsolète, voir RFC5322)

[RFC2879] G. Klyne, L. McIntyre, "Schéma de caractéristique de contenu pour télécopie Internet (v2)", août 2000. (P.S.)

[RFC2913] G. Klyne, "Types de contenu MIME dans les expressions de caractéristiques de support", septembre 2000. (P.S.)

[RFC2938] G. Klyne, L. Masinter, "Identification des caractéristiques de support composite", septembre 2000. (P.S.)

[21] Klyne, G. and D. Crocker, "Timely Delivery for Facsimile Using Internet Mail", Non publiée.

Appendice A Questions de mise en œuvre

Cette section n’est pas une partie normative de cette spécification. Elle expose plutôt certains des problèmes qui ont été considérés durant sa conception d’une façon dont nous espérons qu’elle sera utile à la mise en œuvre.

A.1 État du receveur

Le besoin de conserver une certaine forme d’état des informations est probablement la plus grande implication pour les mises en œuvre de cette proposition par rapport aux agents d’utilisateur de messagerie électronique standard chez le receveur lorsque le contenu est négocié.

Par "état de receveur", on entend qu’un receveur a besoin de se souvenir qu’il a reçu un message initial ET qu’il a demandé une forme de remplacement des données. Sans cela, lorsque un receveur répond par une demande d’un format de données de remplacement, il y a une possibilité (si la réponse n’atteint pas l’envoyeur) que le message soit perdu en silence, en dépit du fait qu’il a été livré au MTA receveur.

La question de la conservation de l’état de receveur est particulièrement appropriée à cause de l’exigence de permettre aux systèmes à faible mémoire de participer à la négociation de contenu. À la différence de la télécopie T.30 traditionnelle, où la négociation a lieu pendant la durée d’une seule connexion, un temps plus long peut être nécessaire pour achever une négociation dans la messagerie électronique. Les informations d’état doivent être conservées pour toutes les négociations qui ont lieu à tout moment, et il n’y a pas de limite supérieure théorique au temps que cela peut durer.

Conserver l’état du receveur n’est probablement pas un problème pour les systèmes qui ont une forte capacité de mémorisation pour détenir les données de message et les informations d’état. Le reste de ce paragraphe discute les stratégies que peuvent employer les concepteurs de petits systèmes pour fixer une limite supérieure à la mémoire qui doit être réservée pour ces informations. Lorsque un receveur a réellement des contraintes de mémoire, la perte de message reste une possibilité, mais les mécanismes décrits ici devraient assurer que cela n’arrive jamais en silence.

Donc, qu’est-ce que cet "état de receveur" ? Il doit contenir, au minimum :

o le fait que les données du message ont été reçues, et que des données de remplacement ont été demandées,

o un identifiant unique de message, et

o l’heure à laquelle une demande de format de remplacement a été envoyée.

Cela permet au receveur de refaire une demande, ou de rapporter une erreur, si les données de remplacement demandées ne sont pas arrivées dans un délai raisonnable.

L’état du receveur peut aussi inclure :

o une copie des données reçues à l’origine. Cela permet au receveur d’afficher les données originales si une solution de remplacement n’est pas reçue.

o les détails du format de données fourni, et des solutions de remplacement offertes. Cela permet d’améliorer le diagnostic si les données de remplacement ne sont pas reçues.

Si un receveur d’un message avec un contenu de remplacement disponible n’a pas assez de mémoire pour contenir les nouvelles informations d’état de négociation, il peut revenir à un comportement de non négociation, accepter les données reçues et envoyer une MDN indiquant la disposition de ces données (voir les paragraphes 3.2.1, 3.2.2).

Si un système receveur manque de mémoire après être entré dans une négociation, un certain nombre d’options sont possibles :

o afficher ou imprimer les données en mémoire tampon, si c’est disponible, et achever la transaction. Si les données de remplacement arrivent ensuite, elles peuvent être ignorées ou éventuellement aussi affichées ou imprimées. Une MDN d’achèvement réussi peut être envoyée à l’envoyeur.

o éliminer toutes les données mises en mémoire tampon, et continuer d’attendre les données de remplacement. Si les données de remplacement n’arrivent pas, un message d’échec de transfert devrait être déclaré.

o interrompre le transfert et déclarer un échec de transfert de message : un message de diagnostic doit être affiché à l’utilisateur local, et une notification d’échec envoyée à l’envoyeur.

A.2 Mise en mémoire tampon des données du message par le receveur

Si un receveur est capable de mettre en mémoire tampon les données de message reçues tout en attendant une solution de remplacement, il faut le préférer parce que cela conserve l’option d’afficher ces données si la solution de remplacement n’est pas reçue (voir ci-dessus).

Des données de message partiel ne devraient pas être mises en mémoire tampon à cette fin : afficher une partie du message original n’est pas un substitut admissible à l’affichage de la totalité des données reçues. (Mais il peut être utile de conserver des données du message original à des fins de diagnostic.)

Si un receveur commence à mettre en mémoire tampon des données du message pendant la négociation, puis trouve que le message entier est trop gros pour sa mémoire, il peut choisir de revenir au "mode étendu" et afficher les données entrantes lorsque il les reçoit.

Lorsque un envoyeur indique la disponibilité de données de remplacement, il indique aussi si elles sont disponibles de façon permanente ou temporaire. L’intention de cela est que si les données de remplacement sont temporaires, un receveur ne devrait pas éliminer les données originales reçues. Si nécessaire, il devrait simplement afficher les données originales sans demander de solution de remplacement.

A.3 État de l’envoyeur

Lorsque un envoyeur indique qu’il peut offrir un format de remplacement d’un contenu de message, il accepte une certaine responsabilité d’essayer de s’assurer que la solution de remplacement est disponible si nécessaire. Donc, le contenu du message (l’original et toute solution de remplacement) devrait être mémorisé pendant un délai raisonnable, ainsi que toutes valeurs correspondantes d’identifiant de message.

Une demande de retransmission doit être accompagnée d’une valeur d’identifiant de message d’origine (Original-Message-ID) que l’envoyeur peut utiliser pour la corréler avec les données du message envoyé à l’origine.

A.4 Temporisation de l’offre des solutions de remplacement

Si l’envoyeur opère avec un appareil qui a une forte capacité de mémorisation de message (par exemple, un lecteur de disque) et détient normalement les données pour une longue période (plusieurs jours ou semaines) il devrait alors indiquer que les données de remplacement sont disponibles en permanence (voir le paragraphe 6.1) : un receveur qui voit cela peut éliminer les données originales, supposant que l’envoyeur va vraisemblablement être capable de retransmettre.

Si l’envoyeur a une capacité de mémoire limitée, et ne sera probablement capable de conserver les données que quelques minutes ou heures, il devrait indiquer que les données de remplacement sont provisoirement disponibles (voir le 6.1). Si il y a un doute sur la capacité de l’envoyeur à conserver le contenu du message, il devrait indiquer que la disponibilité de toute solution de remplacement est transitoire.

A.5 Temporisation des capacités du receveur

On ne devrait pas supposer que les capacités du receveur déclarées durant la négociation sont indéfiniment disponibles.

En particulier, toutes les capacités de receveur déclarées dans une confirmation finale de message devraient être considérées comme définitives, même si elles diffèrent des capacités associées au message juste accepté. Elles peuvent être mémorisées pour une utilisation future.

Toutes les capacités de receveur déclarées lors d’une demande de format de remplacement devraient n’être pas mémorisées pour utilisation future, car le receveur peut avoir été sélectif quant au but dans lequel ces capacités pourraient être utilisées.

A.6 Relations avec la livraison à temps

Certaines questions de la maintenance de l’état de l’envoyeur peuvent être simplifiées si la négociation de contenu est utilisée en conjonction avec un dispositif de livraison à temps (par exemple, [21]). Si il y a une fenêtre de temps connue dans laquelle une réponse devrait être reçue, l’envoyeur peut être moins prudent pour garder les informations sur les offres en cours de données de remplacement pendant de longues durées. Un envoyeur qui exploite de cette façon la livraison à temps devrait indiquer que la solution de remplacement est provisoirement disponible.

A.7 Capacités éphémères

Les capacités éphémères peuvent poser des problèmes particuliers. Considérons le cas du choix d’une variante de contenu particulière qui peut dépendre d’un réglage éphémère.

Imaginons quelqu’un qui envoie une télécopie de base à un télécopieur couleur, indiquant qu’une solution de remplacement en couleur est disponible. Le télécopieur couleur élimine ce contenu et envoie une MDN qui dit "deleted/alternative-preferred" à l’origine du message. Il se trouve n’avoir plus d’encre de couleur. L’origine de la télécopie envoie alors un nouveau message que le télécopieur couleur ne peut pas imprimer.

Ou considérons un client de messagerie électronique dans un téléphone avec le son activé/désactivé comme un problème voisin. Lorsque le son est activé, le téléphone peut être capable d’accepter des messages vocaux par messagerie électronique.

Ce cadre de négociation n’a pas été conçu en pensant à des capacités éphémères, mais avec un peu d’attention, il peut être adaptable pour les traiter.

A.8 Situations où les MDN ne doivent pas être auto générées

En gardant à l’esprit les problèmes de confidentialité, les mises en œuvre devraient veiller à ce que les systèmes n’entrent pas automatiquement dans une négociation d’échange d’une façon qui pourrait divulguer les tenants et aboutissants du receveur sans avoir d’abord obtenu sa permission explicite. Par exemple, si la réception d’un message dépend de quelque façon que ce soit, de la présence physique de l’usager, une négociation automatique ne devrait pas être effectuée.

Bien que cela puisse ne pas poser de problème qu’un télécopieur sans surveillance puisse effectuer une négociation automatisée, il ne convient pas qu’un paquetage logiciel d’ordinateur personnel le fasse sans permission explicite car l’ordinateur personnel peut n’être allumé que lorsque l’utilisateur est présent. Cela suggère que le réglage par défaut devrait à cet égard tenir compte du type du système.

Appendice B Candidats pour d’autres améliorations

Cet appendice énumère les caractéristiques possibles de négociation de contenu qui ont été considérées, mais non incluses dans la spécification actuelle. Dans la plupart des cas, les raisons de l’exclusion ont été (a) qu’elles pourraient introduire des complexités imprévues supplémentaires, et (b) qu’aucune exigence impérieuse les justifiant n’a été trouvée.

o Indicateur de contrôle d’antémémoire des capacités du receveur. Cela dirait à l’envoyeur, ou à un autre composant du système de messagerie, que les informations de capacités dans le message sont seulement pour la transaction en cours, et NE DEVRAIENT PAS être mémorisées pour de futures transactions. Par exemple, un receveur peut ne pas souhaiter que la capacité couleur soit utilisée pour des communications de routine. (Voir aussi le paragraphe A.5.)

o L’utilisation des q-values [RFC2533] dans les expressions de caractéristiques du support pour indiquer les préférences entre les solutions de remplacement disponibles et/ou les préférences du receveur.

o Renvoi partiel. Des propositions sont en cours de développement pour les réponses de "MDN partielle" qui peuvent indiquer l’état de disposition sur la base de la partie de message. Cela ouvre la possibilité de renvois partiels lorsque des formats de remplacement sont demandés pour seulement certaines parties du corps de message. La spécification actuelle suppose que le message est renvoyé en totalité ou pas du tout lorsque la négociation de contenu est utilisée.

o Permettre la négociation avec des parties autres que celles originellement mentionnées dans l’adresse des receveurs d’un message.

o La réponse de négociation peut indiquer un point d’extrémité de réception avec des capacités différentes.

Adresse des auteurs

Déclaration complète de droits de reproduction

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

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

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

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

Remerciement

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