Juin 2006

Protocole léger d'accès à un répertoire (LDAP) : Localisateur universel de ressources

Statut de ce mémo

Le présent document spécifie un protocole de normalisation Internet pour la communauté de l'Internet, qui appelle à la discussion et à des suggestions pour son amélioration. Prière de se reporter à l'édition en cours des "Normes de protocole officielles de l'Internet" (STD 1) sur l'état de la normalisation et le statut de ce protocole. La distribution du présent mémo n'est soumise à aucune restriction.

Notice de Copyright

Copyright (C) The Internet Society (2006).

Résumé

Le présent document décrit un format pour le localisateur universel de ressource (URL, Uniform Resource Locator) du protocole léger d’accès à un répertoire (LDAP, Lightweight Directory Access Protocol). Un URL LDAP décrit une opération de recherche LDAP qui est utilisée pour restituer des informations à partir d’un répertoire LDAP, ou, dans le contexte d’un renvoi de références ou d’une référence LDAP, un URL LDAP décrit un service dans lequel peut progresser une opération LDAP.

Table des matières

1 Introduction
2 Définition d’URL
2.1 Codage en pourcentage
3 Valeurs par défaut pour les champs d’URL LDAP .
4 Exemples
5 Considérations sur la sécurité
6 Références normatives
7 Références informatives
8 Remerciements
Appendice A Changements depuis la RFC 2255
A.1 Changements techniques
A.2 Changements rédactionnels

1 Introduction

LDAP est le protocole léger d’accès à un répertoire (LDAP, Lightweight Directory Access Protocol) [RFC4510]. Le présent document spécifie le format d’URL LDAP pour la version 3 de LDAP et précise comment sont résolus les URL LDAP. Le présent document définit aussi un mécanisme d’extension pour les URL LDAP. Ce mécanisme peut être utilisé pour fournir l’accès à de nouvelles extensions LDAP.

Noter que tous les paramètres de l’opération de recherche LDAP décrits dans la [RFC4511] ne peuvent pas être exprimés en utilisant le format défini dans le présent document. Noter aussi que les URL peuvent être utilisés pour représenter la connaissance d’une référence, y compris pour des opérations qui ne sont pas de recherche.

Le présent document fait partie intégrante de la spécification technique LDAP [RFC4510], qui rend obsolète la spécification technique LDAP précédemment définie, la RFC 3377, dans sa totalité. Le présent document remplace la RFC 2254. La liste des changements à la RFC 2255 figure à l’Appendice A.

Les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans le BCP 14 [RFC2119].

2 Définition d’URL

Un URL LDAP commence par le préfixe de protocole "ldap" et il est défini par la grammaire suivante, d’après la notation ABNF définie dans la [RFC4234].

ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
[SLASH dn [QUESTION [attributes]
[QUESTION [scope] [QUESTION [filter]
[QUESTION extensions]]]]]
; <host> et <port> sont définis aux paragraphes 3.2.2 et 3.2.3 de la [RFC3986].
; <filter> vient de la Section 3 de la [RFC4515], sous réserve des dispositions de la section "Codage en pourcentage" ci-dessous.
scheme = "ldap"
dn = distinguishedName ; d’après la Section 3 de la [RFC4514], sous réserve des dispositions de la section "Codage en pourcentage" ci-dessous.
attributes = attrdesc *(COMMA attrdesc)
attrdesc = selector *(COMMA selector)
selecto = attributeSelector ; d’après le paragraphe 4.5.1 de la [RFC4511], sous réserve des dispositions de la section "Codage en pourcentage" ci-dessous.
scope = "base" / "one" / "sub"
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid ; d’après le paragraphe 1.4 de la [RFC4512].
exvalue = LDAPString ; d’après le paragraphe 4.1.2 de la [RFC4511], sous réserve des dispositions de la section "Codage en pourcentage" ci-dessous.
EXCLAMATION = %x21 ; point d’exclamation ("!")
SLASH = %x2F ; barre oblique ("/")
COLON = %x3A ; deux-points (":")
QUESTION = %x3F ; point d’interrogation ("?")

Le préfixe "ldap" indique une ou des entrées accessibles à partir du serveur LDAP tournant sur le nom d’hôte donné au numéro de port donné. Noter que <host> peut contenir des adresses IPv6 littérales comme spécifié au paragraphe 3.2.2 de la [RFC3986].

Le <dn> est un nom distinctif LDAP qui utilise le format de chaîne décrit dans la [RFC4514]. Il identifie l’objet de base de la recherche LDAP ou la cible pour une opération qui n’est pas de recherche.

La construction <attributes> est utilisée pour indiquer quels attributs devraient être retournés depuis la ou les entrées.

La construction <scope> est utilisée pour spécifier le domaine de la recherche à effectuer dans le serveur LDAP donné. Les domaines admissibles sont "base" pour une recherche d’objet de base, "one" pour une recherche à un seul niveau, ou "sub" pour une recherche de sous-arbre.

Le <filter> est utilisé pour spécifier le filtre de recherche à appliquer aux entrées au sein du domaine spécifié durant la recherche. Il a le format spécifié dans la [RFC4515].

La construction <extensions> donne l’URL LDAP avec un mécanisme d’extensibilité, permettant d’étendre les capacités de l’URL à l’avenir. Les extensions sont une simple liste séparée par des virgules de paires type=value, où la portion =value PEUT être omise pour les options qui ne l’exigent pas. Chaque paire type=value est une extension séparée. Ces extensions d’URL LDAP ne se rapportent pas nécessairement à un des mécanismes d’extension LDAP. Les extensions peuvent être prises en charge ou non par le client qui résout l’URL. Une extension avec le caractère '!' (ASCII 0x21) en préfixe est critique. Une extension sans le caractère '!' en préfixe n’est pas critique.

Si une extension d’URL LDAP est mise en œuvre (c’est à dire, si la mise en œuvre la comprend et est capable de l’utiliser), la mise en œuvre DOIT en faire usage. Si une extension n’est pas mise en œuvre et est marquée critique, la mise en œuvre NE DOIT PAS traiter l’URL. Si une extension n’est pas mise en œuvre et n’est pas marquée critique, la mise en œuvre DOIT ignorer l’extension.

Le type d’extension (<extype>) PEUT être spécifié en utilisant la forme d’OID numérique <numericoid> (par exemple, 1.2.3.4) ou la forme de descripteur <descr> (par exemple, myLDAPURLExtension). L’utilisation de la forme <descr> DEVRAIT être restreinte aux noms descriptifs d’identifiant d’objet enregistré. Voir à la [RFC4520] les questions d’enregistrement et les lignes directrices d’utilisation pour les noms descriptifs.

Aucune extension d’URL LDAP n’est définie dans le présent document. D’autres documents ou une version future du présent document PEUVENT définir une ou plusieurs extensions.

2.1 Codage en pourcentage

Un URL LDAP généré ne DOIT consister qu’en un ensemble restreint de caractères inclus dans une des trois productions suivantes définies dans la [RFC3986] :

<reserved>
<unreserved>
<pct-encoded>

Les mises en œuvre DEVRAIENT accepter en entrée d’autres chaînes UTF-8 valides [RFC3629]. Un octet DOIT être codé en utilisant le mécanisme de codage en pourcentage décrit au paragraphe 2.1 de la [RFC3986] dans les trois situations suivantes :

L’octet n’est pas dans l’ensemble réservé défini au paragraphe 2.2 de la [RFC3986] ou dans l’ensemble non réservé défini au paragraphe 2.3 de la [RFC3986].

Il est le seul caractère '?' réservé et survient dans un élément <dn>, <filter>, ou autre d’un URL LDAP.

Il est un caractère virgule ',' qui survient dans une <exvalue>.

Noter qu’avant d’appliquer le mécanisme de codage en pourcentage, le composant extensions de l’URL LDAP peut contenir un ou plusieurs octets nuls (zéro). Aucun autre composant ne le peut.

3 Valeurs par défaut pour les champs d’URL LDAP

Certains champs de l’URL LDAP sont facultatifs, comme décrit ci-dessus. En l’absence d’autre spécification, les valeurs générales par défaut DEVRAIENT être utilisées lorsqu’un champ est absent. Noter que d’autres documents PEUVENT spécifier des règles de valeurs par défaut différentes ; par exemple, le paragraphe 4.1.10 de la [RFC4511] spécifie une règle différente pour déterminer le nom distinctif correct à utiliser lorsqu’il est absent dans un URL LDAP qui est retourné comme renvoi de référence (referral).

<host>
Si aucun <host> n’est donné, le client doit avoir une connaissance a priori du serveur LDAP approprié à contacter.

<port>
Le port LDAP par défaut est le port TCP 389.

<dn>
Si aucun <dn> n’est donné, la valeur par défaut est le DN de longueur zéro, "".

<attributes>
Si la partie <attributes> est omise, tous les attributs d’utilisateur de la ou des entrées devraient être demandés (par exemple, en réglant le champ des attributs AttributeDescriptionList dans la demande de recherche LDAP à la liste NULL, ou en utilisant le sélecteur spécial <alluserattrs> "*").

<scope>
Si <scope> est omis, un <scope> de "base" est supposé.

<filter>
Si <filter> est omis, un filtre de "(objectClass=*)" est supposé.

<extensions>
Si <extensions> est omis, aucune extension n’est supposée.

4 Exemples

Ci-après figurent des exemples d’URL LDAP qui utilisent le format défini ci-dessus. Le premier exemple est un URL LDAP qui se réfère à l’entrée University of Michigan, disponible à partir d’un serveur LDAP du choix du client :

ldap:///o=University%20of%20Michigan,c=US

L’exemple suivant est un URL LDAP qui se réfère à l’entrée University of Michigan dans un serveur ldap particulier :

ldap://ldap1.example.net/o=University%20of%20Michigan,c=US

Ces deux URL correspondent à une recherche d’objet de base de l’entrée "o=University of Michigan,c=US" en utilisant un filtre de "(objectclass=*)", demandant tous les attributs.

L’exemple suivant est un URL LDAP qui se réfère seulement à l’attribut postalAddress de l’entrée University of Michigan :

ldap://ldap1.example.net/o=University%20of%20Michigan,

c=US?postalAddress

L’opération de recherche LDAP correspondante est la même que dans l’exemple précédent, excepté que seul l’attribut postalAddress est demandé.

L’exemple suivant est un URL LDAP qui se réfère à l’ensemble des entrées trouvées en interrogeant le serveur LDAP désigné sur le port 6666 et en faisant une recherche de sous arbre de l’Université du Michigan pour toute entrée avec un nom commun de "Babs Jensen", restituant tous les attributs :

ldap://ldap1.example.net:6666/o=University%20of%20Michigan,

c=US??sub?(cn=Babs%20Jensen)

L’exemple suivant est un URL LDAP qui se réfère à tous les enfants de l’entrée c=GB :

LDAP://ldap1.example.com/c=GB?objectClass?ONE

Il est demandé que l’attribut objectClass soit retourné avec les entrées, et le filtre par défaut "(objectclass=*)" est utilisé.

L’exemple suivant est un URL LDAP pour restituer l’attribut de messagerie électronique de l’entrée LDAP nommée "o=Question?,c=US", illustrant l’utilisation du mécanisme de codage en pourcentage sur le caractère réservé '?'.

ldap://ldap2.example.com/o=Question%3f,c=US?mail

L’exemple suivant (qui est placé sur deux lignes pour le rendre lisible) illustre l’interaction entre la représentation de chaîne LDAP du mécanisme de citation des filtres et des mécanismes de citation d’URL.

ldap://ldap3.example.com/o=Babsco,c=US
???(four-octet=%5c00%5c00%5c00%5c04)

Dans cet exemple, le filtre utilise le mécanisme d’échappement de LDAP de \ pour coder trois octets zéro ou nuls dans la valeur. En LDAP, le filtre serait écrit avec (four-octet=\00\00\00\04). Parce que le caractère \ doit être esquivé dans un URL, les \ sont codés en pourcentage avec %5c (ou %5C) dans le codage de l’URL.

L’exemple suivant illustre l’interaction entre la représentation de chaîne LDAP du mécanisme de citation des noms distinctifs et des mécanismes de citation d’URL.

ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US

Le nom distinctif codé dans l’URL ci-dessus est :

o=An Example\2C Inc.,c=US

C’est-à-dire que la valeur de RDN la plus à gauche est :

An Example, Inc.

Les trois URL suivants sont équivalents, en supposant qu’on utilise les règles de valeur par défaut spécifiées à la Section 3 du présent document :

ldap://ldap.example.net
ldap://ldap.example.net/
ldap://ldap.example.net/?

Ces trois URL pointent sur le DSE racine sur le serveur ldap.example.net.

Les deux derniers exemples donnés montrent l’utilisation d’une extension de nom de lien expérimental, hypothétique (la valeur associée à l’extension est un DN LDAP).

ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com

Les deux URL sont les mêmes, excepté que le second marque l’extension e-bindname comme critique. Remarquer l’utilisation du mécanisme de codage en pourcentage pour coder les virgules au sein de la valeur de nom distinctif dans l’extension e-bindname.

5 Considérations sur la sécurité

Les considérations générales sur la sécurité des URL exposées dans la [RFC3986] sont pertinentes pour les URL LDAP.

L’utilisation des mécanismes de sécurité lors du traitement des URL LDAP requiert un soin particulier, car les clients peuvent rencontrer de nombreux serveurs différents via les URL, et les URL sont vraisemblablement traités automatiquement, sans intervention de l’utilisateur. Un client DEVRAIT avoir une politique configurable par l’utilisateur qui contrôle avec quels serveurs le client va établir des sessions LDAP et avec quels mécanismes de sécurité, et NE DEVRAIT PAS établir de sessions LDAP qui ne soit pas en cohérence avec cette politique. Si un client choisit de réutiliser une session LDAP existante lors de la résolution d’une ou plusieurs URL LDAP, il DOIT s’assurer que la session est compatible avec l’URL et qu’aucune politique de sécurité n’est violée.

Envoyer des informations d’authentification, quel que soit le mécanisme, peut violer des exigences de confidentialité de l’utilisateur. En l’absence de politique spécifique permettant d’envoyer les informations d’authentification à un serveur, un client devrait utiliser une session LDAP anonyme. (Noter que les clients qui se conforment aux spécifications d’URL LDAP précédentes, où toutes les sessions LDAP sont anonymes et non protégées, sont cohérents avec cette spécification ; ils ont simplement la politique de sécurité par défaut.) Le simple fait d’ouvrir une connexion de transport avec un autre serveur peut violer des exigences de confidentialité d’utilisateur, de sorte que les clients devraient fournir à l’utilisateur un moyen de contrôler le traitement d’URL.

Certaines méthodes d’authentification, en particulier, les mots de passe réutilisables envoyés au serveur, peuvent révéler des informations facilement falsifiées au serveur distant ou à un espion dans le transit et ne devraient pas être utilisées dans le traitement d’URL si elles ne sont pas explicitement permises par la politique. La confirmation par l’utilisateur humain de l’utilisation d’informations d’authentification est appropriée dans de nombreuses circonstances. L’utilisation de méthodes d’authentification fortes qui ne révèlent pas d’informations sensibles est très préférable. Si l’URL représente un renvoi de références pour une opération de mise à jour, des méthodes d’authentification fortes DEVRAIENT être utilisées. Prière de se référer à la Section Considérations sur la sécurité de la [RFC4513] pour plus d’informations.

Le format d’URL LDAP permet d’effectuer la spécification d’une opération de recherche LDAP arbitraire lors de l’évaluation de l’URL LDAP. Suivre un URL LDAP peut provoquer des résultats inattendus, par exemple, la restitution de grandes quantités de données ou l’initialisation de longues recherches. Les implications de sécurité de la résolution d’un URL LDAP sont les mêmes que celles de la résolution d’une interrogation de recherche de LDAP.

6 Références normatives

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

[RFC3629] Yergeau, F., "UTF-8, un format de transformation de ISO 10646", STD 63, RFC 3629, novembre 2003.

[RFC3986] Berners-Lee, T., Fielding, R., et L. Masinter, "Identifiant universel de ressource (URI) : Syntaxe générique", STD 66, RFC 3986, janvier 2005.

[RFC4234] Crocker, D. et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", RFC 4234, octobre 2005.

[RFC4510] Zeilenga, K., Ed., "Protocole léger d’accès à un répertoire (LDAP) : Descriptif des spécifications techniques", RFC 4510, juin 2006.

[RFC4511] Sermersheim, J., Ed., "Protocole léger d’accès à un répertoire (LDAP)  Le protocole", RFC 4511, juin 2006.

[RFC4512] Zeilenga, K., "Protocole léger d’accès à un répertoire (LDAP) : Modèle d’informations de répertoires", RFC 4512, juin 2006.

[RFC4513] Harrison, R., Ed., "Protocole léger d’accès à un répertoire (LDAP) : Méthodes d’authentification et mécanismes de sécurité", RFC 4513, juin 2006.

[RFC4514] Zeilenga, K., Ed., "Protocole léger d’accès à un répertoire (LDAP) : Représentation de chaîne des noms distinctifs", RFC 4514, juin 2006.

[RFC4515] Smith, M. Ed. et. Howes, "Protocole léger d’accès à un répertoire (LDAP) : Représentation de chaîne des filtres de recherche", RFC 4515, juin 2006.

7 Références informatives

[RFC2396] Berners-Lee, T., Fielding, R., et L. Masinter, "Identifiant universel de ressource (URI) : Syntaxe générique", RFC 2396, août 1998.

[RFC4520] Zeilenga, K., "Autorité d’allocation des numéros de l’Internet (IANA) : Considérations pour le Protocole léger d’accès à un répertoire (LDAP)", BCP 64, RFC 4520, juin 2006.

8 Remerciements

Le format d’URL LDAP a été défini à l’origine à l’Université du Michigan. Ces éléments se fondent sur les travaux effectués par le National Science Foundation sous le numéro d’allocation NCR-9416667. Le soutien aussi bien de l’Université du Michigan que de la National Science Foundation est apprécié avec gratitude.

Le présent document rend obsolète la RFC 2255 par Tim Howes et Mark Smith. Les changements inclus dans la présente spécification révisée se fondent sur des discussions entre les auteurs, des discussions au sein du groupe de travail de révision de LDAP (v3) (ldapbis), et de discussions au sein des autres groupes de travail de l’IETF. Nos remerciements vont aux contributions individuelles dans ces groupes de travail. Plusieurs personnes ont en particulier apporté des commentaires utiles sur ce document : les contributions de RL "Bob" Morgan, Mark Wahl, Kurt Zeilenga, Jim Sermersheim, et Hallvard Furuseth méritent une mention particulière.

Appendice A Changements depuis la RFC 2255

A.1 Changements techniques

Les changements techniques suivants ont été faits au contenu de la section "Définition d’URL" :

Révision de tous les ABNF pour utiliser les productions communes tirées de la [RFC4512].

Remplacement de la référence à la [RFC2396] par la référence à la [RFC3986] (cela permet d’utiliser les adresses littérales IPv6 à l’intérieur de la portion <host> de l’URL, et ajout d’une note pour rappeler cette amélioration au lecteur). La référence à la [RFC3986] requiert de changer l’ABNF et le texte de sorte que les productions qui ne sont plus définies par la [RFC3986] ne sont plus utilisées. Par exemple, <hostport> n’est pas défini par la [RFC3986] et il a été remplacé par l’hôte [COLON port]. Noter que la [RFC3986] inclut de nouvelles définitions pour les ensembles de caractères "Reserved" et "Unreserved", et le résultat net est que les deux caractères supplémentaires suivants devraient être codés en pourcentage lorsqu’ils apparaissent n’importe où dans les données utilisées pour construire un URL LDAP : "[" et "]" (ces deux caractères avaient d’abord été ajoutés à l’ensemble "Reserved" par la RFC 2732).

Changement de la définition de <attrdesc> pour se référer à <attributeSelector> d’après la [RFC4511]. Ceci permet d’utilisation de "*" dans la partie <attrdesc> de l’URL. On pense que les mises en œuvre existantes de la RFC 2255 le prennent déjà en charge.

On évite l’utilisation des productions <prose-val> (chaîne entre guillemets) dans les règles <dn>, <host>, <attrdesc>, et <exvalue>.

Changement de l’ABNF pour <ldapurl> pour grouper le composant <dn> avec le <SLASH> précédent.

Changement de la règle <extype> pour un <oid> d’après la [RFC4512].

Changement du texte sur les types d’extension de façon qu’il fasse référence à la [RFC4520]. L’ordre des règles a été revu pour suivre de plus près l’ordre dans lequel apparaissent les éléments dans l’URL.

"Bindname Extension" a été supprimé car n’ayant donné lieu à aucune mise en œuvre connue.

A.2 Changements rédactionnels

Changement du titre du document pour inclure le préfixe "LDAP".

Suppression de la note IESG sur le manque de mécanismes d’authentification obligatoire satisfaisants.

Ajout des sections "Table des matières" et "Propriété intellectuelle".

Copyright : mise à jour selon les dernières lignes directrices de l’IETF.

Section "Introduction" nouvelle, séparée du Résumé. Changement du texte indiquant que la RFC 2255 est remplacée par le présent document (au lieu de la RFC 1959). Ajout du texte qui indique que les URL LDAP sont utilisés pour les références et renvois de références. Correction typographique (remplacement de la phrase "effectuer pour restituer" par "utilisé pour restituer"). Ajout d’une note pour faire savoir au lecteur que ce ne sont pas tous les paramètres de l’opération de recherche LDAP décrits dans la [RFC4511] qui peuvent être exprimés en utilisant ce format.

A la section"Définition d’URL" , suppression de la seconde copie de la grammaire de <ldapurl> et des deux paragraphes suivants (erreur rédactionnelle dans la RFC 2255). Fixation de la coupure de ligne dans la séquence '!'. Reformatage de l’ABNF pour améliorer la lisibilité en alignant les commentaires et en ajoutant des lignes blanches. Remplacement de "résidant dans le serveur LDAP" par "accessible depuis le serveur LDAP" dans la sentence suivant immédiatement l’ABNF. Suppression de la phrase "Les noms attrdesc individuels sont définis pour AttributeDescription dans la [RFC4511]." parce que le <attributeSelector> de la [RFC4511] est maintenant directement utilisé dans l’ABNF. Reformulation du dernier paragraphe pour préciser quels caractères doivent être codés en pourcentage. Ajout du texte indiquant que les URL LDAP sont utilisés pour les références et renvois de références. Ajout du texte qui se réfère à l’ABNF d’après la RFC 4234. Précision et renforcement des exigences par rapport au traitement des URL qui contiennent des extensions mises en œuvre et non mises en œuvre (cette approche correspond maintenant tout à fait à celle spécifiée dans la [RFC4511] pour les contrôles LDAP).

Ajout de la section "Valeurs par défaut pour les champs de l’URL LDAP", formée en déplaçant le texte sur les valeurs par défauts de la section "Définition d’URL". Remplacement de la référence directe au nom d’attribut "*" par une référence au sélecteur spécial <alluserattrs> "*" défini dans la [RFC4511].

Suppression de la section "Traitement de l’URL".

A la section "Exemples" : Modification des exemples pour utiiliser example.com et example.net hostnames. Ajout du '?' manquant à l’exemple d’URL LDAP dont le filtre contient trois octets nuls. Suppression de l’espace après une virgule dans un DN. Révision de l’exemple bindname pour utiliser e-bindname. Changement du nom d’un attribut utilisé dans un exemple de "int" en "four-octet" pour éviter d’éventuelles confusions. Ajout d’un exemple qui montre l’interaction entre un échappement de DN et un codage en pourcentage d’URL. Ajout de quelques exemples pour montrer l’équivalence d’URL par rapport à la portion <dn> de l’URL. Utilisation de majuscules dans certains exemples pour rappeler au lecteur que certains jetons sont insensibles à la casse.

Section "Considérations de sécurité" : Ajout d’une note sur la réutilisation de connexion. Ajout d’une note sur l’utilisation de méthodes fortes d’authentification pour les misese à jour. Ajout d’une référence à la [RFC4513]. Ajout d’une note disant que le simple fait d’ouvrir une connexion peut violer certaines exigences de confidentialité d’utilisateur. Adoption de la spécification de terminologie LDAP révisée du groupe de travail en remplaçant le mot "connexion" selon le cas approprié par "session LDAP" ou "connexion LDAP".

A la section "Remerciements", ajout de la mention que ce document rend obsolète la RFC 2255. Ajout de Kurt Zeilenga, Jim Sermersheim, et Hallvard Furuseth.

La section "Références" a été renommée "Références normatives" selon les nouvelles lignes directrices pour les RFC. Changement du style [1] au style de la [RFC4511] tout au long du document. Ajout des références à la RFC 4234 et RFC 3629. Mise à jour de toutes les références à la RFC 1738 pour mentionner les paragraphes appropriés dans la [RFC3986]. Mise à jour des références LDAP pour se référer aux documents du groupe de travail LDAPBis. Suppression de la référence au document des syntaxes d’attribut LDAP et ajout des références aux [RFC4513], [RFC4520], et [RFC4510].

Ajout de la section "Références informatives".

Ajout de "éditeur" à côté du nom de Mark Smith. Mise à jour des informations d’affiliation et de contact.

Mise à jour de l’année du Copyright.

Dans tout le document, les noms de toutes les productions en ABNF sont entourées de "<" et ">" lorsqu’elles sont utilisées dans du texte descriptif.

Adresse des auteurs

Déclaration de copyright

Copyright (C) The Internet Society (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs 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.

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 pourrait ê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 o 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 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.

Remerciement

Le financement de la fonction d'édition des RFC est actuellement fourni par l'activité de soutien administratif de l'IETF (IASA, Administrative Support Activity).