Indication des caractéristiques de support prises en charge avec des extensions à DSN et MDN

Statut de ce mémoire

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

Notice de copyright

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

1. Résumé

Dans la messagerie et la télécopie Internet le receveur a besoin d’indiquer les caractéristiques du support qu’il prend en charge afin que les messages puissent être générés par les envoyeurs sans excéder les capacités du receveur.

Le présent mémoire décrit un format pour générer des notifications de disposition de message [RFC2298] et des notifications d’état de livraison [RFC1894] qui contiennent de telles informations. Ces informations peuvent être utilisées par les envoyeurs pour éviter d’excéder les capacités du receveur lors de l’envoi des messages suivants.

2. Introduction

Les extensions décrites dans le présent document peuvent être utilisées dans les notifications de disposition de message (DSN, Delivery Status Notification) [RFC2298] ou dans les notifications d’état de livraison (MDN, Message Disposition Notification) [RFC1894], comme approprié pour la mise en œuvre.

Noter que les DSN et les MDN ont tous deux des inconvénients : les DSN ne sont pas disponibles entre tous les envoyeurs et receveurs, et les MDN exigent que le receveur divulgue les informations de disposition du message (ou, si on utilise le type de disposition "refusé", l’heure à laquelle a été générée la notification de disposition).

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans la [RFC 2119].

3. Extensions à utiliser par DSN et MDN

L’extension suivante est disponible dans les messages DSN [RFC1894] et MDN [RFC2298].

Pour un message DSN, les champs par receveur suivants sont définis (paragraphe 2.3 de la [RFC1894]). Pour un message MDN, les champs d’extension suivants sont définis (paragraphe 3.1 de la [RFC2298]). En utilisant le langage de la [RFC2234] :

champ-d’extension = caractéristiques-du-support CRLF

caractéristiques-du-support = "Media-Accept-Features" ":" étiquettes-de-caractéristique-du-support

étiquettes-de-caractéristique-du-support = <*texte comme défini ci-dessous, avec enveloppe LWSP>

Les <étiquettes-de-caractéristique-du-support> sont définies dans des documents de schéma distincts qui DOIVENT utiliser le langage décrit dans la [RFC2533]. Le schéma DOIT être enregistré selon les exigences d’enregistrement de la [RFC2506].

3.1 Exemples

Les exemples suivants supposent qu’il y a un document de schéma qui définit les étiquettes montrées.

3.1.1 Taille de papier et couleur

En supposant qu’un document de schéma décrit les étiquettes taille-de-papier et couleur, l’exemple suivant est valide :

Media-Accept-Features: (& (taille-de-papier=a4) (couleur=binary) )

3.1.2 Support d’UA, taille de papier, et couleur

En supposant qu’un document de schéma décrit les étiquettes taille-de-papier, couleur, et gris :

Media-Accept-Features: (& (| (taille-de-papier=a4) (taille-de-papier=letter) ) (| (& (couleur=gris) (dpi=200) (dpi-xyratio=200/100) ) (& (couleur=limited) (dpi=200) (dpi-xy=200/100) ) )

4. Recommandation pour la mise en œuvre de MTA

Si le MTA du receveur détermine qu’un message ne peut pas être traité, le MTA du receveur est fortement invité à rejeter le message avec un code d’état de 5.6.1 [RFC1893]. Ce code d’état peut être retourné en réponse à l’indicateur de données de fin de message si le MTA prend en charge le rapport de codes d’erreur améliorés de la [RFC2034], ou après la réception du message en générant un échec de livraison DSN ("rejet").

5. Considérations pour la sécurité

Des informations imprécises de caractéristiques du support pourraient causer un déni de service, causant l’envoi ultérieur de messages que le receveur est dans l’incapacité de traiter.

Les informations de caractéristiques du support pourraient être imprécises à cause d’une attaque malveillante (DSN ou MDN falsifié) ou d’une mauvaise configuration.

6. Remerciements

L’auteur remercie les membres du groupe de travail Internet Fax de leur assistance pour le présent document, et en particulier Larry Masinter, Graham Klyne, et Ned Freed.

7. Références

[RFC1894] K. Moore, G. Vaudreuil, "Format de message extensible pour les notifications d'état de livraison", janvier 1996. (Obsolète, voir RFC3464) (MàJ par RFC2852) (P.S.)

[RFC2034] N. Freed, "Extension de service SMTP pour le retour de codes d'erreur améliorés", octobre 1996. (P.S.)

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

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

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

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

8. Adresse de l’auteur

Dan Wing

Cisco Systems, Inc.

101 Cooper Street

Santa Cruz, CA 95060

USA

téléphone : +1 831 457 5200

fax : +1 831 457 5208

mél : dwing@cisco.com

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

Copyright (c) The Internet Society (1999). 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 ces 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 les besoins 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, ses successeurs ou ayant droits.

Le présent document et les informations 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.