Groupe de travail Réseau	C. Allocchio, GARR-Italy	
Request for Comments : 2846	juin 2000	
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle	

Extensions d’élément d’adresse GSTN 
dans les services de messagerie électronique

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

Résumé
Il existe de nombreuses applications où il y a un besoin d’interaction entre l’adressage du réseau téléphonique commuté mondial (GSTN) et l’adressage Internet. Le présent mémoire définit une syntaxe complète pour un cas spécifique, où il est besoin de représenter les adresses GSTN au sein d’adresses de messagerie électronique Internet. La syntaxe complète est un sur ensemble d’une syntaxe minimale qui a été définie dans la [RFC2303].

Table des Matières
1. Introduction	2
1.1 Relations avec l’adressage Internet autre que la messagerie électronique	2
1.2 Conventions de terminologie et de syntaxe	2
2. Numéro GSTN étendu et format pstn-mbox étendu	3
2.1 Syntaxe de local-phone	3
2.2 Élément sub-addr-spec	4
2.3 Éléments post-sep et post-dial	4
3. Élément pstn-recipient	4
3.1 recipient-name	5
3.2 Élément extensible recipient-qualifier	5
4. Cas de sub-addr-spec multiples	6
5. Exemples	6
5.1 Exemples de pstn-mbox	6
5.2 Exemples de pstn-recipient	7
5.3 Exemples de pstn-address	8
5.4 Exemples de pstn-email	8
5.5 Exemple de transaction SMTP complète	8
6. Conclusion	9
7. Considérations sur la sécurité	9
8. Syntaxe ABNF	9
9. Considérations relatives à l’IANA	10
9.1 Gabarit de formulaire d’enregistrement IANA pour les nouvelles valeurs de service-selector d’adresse GSTN	11
9.2 Gabarit de formulaire d’enregistrement IANA pour les nouvelles valeurs de mot-clé et valeur de qualif-type1 d’adresse GSTN	11
10. Formulaire d’enregistrement IANA pour nouvelles valeurs de service-selector "FAX"	11
11. Formulaire d’enregistrement IANA pour les nouvelles valeurs de mot-clé et valeur de qualit-type1 d’adresse GSTN	12
11.1 T33S	12
11.2 ISUB	12
11.3 POSTD	12
11.4 ATTN	12
11.5 ORG	13
11.6 OFNO	13
11.7 OFNA	13
11.8 STR	13
11.9 ADDR	14
11.10 ADDU	14
11.11 ADDL	14
11.12 POB	14
11.13 ZIP	15
11.14 CO	15
12. Adresse de l’auteur	15
13. Références	15
14. Déclaration complète de droits de reproduction	16

1.	Introduction

Les éléments possibles qui composent une adresse du réseau mondial de téléphone commuté (GSTN, Global Switched Telephone Network) (qu’on appelle aussi le RTPC, réseau téléphonique public commuté) dans la messagerie électronique peuvent varier d’un nombre minimum jusqu’à une collection réellement grande et complexe. On a noté que le format minimal et la syntaxe générale d’adresse ont été définis dans la [RFC2303], ainsi que le mécanisme nécessaire pour définir des éléments d’adresse supplémentaires. Le présent mémoire utilise ce mécanisme d’extension pour compléter la syntaxe de représentation des adresses GSTN au sein d’adresses de messagerie électronique et contient les enregistrements IANA pour tous les nouveaux éléments définis.

En particulier, les éléments d’adresse supplémentaires suivants seront définis :
-	la définition détaillée des formats de numéros GSTN, afin de couvrir divers autres schémas standard de numérotation GSTN (c’est-à-dire. gstn-phone, sub-addr-spec et post-dial)
-	la spécification de l’origine et/ou du receveur du message (pstn-recipient)

Les adresses GSTN dans la messagerie électronique PEUVENT contenir des éléments supplémentaires définis et enregistrés dans d’autres spécifications (voir par exemple l’élément "T33S" dans la [RFC2304]), mais elles DOIVENT utiliser les définitions contenues dans le présent mémoire pour les éléments spécifiés ici.
En particulier, les noms "service-selector" et les éléments "qualif-type1" DOIVENT être enregistrés auprès de l’IANA, et publiés au sein du document "Numéros alloués". Cela procure un mécanisme standard pour étendre les ensembles d’éléments et devrait éviter des duplications inutiles. Les gabarits de formulaire d’enregistrement IANA pour les besoins de l’enregistrement de nouveaux éléments sont fournis dans l’Appendice B. De plus, la section Considération relatives à l’IANA de ce document définit les procédures requises pour procéder à de nouveaux enregistrements.

Une collection de formulaires pour les éléments déjà définis "service-selector" et "qualif-type1" est donnée dans les sections, respectivement 10 et 11.

En particulier, des efforts ont été faits pour conserver la compatibilité avec les éléments définis dans les services existants de passerelle de messagerie électronique et les spécifications standard. Par exemple, dans la mesure du possible, la compatibilité a été conservée avec la spécification de passerelles MIXER [RFC2156].

1.1	Relations avec l’adressage Internet autre que la messagerie électronique

Même si dans ce mémoire on se concentre sur les adresses de messagerie électronique, un certain nombre d’éléments définis dans la présente spécification peuvent aussi être utilisés pour les autres spécifications qui traitent de l’incorporation des adresses GSTN dans d’autres adresses : par exemple il y a des travaux en cours sur la spécification des URL qui adoptent des définitions similaires, avec de légers changements dans la syntaxe globale dus aux spécificités du format d’URL.

1.2	Conventions de terminologie et de syntaxe

Dans ce document, les définitions formelles sont décrites en utilisant la syntaxe ABNF, comme défini dans la [RFC2234]. On utilise aussi certaines des "CORE DEFINITIONS" définies dans la Section 8 du présent document. La signification exacte des mots en majuscules "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", "FACULTATIF" est définie dans la [RFC2119].

2.	Numéro GSTN étendu et format pstn-mbox étendu

À la section 2 de la [RFC2303], la définition minimale de pstn-mbox inclut l’élément global-phone, et des détails complémentaires sont définis au paragraphe 2.1 de la [RFC2303].

Cependant d’autres schémas de numérotation téléphonique non mondiaux sont aussi possibles. Donc, l’ensemble minimal de syntaxe défini dans la [RFC2303] devra être étendu pour permettre la prise en charge d’éléments de téléphone local. Le format gstn-phone est défini comme suit :

gstn-phone = ( global-phone / local-phone )

La complexité du système GSTN inclut aussi l’utilisation facultative de sous adresses et de séquences post numérotation. Par conséquent, il est nécessaire d’étendre la définition de pstn-mbox selon la [RFC2303] pour inclure la prise en charge de la définition de l’ensemble minimal et d’une syntaxe étendue.

La définition étendue de pstn-mbox est la suivante :

pstn-mbox = service-selector "=" global-phone

pstn-mbox =/ service-selector "=" gstn-phone [ sub-addr-spec ] [post-sep post-dial]

Note : voir la section 4 pour le cas où plusieurs éléments "sub-addr-spec" doivent être spécifiés par pstn-mbox.

2.1	Syntaxe de local-phone

L’élément local-phone est destiné à représenter l’ensemble des cas possibles où le schéma de numérotation global-phone ne s’applique pas. Étant données les différentes et complexes conventions utilisées actuellement dans le système GSTN, la définition de local-phone prend en charge un grand nombre d’éléments.

La syntaxe détaillée des éléments local-phone est :

local-phone = [ exit-code ] [ dial-number ]

exit-code = phone-string
; cela inclut des éléments tels que le chiffre pour accéder à une ligne sortante, le code d’accès à l’opérateur longue distance, le mot de passe d’accès au service, etc...

dial-number = phone-string
; ceci est dans de nombreux cas composé de différents éléments tels que le numéro de téléphone local, le code de zone (si nécessaire) le code international de pays (si nécessaire) etc...

Note :	le caractère "+" est réservé à l’utilisation dans les adresses global-phone selon [E.164] et NE DOIT PAS être utilisé comme caractère de début dans une chaîne local-phone.

phone-string = 1*( DTMF / pause / tonewait / written-sep )

DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
; des codes DTMF spéciaux comme "*", "#", "A", "B", "C", "D" sont définis dans [ETS300-380] 
Note :	ces éléments ne s’appliquent qu’aux chaînes alphabétiques utilisées dans les opérations DTMF. Elles NE SONT PAS applicables aux caractères alphabétiques qui sont transposés en chiffres sur les claviers téléphoniques dans certains pays.

pause = "p"

tonewait = "w"

L’élément written-sep est défini au paragraphe 2.1 de la [RFC2303].

Note :	l’interprétation des caractères "pause" et "tonewait" dans les numéros de local-phone dépend de la mise en œuvre spécifique de MTA. Leur signification exacte n’est donc pas définie ici. "pause" et "tonewait" sont tous deux insensibles à la casse.

Note : une spécification local-phone est une séquence qui devrait n’être utilisée que par le MTA de destination spécifié par mta-I-pstn (voir la section 3 de la [RFC2303]). Selon la [RFC1123], d’autres MTA devraient transférer le message sans modifier le LHS.

2.2	Élément sub-addr-spec

Dans le service GSTN, il y a des cas où une sub-addr-spec est exigée pour spécifier la destination finale. En particulier, il y a des sous-adresses RNIS [E.164], qui s’appliquent pour divers services, tandis que d’autres types de sous-adresses peuvent être spécifiques du service (voir la sous-adresse du service T.33 de télécopie [T.33], [RFC2304]).

Au sein du fonctionnement du téléphone actuel, il peut y avoir des cas où différents types de sous-adresses sont utilisés au titre d’une seule adresse complète. Donc, la définition de la syntaxe de sub-addr-spec qui suit définit l’élément sous-adresse pour le contexte du RNIS ; l’élément sous-adresse T.33 est défini à la section 2 de la [RFC2304].

La définition de sub-addr-spec est : sub-addr-spec = [ isdn-sep isub-addr ]

En détail :
isdn-sep = "/ISUB="	; noter que "/ISUB=" est INSENSIBLE à la casse.
isub-addr = 1*( DIGIT )
isub-addr =/ 1*( DIGIT / written-sep )

Le formulaire d’enregistrement IANA pour sub-addr-spec est donné au paragraphe 11.2

2.3	Éléments post-sep et post-dial

Dans certains cas, après l’établissement de la connexion avec l’appareil GSTN de destination, Une autre séquence de numérotage est exigée pour accéder à d’autres services. Un exemple typique est un service automatique à base de menus qui utilise des séquences DTMF. Ces cas peuvent être traités en utilisant les éléments "post-sep" et "post-dial" comme définis ci dessous :

post-sep =  "/POSTD=" 	; noter que "/POSTD=" est INSENSIBLE à la casse.
post-dial = phone-string

Le formulaire d’enregistrement IANA pour post-sep et post-dial est au paragraphe 11.3

3.	Élément pstn-recipient

Il y a certaines application où il est valable d’augmenter l’élément pstn-mbox de détails supplémentaires. Les exemples courants incluent l’utilisation des noms du générateur et/ou du receveur et des adresses physiques, en particulier dans le contexte de passerelles à bretelle d’entrée/sortie.

L’élément facultatif pstn-recipient fournit la prise en charge de tels détails.

À titre d’exemple, lorsque une passerelle de télécopie à bretelle de sortie est impliquée, l’élément pstn-recipient pourrait être utilisé pour spécifier le destinataire prévu sur une page de garde de la télécopie, et l’en-tête de la page de garde de la télécopie pourrait être qualifié en utilisant les informations de pstn-recipient de l’origine.

Dans l’intérêt d’une syntaxe compacte, l’élément pstn-recipient peut être utilisé pour prendre en charge les adresses aussi bien du générateur que du receveur. Pour tous les cas des définitions ABNF qui suivent, les éléments étiquetés avec "recipient" peuvent aussi être utilisés pour les informations du générateur.

L’élément pstn-recipient est une séquence d’éléments qualif-type1 comme défini ci-dessous :

pstn-recipient = [ recipient-name ] [ 1*( recipient-qualifier ) ]

Par conséquent, la définition étendue de pstn-address devient :

pstn-address = pstn-mbox  [ qualif-type1 ]

pstn-address =/ pstn-mbox [ pstn-recipient ] [ qualif-type1 ]

La définition pour les éléments qualif-type1 est contenue dans la section 2 de la [RFC2303].

3.1	recipient-name

L’élément recipient-name spécifie le nom personnel du générateur et/ou du receveur :
recipient-name = "/ATTN=" pers-name

pers-name = [ givenname "." ] [ initials "." ] surname

Les définitions suivantes viennent directement da la spécification MIXER [RFC2156] :

surname = printablestring

givenname = 1*( DIGIT /  ALPHA / SP / "'" / "+" / "," / "-" / "/" / ":" / "=" / "?" )

initials = 1*ALPHA

Note : L’élément "initials" peut spécifier l’initiale médiane qui est courante dans certains pays ; cependant, il est aussi possible de prendre en charge plusieurs initiales, qui peuvent être d’utilisation courante dans d’autres pays. Cela permet d’avoir l’ensemble complet d’initiales des prénoms dans toutes les combinaisons possibles. Voir les exemples au paragraphe 5.2.

Il est essentiel de se rappeler que l’élément "pstn-address" (dans tous ses composants et extensions) DOIT suivre strictement les "règles de citation" spécifiées dans les normes pertinentes de messagerie électronique [RFC0822], [RFC1123].

Le formulaire d’enregistrement IANA pour recipient-name est donné au paragraphe 11.4.

3.2	Élément extensible recipient-qualifier

L’élément recipient-name n’est parfois pas suffisant pour spécifier complètement le générateur et/ou le receveur. Un ensemble supplémentaire d’éléments facultatifs, dont la définition spécifique dépend dans la plupart des cas de l’application, est donc défini:

recipient-qualifier = ( qualif-type1 / qualif-type2 )

L’élément recipient-qualifier est un élément qualif-type1, et contient un élément qualif-type1 dans une définition récurrente qui permet un format extensible. L’objet de l’élément qualif-type2 est de permettre une extensibilité supplémentaire pour les éléments qui vont au delà de la portée de ceux définis pour être utilisés avec l’élément qualif-type1.

Une série d’éléments qualif-type2 est définie ci-dessous :

qualif-type2 = "/" qual2-label "=" string

qual2-label = "ORG" / "OFNO" / "OFNA" / "STR" / "ADDR" "ADDU" / "ADDL" / "POB" / "ZIP" / "CO"

string = PCHAR	; noter que les caractères imprimables sont de %x20 à 7E.

printablestring = 1*( DIGIT / ALPHA / SP / "'" / "(" / ")" / "+" / "," / "-" / "." / "/" / ":" / "=" / "?" )
; cette définition vient de l’UIT-T F.401 [F.401] et de MIXER [RFC2156].

Le Tableau 1 comporte une courte définition des champs qual2-label :

Tableau 1 - qual2-label

Étiquette qual2	Description
"ORG"	Nom d’organisation pour livraison physique (exemple : ACME Inc)
"OFNO"	Numéro de bureau pour livraison physique (exemple : BLD2-44)
"OFNA"	Nom de bureau pour livraison physique (exemple : Ventes)
"STR"	Adresse de rue pour livraison physique (exemple :  45, Grand Rue)
"ADDR"	Adresse postale non formatée pour livraison physique (exemple : HWY 14, km 94,5 - Loc. Redhill)
"ADDU"	Nom postal univoque pour livraison physique (exemple : ACMETELEX)
"ADDL"	Attributs postaux locaux pour livraison physique (exemple : Entrée 3, 3ème étage, appart. 296)
"POB"	Boîte postale pour livraison physique
"ZIP"	Code postal ZIP pour livraison physique
"CO"	Nom de pays pour livraison physique

Un élément ou une combinaison de plusieurs des éléments ci-dessus est généralement suffisant pour spécifier exactement le générateur et/ou receveur du message. L’utilisation d’un grand nombre de ces éléments pourrait en fait créer un très long recipient-qualifier. Donc,seuls les éléments strictement nécessaires DEVRAIENT être utilisés. La longueur maximale totale de pstn-email NE DOIT PAS en fait excéder la limite spécifiée dans les normes pertinentes de messagerie électronique [RFC0822], [RFC1123].

Note :	Bien que la signification des éléments ci-dessus soit déduite directement des éléments similaires disponibles dans la spécification [F.401], la convention de désignation utilisée dans le présent document est explicitement différente. De cette façon, un conflit est évité avec les règles d’adressage X.400. Les autres spécifications qui utilisent le mécanisme d’extension du présent document pour définir de nouveaux éléments qualif-type1 qui se recouvrent avec F.401 devront veiller à créer de nouvelles étiquette différentes de celles utilisées dans F.401.

Le formulaire d’enregistrement IANA pour ces éléments est donné aux paragraphes 11.5 à 11.14.

4.	Cas de sub-addr-spec multiples

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

Note de mise en œuvre : L’UA 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 "pstn-mbox" lorsque il soumet le message au MTA.

5.	Exemples

Afin de préciser la spécification, on présente ici un ensemble limité d’exemples. Beaucoup des exemples se réfèrent au service de télécopie, mais des services supplémentaires possibles sont aussi inclus. Voir aussi les exemples de la [RFC2303] et de la [RFC2304] pour des informations supplémentaires. Noter que tous les exemples ne sont donnés qu’à titre d’illustration.

5.1	Exemples de pstn-mbox

Une adresse pstn-mbox en Italie pour le service de télécopie, numérotée aux U.S.A., utilisant un téléphone local, sans sub-addr-spec et sans written-sep :

FAX=0103940226338

Une adresse pstn-mbox en Allemagne pour un service XYZ hypothétique, en utilisant le téléphone mondial, avec une sub-addr-spec RNIS et written-sep "." :

XYZ=+49.81.7856345/ISUB=1234

Une adresse pstn-mbox aux U.S.A. pour le service de télécopie, utilisant le téléphone mondial, avec la sub-addr-spec T.33 8745, avec written-sep "-" et la séquence post-dial p1w7005393w373

FAX=+1-202-455-7622/T33S=8745/PostD=p1w7005393w373

Une adresse pstn-mbox en Italie pour le service de télécopie, utilisant le téléphone local, numérotée à partir d’un MTA en Allemagne, (code d’accès international "00", avec la sous-adresse RNIS 9823, avec la sous-adresse T.33 "4312" et sans pause ni written-sep:

FAX=003940226338/Isub=9823/T33S=4312

La même adresse pstn-mbox en Italie, en utilisant le téléphone local numéroté à partir d’un MTA en Italie (appel longue distance) avec le code d’accès longue distance "0", avec exit-code "9", sous-adresse T.33 "4312", pause "p" et written-sep "." :

FAX=9p040p22.63.38/t33s=4312

Une adresse pstn-mbox en Amérique du Nord pour un service XYZ hypothétique, utilisant le téléphone mondial, sans sub-addr-spec et avec written-sep "-" et "." :

XYZ=+1.202.344-5723

Une adresse pstn-mbox pour le service de télécopie en France, utilisant le téléphone local numéroté à partir d’un MTA en France (appel longue distance) avec le exit-code "0", la sous-adresse T.33 "3345" et pause "p" :

FAX=0p0134782289/T33s=3345

Une adresse pstn-mbox pour le service de télécopie en Amérique du Nord, utilisant le téléphone local, sans sub-addr-spec, sans local-number, utilisant seulement des séquences post-dial pour atteindre les numéros mémorisés dans une base de données de numéros abrégés définie en local, où 6743 est un mot de passe d’accès, et 99p51 est la séquence pour accéder au numéro abrégé local :

FAX=/postd=w6743w99p51

5.2	Exemples de pstn-recipient

Voici un certain nombre d’exemples de pstn-recipient. Noter que pstn-recipient est juste un élément facultatif, et donc qu’un élément pstn-mbox est aussi exigé dans une pstn-address.

Un pstn-recipient utilisant seulement recipient-name, avec les initiales du prénom et le nom :

/ATTN=Tom.J.Smiths

Un pstn-recipient utilisant seulement recipient-name, avec le prénom, un jeu complet d’initiales (incluant l’initiale "C" du prénom) et un nom de famille (où les prénoms "réels" sont "Carlo Maria Luis Santo" et le nom de famille est "Nascimento"):

/ATTN=Carlo.CMLS.Nascimento

Un pstn-recipient utilisant seulement recipient-name, avec prénom et nom de famille :

/ATTN=Mark.Collins

Un pstn-recipient utilisant seulement un recipient-name, avec seulement le nom de famille :

/ATTN=Smiths

Un pstn-recipient utilisant le recipient-name, et un élément recipient-qualifier :

/ATTN=J.Smiths/OFNA=Contrôle qualité

Un pstn-recipient utilisant seulement deux extensions recipient-qualifier :

/OFNO=T2-33A/OFNA=Contrôle qualité

Un fax-recipient utilisant des recipient-qualifier pour la livraison physique :

/STR=45, Grand Rue/OFNA=Bureau des ventes

5.3	Exemples de pstn-address

Des exemples de pstn-address, obtenus en combinant des éléments des exemples précédents. Il y a des adresses complètes qui peuvent être utilisées comme élément "partie locale" (LHS) d’une adresse de messagerie électronique.

Sans pstn-recipient facultatif (service de télécopie) :

FAX=+12023445723

Avec pstn-recipient (service XYZ) :

XYZ=+3940226338/ATTN=Mark.Collins

Avec un pstn-recipient fait de deux extensions recipient-qualifier (service de télécopie) :

FAX=9p040p22.63.38/t33s=4312/ofno=T2-33A/OFNA=Q-C

5.4	Exemples de pstn-email

Voici les mêmes adresses que précédemment, où "faxgw" est le champ mta-I-pstn pour le service de télécopie.

FAX=+12023445723@faxgw

FAX=+39-40-226338/ATTN=Mark.Collins@faxgw

FAX=9p040p226338/T33S=4312/OFNO=T2-33A/OFNA=Q-C@faxgw

FAX=+39040226338/ATTN=Mark.Collins/@faxgw

Note : le "/" facultatif en tête pour le signe "@" peut être généré par les passerelles avec d’autres services, comme MIXER [RFC2156].

5.5	Exemple de transaction SMTP complète

Voici un exemple de transaction SMTP complète.

S: <écoutant sur accès SMTP>
C: <ouvre une connexion à l’accès SMTP>
S: 220 foo.domain.com ESMTP service prêt
C: EHLO pc.mailfax.com
S: 250 foo.domain.com dit bonjour
C: MAIL FROM:<tom@mailfax.com>
S: 250 <tom@mailfax.com> Envoyeur ok
C: RCPT TO:<FAX=+3940226338@foo.mailfax.com>
S: 250 <FAX=+3940226338> receveur ok
C: DATA
S: 354 Entrez vos données
C: From: Thomas Blake <tom@mailfax.com>
C: To: Jim Burton <FAX=+3940226338@foo.mailfax.com>
C: Objet : Bonjour chez vous
C: MIME-version: 1.0
C: Date: Mon, 01 Sep 1997 18:14:23 -0700
C: Content-Type: multipart/mixed; boundary=16820115-1435684603#2306
C:
C: Ceci est un message MIME. Il contient une partie de corps TIFF fax
C:
C: --16820115-1435684603#2306
C: Content-Type: image/TIFF
C: Content-Transfer-Encoding: BASE64
C: Content-Description: FAX
C:
C: ABAA745HDKLSW932ALSDL3ANCVSASDFLALSDFA
C: 87AASS2999499ASDANASDF0000ASDFASDFNANN
C: 87BBHDXBADS00288SADFNAZBZNNDNNSNNA11A0
C: H8V73KS0C8JS6BFJEH78CDWWDUJEDF7JKES8==
C: --16820115-1435684603#2306--
C: .
S: 250 D’accord
C: QUIT
S: 221 Au revoir

6.	Conclusion

Cette proposition crée un ensemble standard d’extensions pour les adresses GSTN, enrichissant la spécification minimale existante [RFC2303]. La proposition est cohérente avec les normes existantes de messagerie électronique, mais permet une spécification plus détaillée d’adresse GSTN, incluant des éléments spécifiques par générateur et/ou receveur. Le mécanisme d’enregistrement de l’IANA pour permettre l’ajout de nouveaux services et qualificatifs en utilisant les adresses GSTN est aussi fourni.

7.	Considérations sur la sécurité

Le présent document spécifie un moyen par lequel les adresses GSTN peuvent être codées 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, ce qui causerait le détournement de messages électroniques via certains MTA ou passerelles où la sécurité du logiciel a été compromise.

Il y a plusieurs moyens par lesquels un agresseur peut se rendre capable de livrer des informations d’acheminement de messagerie incorrectes à un client. Cela inclut : (a) de compromettre un serveur DNS, (b) de générer une réponse contrefaite aux interrogations du DNS d’un client, (c) de retourner des "informations supplémentaires" incorrectes en réponse à une interrogation sans rapport. Les clients DEVRAIENT s’assurer que l’acheminement de messagerie ne se fonde que sur des réponses d’autorité. Une fois que les mécanismes de sécurité du DNS [E.164] 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.

Certains serveurs GSTN exigent de taper des codes privés, comme des numéros d’identification personnelle, pour appeler un receveur de télécopie groupe 3, ou pour accéder à des services spéciaux. Comme les adresses de messagerie électronique sont transmises sans codage sur le service de transport des MTA, cela pourrait permettre à des personnes non autorisées d’obtenir l’accès à ces codes lorsque ils sont utilisés au sein d’un téléphone local. De plus, ces codes peuvent apparaître dans certains cas dans les adresses du générateur et/ou du receveur sur les pages de garde livrées via des passerelles à bretelle de sortie à des receveurs de télécopie groupe 3. Les envoyeurs DEVRAIENT se voir fournir des méthodes pour empêcher cette divulgation, comme le chiffrement du code, ou des techniques de déguisement : communication hors bande des informations d’autorisation ou utilisation de données chiffrées dans des champs spéciaux sont les techniques non standard disponibles.

8.	Syntaxe ABNF

Dans cette section, on fournit un sommaire de la spécifications ABNF qui définit à la fois l’ensemble minimal [RFC2303] et les éléments étendus de pstn-address.

pstn-email =  ["/"] pstn-address ["/"] "@" mta-I-pstn
mta-I-pstn = domain
pstn-address = pstn-mbox  [ qualif-type1 ]
pstn-address =/ pstn-mbox [ pstn-recipient ] [ qualif-type1 ]
pstn-mbox = service-selector "=" global-phone
pstn-mbox =/ service-selector "=" gstn-phone [ sub-addr-spec ] [post-sep post-dial]
service-selector = 1*( DIGIT / ALPHA / "-" )
qualif-type1 = "/" keyword "=" string
keyword = 1*( DIGIT / ALPHA / "-" )
string = PCHAR
gstn-phone = ( global-phone / local-phone )
global-phone = "+" 1*( DIGIT / written-sep )
local-phone = [ exit-code ] [ dial-number ]
exit-code = phone-string
dial-number = phone-string
phone-string = 1*( DTMF / pause / tonewait / written-sep )
DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
written-sep = ( "-" / "." )
pause = "p"
tonewait = "w"
sub-addr-spec = [ isdn-sep isub-addr ]
isdn-sep = "/ISUB="
isub-addr = 1*( DIGIT )
isub-addr =/ 1*( DIGIT / written-sep )
post-sep =  "/POSTD="
post-dial = phone-string
pstn-recipient = [ recipient-name ] [ 1*( recipient-qualifier ) ]
recipient-name = "/ATTN=" pers-name
pers-name = [ givenname "." ] [ initials "." ] surname
surname = printablestring
givenname = 1*( DIGIT /  ALPHA / SP / "'" / "+" / "," / "-" / "/" / ":" / "=" / "?" )
initials = 1*ALPHA
recipient-qualifier = ( qualif-type1 / qualif-type2 )
qualif-type2 = "/" qual2-label "=" string
qual2-label = "ORG" / "OFNO" / "OFNA" / "STR" / "ADDR" "ADDU" / "ADDL" / "POB" / "ZIP" / "CO"
printablestring = 1*( DIGIT / ALPHA / SP / "'" / "(" / ")" / "+" / "," / "-" / "." / "/" / ":" / "=" / "?" )

9.	Considérations relatives à l’IANA

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

Pour enregistrer un élément service-selector ou qualif-type1, le gabarit du formulaire d’enregistrement donné aux paragraphes 10.1 et 10.2 DOIT être utilisé. Tout nouvel enregistrement DOIT satisfaire aux critères de "Spécification exigée", comme défini à 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 disponible, en détails suffisants 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 apportés par une spécification répondant aux critères définis ci-dessus et qui ne sont pas pleinement spécifiés selon les gabarits de formulaire donnés aux paragraphes 10.1 et 101.2. En cas de besoin de consultation plus approfondie sur l’acceptation d’un nouvel enregistrement, l’IANA DEVRAIT se référer au Directeur de zone d’application pour être dirigé sur "l’expert" individuel ou le groupe de travail de l’IETF approprié.

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

9.1	Gabarit de formulaire d’enregistrement IANA pour les nouvelles valeurs de service-selector d’adresse GSTN

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour la spécification du service-selector d’adresse GSTN "foo"
Nom du service-selector : foo
Description de l’utilisation : foo - ("foo" est un nouveau sélecteur de service fictif utilisé dans ce gabarit comme exemple ; il est à remplacer par la nouvelle valeur à enregistrer. Inclure ici une brève description de l’utilisation de la nouvelle valeur. Cela DOIT inclure une référence 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 assez complètement pour permettre une mise en œuvre indépendante).
Considérations pour la sécurité : (Toute considération sur la sécurité supplémentaire qui peut être introduite par l’utilisation du nouveau paramètre de sélecteur de service devrait être définie ici ou dans les RFC en cours de normalisation de référence).
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : (fournir les informations de contact).
Information sur le soumettant : Les enregistrements acceptés seront mentionnés dans la série de RFC "Numéros alloués". Les informations du formulaire d’enregistrement sont en accès libre.

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

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 d’adresse GSTN "bar".
Nom du "mot-clé" qualif-type1 : bar
Définition ABNF de la "valeur" de qualif-type1 : abnf - ("abnf" DOIT définir la forme ABNF de la valeur de qualif-type1. La spécification ABNF DOIT être autonome, utilisant comme éléments de base les jetons donnés dans la [RFC2234]. Pour éviter toute duplication (lorsque approprié) elle DOIT aussi utiliser pour sa construction les jetons non de base déjà enregistrés provenant d’autres éléments qualif-type1, c’est-à-dire qu’elle DOIT utiliser les mêmes noms de jeton non de base et répéter leur définition ABNF identique à partir des jetons de base ; voir des exemples à la section 11.
Description de l’utilisation : bar - ("bar" est une description fictive d’un nouvel élément qualif-type1 utilisé dans ce gabarit comme exemple. Il est à remplacer par la description réelle de l’élément qualif-type1 enregistré. Inclure ici une courte description de l’utilisation du nouveau qualif-type1. Cela DOIT inclure une référence à des RFC en cours de normalisation et éventuellement à des documents d’autres organisations de normalisation pour la description complète ; l’utilisation de la valeur DOIT être définie assez complètement pour permettre une mise en œuvre indépendante.)
Restrictions d’utilisation : (Si le nouvel élément qualif-type1 n’a de signification que pour un ensemble spécifique d’éléments de service, on DOIT spécifier ici la liste des types d’éléments de service permis. Si il n’y a pas de restriction, spécifier alors le mot-clé "aucune".)
Considérations pour la sécurité : (Toute considération supplémentaire de sécurité qui pourrait être introduite par l’utilisation 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.)
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : (informations de contact)
Informations au soumettant : Les enregistrements acceptés seront mentionnés dans la série des RFC des "Numéros alloués". Les informations du formulaire d’enregistrement sont en accès libre.

10.	Formulaire d’enregistrement IANA pour nouvelles valeurs de service-selector "FAX"

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour spécifier le sélecteur de service "FAX" d’adresse GSTN
Nom du sélecteur de service : FAX
Description de l’utilisation : FAX – spécifie que l’adresse GSTN se réfère soit à un appareil de télécopie Internet, soit à une passerelle à bretelle d’entrée/sortie de télécopie. Pour une description complète, se référer à la RFC2304 et la RFC2303
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.	Formulaire d’enregistrement IANA pour les nouvelles valeurs de mot-clé et valeur de qualit-type1 d’adresse GSTN
11.1	T33S

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "T33S" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : T33S
Définition ABNF de la "valeur" qualif-type1 : sub-addr = 1*( DIGIT )
Description de l’utilisation : T33S est utilisé pour spécifier l’élément strictement numérique facultatif de sous-adresse de télécopie décrit dans la Recommandation UIT-T T.33 "Acheminement de la télécopie utilisant la sous-adresss" (juillet  1996). Une description plus détaillée est disponible dans la RFC2304.
Restrictions d’utilisation : L’utilisation de "T33S" est réservée au sélecteur de service "FAX", 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 RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.2	ISUB

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "ISUB" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 :      ISUB
Définition ABNF de la "valeur" qualif-type1 :
isub-addr = 1*( DIGIT )
isub-addr =/ 1*( DIGIT / written-sep )
written-sep = ( "-" / "." )
Description de l’utilisation : "ISUB" est utilisé pour spécifier les éléments facultatifs de sous-adresse RNIS utilisés dans le service RNIS pour atteindre des objets spécifiques du service RNIS. Il peut éventuellement incorporer des éléments de séparateur écrits dans le seul but d’améliorer la lisibilité pour l’homme. Voir les détails dans la RFC2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.3	POSTD

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "POSTD" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : POSTD
Définition ABNF de la "valeur" qualif-type1 :
phone-string = 1*( DTMF / pause / tonewait / written-sep )
DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
pause = "p"
tonewait = "w"
written-sep = ( "-" / "." )
Description de l’utilisation : POSTD est la séquence facultative de suite de numérotation nécessaire pour accéder à des services supplémentaires (par exemple une interface pilotée par un menu) disponibles après l’accès au site du service en utilisant le gstn-phone. Voir les détails dans la RFC2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.4	ATTN

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "ATTN" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : ATTN
Définition ABNF de la "valeur" qualif-type1 :
pers-name = [ givenname "." ] [ initials "." ] surname
surname = printablestring
givenname = 1*( DIGIT /  ALPHA / SP / "'" / "+" / "," / "-" / "/" / ":" / "=" / "?" )
initials = 1*ALPHA
printablestring = 1*( DIGIT / ALPHA / SP / "'" / "(" / ")" / "+" / "," / "-" / "." / "/" / ":" / "=" / "?" )
Description de l’utilisation : Pour spécifier le nom personnel de l’individu prévu comme générateur ou receveur du message. Voir les détails dans la RFC2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.5	ORG

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "ORG" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 :  ORG
Définition ABNF de la "valeur" qualif-type1 :      string = PCHAR
Description de l’utilisation : Pour spécifier le nom d’organisation (exemple : ACME Inc.) Voir les détails dans la RFC  2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.6	OFNO

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "OFNO" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : OFNO
Définition ABNF de la "valeur" qualif-type1 : string = PCHAR
Description de l’utilisation : Pour spécifier le numéro de bureau (exemple : BLD2-44) Voir les détails dans la RFC  2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.7	OFNA

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "OFNA" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : OFNA
Définition ABNF de la "valeur" qualif-type1 :      string = PCHAR
Description de l’utilisation : Pour spécifier le nom du bureau (exemple  : Ventes) Voir les détails dans la RFC  2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.8	STR

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "STR" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : STR
Définition ABNF de la "valeur" qualif-type1 :  string = PCHAR
Description de l’utilisation : Pour spécifier l’adresse (exemple : 45, Grand rue). Voir les détails dans la RFC  2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.9	ADDR

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "ADDR" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : ADDR
Définition ABNF de la "valeur" qualif-type1 : string = PCHAR
Description de l’utilisation : Pour spécifier une adresse postale non formatée (exemple : HWY 14, km 94,5 - Loc. Redhill). Voir les détails dans la RFC  2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.10	ADDU

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "ADDU" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : ADDU
Définition ABNF de la "valeur" qualif-type1 : string = PCHAR
Description de l’utilisation : Pour spécifier le nom postal (exemple : ACMETELEX). Voir les détails dans la RFC  2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.11	ADDL

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "ADDL" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : ADDL
Définition ABNF de la "valeur" qualif-type1 : string = PCHAR
Description de l’utilisation : Pour spécifier des attributs postaux locaux (exemple : Entrée 3, 3ème étage, Appart. 296). Voir les détails dans la RFC  2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.12	POB

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "POB" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : POB
Définition ABNF de la "valeur" qualif-type1 : string = PCHAR
Description de l’utilisation : Pour spécifier la boîte postale (exemple : CP 1374). Voir les détails dans la RFC  2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.13	ZIP

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "ZIP" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : ZIP
Définition ABNF de la "valeur" qualif-type1 : string = PCHAR
Description de l’utilisation : Pour spécifier le code postal ZIP (exemple : I 34012). Voir les détails dans la RFC  2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

11.14	CO

To: IANA@isi.edu
Objet : Enregistrement de nouvelles valeurs pour l’élément qualif-type1 "CO" d’adresse GSTN.
Nom du "mot-clé" qualif-type1 : CO
Définition ABNF de la "valeur" qualif-type1 : string = PCHAR
Description de l’utilisation : Pour spécifier le nom du pays (exemple : Belgique) Voir les détails dans la RFC  2846.
Restrictions d’utilisation : aucune.
Considérations pour la sécurité : Voir la Section Considération pour la sécurité de la RFC2846.
Adresse postale et de messagerie de la personne à contacter pour d’autres informations : Voir la Section Adresse de l’auteur ci-dessous

12.	Adresse de l’auteur

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

mél : Claudio.Allocchio@elettra.trieste.it 
X.400:  C=it;A=garr;P=Trieste;O=Elettra;S=Allocchio;G=Claudio;
téléphone :  +39 040 3758523
fax :    +39 040 3758565

13.	Références

[E.164]	Recommandation UIT-T E.164 "Plan de numérotoage international des télécommunications publiques E.164/I.331", mai  1997.

[ETS300-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 traitement des messages : dénomination et adressage pour service public de traitement de message", août 1992.

[F.423]	Recommandation UIT-T F.423 "Services de traitement des messages : intercommunication entre le service de messagerie interpersonnelle et le service de télécopie" , août 1992.

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

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

[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. (MàJ RFC0822) (P.S.)

[RFC2303]	C. Allocchio, "Format minimal d'adresse RTPC dans la messagerie Internet", mars 1998. (Obsolète, voir RFC3191) (P.S.)

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

[RFC2304]	C. Allocchio, "Format minimal d'adresse de télécopie dans la messagerie Internet", mars 1998. (Obsolète, voir RFC3192) (P.S.)

[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. (Oobsolète, voir la RFC5226)

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

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

Copyright (C) The Internet Society (2000). 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.

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