RFC3296 Références subordonnées dans LDAP Zeilenga

Groupe de travail Réseau

K. Zeilenga, OpenLDAP Foundation

Request for Comments : 3296


Catégorie : En cours de normalisation


Traduction Claude Brière de L’Isle

juillet 2002



Références subordonnées désignées dans les répertoires
du protocole léger d’accès aux répertoires (LDAP)



Statut de ce 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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 (2002). Tous droits réservés.


Résumé

Le présent document détaille les éléments de schéma et de protocole pour représenter et gérer les références désignées subordonnées dans les répertoires du protocole léger d’accès aux répertoires (LDAP, Lightweight Directory Access Protocol).


Conventions

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


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

Table des Matières

1. Fondements et utilisation prévue 1

2. Schéma 2

2.1 Classe d’objets de référence 2

2.2 Type d’attribut ref 2

3. Commande ManageDsaIT 3

4. Références désignées subordonnées 3

5. Scénarios 4

5.1 Exemple de configuration 4

5.2 Considérations sur les objets cibles 4

5.3 Considérations sur les objets de base 5

5.4 Considérations sur la continuation de recherche 6

5.6 Autres considérations 7

6. Considérations sur la sécurité 7

7. Remerciements 7

8. Références normatives 8

9. Références pour information 8

10. Adresse de l’auteur 8

11. Déclaration complète de droits de reproduction 8


1. Fondements et utilisation prévue


L’intérêt croissant pour les répertoires LDAP (protocole léger d’accès aux répertoires) [RFC2251] au delà de leur utilisation comme frontaux pour les répertoires X.500 [X.500] a créé un besoin de représentation des informations de connaissance d’une façon plus générale. Les informations de connaissance sont des informations sur un ou plusieurs serveurs détenues dans un autre serveur, utilisées pour lier ensemble serveurs et services.


Le présent document précise les éléments de schéma et de protocole pour représenter et manipuler des références subordonnés désignées dans les répertoires LDAP. Un objet referral (renvoi documentaire) est utilisé pour détenir des informations de référence subordonnées dans le répertoire. Ces objets referral contiennent un ou plusieurs URI [RFC2396] contenus dans des valeurs du type d’attribut ref et sont utilisés pour générer des références et continuations de protocole.


Une commande, ManageDsaIT, est définie pour permettre la manipulation des objets referral et autres objets particuliers comme des objets normaux. Comme l’implique le nom de commande, elle est destinée à être analogue à l’option de service ManageDsaIT décrite dans [X.511].


Les autres formes d’informations de connaissance ne sont pas détaillées dans le présent document. Ces formes pourront être décrites dans des documents ultérieurs.


Le présent document détaille les exigences du traitement des références subordonnées pour les serveurs. Il ne décrit pas la syntaxe et la sémantique du protocole. Cela est précisé dans la [RFC2251].


Le présent document ne rentre pas dans les détails de l’utilisation des références de connaissances subordonnées pour la prise en charge des répliques d’environnements ni des opérations réparties (par exemple, le chaînage d’opérations d’un serveur à d’autres serveurs).


2. Schéma

2.1 Classe d’objets de référence


Un objet referral est une entrée de répertoire dont la classe d’objet structurelle est (ou est déduite de) la classe d’objet referral.


( 2.16.840.1.113730.3.2.6

NOM 'referral'

DESC 'objet de référence subordonnée désigné'

STRUCTURAL

DOIT ref )


La classe d’objet referral est une classe d’objet structurelle utilisée pour représenter une référence subordonnée dans le répertoire. La classe d’objet referral DEVRAIT être utilisée en conjonction avec la classe d’objet extensibleObject pour prendre en charge les attributs de désignation utilisés dans le nom distinctif (DN, Distinguished Name) [RFC2253] de l’entrée.


Les objets referral sont normalement instanciés dans les entrées spécifiques d’un agent système de répertoire (DSE, DSA specific entry) immédiatement subordonnées aux entrées d’objet au sein d’un contexte de dénomination détenu par l’agent système de répertoire (DSA, Directory System Agent). Les objets referral sont analogues aux DSE de connaissance subordonnée de X.500 [X.501].


En présence d’une commande ManageDsaIT, les objets referral sont traités comme des entrées normales comme décrit à la Section 3. Noter que l’attribut ref est opérationnel et ne sera retourné que dans une réponse d’entrée de recherche lorsque demandé.


En l’absence d’une commande ManageDsaIT, le contenu des objets referral est utilisé pour construire des références et des références de recherche comme décrit à la Section 4 et, à ce titre, les entrées referral ne sont pas elles-mêmes visibles des clients.


2.2 Type d’attribut ref


( 2.16.840.1.113730.3.1.34

NOM 'ref'

DESC 'référence nommée - un labeledURI'

EQUALITY caseExactMatch

SYNTAXE 1.3.6.1.4.1.1466.115.121.1.15

USAGE distributedOperation )


Le type d’attribut ref a la syntaxe de directoryString et est sensible à la casse. L’attribut ref est à plusieurs valeurs. Les valeurs placées dans l’attribut DOIVENT se conformer à la spécification donnée pour l’attribut labeledURI [RFC2079]. La spécification de labeledURI définit un format qui est un URI, facultativement suivi d’une espace et d’une étiquette. Le présent document n’utilise pas la portion étiquette de la syntaxe. Des documents futurs PEUVENT activer de nouvelles fonctionnalités en imposant une structure supplémentaire à la portion étiquette de la syntaxe comme elle apparaît dans l’attribut ref.


Si l’URI contenu dans une valeur d’attribut ref se réfère à un serveur LDAP [RFC2251], il DOIT être sous la forme d’un URL LDAP [RFC2255]. L’URL LDAP NE DEVRAIT PAS contenir de spécification explicite de portée, de filtre, de liste de description d’attribut, ou d’extension. L’URL LDAP DEVRAIT contenir un nom distinctif (DN) non vide. Le traitement des URL LDAP avec des parties de DN absentes ou vides ou avec une spécification de portée explicite n’est pas défini dans la présente spécification.


D’autres schémas d’URI PEUVENT être utilisés pour autant que toutes les opérations qui retournent des renvois documentaires fondés sur la valeur puissent être effectuées. Le présent document ne rentre pas dans les détails de l’utilisation des URI non LDAP. Cette question fera l’objet d’une future spécification.


L’intégrité référentielle de l’URI NE DEVRAIT PAS être validée par le serveur qui détient ou retourne l’URI (comme une valeur de l’attribut ou au titre d’un résultat de renvoi documentaire ou d’une réponse de référence de recherche).


Lors du retour d’un résultat de renvoi documentaire ou d’une continuation de recherche, le serveur NE DOIT PAS retourner les portions séparateur ou étiquette de la valeur d’attribut au titre de la référence. Lorsque l’attribut contient plusieurs valeurs, la partie URI de chaque valeur est utilisée pour construire le résultat du renvoi documentaire ou de la continuation de recherche.


Les valeurs d’attribut ref NE DEVRAIENT PAS être utilisées comme composant d’un nom relatif du nom distinctif d’une entrée [RFC2253].


Le présent document utilise l’attribut ref en conjonction avec la classe d’objets referral pour représenter les références subordonnées. L’attribut ref peut être utilisé à d’autres fins comme défini par d’autres documents.


3. Commande ManageDsaIT


Le client peut fournir la commande ManageDsaIT avec une opération pour indiquer que l’opération est destinée à gérer des objets au sein de l’arborescence d’informations du DSA (serveur). La commande cause des entrées spécifiques du répertoire (des DSE) sans considération de type, à traiter comme des entrées normales permettant aux clients d’interroger et mettre à jour ces entrées en utilisant les opérations LDAP.


Un client PEUT spécifier la commande suivante lorsque il produit une demande Ajouter, Comparer, Supprimer, Modifier, ModifierDN, Rechercher, ou une opération étendue pour laquelle la commande est définie.


Le type de la commande est 2.16.840.1.113730.3.4.2. La criticité de la commande peut être VRAI ou, si FAUX, absente. La valeur de la commande est absent.


Lorsque la commande est présente dans la demande, le serveur NE DEVRA PAS générer un referral ou une continuation de référence sur la base des informations détenues dans les objets referral et DEVRA plutôt traiter l’objet referral comme une entrée normale. Le serveur est cependant toujours libre de retourner des renvois documentaires pour d’autres raisons. Lorsque elle n’est pas présente, les objets referral DEVRONT être traités comme décrit ci-dessus.


La commande PEUT causer le traitement d’autres objets comme des entrées normales comme il sera défini par des documents ultérieurs.


4. Références désignées subordonnées


Une référence subordonnée désignée est construite par l’instanciation d’un objet referral dans le serveur de référence avec des valeurs d’attribut ref qui pointent sur la sous arborescence correspondante tenue dans le serveur référencé. En général, le nom de l’objet referral est le même que celui de l’objet référencé et cet objet référencé est un préfixe context [X.501].


C’est-à-dire que si le serveur A détient "DC=example,DC=net" et si le serveur B détient "DC=sub,DC=example,DC=net", le serveur A peut contenir un objet referral nommé "DC=sub,DC=example,DC=net" qui contient un attribut ref avec la valeur de "ldap://B/DC=sub,DC=example,DC=net".


dn: DC=sub,DC=example,DC=net

dc: sub

ref: ldap://B/DC=sub,DC=example,DC=net

objectClass: referral

objectClass: extensibleObject


Normalement, le DN de l’objet referral et le DN de l’objet dans le serveur référencé sont les mêmes.


Si l’attribut ref a plusieurs valeurs, tous les DN contenus dans les URL LDAP DEVRAIENT être équivalents. Les administrateurs DEVRAIENT éviter de configurer des dénominations en boucle lorsque ils utilisent des renvois documentaires.


Les références désignées DOIVENT être traitées comme des entrées normales si la demande comporte la commande ManageDsaIT comme décrit à la Section 3.


5. Scénarios


Les paragraphes qui suivent contiennent les spécifications de la façon dont l’objet referral devrait être utilisé dans différents scénarios suivis par des exemples qui illustrent cet usage. Les scénarios décrits ici consistent en un traitement de l’objet referral lorsque il trouve la cible d’une opération hors opération de recherche, lorsque il trouve la base d’une opération de recherche, et lorsque il génère des références de recherche. Finalement, on présente d’autres considérations sur le traitement des opérations.

On notera que, dans le présent document, une opération de recherche est conceptuellement divisée en deux phases séquentielles distinctes : (1) trouver l’objet de base lorsque la recherche doit commencer, et (2) effectuer la recherche elle-même. La première phase est similaire, mais pas semblable, à trouver la cible d’une opération qui n’est pas de recherche.

On devrait aussi noter que l’attribut ref peut avoir plusieurs valeurs et, lorsque ces paragraphes se réfèrent à une seule valeur d’attribut ref, plusieurs valeurs d’attribut ref peuvent lui être substituées et DEVRAIENT être traitées et retournées (dans n’importe quel ordre) comme un groupe dans un renvoi documentaire ou référence de recherche de la même façon que décrit pour une seule valeur d’attribut ref.

Les références de recherche retournées pour une certaine demande peuvent être retournées dans n’importe quel ordre.


5.1 Exemple de configuration


Par exemple, supposons que le serveur contacté (hosta) détienne l’entrée "O=MNN,C=WW", l’entrée "CN=Manager,O=MNN,C=WW" et les objets referral suivants :

dn: OU=People,O=MNN,C=WW

ou: People

ref: ldap://hostb/OU=People,O=MNN,C=US

ref: ldap://hostc/OU=People,O=MNN,C=US

objectClass: referral

objectClass: extensibleObject


dn: OU=Roles,O=MNN,C=WW

ou: Roles

ref: ldap://hostd/OU=Roles,O=MNN,C=WW

objectClass: referral

objectClass: extensibleObject


Le premier objet referral donne au serveur l’information que le sous arbre "OU=People,O=MNN,C=WW" est détenu par hostb et hostc (par exemple, l’un est le maître et l’autre est un reflet). Le second objet referral donne au serveur l’information que le sous-arbre "OU=Roles,O=MNN,C=WW" est détenu par hostd.


Aussi, dans le contexte du présent document, le "plus proche contexte de désignation" signifie le plus profond contexte dans lequel est l’objet. C’est-à-dire que si l’objet est dans plusieurs contextes de dénomination, le contexte de dénomination de plus proche est celui qui est subordonné à tous les autres contextes de dénominations dans lesquels se trouve l’objet.


5.2 Considérations sur les objets cibles


Ce paragraphe précise les détails du traitement de referral pour les opérations add (ajouter), compare (comparer), delete (supprimer), modify (modifier), et modify DN (modifier le nom distinctif). Si le client demande une de ces opérations, il y a quatre cas que le serveur doit traiter par rapport à l’objet cible.


La partie DN DOIT être modifiée de telle sorte qu’elle se réfère à la cible appropriée dans le serveur référencé (comme précisé ci-dessous). Même lorsque le DN à retourner est le même que le DN cible, la partie DN NE DEVRAIT PAS être rognée.


Dans les cas où l’URI à retourner est un URL LDAP, le serveur DEVRAIT retirer de l’URI toute portée, filtre, ou liste d’attributs, présent avant de le retourner. Les extensions critiques NE DOIVENT PAS être retirées ou modifiées.


Cas 1 : L’objet cible n’est pas détenu par le serveur et n’est ni dans, ni subordonné à, aucun contexte de désignation, ni subordonné à aucun objet referral détenu par le serveur.


Le serveur DEVRAIT traiter normalement la demande comme approprié pour une base non existante qui n’est dans aucun contexte de désignation du serveur (il retourne généralement un noSuchObject ou un referral fondé sur des informations de référence supérieures connues). Le présent document ne rentre pas dans les détails de la gestion ou du traitement des informations de référence supérieures connues.


Cas 2 : L’objet cible est détenu par le serveur et est un objet referral.

Le serveur DEVRAIT retourner la valeur de l’URI contenue dans l’attribut ref de l’objet referral modifié de façon appropriée comme décrit ci-dessus.


Exemple : Si le client produit une demande Modifier pour l’objet cible "OU=People,O=MNN,c=WW", le serveur retournera :

ModifyResponse (referral) {

ldap://hostb/OU=People,O=MNN,C=WW

ldap://hostc/OU=People,O=MNN,C=WW

}


Cas 3 : L’objet cible n’est pas détenu par le serveur, mais le plus proche contexte de désignation ne contient aucun objet referral auquel l’objet cible soit subordonné.

Si le plus proche contexte de désignation ne contient aucun objet referral auquel la cible soit subordonnée, le serveur DEVRAIT traiter la demande comme approprié pour une cible non existante (retourner généralement un noSuchObject).


Cas 4 : L’objet cible n’est pas détenu par le serveur, mais le plus proche contexte de désignation contient un objet referral auquel l’objet cible est subordonné.

Si un client demande une opération pour laquelle l’objet cible n’est pas détenu par le serveur et si le plus proche contexte de désignation contient un objet referral auquel l’objet cible est subordonné, le serveur DEVRAIT retourner une réponse referral construite à partir de la portion URI de la valeur ref de l’objet referral.


Exemple : Si le client produit une demande Ajouter dans laquelle l’objet cible a un DN de "CN=Manager,OU=Roles,O=MNN,C=WW", le serveur va retourner :

AddResponse (referral) {

ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"

}


Noter que la partie DN de l’URL LDAP est modifiée de façon à ce qu’elle se réfère à l’entrée appropriée dans le serveur référencé.


5.3 Considérations sur les objets de base


Ce paragraphe précise le traitement de referral pour les objets de base dans les opérations de recherche. Comme pour les considérations d’objet cible pour les opérations qui ne sont pas de recherche, il y a quatre cas.


Dans les cas où l’URI à retourner est un URL LDAP, le serveur DOIT fournir une spécification explicite de portée à partir de l’URL LDAP avant de le retourner. De plus, la partie DN DOIT être modifiée de telle sorte qu’elle se réfère à la cible appropriée dans le serveur référencé (comme on le précise ci dessous).


Si il est nécessaire de déréférencer un alias pour trouver l’objet referral, la partie DN de l’URI DOIT être remplacée par le DN de base comme modifié par l’alias qui le déréférence afin que l’URL retourné se réfère au nouvel objet cible conformément au paragraphe 4.1.11 de la [RFC2251].


Les extensions critiques NE DOIVENT être ni rognées ni modifiées.


Cas 1 : L’objet de base n’est pas détenu par le serveur et n’est ni dans, ni subordonné à, un contexte de désignation détenu par le serveur. Le serveur DEVRAIT traiter normalement la demande comme approprié pour une base non existante qui n’est pas dans un contexte de désignation du serveur (il retourne généralement un referral supérieur ou noSuchObject). Le présent document ne rentre pas dans les détails de la gestion ni du traitement des références supérieures de connaissances.


Cas 2 : L’objet de base est détenu par le serveur et est un objet referral. Le serveur DEVRAIT retourner la valeur de l’URI contenue dans l’attribut ref de l’objet referral, modifié de la façon appropriée comme décrit ci-dessus.


Exemple : Si le client produit une recherche de sous arborescence dans laquelle l’objet de base est "OU=Roles,O=MNN,C=WW", le serveur retournera :

SearchResultDone (referral) {

ldap://hostd/OU=Roles,O=MNN,C=WW??sub

}


Si le client devait produire une recherche de base ou oneLevel au lieu de la sous arborescence, l’URL LDAP retourné spécifierait explicitement "base" ou "one", respectivement, au lieu de "sub".


Cas 3 : L’objet de base n’est pas détenu par le serveur, mais le plus proche contexte de désignation ne contient pas l’objet referral auquel est subordonné l’objet de base. Si le plus proche contexte de désignation ne contient pas d’objet referral auquel la base soit subordonnée, la requête DEVRAIT être traitée normalement comme approprié pour une base non existante (il retourne généralement un noSuchObject).


Cas 4 : L’objet de base n’est pas détenu par le serveur, mais le plus proche contexte de désignation contient un objet referral auquel l’objet de base est subordonné. Si un client demande une opération pour laquelle l’objet cible n’est pas détenu par le serveur, et si le plus proche contexte de désignation contient un objet referral auquel l’objet cible est subordonné, le serveur DEVRAIT retourner une réponse referral qui est construite à partir de la portion URI de la valeur ref de l’objet referral.


Exemple : Si le client produit une demande de recherche de base pour "CN=Manager,OU=Roles,O=MNN,C=WW", le serveur retournera :

SearchResultDone (referral) {

ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"

}


Si le client devait produire une sous arborescence ou une recherche oneLevel au lieu d’une sous arborescence, l’URL LDAP retourné spécifierait explicitement "sub" ou "one", respectivement, au lieu de "base".


Noter que la partie DN de l’URL LDAP est modifiée de façon telle qu’elle se réfère à l’entrée appropriée dans le serveur référencé.


5.4 Considérations sur la continuation de recherche


Pour les opérations de recherche, une fois que l’objet de base a été trouvé et qu’il a été déterminé qu’il n’est pas un objet referral, la recherche peut progresser. Toute entrée qui correspond au filtre et à la portée de la recherche qui n’est pas un objet referral est retourné au client normalement comme décrit dans la [RFC2251].


Pour chaque objet referral dans la portée demandée, sans considération du filtre de recherche, le serveur DEVRAIT retourner un SearchResultReference qui est construit à partir du composant d’URI des valeurs de l’attribut ref. Si le composant d’URI n’est pas un URL LDAP, il devrait être retourné tel qu’il est. Si la partie DN de l’URL LDAP est absente ou vide, la partie DN doit être modifiée pour contenir le DN de l’objet referral. Si le composant d’URI est un URL LDAP, l’URI DEVRAIT être modifié pour ajouter une spécification de portée explicite.


Exemple de sous arborescence :

Si un client demande une recherche de sous arborescence de "O=MNN,C=WW", alors, en plus de toutes les entrées dans la portée qui satisfont au filtre, hosta va aussi retourner deux références de recherche au titre des deux objets referral qui sont dans la portée. Une réponse possible pourrait être :

SearchEntry for O=MNN,C=WW

SearchResultReference {

ldap://hostb/OU=People,O=MNN,C=WW??sub

ldap://hostc/OU=People,O=MNN,C=WW??sub

}

SearchEntry for CN=Manager,O=MNN,C=WW

SearchResultReference {

ldap://hostd/OU=Roles,O=MNN,C=WW??sub

}

SearchResultDone (réussite)


Exemple de One Level :

Si un client demande une recherche à un niveau de "O=MNN,C=WW" alors, en plus de toutes les entrées à un niveau en dessous de l’entrée "O=MNN,C=WW" qui satisfait au filtre, le serveur va aussi retourner deux références de recherche au titre des deux objets referral qui sont dans la portée. Une séquence possible serait la suivante :

SearchResultReference {

ldap://hostb/OU=People,O=MNN,C=WW??base

ldap://hostc/OU=People,O=MNN,C=WW??base

}

SearchEntry for CN=Manager,O=MNN,C=WW

SearchResultReference {

ldap://hostd/OU=Roles,O=MNN,C=WW??base

}

SearchResultDone (réussite)


Note : À la différence des exemples du paragraphe 4.5.3.1 de la [RFC2251], les URL LDAP retournés avec le message SearchResultReference contiennent, comme l’exige la présente spécification, une spécification explicite de portée.


5.6 Autres considérations


Ce paragraphe détaille les considérations de traitement des autres opérations.


5.6.1 Bind

Les serveurs NE DEVRAIENT PAS retourner de code de résultat de renvoi documentaire si le nom bind (ou l’identité d’authentification ou l’identité d’autorisation) est (ou est subordonnée à) un objet referral mais PEUT utiliser les informations de connaissance pour traiter la demande bind (comme en soutien d’une future spécification d’opération répartie). Lorsque le serveur n’utilise pas les informations de connaissance, il traite la demande normalement comme approprié pour une identité d’authentification ou d’autorisation non existante (par exemple, retourner invalidCredentials).


5.6.2 Modify DN

Si le newSuperior est un objet referral ou est subordonné à un objet referral, le serveur DEVRAIT retourner affectsMultipleDSAs (affecte plusieurs DSA). Si le newRDN existe déjà mais est un objet referral, le serveur DEVRAIT retourner affectsMultipleDSAs au lieu de entryAlreadyExists (l’entrée existe déjà).


6. Considérations sur la sécurité


Le présent document définit des mécanismes qui peuvent être utilisés pour lier ensemble les serveurs LDAP (et les autres). Les informations utilisées pour lier ensemble les services devraient être protégées contre la modification non autorisée. Si les informations de topologie du serveur ne sont pas des informations publiques, elles devraient aussi être protégées contre toute divulgation non autorisée.


7. Remerciements


Le présent document emprunte beaucoup aux travaux antérieurs du groupe de travail LDAPext de l’IETF. En particulier, il se fonde sur "Références désignées dans les répertoires LDAP" (projet Internet arrivé à expiration) de Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith, et Mark Wahl.


8. Références normatives


[RFC2079] M. Smith, "Définition d'un type d'attribut et d'une classe d'objet X.500 pour contenir les identifiants de ressource uniformes (URI)", janvier 1997. (P.S.)


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


[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, RFC4512, RFC4517, RFC4523) (P.S.)


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


[RFC2255] T. Howes, M. Smith, "Format d'URL LDAP", décembre 1997. (Obsolète, voir RFC4510, RFC4516) (P.S.)


[RFC2396] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiants de ressource uniformes (URI) : Syntaxe générique", août 1998. (Obsolète, voir RFC3986)


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


9. Références pour information


[X.500] Recommandation UIT-T X.500, "L’annuaire : Généralités sur les concepts,les modèles, et les services", 1993.


[X.511] Recommandation UIT-T X.511, "L’annuaire: Définition de service abstraite", 1997.


10. Adresse de l’auteur


Kurt D. Zeilenga

OpenLDAP Foundation


mél : Kurt@OpenLDAP.org


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


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