Groupe de travail Réseau	K. Zeilenga, OpenLDAP Foundation	
Request for Comments : 3672	S. Legg, Adacel Technologies	
Catégorie : Sur la voie de la normalisation	décembre 2003	
	Traduction Claude Brière de L'Isle	

Sous entrées dans le protocole léger d'accès à un répertoire (LDAP)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir 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 (2003). Tous droits réservés.

Résumé
Dans les répertoires X.500, les sous entrées sont des entrées spéciales utilisées pour contenir des informations associées à une sous arborescence ou embranchement de sous arborescence. Le présent document adapte les mécanismes de sous entrées de X.500 à l'utilisation dans le protocole léger d'accès à un répertoire (LDAP, Lightweight Directory Access Protocol).
Table des matières
1. Généralités	1
1.3 Conventions	2
2. Schéma de sous entrée	2
2.1 Syntaxe de la spécification de sous arborscence	2
2.2 Type d'attribut de rôle administratif	3
2.3 Type d'attribut de spécification de sous arborescence	4
2.4 Classe d'objet de sous entrée	4
3. Contrôle de sous entrée	4
4. Considérations sur la sécurité	5
5. Considérations relatives à l'IANA	5
5.1 Descripteurs	5
5.2 Identifiants d'objet	5
5.3 Mécanismes de protocole	5
6. Remerciements	6
7. Déclaration de propriété intellectuelle	6
A. ABNF de la spécification  de sous arborescence	6
Références normatives	7
Références pour information	8
Adresse des auteurs	8
Déclaration complète de droits de reproduction	8

 	1.	Généralités

D'après [X.501], "Une sous entrée est sorte spéciale d'entrée immédiatement subordonnée à un point administratif. Elle contient des attributs qui relèvent d'une sous arborescence (ou embranchement de sous arborescence) associée à son point administratif. Les sous entrées et leur point administratif font partie du même contexte de désignation.

Une seule sous entrée peut servir à tous ou plusieurs aspects d'autorité administrative. Autrement, un aspect spécifique d'autorité administrative peut être traité au moyen d'une ou plusieurs de ses propres sous entrées.

Les sous entrées dans le protocole léger d'accès à un répertoire (LDAP) [RFC3377] DEVRONT se comporter en accord avec la Recommandation UIT-T X.501 sauf mention contraire dans la présente spécification.

En l'absence de contrôle des sous entrées (détaillé à la Section 3) les sous entrées NE DEVRONT PAS être considérées dans les opérations de recherche de portée à un niveau et de sous arborescence. Pour toutes les autres opérations, incluant les opérations de recherche de portée de base, les sous entrées DEVRONT être prises en compte.

 	1.3	Conventions
Les définitions de schémas sont fournies en utilisant les formats de description LDAPv3 [RFC2252]. Les définitions fournies ici sont formatées (saut à la ligne) pour la lisibilité.

Les éléments de protocole sont décrits en utilisant l'ASN.1 [X.680]. Le terme "codé en BER" signifie que l'élément est à coder en utilisant les règles de codage de base (BER, Basic Encoding Rules) [X.690] avec les restrictions du paragraphe 5.1 de la [RFC2251].

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

 	2.	Schéma de sous entrée
 	2.1	Syntaxe de la spécification de sous arborescence
La syntaxe de la spécification de sous arborescence donne un mécanisme général pour la spécification d'un sous ensemble d'entrées dans une sous arborescence de l'arborescence d'informations de répertoire (DIT, Directory Information Tree). Une sous arborescence commence à une entrée de base et inclut les subordonnés de cette entrée jusqu'à une limite inférieure identifiée, s'étendant éventuellement jusqu'aux entrées d'extrémité. Une spécification de sous arborescence est toujours utilisée dans un contexte ou une portée qui détermine implicitement les limites de la sous arborescence. Par exemple, la portée d'une spécification de sous arborescence pour une zone administrative de sous schéma n'inclut pas les sous arborescences des entrées de point administratif subordonné pour l'administration de sous schéma. Lorsque une spécification de sous arborescence n'identifie pas un sous ensemble contigu d'entrées au sein d'une seule sous arborescence, la collection est appelée un embranchement de sous arborescence.

Cette syntaxe correspond au type ASN.1 SubtreeSpecification décrit au paragraphe 11.3 de [X.501]. Cette définition de type de données ASN.1 est reproduite ici.

SubtreeSpecification ::= SEQUENCE {
    base                [0] LocalName PAR DEFAUT { },
                            COMPONSANTS DE ChopSpecification,
    specificationFilter [4] Refinement FACULTATIF }

LocalName ::= RDNSequence

ChopSpecification ::= SEQUENCE {
    specificExclusions   [1] ENSEMBLE DE CHOIX {
                 chopBefore [0] LocalName,
                    chopAfter [1] LocalName } FACULTATIF,
    minimum                  [2] BaseDistance PAR DEFAUT 0,
    maximum                  [3] BaseDistance FACULTATIF }

BaseDistance ::= ENTIER (0 .. MAX)

Refinement ::= CHOIX {
    item                [0] OBJECT-CLASS.&id,
    et                    [1] ENSEMBLE DE Refinement,
    ou                   [2] ENSEMBLE DE Refinement,
    non                 [3] Refinement }

Les composants de SubtreeSpecification sont : base, qui identifie l'entrée de base de la sous arborescence ou embranchement de sous arborescence, et specificExclusions, minimum, maximum et specificationFilter, qui réduisent l'ensemble des entrées  subordonnées de l'entrée de base. La sous arborescence ou embranchement de sous arborescence contient toutes les entrées de la portée qui ne sont pas exclues par un des composants de la spécification de sous arborescence. Quand tous les composants de SubtreeSpecification sont absents (c'est-à-dire, quand une valeur de la syntaxe de spécification de sous arborescence est la séquence vide, {}), la sous arborescence spécifiée inclut implicitement toutes les entrées dans la portée.

Toute utilisation particulière de ce mécanisme PEUT imposer des limitations ou contraintes aux composants de SubtreeSpecification.

La spécification de la syntaxe LDAP est :

( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )

Le codage spécifique de LDAP des valeurs de cette syntaxe est défini par les règles génériques de codage de chaîne (GSER, Generic String Encoding Rules) [RFC3641]. L'Appendice A donne un format équivalent en Backus-Naur augmenté (ABNF) [RFC2234] pour cette syntaxe.

 	2.1.1	Base
Le composant de base de SubtreeSpecification désigne l'entrée de base de la sous arborescence ou embranchement de sous arborescence. L'entrée de base peut être une entrée qui est subordonnée à l'entrée récine de la portée dans laquelle est utilisée la spécification de sous arborescence, auquel cas le composant de base contient une séquence de noms distinctifs relatifs (RDN, Relative Distinguished Name) relatifs à l'entrée racine de la portée, ou peut être de l'entrée racine de la portée elle-même (par défaut) et dans ce cas le composant de base est absent ou contient une séquence vide de RDN.

Les entrées qui ne sont pas subordonnées à l'entrée de base sont exclues de la sous arborescence ou embranchement de sous arborescence.

 	2.1.2	Exclusions spécifiques
Le composant specificExclusions d'une ChopSpecification est une liste d'exclusions qui spécifie des entrées et leurs subordonnés à exclure de la sous arborescence ou embranchement de sous arborescence. L'entrée est spécifiée par une séquence de RDN relatifs à l'entrée de base (c'est-à-dire, un LocalName). Chaque exclusion est de forme chopBefore ou chopAfter. Si la forme chopBefore est utilisée, alors l'entrée spécifiée et ses subordonnées sont exclues de la sous arborescence ou embranchement de sous arborescence. Si la forme chopAfter est utilisée alors seulement les subordonnées de l'entrée spécifiée sont exclues de la sous arborescence ou embranchement de sous arborescence.

 	2.1.3	Minimum et maximum
Les composants minimum et maximum d'une ChopSpecification permettent l'exclusion d'entrées sur la base de leur profondeur dans le DIT.

Les entrées qui sont moins que le nombre minimum des arcs de RDN en dessous de l'entrée de base sont exclues de la sous arborescence ou embranchement de sous arborescence. Une valeur minimum de zéro (la valeur par défaut) correspond à l'entrée de base.

Les entrées qui sont plus que le nombre maximum des arcs de RDN en dessous de l'entrée de base sont exclues de la sous arborescence ou embranchement de sous arborescence. Un composant maximum absent indique qu'il n'y a pas de limite supérieure au nombre d'arcs de RDN en dessous de l'entrée de base pour les entrées dans la sous arborescence ou embranchement de sous arborescence.

 	2.1.4	Filtre de spécification
Le composant specificationFilter est une expression booléenne d'assertions sur les valeurs de l'attribut objectClass de l'entrée de base et ses subordonnées. Un élément d'assertion Refinement s'évalue à vrai pour une entrée si l'attribut objectClass de cette entrée contient l'OID nommé dans l'assertion. Les entrées pour lesquelles le filtre global s'évalue à faux sont exclues de l'embranchement de sous arborescence. Si specificationFilter est absent, aucune entrée n'est alors exclue de la sous arborescence ou embranchement de sous arborescence à cause de sa valeur d'attribut objectClass.

 	2.2	Type d'attribut de rôle administratif
Le modèle administratif défini dans [X.501], clause 10 exige que les entrées administratives contiennent un attribut administrativeRole pour indiquer que la zone administrative associée est concernée par un ou plusieurs rôles administratifs.

L'attribut opérationnel administrativeRole est spécifié comme suit :

( 2.5.18.5 NAME 'administrativeRole'
    EQUALITY objectIdentifierMatch
    USAGE directoryOperation
    SYNTAXE 1.3.6.1.4.1.1466.115.121.1.38 )

Les valeurs possibles de cet attribut définies dans X.501 sont :

OID	Nom
2.5.23.1	autonomousArea (zone autonome)
2.5.23.2	accessControlSpecificArea (zone de contrôle d'accès spécifique)
2.5.23.3	accessControlInnerArea (zone de contrôle d'accès interne)
2.5.23.4	subschemaAdminSpecificArea (zone spécifique de sous schéma administratif)
2.5.23.5	collectiveAttributeSpecificArea (zone spécifique d'attribut collectif)
2.5.23.6	collectiveAttributeInnerArea (zone d'attribut collectif interne)

D'autres valeurs peuvent être définies dans d'autres spécifications. Les noms associés à chaque rôle administratif sont des descripteurs d'identifiant d'objet [RFC3383].

L'attribut opérationnel administrativeRole est aussi utilisé pour réguler les sous entrées permises comme subordonnées d'une entrée administrative. Une sous entrée non d'une classe permise par l'attribut administrativeRole ne peut pas être subordonnée à l'entrée administrative.

 	2.3	Type d'attribut de spécification de sous arborescence
L'attribut opérationnel subtreeSpecification est défini comme suit :

( 2.5.18.6 NAME 'subtreeSpecification'
    SINGLE-VALUE
    USAGE directoryOperation
    SYNTAXE 1.3.6.1.4.1.1466.115.121.1.45 )

Cet attribut est présent dans toutes les sous entrées (voir [X.501], clause 10). Les valeurs de l'attribut subtreeSpecification désignent des collections d'entrées au sein du DIT pour un ou plusieurs aspects de l'autorité administrative.

 	2.4	Classe d'objet de sous entrée
La classe d'objets sous entrée est une classe d'objets structurelle.

( 2.5.17.0 NOM 'sous entrée'
           SUP top STRUCTURAL
           DOIT ( cn $ subtreeSpecification ) )

 	3.	Commande de sous entrée

La commande de sous entrées PEUT être envoyée avec un searchRequest (demande de recherche) pour contrôler la visibilité des entrées et sous entrées qui sont dans la portée. Les entrées ou sous entrées non visibles ne sont pas retournées en réponse à la demande.

La commande sous entrées est une commande LDAP dont le controlType est 1.3.6.1.4.1.4203.1.10.1, sa criticité est VRAI ou FAUX (donc absent) et controlValue contient un BOOLEEN codé en BER qui indique la visibilité. Une controlValue contenant la valeur VRAI indique que les sous entrées sont visibles et que les entrées normales ne le sont pas. Une controlValue contenant la valeur FAUX indique que les entrées normales sont visibles et que les sous entrées ne le sont pas.

Noter que visibilité VRAI a le codage de trois octets { 01 01 FF } et la visibilité FAUX a le codage de trois octets { 01 01 00 }.

La controlValue NE DEVRA PAS être absente.

En l'absence de cette commande, les sous entrées ne sont pas visibles aux demandes de portée singleLevel et wholeSubtree mais sont visibles aux demandes de recherche de portée baseObject.

Il n'y a pas de commande de réponse correspondante.

Cette commande n'est pas appropriée pour les opérations qui ne sont pas de recherche.

 	4.	Considérations sur la sécurité

Les sous entrées contiennent souvent des informations administratives ou autres informations sensibles et devraient être protégées contre les accès non autorisés et la divulgation comme décrit dans les [RFC2829] et [RFC2830].

Les considération générales de sécurité LDAP [RFC3377] 'appliquent aussi.

 	5.	Considérations relatives à l'IANA
 	5.1	Descripteurs
L'IANA a enregistrés les descripteurs LDAP définis dans cette spécification technique. Le gabarit d'enregistrement suivant est suggéré :

Objet : demande d'enregistrement de descripteur LDAP
Descripteur (nom abrégé) : voir les commentaires
Identifiant d'objet : voir les commentaires
Adresse de la personne & de messagerie à contacter pour plus d'informations : Kurt Zeilenga <kurt@OpenLDAP.org>
Usage : voir le commentaire
Spécification : RFC3672
Auteur/Contrôleur des changements : IESG
Commentaires :

Nom	Type	OID
accessControlInnerArea	R	2.5.23.3
accessControlSpecificArea	R	2.5.23.2
administrativeRole	A	2.5.18.5
autonomousArea	R	2.5.23.1
collectiveAttributeInnerArea	R	2.5.23.6
collectiveAttributeSpecificArea	R	2.5.23.5
Subentries	O	2.5.17.0
subschemaAdminSpecificArea 	R	2.5.23.4
subtreeSpecification	A	2.5.18.6

où Type A est attribut, Type O est classe d'objet, et Type R est rôle administratif.

 	5.2	Identifiants d'objet
Le présent document utilise l'OID 1.3.6.1.4.1.4203.1.10.1 pour identifier un élément de protocole LDAP défini ici. Cet OID a été alloué [ASSIGN] par la Fondation OpenLDAP, sous son allocation d'entreprise privée allouée par l'IANA [PRIVATE], pour être utilisée dans la présente spécification.

D'autres OID qui apparaissent dans le présent document ont été alloués par le sous comité 6 du comité JTC1 de l'ISO/CEI pour identifier les éléments de schéma X.500 ou alloués dans la RFC 2252 pour l'usage décrit ici.

 	5.3	Mécanismes de protocole
L'IANA a enregistré les mécanismes de protocole LDAP [RFC3383] détaillés dans la présente spécification.

Sujet : demande d'enregistrement de mécanisme de protocole  LDAP
Description : Subentries
Adresse de la personne & de messagerie à contacter pour plus d'informations : Kurt Zeilenga <kurt@OpenLDAP.org>
Usage : Comandel
Spécification : RFC3672
Auteur/Contrôleur des changements : IESG
Commentaires : aucun

 	6.	Remerciements

Le présent document se fonde sur l'ingénierie faite par les groupes de travail LDUP et LDAPext de l'IETF incluant "LDAP Subentry Schema" par Ed Reed. Ce document emprunte aussi à un certain nombre de documents de l'UIT-T incluant X.501.

 	7.	Déclaration de propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org .

 	A.	ABNF de la spécification  de sous arborescence

Cet appendice n'est pas normatif.

Le codage de chaîne spécifique de LDAP pour la syntaxe de la spécification de sous arborescence est spécifié par les règles génériques de codage de chaîne [RFC3641]. L'ABNF [RFC2234] dans cet appendice pour cette syntaxe n'est fourni que pour information et est équivalent au codage spécifié par l'application de la [RFC3641]. Comme le type ASN.1 SubtreeSpecification peut être étendu dans de futures éditions de [X.501], l'ABNF fourni devrait être considéré comme une photographie à un instant donné. Le codage spécifique de LDAP pour toute extension au type ASN.1 SubtreeSpecification peut être déterminé à partir de la [RFC3641].

En cas de discordance entre cet ABNF et le codage déterminé par la [RFC3641], celui de la [RFC3641] est à considérer comme définitif.

SubtreeSpecification = "{"    [ sp ss-base ]
                             [ sep sp ss-specificExclusions ]
                             [ sep sp ss-minimum ]
                             [ sep sp ss-maximum ]
                             [ sep sp ss-specificationFilter ]
                                   sp "}"

ss-base                = id-base                msp LocalName
ss-specificExclusions  = id-specificExclusions  msp SpecificExclusions
ss-minimum             = id-minimum             msp BaseDistance
ss-maximum             = id-maximum             msp BaseDistance
ss-specificationFilter = id-specificationFilter msp Refinement

id-base                = %x62.61.73.65 ; "base"
id-specificExclusions  = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73 %x69.6F.6E.73 ; "specificExclusions"
id-minimum             = %x6D.69.6E.69.6D.75.6D ; "minimum"
id-maximum             = %x6D.61.78.69.6D.75.6D ; "maximum"
id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46 %x69.6C.74.65.72 ; "specificationFilter"

SpecificExclusions = "{" [ sp SpecificExclusion *( "," sp SpecificExclusion ) ] sp "}"
SpecificExclusion  = chopBefore / chopAfter
chopBefore         = id-chopBefore ":" LocalName
chopAfter          = id-chopAfter  ":" LocalName
id-chopBefore      = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
id-chopAfter       = %x63.68.6F.70.41.66.74.65.72    ; "chopAfter"

Refinement  = item / et / ou / not
item        = id-item ":" IDENTIFIANT-D'OBJET
and        = id-and  ":" Refinements
or          = id-or   ":" Refinements
not         = id-not  ":" Refinement
Refinements = "{" [ sp Refinement *( "," sp Refinement ) ] sp "}"
id-item     = %x69.74.65.6D ; "item"
id-and     = %x61.6E.64    ; "and"
id-or       = %x6F.72       ; "or"
id-not      = %x6E.6F.74    ; "not"

BaseDistance = ENTIER-0-MAX

Les règles <sp>, <msp>, <sep>, <ENTIER>, <ENTIER-0-MAX>, <IDENTIFIANT-D'OBJET> et <LocalName> sont définies dans la [RFC3642].

 	Références normatives

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

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

[RFC2252]	M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Protocole léger d’accès à un répertoire (v3) : Définitions de syntaxe d'attribut", décembre 1997. (Obsolète, voir RFC4510, RFC4517, RFC4523, RFC4512) (MàJ par RFC3377) (P.S.)

[RFC2829]	M. Wahl et autres, "Méthodes d'authentification pour LDAP", mai 2000. (Obsolète, voir RFC4513, RFC4510) (P.S.)

[RFC2830]	J. Hodges, R. Morgan, M. Wahl, "Protocole léger d'accès à un répertoire (v3) : extension pour la sécurité de la couche transport", mai 2000. (Obsolète, voir RFC4511, RFC4513, RFC4510) (P.S.)

[RFC3377]	J. Hodges, R. Morgan, "Protocole léger d'accès à un répertoire (v3) : Spécification technique", septembre 2002. Obsolète, voir RFC4510) (P.S.)

[RFC3383]	K. Zeilenga, "Autorité d'allocation des numéros de l'Internet (IANA) : Considérations sur le protocole léger d'accès à un répertoire (LDAP)", septembre 2002. (Obsolète, voir RFC4520)

[RFC3641]	S. Legg, "Règles génériques de codage de chaînes (GSER) pour les types ASN.1", octobre 2003. (MàJ par RFC4792)

[X.501]	Recommandation UIT-T X.501, "L'annuaire : Modèles", 1993.

[X.680]	Recommandation UIT-T X.680 | ISO/CEI 8824-1:2002 "Technologies de l’information - Notation de syntaxe abstraite n°1 (ASN.1) : Spécification de la notation de base". (07/2002)

[X.690]	Recommandation UIT-T X.690 | ISO/CEI 8825-1:2002, "Technologies de l’information  - Règles de codage de l’ASN.1 : Spécification des règles de codage de base (BER), règles de codage canoniques (CER) et règles de codage distinctives (DER)", (07/2002).

 	Références pour information

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

[RFC3642]	S. Legg, "Éléments communs des règles génériques de codage de chaînes (GSER)", octobre 2003.

[ASSIGN]	OpenLDAP Foundation, "OpenLDAP OID Delegations", http://www.openldap.org/foundation/oid-delegate.txt

[PRIVATE]	IANA, "Private Enterprise Numbers", http://www.iana.org/assignments/enterprise-numbers

 	Adresse des auteurs

Kurt D. Zeilenga
OpenLDAP Foundation
mél : Kurt@OpenLDAP.org 

Steven Legg
Adacel Technologies Ltd.
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA
téléphone : +61 3 8530 7710
mél : steven.legg@adacel.com.au 

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). 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 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 les besoins 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 contenues sont fournis 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 encloses ne viole 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 la Internet Society.