RFC3191 page - 2 - Allochio

Groupe de travail Réseau

C. Allocchio, GARR-Italy

Request for Comments : 3191

octobre 2001

RFC rendue obsolète : 2303


RFC mise à jour : 2846


Catégorie : En cours de normalisation

Traduction Claude Brière de L’Isle



Format minimal d’adresse GSTN 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) (appelées couramment "numéros de téléphone") dans la partie locale des adresses de messagerie Internet, ainsi qu’un mécanisme d’extension pour permettre le codage d’attributs standard supplémentaires pour les passerelles de messagerie avec les services fondés sur le GSTN.


1. Introduction


Comme avec toutes les adresses de messagerie Internet, la partie gauche (la partie locale) d’une adresse générée conformément à la présente spécification, n’est à interpréter que par un agent de transport de messagerie (MTA, Mail Transport Agent) qui traite les messages pour le domaine désigné dans la partie droite.


Depuis que le tout premier message électronique à des services passerelles du GSTN est apparu, un certain nombre de méthodes différentes ont été utilisées par les mises en œuvre pour spécifier une adresse du GSTN comme adresse de messagerie électronique. Plusieurs objectifs ont été identifiés pour ces méthodes, comme de permettre à un utilisateur de messagerie électronique d’accéder aux services du GSTN à partir de son interface de messagerie, de permettre une certaine forme de transport du "GSTN sur un service de messagerie électronique" (réduisant éventuellement le coût des transmission à longue distance du GSTN) tout en utilisant l’infrastructure de messagerie électronique existante.


Le présent mémoire décrit la méthode MINIMALE d’adressage pour coder les adresses du GSTN en adresses de messagerie électronique et le mécanisme d’extension standard pour permettre la définition d’autres éléments standard. Le problème inverse, c’est-à-dire, de permettre à un utilisateur d’appareil GSTN traditionnel seulement numérique d’accéder au service de transport de messagerie électronique, n’est pas abordé ici.


Le gabarit d’enregistrement de l’IANA qui DOIT être utilisé pour enregistrer tout élément standard défini conformément à la présente spécification est donné dans la section 7 "Considérations relatives à l’IANA" du présent document.


Toutes les mises en œuvre qui prennent en charge le service GSTN sur messagerie électronique DOIVENT prendre en charge au minimum la spécification exposée dans le présent document. Le cas générique complexe de la conversion de la totalité de l’adressage du GTSN en adressage de messagerie électronique sort du domaine d’application de cette spécification minimale.


1.1 Terminologie et conventions syntaxiques


Dans le présent document, les définitions formelles sont décrites en utilisant la syntaxe ABNF, comme définie dans la [RFC5234]. Le présent mémoire utilise aussi certaines des définitions du "Cœur ABNF de l’ABNF" de l’appendice B de ce document.


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


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


appareil I-rtpc : Un appareil qui a un nom de domaine Internet et est capable de communiquer directement ou indirectement avec le réseau GSTN.


mta-I-rtpc : Le nom de domaine Internet qui identifie de façon univoque un appareil I-rtpc sur l’Internet.


rtpc-email : La structure complète d’adresse de messagerie électronique Internet qui est utilisée pour transporter une adresse GSTN sur le service de messagerie électronique de l’Internet.


2. Adresse GSTN minimale


La spécification minimale d’une adresse GSTN au sein d’une adresse de messagerie électronique est la suivante :


adresse-rtpc = mbox-rtpc [ qualif-type1 ]


mbox-rtpc = service-sélecteur "=" téléphone-mondial


service-sélecteur = 1*( DIGIT / ALPHA / "-" ) ; noter que le caractère SP (espace) n’est pas admis dans service-sélecteur.

; service-sélecteur DOIT être traité comme une chaîne insensible à la casse 

; par les mises en œuvre


Les autres spécifications adoptant la définition de "adresse-rtpc" DOIVENT définir et enregistrer auprès de l’IANA un élément "service-sélecteur" unique insensible à la casse pour identifier le service de messagerie spécifique concerné.


Ces spécifications et enregistrements DOIVENT aussi définir quelles extensions minimales "qualif-type1", si il en est, DOIVENT être prises en charge pour le service de messagerie spécifié.


Les mises en œuvre qui se conforment à cette spécification d’exigences minimales sont autorisées à ignorer tout autre élément d’adresse d’extensions non minimales qui est présent dans "adresse-rtpc". Cependant, les mises en œuvre conformes DOIVENT préserver tous les éléments d’adresse "qualif-type1" qu’ils reçoivent.


L’élément "qualif-type1" générique est défini par :


qualif-type1 = "/" mot-clé "=" chaîne


mot-clé = 1*( CHIFFRE / ALPHA / "-" ) ; noter que SP (espace) n’est pas admis dans mot-clé


chaîne = PCHAR ; noter que les caractères imprimables sont %x20-7E


À ce titre, tous les éléments d’extension "adresse-rtpc" DOIVENT être définis dans la forme "qualif-type1" au moment de l’enregistrement auprès de l’IANA.


2.1 Définition du "téléphone mondial" minimal


L’objet de l’élément téléphone mondial est de représenter les adresses numériques de la Recommandation UIT-T [E.164] au sein d’une syntaxe pour l’adressage de messagerie électronique conforme à la spécification de la messagerie électronique standard donnée dans les [RFC821] et [RFC822].


La syntaxe minimale prise en charge pour l’élément téléphone-mondial est la suivante :


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


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


L’utilisation d’autres schémas de numérotation pour les numéros du GSTN (comme les plans de numérotation privés ou les conventions de numérotation locales) est aussi permise. Cependant, cela n’empêche ni ne supprime l’exigence de prise en charge de la syntaxe "téléphone-mondial" au sein du format minimal d’adresse GSTN.


Aucun autre schéma de numérotation NE DOIT utiliser le "+" en tête défini ici entre le signe "=" et la chaîne de numérotation. Le signe "+" est strictement réservé à la syntaxe "téléphone-mondial" standard.


Note : La spécification d’autres schémas de numérotation sort du domaine d’application de la présente spécification minimale.


Le présent document permet aussi l’utilisation des éléments séparateur-écrit afin d’améliorer la lisibilité par l’homme des adresses de messagerie électronique du GSTN. Les séparateur-écrit sont des éléments qui peuvent être placés entre les éléments de numérotation tels que les chiffres, etc.


Note de mise en œuvre : L’utilisation des éléments séparateur-écrit est permise, mais pas recommandée pour la transmission. Toutes occurrences d’éléments séparateur-écrit dans un rtpc-mbox DOIVENT être ignorées par toute mise en œuvre conforme.


2.2 Exemples de "adresse-rtpc" minimales


Quelques exemples d’adresse-rtpc minimales sont :


VOCAL=+3940226338


FAX=+12027653000/T33S=6377


SMS=+33-1-88335215


Note : Ces exemples ne sont donnés qu’à titre d’illustration ; ils ne représentent pas nécessairement des adresse-rtpc valides.


3. L’adresse de messagerie électronique de l’appareil I-rtpc : mta-I-rtpc


Un "appareil I-rtpc" 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 à droite du signe "@". Pour les besoins du présent document, on l’appelle "mta-I-rtpc"


mta-I-rtpc = domaine


Pour les chaînes "domaine" utilisées dans les transmissions SMTP, la chaîne DOIT se conformer aux exigences des spécifications standard de <domaine> dans les [RFC821], [RFC823]. 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, les [RFC822], [RFC1123].


Note : L’utilisation des "noms de domaine" ou "domaine littéral" est permise dans les adresses aussi bien dans les champs d’enveloppe SMTP que des en-têtes de message.


4. Le rtpc-email


La structure complète utilisée pour transférer une adresse GSTN minimale sur le système de transport Internet de messagerie électronique est appelé "rtpc-email". Cet objet est une adresse de messagerie électronique qui se conforme à la syntaxe "addr-spec" des [RFC822] et [RFC1123], avec des précisions de structure qui permettent d’identifier le numéro GSTN.


rtpc-email = ["""] ["/"] adresse-rtpc ["/"] ["""] "@" mta-I-rtpc


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 rtpc-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. D’un autre côté, dans la pratique de la messagerie électronique, une adresse de messagerie électronique unique et distincte est toujours utilisée pour chaque receveur.


Dans l’éventualité où un service GSTN particulier exige plusieurs sous-adresses (dans toute forme définie par la spécification standard pour ce service GSTN) qui sont associées à la même "rtpc-mbox", alors l’utilisation de plusieurs éléments "rtpc-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 "rtpc-mbox" lorsque il soumet le message au MTA.


4.2 Quelques exemples d’adresses "rtpc-email" minimales


Voici quelques exemples d’adresses rtpc-email minimales :


VOCAL=+3940226338@worldvoice.com


FAX=+1.202.7653000/T33S=6377@faxserv.org


/SMS=+33-1-88335215/@telecom.com


Note : Ces exemples ne sont donnés qu’à des fins d’illustration ; ils ne représentent pas nécessairement des adresse-rtpc valides.


5. Conclusions


La présente proposition crée un codage standard minimal pour les adresses GSTN au sein du système mondial de transport de messagerie électronique. Elle définit aussi le mécanisme d’extension standard à utiliser pour introduire de nouveaux éléments pour les adresses GSTN.


La proposition est cohérente avec les normes existantes de messagerie électronique. Chaque service GSTN spécifique qui utilise cette proposition DOIT définir et enregistrer auprès de l’IANA sa propre spécification de "sélecteur-de-service" et DOIT définir et enregistrer les éventuels autres éléments "qualif-type1" nécessaires pour son application spécifique. Un exemple d’une telle application est contenu dans la [RFC3192].


6. Considérations sur la sécurité


Le présent document spécifie un moyen pour coder les adresses GSTN 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 domaine (DNS, Domain Name System) une attaque réussie contre le DNS pourrait disséminer des informations altérées, qui causeraient le détournement des messages électroniques via certains MTA ou passerelles où la sécurité des logiciels 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 pour l’IANA


Comme les valeurs des éléments service-sélecteur et qualif-type1 sont extensibles, elles DOIVENT être enregistrées auprès de l’IANA.


Pour enregistrer un élément service-sélecteur ou qualif-type1, le gabarit du formulaire d’enregistrement donné aux paragraphes 7.1 et 7.2 DOIT être utilisé. Tout nouvel enregistrement DOIT satisfaire aux critères des "Spécifications exigées", telles que définis à la section 2 de la [RFC2434] :


"Spécification exigée – Les valeurs et leur signification DOIVENT être documentées dans une RFC ou autre référence permanente et directement accessible, avec un détail suffisant pour que soit possible l’interopérabilité entre des mises en œuvre indépendantes."


L’IANA NE DOIT PAS accepter des enregistrements qui ne sont pas appuyés sur une spécification comme définie ci-dessus et qui ne sont pas pleinement spécifiés conformément aux formulaires de gabarit donnés aux paragraphes 7.1 et 7.2. En cas de besoin de consultations supplémentaires sur l’acceptabilité d’un nouvel enregistrement, L’IANA DEVRAIT se référer au directeur du domaine d’application pour l’orienter sur l’expert ou groupe de travail de l’IETF approprié.


Après un enregistrement réussi, l’IANA devrait publier l’élément enregistré sur le site en ligne de la Toile de l’IANA, et l’inclure dans les mises à jour de la série des RFC "Numéros alloués".


La présente section (y compris les paragraphes 7.1 et 7.2) met à jour celles contenues dans la [RFC2846].


7.1 Gabarit de formulaire d’enregistrement IANA de nouvelles valeurs de service-sélecteur d’adresse GSTN


À : IANA@iana.org

Objet : Enregistrement de nouvelles valeurs pour spécifier le service-sélecteur d’adresse GSTN "foo"


nom du service-sélecteur : foo


Description d’utilisation :

foo - ("foo" est un nouveau service-sélecteur fictif utilisé dans ce gabarit comme exemple, il est à remplacer par la nouvelle valeur enregistrée. Cela inclut ici une brève description de l’utilisation de la nouvelle valeur. Cela DOIT inclure des références aux RFC en cours de normalisation et éventuellement à des documents d’autres organismes de normalisation pour la description complète ; l’utilisation de la valeur doit être définie de façon suffisamment complète pour une mise en œuvre indépendante.)


Considérations pour la sécurité :

(Toute considération de sécurité supplémentaire qui peut être introduite par l’usage du nouveau paramètre de service-sélecteur devrait être définie ici ou dans les références de RFC en cours de normalisation).


Personne & adresse de messagerie à contacter pour des informations complémentaires :

(remplir les informations sur les contacts)


INFORMATION AU SOUMETTANT :

Les enregistrements acceptés seront énumérés dans la série des RFC "Numéros alloués". Les informations du formulaire d’enregistrement sont disponibles gratuitement.


7.2 Gabarit de formulaire d’enregistrement IANA de nouvelles valeurs de mot clé et valeur de qualif-type1 d’adresse GSTN


À : IANA@iana.org

Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "bar" d’adresse GSTN.


nom du "mot-clé" qualif-type1 : bar


Définition ABNF de "valeur" qualif-type1 : abnf - ("abnf" DOIT définir la forme ABNF de la valeur de qualif-type1. La spécification ABNF DOIT être auto explicative, utilisant comme éléments de base les jetons donnés dans la [RFC1528]. Pour éviter toute duplication (le cas échéant) elle DOIT aussi utiliser tout jeton non de base déjà enregistré provenant d’autres éléments qualif-type1, c’est-à-dire, elle DOIT utiliser le même nom de jeton non basique et répéter à l’identique sa définition ABNF à partir des jetons de base.


Description d’usage :

bar - ("bar" est une description fictive pour un nouvel élément qualif-type1 utilisé comme exemple dans ce gabarit. Il est à remplacer par la description réelle de l’élément qualif-type1 à enregistrer. Cela inclut ici une brève description de l’usage du nouveau qualif-type1. Cela DOIT inclure des références aux RFC en cours de normalisation et éventuellement à des documents d’autres organismes de normalisation pour une description complète ; l’usage de la valeur DOIT être défini de façon suffisamment complète pour une mise en œuvre indépendante.)


Restriction d’usage :

(Si les nouveaux éléments qualif-type1 n’ont de signification que pour un ensemble spécifique d’éléments de service, on DOIT spécifier ici la liste des types admis d’éléments de service. Si il n’y a pas de restriction, on spécifie alors le mot clé "aucune".)


Considérations pour la sécurité :

(Toute considération supplémentaire pour la sécurité qui pourrait être introduite par l’usage du nouveau paramètre de sélecteur de service devrait être défini ici ou dans les RFC en cours de normalisation de référence.)


Personne & adresse de messagerie à contacter pour des informations complémentaires : (remplir les informations de contact)


INFORMATION AU SOUMETTANT :

Les enregistrements acceptés seront énumérés dans la série des RFC "Numéros alloués". Les informations du formulaire d’enregistrement sont disponibles gratuitement.


8. Changements par rapport à la spécification de la RFC 2303


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


- il a été précisé que "adresse GSTN" correspond, dans le langage courant, à "numéro de téléphone" et que le "téléphone mondial" est une représentation des adresses numériques de la Recommandation UIT-T [E.164] ;


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


- le fait que toute autre spécification qui adopte la définition de "adresse-rtpc" DOIVE enregistrer auprès de l’IANA les nouveaux éléments "service-sélecteur" et "qualif-type1" a été rendu explicite dans tout le document ; le mécanisme pertinent à utiliser a été ajouté à la section 7 "Considérations pour l’IANA" (y compris les formulaires d’enregistrement de l’IANA) ; ceci est aussi cohérent avec la [RFC2846] ;


- au paragraphe 2.1, l’utilisation et la signification de "séparateur-écrit" a été précisée ;


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


- le paragraphe 4.1 a été mis à jour pour préciser comment générer "rtpc-email" lorsque plus d’une sous-adresse est utilisée ;


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


- la liste des références a été mise à jour pour inclure les RFC2846 et RFC2434.


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


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


[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC 5226)


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


[RFC3192] C. Allocchio, "Format minimal d'adresse FAX 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).


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


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.