RFC2849 LDIF – Spécification technique Good

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.


Remerciement

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

page - 8 -