Groupe de travail Réseau	G. Good, iPlanet e-commerce Solutions	
Request for Comments : 2849	juin 2000	
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle	

Format d’échange de données LDAP (LDIF) - Spécification technique

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

Résumé
Le présent document décrit un format de fichier convenable pour la description des informations d’un répertoire ou les modifications faites aux informations d’un répertoire. Le format de fichier, connu sous le nom de format d’échange de données pour LDAP (LDIF, LDAP Data Interchange Format) est normalement utilisé pour importer et exporter des informations de répertoires entre des serveurs de répertoires fondés sur LDAP, ou pour décrire un ensemble de changements qui sont à appliquer à un répertoire.

Fondements et utilisation prévue

Il y a un certain nombre de situations où un format commun d’échange est souhaitable. Par exemple, on peut souhaiter exporter une copie du contenu d’un serveur de répertoires dans un fichier, déplacer ce fichier dans une machine différente, et importer le contenu dans un second serveur de répertoires.

De plus, en utilisant un format d’échange bien défini, le développement d’outils d’importation de données de systèmes traditionnels est facilité. Un ensemble très simple d’outils écrits en awk ou perl peut, par exemple, convertir une base de données d’informations personnelles en un fichier LDIF. Ce fichier peut alors être importé dans un serveur de répertoire, sans considération de la représentation interne de la base de données qu’utilise le serveur de répertoires cible.

Le format LDIF a été développé à l’origine et utilisé dans la mise en œuvre de LDAP de l’Université du Michigan. La première utilisation de LDIF a été pour décrire des entrées de répertoire. Plus tard, le format a été étendu pour permettre la représentation des changements des entrées de répertoire.

Relations avec le type de contenu MIME application/directory

Le type de contenu MIME application/directory [RFC2425] est un cadre général et un format pour transporter des informations de répertoire, et est indépendant de tout service de répertoire particulier. Le format LDIF est un format plus simple qui est peut-être plus facile à créer, et peut aussi être utilisé, comme on l’a noté, pour décrire un ensemble de changements à appliquer à un répertoire.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

Définition du format d’échange de données LDAP

Le format LDIF est utilisé pour porter des informations de répertoire, ou une description d’un ensemble de changements faits à des entrées de répertoire. Un fichier LDIF consiste en une série d’enregistrements séparés par des séparateurs de lignes. Un enregistrement consiste en une séquence de lignes qui décrivent une entrée de répertoire, ou une séquence de lignes décrivant un ensemble de changements à une entrée de répertoire. Un fichier LDIF spécifie un ensemble d’entrées, ou un ensemble de changements à appliquer aux entrées de répertoire, mais pas les deux.

Il y a une corrélation biunivoque entre les opérations LDAP qui modifient le répertoire (add, delete, modify, et modrdn) et les types de changerecords décrits ci-dessous ("add", "delete", "modify", et "modrdn" ou "moddn"). Cette correspondance est intentionnelle, et permet une traduction directe des changerecords LDIF en opérations de protocole.

Définition formelle de la syntaxe de LDIF

La définition suivante utilise la forme Backus-Naur augmenté spécifiée dans la [RFC2234].

ldif-file = ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-changes = version-spec 1*(1*SEP ldif-change-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
ldif-change-record = dn-spec SEP *control changerecord
version-spec = "version:" FILL version-number
version-number  = 1*DIGIT	; version-number DOIT être "1" pour le format LDIF décrit dans ce document.
dn-spec = "dn:" (FILL distinguishedName / ":" FILL base64-distinguishedName)
distinguishedName = SAFE-STRING	; nom distinctif, comme défini dans la [RFC2253].
base64-distinguishedName = BASE64-UTF8-STRING 	; nom distinctif codé en base64 (voir note 10)
rdn = SAFE-STRING 	; nom distinctif relatif, défini comme <name-component> dans la [RFC2253].
base64-rdn = BASE64-UTF8-STRING 	; rdn codé en base64 (voir note 10)
control = "control:" FILL ldap-oid 	; controlType
                           0*1(1*SPACE ("true" / "false")) 	; criticality
                           0*1(value-spec)  	; controlValue
                           SEP 	; (voir note 9, below)
ldap-oid = 1*DIGIT 0*("." 1*DIGIT)	; OID LDAP, comme défini dans la [RFC2251].
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" (    FILL 0*1(SAFE-STRING) / ":" FILL (BASE64-STRING) / "<" FILL url)	; voir notes 7 et 8.
url = <Localisateur de ressource universel, comme défini dans la [RFC1738]>	; (voir note 6)
AttributeDescription = AttributeType [";" options]	; Définition tirée de la [RFC2251].
AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
options  = option / (option ";" options)
option = 1*opt-char
attr-type-chars = ALPHA / DIGIT / "-"
opt-char  = attr-type-chars
changerecord = "changetype:" FILL (change-add / change-delete / change-modify / change-moddn)
change-add  = "add" SEP 1*attrval-spec
change-delete = "delete" SEP
change-moddn = ("modrdn" / "moddn") SEP "newrdn:" ( FILL rdn / ":" FILL base64-rdn) SEP "deleteoldrdn:" FILL ("0" / "1")  SEP 0*1("newsuperior:" ( FILL distinguishedName / ":" FILL base64-distinguishedName) SEP)
; Si deleteoldrdn est "0" le vieux rdn sera gardé ; si il est à "1" le vieux rdn sera supprimé.
change-modify = "modify" SEP *mod-spec
mod-spec = ("add:" / "delete:" / "replace:") FILL AttributeDescription SEP *attrval-spec  "-" SEP
SPACE = %x20	; ASCII SP, espace.
FILL = *SPACE
SEP = (CR LF / LF)
CR = %x0D    	; ASCII CR, retour chariot.
LF  = %x0A	; ASCII LF, saut à la ligne.
ALPHA = %x41-5A / %x61-7A	; A à Z / a à z.
DIGIT  = %x30-39	; 0 à 9.
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F	; toute valeur ≤ 127 décimal sauf NUL, LF, et CR.
SAFE-INIT-CHAR  = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B / %x3D-7F
; toute valeur ≤ 127sauf NUL, LF, CR, SPACE, deux-points (":", ASCII 58 décimal) et inférieur à ("<" , ASCII 60 décimal)
SAFE-STRING  = [SAFE-INIT-CHAR *SAFE-CHAR]
UTF8-CHAR  = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
UTF8-STRING = *UTF8-CHAR
BASE64-UTF8-STRING = BASE64-STRING	; DOIT être un codage base64 d’une chaîne UTF8.
BASE64-CHAR  = %x2B / %x2F / %x30-39 / %x3D / %x41-5A / %x61-7A	; +, /, 0-9, =, A à Z, et a à z comme spécifié dans la [RFC2045]
BASE64-STRING = [*(BASE64-CHAR)]

Notes sur la syntaxe de LDIF

1)	Pour le format LDIF décrit dans ce document, le numéro de version DOIT être "1". Si le numéro de version est absent, les mises en œuvre PEUVENT choisir d’interpréter le contenu comme un format de fichier LDIF plus ancien, pris en charge par la mise en œuvre ldap-3.3 de l’Université du Michigan [SLADP].

2)	Toute ligne non vide, y compris les lignes de commentaires, dans un fichier LDIF PEUT se poursuivre en insérant un séparateur de ligne (SEP) et un caractère SPACE. Le passage à la ligne NE DOIT PAS se produire avant le premier caractère de la ligne. En d’autres termes, couper une ligne en deux lignes, la première étant vide, n’est pas permis. Toute ligne qui commence par une seule espace DOIT être traitée comme une continuation de la ligne précédente (non vide). Lorsque on fusionne des lignes séparées, exactement un caractère espace au début de chaque ligne de continuation doit être éliminé. Les mises en œuvre NE DEVRAIENT PAS couper des lignes au milieu d’un caractère UTF-8 multi-octets.

3)	Toute ligne qui commence par un signe dièse ("#", ASCII 35) est une ligne de commentaire, et DOIT être ignorée à l’analyse d’un fichier LDIF.

4)	Tout nom distinctif (dn) ou nom distinctif relatif (rdn) qui contient des caractères autres que ceux définis comme "SAFE-UTF8-CHAR", ou commence par un caractère autre que ceux définis dans "SAFE-INIT-UTF8-CHAR", ci-dessus, DOIT être codé en base-64. D’autres valeurs PEUVENT être codées en base-64. Toute valeur qui contient des caractères autres que ceux définis comme "SAFE-CHAR", ou commence par un caractère autre que ceux définis comme "SAFE-INIT-CHAR", ci-dessus, DOIT être codée en base-64. D’autres valeurs PEUVENT être codées en base-64.

5)	Lorsque une valeur d’attribut de longueur zéro doit être incluse directement dans un fichier LDIF, elle DOIT être représentée comme AttributeDescription ":" FILL SEP. Par exemple, "seeAlso:" suivi par une nouvelle ligne représente une valeur d’attribut "seeAlso" de longueur zéro. Il est aussi permis que la valeur référencée par un URL soit de longueur zéro.

6)	Lorsque un URL est spécifié dans un attrval-spec, les conventions suivantes s’appliquent :
a)	Les mises en œuvre DEVRAIENT prendre en charge le format d’URL file://. Le contenu du fichier référencé est à inclure textuellement dans le résultat interprété du fichier LDIF.
b)	Les mises en œuvre PEUVENT prendre en charge d’autres formats d’URL. La sémantique associée à chaque URL pris en charge sera documentée dans une déclaration d’applicabilité associée.

7)	Les noms distinctifs, les noms distinctifs relatifs, et les valeurs d’attribut de syntaxe DirectoryString DOIVENT être des chaînes UTF-8 valides. Les mises en œuvre qui lisent LDIF PEUVENT interpréter les fichiers dans lesquels ces entités sont mémorisées dans un autre codage de jeu de caractères, mais les mises en œuvre NE DOIVENT PAS générer de contenu LDIF qui ne contiendrait pas de données UTF-8 valides.

8)	Les valeurs ou noms distinctifs qui se terminent par une ESPACE DEVRAIENT être codés en base-64.

9)	Lorsque des contrôles sont inclus dans un fichier LDIF, les mises en œuvre PEUVENT choisir d’en ignorer certaines ou toutes. Cela peut être nécessaire si les changements décrits dans le fichier LDIF sont à envoyer sur une connexion LDAPv2 (LDAPv2 n’accepte pas les contrôles) ou si ces contrôles particuliers ne sont pas acceptés par le serveur distant. Si la criticité d’un contrôle est "vrai", la mise en œuvre DOIT alors inclure le contrôle, ou NE DOIT PAS envoyer l’opération à un serveur distant.

10)	Lorsque un attrval-spec, un distinguishedName, ou un rdn est codé en base64, les règles de codage spécifiées dans la [RFC2045] sont utilisées avec les exceptions suivantes :
a)	L’exigence que les flux de sortie en base64 doivent être représentés comme des linges de pas plus de 76 caractères est supprimée. Les lignes dans les fichiers LDIF peuvent seulement être coupées selon les règles de saut à la ligne décrites dans la note 2, ci-dessus.
b)	Les chaînes en base64 dans la [RFC2045] peuvent contenir des caractères autres que ceux définis dans BASE64-CHAR, et sont ignorées. LDIF ne permet aucun caractère étranger, autres que ceux utilisés pour le saut à la ligne.

Exemples de format d’échange de données LDAP

Exemple 1 : Un simple fichier LDAP avec deux entrées

version: 1
dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Barbara Jensen
cn: Barbara J Jensen
cn: Babs Jensen
sn: Jensen
uid: bjensen
telephonenumber: +1 408 555 1212
description: Fanatique de voile.

dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bjorn Jensen
sn: Jensen
telephonenumber: +1 408 555 1212

Exemple 2 : Fichier contenant une entrée avec une valeur d’attribut sur deux lignes

version: 1
dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
objectclass:top
objectclass:person
objectclass:organizationalPerson
cn:Barbara Jensen
cn:Barbara J Jensen
cn:Babs Jensen
sn:Jensen
uid:bjensen
telephonenumber:+1 408 555 1212
description:Babs est une grande fanatique de voile, et voyage de façon extensive à la rech
 erche de conditions de navigation parfaites.
title:Gestionnaire de produit, Division tiges et bobines

Exemple 3 : Fichier contenant une valeur codée en base-64.

version: 1
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
uid: gernj
telephonenumber: +1 408 555 1212
description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu

Exemple 4 : Fichier contenant une entree avec des valeurs d’attribut codées en UTF-8, incluant des étiquettes de langage. Des commentaires indiquent le contenu des attributs et noms distinctifs codés en UTF-8.

version: 1
dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: ou=<JapaneseOU>,o=Airius
objectclass: top
objectclass: organizationalUnit
ou:: 5Za25qWt6YOo
# ou:: <JapaneseOU>
ou;lang-ja:: 5Za25qWt6YOo
# ou;lang-ja:: <JapaneseOU>
ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2

# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
ou;lang-en: Sales
description: Japanese office

dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: rogasawara
mail: rogasawara@airius.co.jp
givenname;lang-ja:: 44Ot44OJ44OL44O8
# givenname;lang-ja:: <JapaneseGivenname>
sn;lang-ja:: 5bCP56yg5Y6f
# sn;lang-ja:: <JapaneseSn>
cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn;lang-ja:: <JapaneseCn>
title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
# title;lang-ja:: <JapaneseTitle>
preferredlanguage: ja
givenname:: 44Ot44OJ44OL44O8
# givenname:: <JapaneseGivenname>
sn:: 5bCP56yg5Y6f
# sn:: <JapaneseSn>
cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn:: <JapaneseCn>
title:: 5Za25qWt6YOoIOmDqOmVtw==
# title:: <JapaneseTitle>
givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
# givenname;lang-ja;phonetic::
<JapaneseGivenname_in_phonetic_representation_kana>
sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
# title;lang-ja;phonetic::
# <JapaneseTitle_in_phonetic_representation_kana>
givenname;lang-en: Rodney
sn;lang-en: Ogasawara
cn;lang-en: Rodney Ogasawara
title;lang-en: Sales, Director

Exemple 5 : Fichier contenant une référence à un fichier externe.

version: 1
dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Horatio Jensen

cn: Horatio N Jensen
sn: Jensen
uid: hjensen
telephonenumber: +1 408 555 1212
jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg

Exemple 6 : Fichier contenant une série d’enregistrements de changements et de commentaires

version: 1
# Ajouter une nouvelle entrée
dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Fiona Jensen
sn: Jensen
uid: fiona
telephonenumber: +1 408 555 1212
jpegphoto:< file:///usr/local/directory/photos/fiona.jpg

# Supprimer une entrée existante
dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
changetype: supprimer

# Modifier le nom distinctif d’une entree
dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
changetype: modrdn
newrdn: cn=Paula Jensen
deleteoldrdn: 1

# Renommer une entrée et déplacer tous ses descendants à une nouvelle localisation dans l’arborescence du répertoire (seulement mis en œuvre par les serveurs LDAPv3). #

dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
changetype: modrdn
newrdn: ou=Product Development Accountants
deleteoldrdn: 0
newsuperior: ou=Accounting, dc=airius, dc=com

# Modifier une entrée : ajouter une valeur supplémentaire à l’attribut postaladdress, supprimer complètement l’attribut description, remplacer l’attribut telephonenumber par deux valeurs, et supprimer une valeur spécifique de l’attribut facsimiletelephonenumber #

dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
changetype: modify
add: postaladdress
postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
-

delete: description
-
replace: telephonenumber
telephonenumber: +1 408 555 1234
telephonenumber: +1 408 555 5678
-
delete: facsimiletelephonenumber
facsimiletelephonenumber: +1 408 555 9876
-

# Modifier une entrée : remplacer l’attribut postaladdress par un ensemble vide de valeurs (ce qui va causer le retrait de l’attribut) et supprimer l’attribut description en entier. Noter que le premier va toujours réussir, alors que le second ne va réussir que si au moins une valeur de l’attribut description est présente. #

dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
changetype: modify
replace: postaladdress
-
delete: description
-

Exemple 7 : Fichier LDIF contenant un changement d’enregistrement avec un contrôle
version: 1
# Supprimer une entrée. L’opération va attacher le contrôle Delete Tree LDAPv3 défini en [9]. Le champ criticité est "vrai" et le champ controlValue est absent, comme exigé en [9].
dn: ou=Product Development, dc=airius, dc=com
control: 1.2.840.113556.1.4.805 true
changetype: delete

Considérations sur la sécurité

Étant données les applications normales de répertoires, un fichier LDIF va vraisemblablement contenir des données personnelles sensibles. Des mesures appropriées devraient être prises pour protéger la vie privée des personnes dont les données sont contenues dans un fichier LDIF.

Comme des directives ":<" peuvent causer l’inclusion de contenu externe lors du traitement d’un fichier LDIF, on devrait être très prudent avant d’accepter des fichiers LDIF provenant de sourcesexternes. Un fichier LDIF "cheval de Trois" pourrait désigner un fichier ayant un contenu sensible et causer son inclusion dans une entrée de répertoire, qu’uhe entité hostile pourrait lire via LDAP.

LDIF ne fournit aucune méthode pour porter des informations d’authentification avec un fichier LDIF. Les utilisateurs de fichiers LDIF doivent prendre soin de vérifier l’intégrité d’un fichier LDIF reçu d’une source externe.

Remerciements

Le format d’échange LDAP a été développé au titre de la mise en œuvre de référence de LDAP par l’Université du Michigan, et a été développé par Tim Howes, Mark Smith, et Gordon Good. Il se fonde en partie sur un travail soutenu par la National Science Foundation sous le numéro NCR-9416667.

Les membres du groupe de travail Extensions LDAP de l’IETF ont fourni de nombreuses suggestions utiles. En particulier, Hallvard B. Furuseth de l’Université d’Oslo a fait de nombreuses contributions significatives à ce document, incluant une relecture attentive et la rééecriture du BNF.

Références

[RFC1738]	T. Berners-Lee et autres, "Localisateurs uniformes de ressource (URL)", décembre   1994. (P.S., Obsolète, voir les RFC4248 et 4266)

[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

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

[RFC2251]	M. Wahl, T. Howes et S. Kille, "Protocole léger d’accès à un répertoire (v3)", décembre 1997.

[RFC2253]	M. Wahl, S. Kille et T. Howes, "Protocole léger d'accès à un répertoire (LDAPv3) : Représentation de chaîne UTF-8 des noms distinctifs", décembre 1997.

[RFC2425]	T. Howes, M. Smith, F. Dawson, "Type de contenu MIME pour informations de répertoire", septembre 1998. (Obsolète, voir RFC6350 P.S.)

[SLADP]	University of Michigan “The SLAPD and SLURPD Administrators Guide”, avril 1996. <URL : http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html >

[9]	M. P. Armijo, "Tree Delete Control", Non publiée.

Adresse de l’auteur

Gordon Good
iPlanet e-commerce Solutions
150 Network Circle
Mailstop USCA17-201
Santa Clara, CA 95054
USA

téléphone : +1 408 276 4351
mél :  ggood@netscape.com 

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.