Groupe de travail Réseau	C. Allocchio, GARR-Italy	
Request for Comments : 3192	octobre 2001	
RFC rendue obsolète : 2304		
RFC mise à jour : 2846		
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle	

Format minimal d’adresse de télécopie dans la messagerie Internet

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 (2001). Tous droits réservés.

Résumé
Le présent mémoire décrit une méthode simple de codage des adresses du réseau téléphonique commuté mondial (GSTN, Global Switched Telephone Network) d’appareils de télécopie dans la partie locale des adresses de messagerie Internet.

1.	Introduction

Comme avec toutes les adresses de messagerie Internet, le côté gauche (la partie locale) d’une adresse générée conformément à la présente spécification, n’est pas à interpréter, sauf par l’agent de transport de messagerie (MTA, Mail Transport Agent)  qui est désigné sur le côté droit (le domaine).

Depuis la toute première apparition des objets de passerelle de messagerie électronique à télécopie, un certain nombre de méthodes différentes ont été utilisées par les mises en œuvre pour spécifier une adresse de télécopie comme adresse de messagerie électronique. Plusieurs objectifs ont été identifiés pour ces méthodes, comme de permettre à un utilisateur de messagerie électronique d’envoyer et de recevoir des télécopies à partir de son interface de messagerie électronique, de permettre une certaine forme de transport de "service de télécopie sur messagerie électronique" (réduisant éventuellement le coût de la transmission à grande distance du GSTN) tout en utilisant l’infrastructure existante de messagerie électronique.

Le présent mémoire décrit la méthode MINIMALE d’adressage et les extensions standard pour coder les adresses de télécopie en adresses de messagerie électronique, comme exigé par la [RFC3191]. Le problème inverse, c’est-à-dire, de permettre à un utilisateur d’appareil de télécopie traditionnel uniquement numérique d’accéder au service de transport de messagerie électronique, n’est pas abordé ici.

Les formulaires IANA utilisés pour enregistrer les éléments standard définis ici sont données à la section 7 "Considérations relatives à l’IANA".

Toutes les mises en œuvre qui prennent en charge le format d’adresse de télécopie sur messagerie électronique DOIVENT prendre en charge cette spécification minimale.

1.1	Terminologie et conventions syntaxiques

Dans le présent document, les définitions formelles sont décrites à l’aide de la syntaxe ABNF, telle que définie dans la [RFC2234]. On utilisera aussi certaines des "Définitions du cœur des règles" définies dans l’appendice A - "Cœur des règles" de ce document.

La signification exacte des mots en majuscules "DOIT", "NE DOIT PAS", "EXIGÉ", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RRECOMMANDE", "PEUT", "FACULTATIF" est définie dans la [RFC2119].

Dans le présent document, les nouveaux termes suivants sont aussi définis :

appareil I-fax :	un type d’appareil I-rtpc [RFC3191] qui est capable de communiquer directement ou indirectement avec la télécopie traditionnelles sur le service GSTN.

mta-I-fax :	nom de domaine Internet qui identifie de façon univoque un appareil I-fax sur l’Internet (voir aussi mta-I-rtpc dans la [RFC3191]).

fax-email :	structure complète d’adresse de messagerie électronique Internet utilisée pour transporter une adresse de télécopie sur le service de messagerie électronique Internet (voir aussi rtpc-email dans la [RFC3191]).

2.	Adresse de télécopie minimale

L’adresse de télécopie minimale au sein d’un message électronique a été définie pour être en cohérence avec celle de la [RFC3191] et elle contient deux éléments : l’élément fax-mbox et un élément facultatif qualif-type1.

Plus précisément, la spécification d’adresse GSTN minimale exige l’utilisation d’un sélecteur de service unique pour chaque application spécifique (section 2 de la [RFC3191]).

Le "sélecteur de service" défini pour le service de télécopie est le suivant :

service-sélecteur = "FAX"

Dans la syntaxe d’adresse de télécopie, un élément qualif-type1 a été défini pour la prise en charge des sous-adresses T.30/T.33 (voir la section 2 de la [RFC3191]). L’utilisation de cet élément est FACULTATIVE, mais les mises en œuvre conformes DOIVENT être capables de le prendre en charge et de l’interpréter correctement lorsque il est présent. Sa définition est la suivante :

qualif-type1 = "/" t33-sep "=" sub-addr

où

t33-sep = "T33S"

sub-addr = 1*( CHIFFRE )

Donc, la spécification minimale d’une télécopie dans une adresse de messagerie électronique  est :

fax-address = fax-mbox [ "/T33S=" sub-addr ]

fax-mbox = "FAX=" téléphone-mondial

Note :	Dans le cas d’une seule sous-adresse, seuls des nombres sont permis dans <sub-addr> ce qui est cohérent avec T.30, [T.33], et le présent document. Bien que [T.30] et [T.33] utilisent SPACE pour bourrer ce champ, le bourrage n’est pas nécessaire dans le champ <sub-addr> défini dans le présent document.

Note :	Dans le cas de plusieurs sous-adresses, [T.33] spécifie d’utiliser le caractère "#" pour spécifier la présence de plusieurs sous-adresses. Cependant, seuls les chiffres sont permis dans le champ <sub-addr> défini par ce document.  Se référer au paragraphe 4.1 au cas où plusieurs <sub-addr> par <fax-mbox> ont besoin d’être spécifiées.

La syntaxe minimale prise en charge pour téléphone-mondial (comme décrite au paragraphe 2.1 de la [RFC3191]) est :

téléphone-mondial = "+" 1*( CHIFFRE / séparateur-écrit )

séparateur-écrit = ( "-" / "." )

Se référer au paragraphe 2.1 de la [RFC3191] pour les autres considérations importantes sur l’élément téléphone-mondial.

2.2	Exemples d’une "fax-address" minimale

Voici quelques exemples de fax-address minimales :

FAX=+3940226338

FAX=+12027653000/T33S=1387

FAX=+33-1-88335215

Note : Les exemples donnés ne sont qu’à des fins d’illustration.

3.	Adresse de messagerie électronique pour l’appareil I-fax : mta-I-fax

Un "appareil I-fax" a, entre autres caractéristiques, un nom de domaine Internet unique qui l’identifie sur l’Internet. Au sein de la messagerie Internet, c’est le côté droit (RHS, Right Hand Side) de l’adresse, c’est-à-dire, la partie à la droite du signe "@". Pour les besoins du présent document, on appelle cela "mta-I-fax"

mta-I-fax = domaine

Pour les chaînes "domaine" utilisées dans les transmissions SMTP, cette chaîne DOIT se conformer aux exigences des normes qui spécifient <domaine> , les [RFC821], [RFC1123]. Pour les chaînes "domaine" utilisées dans les en-têtes de contenu de message, la chaîne DOIT se conformer aux exigences des normes pertinentes [RFC8222], [RFC1123].

Note :	L’utilisation des "noms de domaines" ou de "domaine littéraux" est permise dans les adresses à la fois dans l’enveloppe SMTP et dans les champs d’en-tête de message.

4.	fax-email

La structure complète utilisée pour transférer une adresse minimale de télécopie sur le système Internet de transport de messagerie électronique est appelé "fax-email". Cet objet est une adresse de messagerie électronique qui se conforme à la syntaxe "addr-spec" de la [RFC822] et de la [RFC1123] avec des raffinements de structure qui permettent d’identifier les numéros de télécopie.

fax-email = ["""] ["/"] fax-address ["/"] ["""] "@" mta-I-fax

Note de mise en œuvre : Le caractère facultatif "/" peut résulter de traductions d’autres passerelles de transport (comme certaines passerelles X.400) qui ont inclus le "/" comme élément optionnel. Les mises en œuvre DOIVENT accepter les barres obliques facultatives, mais NE DEVRAIENT PAS les générer. Les passerelles sont autorisées à les supprimer lors de la conversion en adressage de messagerie Internet. Les normes pertinentes [RFC822], [RFC1123] définissent exactement quand les caractères facultatifs "guillemets" entourant toute la partie locale (c’est-à-dire, la partie à gauche du caractère "@" dans le fax-email) DOIVENT être ajoutés.

4.1	Sous-adresses multiples

Il y a certaines instances d’applications du GSTN où plusieurs sous-adresses sont utilisées : les sous-adresses de la Recommandation UIT-T T.33 dans le service de télécopie sont un de ces cas. Dans la pratique de la messagerie électronique, une adresse séparée et unique est toujours utilisée pour chaque receveur ; à ce titre , si plusieurs sous-adresses T.33 sont présentes, l’utilisation de plusieurs éléments "fax-email" est EXIGÉE.

Note de mise en œuvre :	L’agent d’utilisateur PEUT accepter plusieurs éléments de sous-adresse pour le même téléphone mondial, mais il DOIT générer plusieurs éléments "fax-mbox" puis soumettre le message au MTA.

4.2	Exemples de "fax-email" minimal

Voici des exemples d’adresses minimales fax-email :

FAX=+3940226338@faxworld.org

FAX=+12027653000/T33S=1387@faxworld.org

/FAX=+33-1-88335215/@faxworld.org

Note : Les exemples ne sont donnés qu’à des fins d’illustration.

5.	Conclusion

Cette proposition crée un codage standard pour les adresses de télécopie au sein du système mondial de transport de messagerie électronique. La proposition est en cohérence avec les normes existantes de messagerie électronique.

6.	Considérations pour la sécurité

Le présent document spécifie un moyen pour coder les adresses de télécopie en adresses de messagerie électronique. Comme l’acheminement de la messagerie électronique est déterminé par les données du système des noms de domaines (DNS, Domain Name System) la réussite d’une attaque contre le DNS pourrait disséminer des informations altérées, qui causerait le détournement des messages électroniques via certains MTA ou passerelles où la sécurité du logiciel a été compromise.

Un attaquant dispose de plusieurs moyens pour se rendre capable de livrer des informations d’acheminement de messagerie incorrectes à un client. Cela inclut : (a) la compromission d’un serveur du DNS, (b) la génération d’une réponse contrefaite à l’interrogation du DNS par un client, (c) de retourner des "informations supplémentaires" incorrectes en réponse à une interrogation sans rapport avec elles. Les clients DEVRAIENT s’assurer que l’acheminement de la messagerie ne se fonde que sur des réponses autorisées. Une fois que les mécanismes de sécurité du DNS [RFC2065] seront plus largement déployés, les clients DEVRAIENT employer ces mécanismes pour vérifier l’authenticité et l’intégrité des enregistrements d’acheminement de messagerie.

7.	Considérations relatives à l’IANA 

Les formulaires d’enregistrement de l’IANA pour les éléments sélecteur de service "FAX" et le qualif-type1 "T33S" sont définis ici. Ces formulaires mettent à jour les formulaires d’enregistrements précédents définis dans la [RFC2846].

7.1	Formulaire d’enregistrement IANA pour la valeur mise à jour du sélecteur de service "FAX" d’adresse GSTN

À : IANA@iana.org
Objet : Enregistrement des valeurs mises à jour pour le spécificateur de sélecteur de service d’adresse GSTN "FAX"

Nom du sélecteur de service : FAX

Description d’usage :
FAX – spécifie que l’adresse GSTN se réfère à un appareil de télécopie Internet ou à une passerelle à bretelle d’entrée/sortie de télécopie.

Pour une description complète, se référer aux RFC3192 et RFC3191.

Considérations pour la sécurité :
Voir la section "Considération pour la sécurité" de la RFC3192.

Personne & adresse de messagerie à contacter pour d’autres informations :
Claudio Allocchio
INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza
I 34012 Trieste
Italy

mél : Claudio.Allocchio@garr.it
X.400:   C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
téléphone :   +39 040 3758523
Fax :     +39 040 3758565

7.2	Formulaire d’enregistrement IANA pour la valeur mise à jour du mot-clé "T33S" de qualit-type1 d’adresse GSTN

À : IANA@iana.org
Objet : Enregistrement des valeurs mises à jour pour l’élément "T33S" de qualif-type1 d’adresse GSTN.

Nom du mot-clé de qualif-type1 : T33S

Définition ABNF de la valeur de qualif-type1 : sub-addr = 1*( CHIFFRE )

Description d’usage :
T33S est utilisé pour spécifier l’élément facultatif entièrement numérique de sous-adresse de télécopie décrit dans la Recommandation UIT-T  T.33 "Acheminement de télécopie fondé sur la sous-adresse" (juillet 1996). Une description plus détaillée set disponible dans la RFC3192.

Restriction d’usage :
L’usage de "T33S" est restreint au sélecteur de service "FAX", car il n’a pas de signification en dehors du service de télécopie.

Considérations pour la sécurité :
Voir la section "Considération pour la sécurité'" de la RFC3192.

Personne & adresse de messagerie à contacter pour d’autres informations :
Claudio Allocchio
INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza
I 34012 Trieste
Italy

mél : Claudio.Allocchio@garr.it
X.400:   C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
téléphone :   +39 040 3758523
Fax :     +39 040 3758565

8.	Changements par rapport à la spécification de la RFC2304

Bien qu’il n’y ait pas de changement technique ou majeur par rapport à la spécification de la RFC2303, la présente section décrit brièvement où des mises à jour et précisions ont été introduites :

-	Considérant que le cas des systèmes téléphoniques ne se conforme plus au paradigme de "un seul ou quelques" opérateurs publics, la vieille définition du "RTPC – réseau téléphonique public commuté" a été changée en celle plus adéquate de "GSTN – réseau téléphonique commuté mondial". Cependant, afin de rester cohérent avec la spécification précédente, le nom des variables ABNF n’a pas été changé.

-	La section 7 "Considérations relatives à l’IANA" et les formulaires d’enregistrement IANA pour les éléments sélecteur de service "FAX" et qualif-type1 "T33S" a été ajoutée.

-	Une liste explicite de "nouveaux termes" avec des explications a été ajoutée au paragraphe 1.1 ;

-	Le cas où plusieurs sous-adresses T.33 sont présentes a été décrit de façon plus explicite afin de préciser comment les traiter (paragraphe 4.1).

-	À la section 3, le langage qui décrit "mta-I-fax" a été mis à jour pour mieux décrira sa relation avec une adresse de messagerie Internet.

-	À la section 4, les règles de citation de "fax-address" et leur utilisation pratique ont été rendues explicites à la fois dans la définition de "fax- email" et dans la note de mise en œuvre.

-	l’adresse de l’auteur a été mise à jour ;

-	La liste des références a été mise à jour pour substituer UIT-T E.164 (1997) à UIT-T E.164 (1991).

9.	Adresse de l’auteur

Claudio Allocchio
INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza
I 34012 Trieste
Italy

mél : Claudio.Allocchio@garr.it
X.400:   C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
téléphone :   +39 040 3758523
Fax :     +39 040 3758565

10.	Références

[300 380]	ETSI I-ETS 300 380 "Universal Personal Telecommunication (UPT): Access Devices Dual Tone Multi Frequency (DTMF) sender for acoustical coupling to the microphone of a handset telephone" (mars 1995).

[F.401]	Recommandation UIT-T F.401 "Services de messagerie : Dénomination et adressage pour le service de messagerie publique" (août 1992).

[F.423]	Recommandation UIT-T F.423 "Services de messagerie : Intercommunication entre le service de messagerie interpersonnelle et le service de télécopie" (août 1992).

[E.164]	Recommandation UIT-T E.164/I.331 "Plan de numérotage des télécommunications publiques internationales" (mai 1997).

[RFC0821]	J. Postel, "Protocole simple de transfert de messagerie", STD 10, août 1982.

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

[RFC1123]	R. Braden, éditeur, "Exigences pour les hôtes Internet – Application et prise en charge", STD 3, octobre 1989.

[RFC1528]	C. Malamud et M. Rose, "Principes de fonctionnement du sous-domaine TPC.INT : Impression à distance ; procédures techniques", octobre 1993. (Expérimental)

[RFC2065]	D. Eastlake 3rd, C. Kaufman, "Extensions de sécurité du système de noms de domaines", janvier 1997. (Obsolète, voir RFC2535) (MàJ RFC1034, RFC1035) (P.S.)

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

[RFC2156]	S. Kille, "MIXER (Relais amélioré Mime Internet X.400) : transposition entre X.400 et la RFC0822/MIME ", janvier 1998. (P.S.)

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

[RFC2846]	C. Allocchio, "Extensions d'élément d'adresse GSTN dans les services de messagerie électronique", juin 2000. (MàJ par RFC3191, RFC3192) (P.S.)

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

[T.33]	Recommandation UIT-T T.33 "Acheminement de la télécopie fondé sur la sous-adresse" (juillet 1996).

Déclaration complète de droits de reproduction

Copyright (c) The Internet Society (2001). 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 copyright ci-dessus et le présent et 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, 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.