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

Protocole léger d'accès à un répertoire version 3 (LDAPv3) : tous les attributs de fonctionnement

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é
Le protocole léger d'accès à un répertoire (LDAP, Lightweight Directory Access Protocol) prend en charge un mécanisme pour demander le retour de tous les attributs d'un utilisateur mais pas tous les attributs de fonctionnement. Le présent document décrit une extension à LDAP que les clients peuvent utiliser pour demande le retour de tous les attributs de fonctionnement.
Table des matières
1. Généralités	1
2. Tous les attributs de fonctionnement	1
3. Considérations d'interopérabilité	2
4. Considérations sur la sécurité	2
5. Considérations relatives à l'IANA	2
6. Remerciements	2
7. Déclaration de propriété intellectuelle	3
8. Références	3
8.1 Références normatives	3
8.2 Références pour information	3
9. Adresse des auteurs	3
10. Déclaration complète de droits de reproduction	4

 	1.	Généralités

La Recommandation UIT-T X.500 [X.500] donne un mécanisme pour que les clients demandent que tous les attributs de fonctionnement soient retournés avec les entrées fournies en réponse à une opération de recherche. Ce mécanisme est souvent utilisé par les clients pour découvrir quels attributs de fonctionnement sont présents dans une entrée.

Le présent documents étend le protocole léger d'accès à un répertoire (LDAP) [RFC3377] à fournir un mécanisme simple que les clients puissent utiliser pour demander le retour de tous les attributs de fonctionnement. Le mécanisme est conçu pour être utilisé avec les clients LDAP d'utilité générale existants (incluant les navigateurs de la Toile qui prennent en charge les URL LDAP) et les API LDAP existantes.

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.	Tous les attributs de fonctionnement

La présence de l'attribut de description "+" (ASCII 43) dans la liste des attributs d'une demande de recherche [RFC2251] DEVRA signifier une demande du retour de tous les attributs de fonctionnement.

Comme avec toutes les demandes de recherche, les mises en œuvre de client devraient noter que le résultat peut ne pas inclure tous les attributs demandés à cause des contrôles d'accès et autres restrictions. Les mises en œuvre de client devraient aussi noter que certains attributs de fonctionnement peuvent n'être retournés que si ils sont demandés par leur nom même quand "+" est présent. C'est parce que certains attributs de fonctionnement sont très coûteux à retourner.

Les serveurs qui prennent en charge cette caractéristique DEVRAIENT publier l'identifiant d'objet 1.3.6.1.4.1.4203.1.5.1 comme valeur de l'attribut 'supportedFeatures' [RFC3674] dans l'entrée spécifique d’un agent système de répertoire (DSE, DSA Specific Entry) racine.

 	3.	Considérations d'interopérabilité

Ce mécanisme est spécifiquement conçu pour permettre aux utilisateurs de demander tous les attributs de fonctionnement en utilisant les clients LDAP existants. En particulier, le mécanisme est conçu pour être compatible avec les clients LDAP d'utilité générale existants incluant ceux qui prennent en charge les URL LDAP [RFC2255].

L'ajout de ce mécanisme à LDAP n'est pas estimé devoir causer de problème d'interopérabilité significatif (ceci a été confirmé par des essais). Les serveurs qui ont déjà mis en œuvre la présente spécification DEVRAIENT ignorer le "+" comme une description d'attribut non reconnue selon le paragraphe 4.5.1 de la [RFC2251]. Du point de vue du client, un serveur qui ne retourne pas tous les attributs de fonctionnement quand "+" est demandé devraient être vus comme ayant d'autres 4.5.1 restrictions.

Il est aussi noté que ce mécanisme est estimé n'exiger aucune modification des API LDAP existantes.

 	4.	Considérations sur la sécurité

Le présent document fournit un mécanisme général que les clients peuvent utiliser pour découvrir les attributs. de fonctionnement. Avant l'introduction de ce mécanisme, les attributs de fonctionnement étaient seulement découverts quand ils étaient demandés par leur nom. Certains peuvent avoir vu cela comme une caractéristique de dissimulation. Cependant, cette caractéristique donne un faux sentiment de sécurité car les attributs sont quand même transférables.

Les mises en œuvre DEVRAIENT mettre en place des mécanismes de contrôle d'accès appropriés  pour restreindre l'accès aux attributs de fonctionnement.

 	5.	Considérations relatives à l'IANA
Le présent document utilise l'OID 1.3.6.1.4.1.4203.1.5.1 pour identifier la caractéristique décrite ci-dessus. Cet OID a été alloué [ASSIGN] par la Fondation OpenLDAP, sous son allocation d'entreprise privée allouée par l'IANA [PRIVATE], pour l'utiliser dans la présente spécification.

L'enregistrement de cette caractéristique a été réalisé par l'IANA [RFC3674], [RFC3383].

Sujet : Demande d'enregistrement de mécanisme pour le protocole LDAP
Identifiant d'objet : 1.3.6.1.4.1.4203.1.5.1
Description : tous les attributs de fonctionnement
Adresse et messagerie de la personne à contacter pour plus d'informations : Kurt Zeilenga <kurt@openldap.org>
Usage : caractéristique
Spécification : RFC3673
Auteur/Contrôleur des changements : IESG
Commentaires : aucun

 	6.	Remerciements

Le mécanisme "+" a été probablement suggéré pour la première fois par Bruce Greenblatt dans un message de novembre 1998 sur la liste de diffusion du groupe de travail LDAPext de l'IETF.

 	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 .

 	8.	Références
 	8.1	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.

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

[RFC3674]	K. Zeilenga, "Dispositif de découverte dans le protocole léger d'accès à un répertoire (LDAP)", décembre 2003. (Obsolète, voir RFC4512) (P.S.)

 	8.2	Références pour information

[RFC2255]	T. Howes, M. Smith, "Format d'URL LDAP", décembre 1997. (Obsolète, voir RFC4510, RFC4516) (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)

[X.500]	Recommandation UIT-T X.500, "L'annuaire : aperçu général des concepts, modèles et services", 1993.

[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

 	9.	Adresse de l'auteur

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

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