Groupe de travail Réseau |
K. Zeilenga |
Request for Comments : 4520 |
OpenLDAP Foundation |
BCP : 64 |
Juin 2006 |
RFC rendue obsolète : 3383 |
|
Catégorie : Guide de bonne conduite |
Traduction Claude Brière de L’Isle, mai 2007 |
Statut de ce mémo
Le présent document spécifie les bonnes pratiques en cours sur l’Internet pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. La diffusion 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 donne les procédures pour enregistre les éléments d’extension du protocole léger d’accès à un répertoire (LDAP, Lightweight Directory Access Protocol ). Le document donne aussi des lignes directrices de l’Autorité d’allocation des numéros Internet (IANA, Internet Assigned Numbers Authority ) qui décrivent les conditions dans lesquelles de nouvelles valeurs peuvent être allouées.
Le protocole léger d’accès à un répertoire [RFC4510] (LDAP) est un protocole extensible. LDAP accepte :
- L’ajout de nouvelles opérations,
- L’extension des opérations existantes, et
- Le schéma extensible.
Le présent document précise les procédures pour l’enregistrement des valeurs utilisées pour identifier de façon non ambiguë les éléments extensibles du protocole, y compris ceux qui suivent :
- types de message LDAP
- opérations et commandes LDAP étendues
- codes de résultat LDAP
- méthodes d’authentification LDAP
- options de description d’attribut LDAP
- descripteurs d’identifiant d’objet
Ces registres sont conservés par l’Autorité d’allocation des numéros Internet (IANA).
De plus, le présent document donne des lignes directrices à l’IANA pour décrire les conditions dans lesquelles de nouvelles valeurs peuvent être allouées.
Le présent document remplace la RFC 3383.
La présente section détaille les termes et conventions utilisés dans le présent document.
Les termes " IESG Approval " (approbation par l’IESG), " Standards Action " (action de normalisation), "IETF Consensus" (consensus de l’IETF), " Specification Required " (spécification éxigée), " First Come First Served " (premier arrivé, premier servi), " Expert Review " (révision par experts), et " Private Use " (utilisation privée) sont utilisés conformément à la définition du BCP 26 [RFC2434].
Le terme " registration owner " (propriétaire de l’enregistrement) (ou " owner ") se réfère à la partie autorisée à changer l'enregistrement d’une valeur.
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT", "NE DEVRAI PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans le BCP 14 [RFC2119]. Dans ce cas, "la spécification", telle qu’utilisée par le BCP 14, se réfère au traitement des protocoles qui sont soumis au processus de normalisation de l’IETF.
Un certain nombre de syntaxes sont décrites dans le présent document en utilisant l’ABNF [RFC4234]. Ces syntaxes s’appuient sur les productions communes suivantes
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
LDIGIT = %x31-39 ; "1"-"9"
DIGIT = %x30 / LDIGIT ; "0"-"9"
HYPHEN = %x2D ; "-"
DOT = %x2E ; "."
number = DIGIT / ( LDIGIT 1*DIGIT )
keychar = ALPHA / DIGIT / HYPHEN
leadkeychar = ALPHA
keystring = leadkeychar *keychar
keyword = keystring
Les mots clés sont insensibles à la casse.
La présente section précise chaque sorte de valeur de protocole qui peut être enregistrée et donne les lignes directrices de l’IANA sur la façon d’allouer de nouvelles valeurs.
L’IANA peut rejeter les enregistrements manifestement erronés.
Les valeurs LDAP spécifiées dans les RFC DOIVENT être enregistrées. D’autres valeurs LDAP, sauf celles des espaces de noms à utilisation privée, DEVRAIENT être enregistrées. Les RFC NE DEVRAIENT PAS faire référence, usage, ou de toutes façons, reconnaître des valeurs LDAP non enregistrées.
De nombreux éléments de schémas et protocoles LDAP sont identifiés par des identifiants d’objet (OID) [X.680]. Les spécifications qui allouent des OID à des éléments DEVRAIENT déclarer qui a délégué les OID pour leur usage.
Pour les éléments développés par l’IETF, les spécifications DEVRAIENT utiliser les OID sous des "Numéros de répertoire Internet" (1.3.6.1.1.x). Pour les éléments développés par d’autres, tout OID délégué de façon appropriée peut être utilisé, y compris ceux qui sont sous des "numéros de répertoire Internet" (1.3.6.1.1.x) ou des "numéros d’entreprise privée" (1.3.6.1.4.1.x).
Les numéros de répertoire Internet (1.3.6.1.1.x) seront alloués sur révision d’expert avec les spécifications exigées. Seul un OID par spécification sera alloué. La spécification PEUT alors allouer tout nombre d’OID au sein de cet arc sans autre coordination avec l’IANA.
Les numéros Internet d’entreprise privée (1.3.6.1.4.1.x) sont alloués par IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Les pratiques pour l’allocation par IANA des numéros Internet d’entreprise privée sont précisées dans la RFC 2578.
Pour éviter des problèmes d’interopérabilité entre les mises en œuvre précoces d’un "travail en cours" et les mises en oeuvres de la spécification publiée (par exemple, la RFC), des OID expérimentaux DEVRAIENT être utilisés dans les "travaux en cours" et les mises en œuvre précoces. Des OID sous l’arc d’OID Internet expérimental (1.3.6.1.3.x) peuvent être utilisés à cette fin. Les pratiques d’allocation par IANA de ces numéros Internet expérimentaux sont précisées dans la RFC 2578.
LDAP fournit un certain nombre d’attributs racines d’entrées spécifiques de DSA (DSE, DSA-Specific Entry ) pour la découverte des mécanismes de protocole identifiés par les OID, y compris les attributs supportedControl, supportedExtension, et supportedFeatures [RFC4512].
Un registre des OID utilisés pour la découverte des mécanismes de protocole est fourni pour permettre aux développeurs et autres de localiser la spécification technique pour ces mécanismes de protocole. Les spécifications futures d’attributs DSE racines supplémentaires qui contiennent des valeurs qui identifient des mécanismes de protocole PEUVENT étendre ce registre à leurs valeurs.
Les mécanismes de protocole sont enregistrées sur la base du premier arrivant premier servi.
Ce registre donne une liste des syntaxes LDAP [RFC4512]. Chaque syntaxe LDAP est identifiée par un OID. Ce registre est fourni pour permettre aux développeurs et autres de localiser une spécification technique décrivant une syntaxe LDAP particulière.
Les syntaxes LDAP sont enregistrées sur la base de premier arrivant premier servi de la spécification exigée.
Note : À la différence des classes d’objet, des types d’attribut, et diverses autres sortes d’éléments de schéma, les descripteurs ne sont pas utilisés dans LDAP pour identifier les syntaxes LDAP.
LDAP permet d’utiliser des noms descriptifs courts (ou descripteurs) au lieu d’un identifiant d’objet numérique pour identifier les extensions choisies de protocole [RFC4511], d’élément de schéma [RFC4512], d’URL LDAP [RFC4516], et d’autres objets.
Bien que le protocole permette que le même descripteur se réfère à différents identifiants d’objet dans certains cas et que le registre prenne en charge plusieurs enregistrements du même descripteur (chacun indiquant une sorte différente d’élément de schéma et des identifiants d’objet différents), plusieurs enregistrements du même descripteur sont à éviter. Toutes ces demandes d’enregistrement multiples exigent une révision d’experts.
Les descripteurs sont réservés aux chaînes de caractères Unicode codés en UTF-8 [RFC3629] avec la restriction de l’ABNF suivant :
name = keystring
Les descripteurs sont insensibles à la casse.
Plusieurs noms peuvent être alloués à un OID donné. Pour les besoins de l’enregistrement, un OID sera représenté en forme d’OID numérique (par exemple, 1.1.0.23.40) conformément à l’ABNF suivant :
numericoid = number 1*( DOT number )
Bien que le protocole n’impose aucune restriction de longueur maximale aux descripteurs, ils devraient être courts. Les descripteurs plus longs que 48 caractères peuvent être perçus comme trop longs pour l’enregistrement.
Une valeur qui se termine par un trait d’union ("-") réserve tous les descripteurs qui commencent par cette valeur. Par exemple, l’enregistrement de l’option "descrFamily-" réserve toutes les options qui commencent par "descrFamily-" pour des objets qui s’y rapportent.
Les descripteurs qui commencent par "x-" sont pour utilisation privée et ne peuvent être enregistrés.
Les descripteurs qui commencent par "e-" sont réservé pour les expériences et seront enregistrés sur la base du premier arrivé, premier servi.
Tous les autres descripteurs exigent un examen d’expert pour être enregistrés.
Il n’est pas nécessaire qui l’OID désigné soit la "propriété" de celui qui dépose la demande d’enregistrement.
L’espace de nom de l’OID est géré par le sous-comité 6 du comité technique conjoint n° 1 de l’ISO/CEI.
Une AttributeDescription [RFC4512] peut contenir zéro ou plusieurs options qui spécifient des sémantiques supplémentaires. Une option DOIT être restreinte à une chaîne de caractères Unicode codés en UTF-8 limitée par l’ABNF suivant :
option = keystring
Les options sont insensibles à la casse.
Bien que le protocole n’établisse aucune restriction de longueur maximale sur les chaînes d’option, elles devraient être courtes. Les options plus longues que 24 caractères peuvent être perçues comme trop longues à enregistrer.
Les valeurs qui se terminent par un trait d’union ("-") réservent tous les noms d’option qui commencent par le nom. Par exemple, l’enregistrement de l’option "optionFamily-" réserve toutes les options qui commencent par "optionFamily-" pour un objet qui s’y rapporte.
Les options qui commencent par "x-" sont pour utilisation privée et ne peuvent pas être enregistrés.
Les options qui commencent par "e-" sont réservées aux expériences et seront enregistrées sur la base du premier arrivé, premier servi.
Toutes les autres options exigent une action de normalisation ou une révision d’expert avec l’exigence d’enregistrement de la spécification.
Chaque message de protocole est encapsulé dans une enveloppe LDAPMessage [RFC4511. Le CHOIX protocolOp indique le type de message encapsulé. Chaque type de message consiste en un identifiant ASN.1 de la forme d’un mot d’un numéro de choix non négatif. Le numéro de choix est combiné avec la classe (APPLICATION) et le type de données (CONSTRUCTED ou PRIMITIVE) pour construire l’étiquette du BER dans le codage du message. Les numéros de choix pour les messages de protocole existants sont implicites dans l’ASN.1 des protocoles définis dans la [RFC4511].
Les nouvelles valeurs seront enregistrées en fonction de l’action de normalisation.
Note : LDAP fournit des messages extensibles qui réduisent mais n’éliminent pas la nécessité d’ajouter de nouveaux types de message.
L’opération Bind de LDAP prend en charge plusieurs méthodes d’authentification [RFC4511]. Chaque choix d’authentification consiste en un identifiant ASN.1 de la forme d’un mot clé et d’un entier non négatif.
Le registrant DOIT classer l’utilisation de la méthode d’authentification à l’aide de l’un des termes suivants :
COMMON - la méthode est appropriée à un usage courant sur l’Internet.
LIMITED USE - la méthode est appropriée pour un usage limité.
OBSOLETE - la méthode a été déconseillée ou trouvée inappropriée pour tout usage.
Les méthodes sans spécifications disponibles au public NE DOIVENT PAS être classées comme COMMON. De nouveaux enregistrements de la classe OBSOLETE ne peuvent pas être effectués.
Les entiers de nouvelle méthode d’authentification dans la gamme de 0 à 1023 exigent que l’action de normalisation soit enregistrée. Les entiers de nouvelle méthode d’authentification dans la gamme de 1024 à 4095 exigent une relecture d’expert avec spécification exigée. Les entiers de nouvelle méthode d’authentification dans la gamme de 4096 à 16383 seront enregistrés sur la base du premier arrivé, premier servi. Les mots clés associés aux entiers dans la gamme de 0 à 4095 NE DOIVENT PAS commencer par "e-" ou "x-". Les mots clés associés à des entiers dans la gamme de 4096 à 16383 DOIVENT commencer par "e-". Les valeurs supérieures ou égales à 16 384 et les mots clés commençant par "x-" sont pour utilisation privée et ne peuvent pas être enregistrés.
Note : LDAP prend en charge l’authentification simple et les couches de sécurité (SASL) de la [RFC4422] comme un choix d’authentification. SASL est un cadre d’authentification extensible.
Les messages de résultat LDAP portent une valeur énumérée de resultCode pour indiquer le résultat de l’opération [RFC4511]. Chaque code de résultat consiste en un identifiant ASN.1 de la forme d’un mot clé et d’un entier non négatif.
Les nouveaux entiers de resultCodes dans la gamme de 0 à 1023 exigent d’être enregistrés par l’action de normalisation. Les nouveaux entiers de resultCode dans la gamme de 1024 à 4095 exigent une révision par les experts avec la spécification exigée. De nouveaux entiers de resultCode dans la gamme de 4096 à 16 383 seront enregistrés sur la base du premier arrivé premier servi. Les mots clés associés aux entiers dans la gamme de 0 à 4095 NE DOIVENT PAS commencer par "e-" ou "x-". Les mots clés associés aux entiers dans la gamme 4096 à 16 383 DOIVENT commencer par "e-". Les valeurs supérieures ou égales à 16 384 et les mots clés commençant par "x-" sont pour utilisation privée et ne peuvent pas être enregistrés.
Les messages SearchRequest LDAP portent une valeur énumérée dans le domaine d’application pour indiquer la portée d’une recherche au sein du DIT [RFC4511]. Chaque valeur de recherche consiste en un identifiant ASN.1 sous la forme d’un mot clé et d’un entier non négatif.
Les nouveaux entiers de portée dans la gamme de 0 à 1023 exigent d’être enregistrés par l’action de normalisation. Les nouveaux entiers de portée dans la gamme de 1024-4095 exigent une révision par les experts avec la spécification exigée. Les nouveaux entiers de portée dans la gamme de 4096-16383 seront enregistrés sur la base du premier arrivé premier servi. Les mots clés associés aux entiers dans la gamme de 0 à 4095 NE DOIVENT PAS commencer par "e-" ou "x-". Les mots clés associés aux entiers dans la gamme 4096 à 16 383 DOIVENT commencer par "e-". Les valeurs supérieures ou égales à 16 384 et les mots clés commençant par "x-" sont pour utilisation privée et ne peuvent pas être enregistrés.
Les filtres LDAP sont utilisés pour faire des assertions au sujet d’un objet représenté dans le répertoire [RFC4511]. Le filtre CHOICE indique un type d’assertion. Chaque filtre CHOICE consiste en un identifiant ASN.1 sous la forme d’un mot clé et d’un numéro de choix non négatif.
Le numéro de choix est combiné avec la classe (APPLICATION) et le type de données (CONSTRUCTED ou PRIMITIVE) pour construire l’étiquette de BER dans le codage du message.
Note : LDAP fournit le choix extensibleMatching, qui réduit mais n’élimine pas le besoin de nouveaux choix de filtres.
ModifyRequest de LDAP porte une séquence d’opérations de modification [RFC4511]. Chaque sorte d’opération (par exemple, ajouter, supprimer, remplacer) consiste en un identifiant ASN.1 sous la forme d’un mot clé et d’un entier non négatif.
Les entiers de nouveau type d’opération dans la gamme de 0 à 1023 exigent d’être enregistrés par l’action de normalisation. Les entiers de nouveau type d’opération dans la gamme de 1024-4095 demandent une révision par les experts avec la spécification exigée. Les entiers de nouveau type d’opération dans la gamme de 4096-16383 seront enregistrés sur la base du premier arrivé premier servi. Les mots clés associés aux entiers dans la gamme de 0 à 4095 NE DOIVENT PAS commencer par "e-" ou "x-". Les mots clés associés aux entiers dans la gamme 4096 à 16 383 DOIVENT commencer par "e-". Les valeurs supérieures ou égales à 16 384 et les mots clés commençant par "x-" sont pour utilisation privée et ne peuvent pas être enregistrés.
Les identités d’autorisation dans LDAP sont des chaînes qui se conforment à la production <authzId> [RFC4513]. Cette production est extensible . Chaque nouvelle forme d’autorisation spécifique est identifiée par une chaîne en préfixe qui se conforme à l’ABNF suivant :
prefix = keystring COLON
COLON = %x3A ; COLON (":" U+003A)
Les préfixes sont insensibles à la casse.
Bien que le protocole ne fixe pas de restriction à la longueur maximale des chaînes de préfixe, elles devraient être courtes. Les préfixes plus longs que 12 caractères peuvent être perçus comme trop longs à enregistrer.
Les préfixes qui commencent par "x-" sont pour utilisation privée et ne peuvent pas être enregistrés.
Les préfixes qui commencent par "e-" sont réservés aux expériences et seront enregistrés sur la base du premier arrivé premier servi.
Tous les autres préfixes exigent d’être enregistrés par l’action de normalisation ou d’être révisé par des experts avec la spécification exigée.
Le registre tenu par l’IANA des "Noms des systèmes de répertoires" [IANADSN] des mots clés valides pour les attributs bien connus a été utilisé dans la représentation de chaîne LDAPv2 d’un nom distinctif [RFC1779]. LDAPv2 est maintenant dépassée [RFC3494].
Les noms de systèmes de répertoires n’ont pas d’utilisation connue dans un autre contexte. LDAPv3 [RFC4514] utilise les descripteurs d’identifiant d’objet (Object Identifier Descriptors ) [paragraphe 3.2] (qui ont une syntaxe différente de celle des noms de système de répertoire).
De nouveaux noms de systèmes de répertoire ne seront plus acceptés. Pour les besoins des historiens, la liste actuelle des noms enregistrés devrait rester accessible au public.
La procédure donnée ici DOIT être utilisée par tous ceux qui souhaitent utiliser une nouvelle valeur d’un type décrit à la Section 3 du présent document.
La première étape pour le demandeur est de remplir le formulaire approprié. Des modèles sont fournis à l’Appendice A .
Si la politique est l’action de normalisation, le formulaire complété DEVRAIT être fourni à l’IESG avec la demande d’action de normalisation. Après l’approbation par Standards Action, l’IESG DOIT transmettre la demande (éventuellement révisée) à l’IANA. L’IESG DOIT être considéré comme le propriétaire des enregistrements de toutes les valeurs qui demandent une action de normalisation.
Si la politique est la révision par les experts, le demandeur DOIT adresse le formulaire complété à la liste de diffusion <directory@apps.ietf.org> pour une révision publique. La période de révision est de deux (2) semaines. Si un formulaire révisé est soumis ultérieurement, la période de révision redémarre. Tout un chacun peut s’abonner à cette liste en envoyant une demande à <directory-request@apps.ietf.org>. Durant la révision, des objections peuvent être soulevées par tout un chacun (y compris l’expert) qui figure sur la liste. Après l’achèvement de la révision, l’expert, sur la base des commentaires publics, DOIT soit approuver la demande et la transmettre à l’IANA, soit refuser la demande. Dans les deux cas, l’expert DOIT le notifier rapidement au demandeur de l’action. Les actions de l’expert peuvent faire l’objet d’un appel [RFC2026]. L’expert est appointé par les directeurs de domaine d’applications. Le demandeur est considéré comme le propriétaire de l’enregistrement des valeurs enregistrées sous révision d’experts.
Si la politique est le premier arrivé est le premier servi, le demandeur DOIT soumettre directement le formulaire complété à l’IANA : <iana@iana.org>. Le demandeur est considéré comme le propriétaire de l’enregistrement des valeurs enregistrées sous premier arrivé, premier servi.
Ni l’expert ni l’IANA ne prendront position sur les problèmes de revendications de droits de propriété intellectuelle ou commerciale concernant les formulaires complétés.
Avant la soumission du projet Internet (I-D) à l’éditeur de RFC, mais après la révision de l’IESG et la tentative d’approbation, l’éditeur du document DEVRAIT réviser le projet pour utiliser les valeurs enregistrées.
La présente section discute de la maintenance des enregistrements.
L’IANA fait des listes des valeurs enregistrées qui sont disponibles pour la communauté de l’Internet sur son site : <http://www.iana.org/>.
Le propriétaire de l’enregistrement PEUT mettre à jour l’enregistrement avec les mêmes contraintes et révisions que pour les nouveaux enregistrements. Dans les cas où le propriétaire de l’enregistrement n’est pas à même ou non désireux de faire les mises à jour nécessaires, l’IESG PEUT assumer la propriété de l’enregistrement afin de mettre à jour l’enregistrement.
Pour les cas où des tiers (toute personne autre que le propriétaire de l’enregistrement) ont des objections significatives à un enregistrement et où le propriétaire de l’enregistrement n’est pas d’accord pour changer l’enregistrement, des commentaires PEUVENT être joints à un enregistrement sous révision d’experts. Pour les enregistrements possédés par l’IESG, les objections DEVRAIENT être formulées en initiant une demande de révision d’experts.
La forme de ces demandes est ad hoc, mais DOIT inclure les objections spécifiques à revoir et DEVRAIENT contenir (directement ou par référence) des arguments pour soutenir les objections.
Les considérations sur la sécurité détaillées dans le BCP 26 [RFC2434] sont applicables de façon générale au présent document. Des considérations supplémentaires sur la sécurité spécifiques de chaque espace de nom sont exposées à la Section 3, lorsque approprié.
Les considérations sur la sécurité pour LDAP sont discutées dans les documents qui constituent la spécification technique LDAP [RFC4510].
Le présent document a été produit par le groupe de travail Révision LDAP de l’IETF (LDAPBIS). Le présent document est une révision de la RFC 3383, produite elle aussi par le groupe de travail LDAPBIS.
Le présent document inclut des textes empruntés aux "Lignes directrices pour la rédaction d’une section Considérations relatives à l’IANA dans les RFC" [RFC2434] par Thomas Narten et Harald Alvestrand.
[RFC2026] Bradner, S., "Le processus d’élaboration des normes de l’Internet -- Révision 3", BCP 9, RFC 2026, octobre 1996.
[RFC2119] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigence", BCP 14, RFC 2119, mars 1997.
[RFC2434] Narten, T. et H. Alvestrand, "Lignes directrices pour la rédaction d’une section Considérations relatives à l’IANA dans les RFC", BCP 26, RFC 2434, octobre 1998.
[RFC2578] McCloghrie, K., Perkins, D., et J. Schoenwaelder,"Structure des informations de gestion, Version 2 (SMIv2)", STD 58, RFC 2578, avril 1999.
[RFC3629] Yergeau, F., "UTF-8, un format de transformation de ISO 10646", STD 63, RFC 3629, novembre 2003.
[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): Feuille de route de la spécification technique", 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èles d’informations de répertoire", 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.
[RFC4516] Smith, M., Ed. et T. Howes, "Protocole léger d’accès à un répertoire (LDAP) : Localisateurs de ressources uniformes", RFC 4516, juin 2006.
[RFC4517] Legg, S., Ed., "Protocole léger d’accès à un répertoire (LDAP) : Syntaxes et règles de correspondance", RFC 4517, juin 2006.
[Unicode] The Unicode Consortium, "la norme Unicode, Version 3.2.0" est défini par "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), amendé par le "Unicode Standard Annexe n° 27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) et par le "Unicode Standard Annexe n° 28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[X.680] Union Internationale des Télécommunications – Secteur de la normalisation des Télécommunications, "Notation de syntaxe abstraite n° I (ASN.1) - Spécification de la notation de base", X.680(2002) (aussi ISO/CEI 8824-1:2002).
[RFC1779] Kille, S., "Représentation de chaîne des noms distinctifs", RFC 1779, mars 1995.
[RFC3494] Zeilenga, K.," Protocole léger d’accès à un répertoire version 2 (LDAPv2) vers un statut historique", RFC 3494, mars 2003.
[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.
[RFC4422] Melnikov, A., Ed. et K. Zeilenga, Ed., "Authentification simple et couche de sécurité (SASL)", RFC 4422, juin 2006.
[IANADSN] IANA, "Noms des systèmes de répertoires", http://www.iana.org/assignments/directory-system-names.
Le présent appendice fournit des modèles d’enregistrement pour enregistrer de nouvelles valeurs LDAP. Noter que plus d’une valeur peuvent être demandées en étendant le modèle par une liste de plusieurs valeurs, ou par l’utilisation de tableaux.
Sujet : Demande d’enregistrement d’OID pour LDAP
Adresse postale et électronique de la personne à contacter pour des précisions :
Spécification : (I-D)
Auteur/Contrôleur des modifications :
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Sujet : Demande d’enregistrement de mécanisme de protocole pour LDAP
Identifiant d’objet :
Description :
Adresse postale et électronique de la personne à contacter pour des précisions :
Usage : (Contrôle ou extension ou caractéristique ou autre)
Spécification : (RFC, I-D, URI)
Auteur/Contrôleur des modifications :
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Sujet : Demande d’enregistrement de syntaxe pour LDAP
Identifiant d’objet :
Description :
Adresse postale et électronique de la personne à contacter pour des précisions :
Spécification : (RFC, I-D, URI)
Auteur/Contrôleur des modifications :
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Sujet : Demande d’enregistrement de descripteur pour LDAP
Descripteur (nom abrégé) :
Identifiant d’objet :
Adresse postale et électronique de la personne à contacter pour des précisions :
Usage : (Un parmi rôle administratif, type d’attribut, règle de correspondance, forme de nom, classe d’objet, extension d’URL, ou autre)
Spécification : (RFC, I-D, URI)
Auteur/Contrôleur des modifications :
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Sujet : Demande de nom d’option d’enregistrement d’option de description d’attribut pour LDAP :
Famille d’options : (OUI ou NON)
Adresse postale et électronique de la personne à contacter pour des précisions :
Spécification : (RFC, I-D, URI)
Auteur/Contrôleur des modifications :
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Sujet : Demande d’enregistrement de type de message pour LDAP
Nom du message LDAP :
Adresse postale et électronique de la personne à contacter pour des précisions :
Spécification: (I-D approuvé)
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Sujet : Demande d’enregistrement de méthode d’authentification pour LDAP
Nom de méthode d’authentification :
Adresse postale et électronique de la personne à contacter pour des précisions :
Spécification : (RFC, I-D, URI)
Usage prévu : (Un parmi COMMUN, UTILISATION LIMITÉE, OBSOLÈTE)
Auteur/Contrôleur des modifications :
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Sujet : Demande d’enregistrement de code de résultat pour LDAP
Nom du code de résultat :
Adresse postale et électronique de la personne à contacter pour des précisions :
Spécification : (RFC, I-D, URI)
Auteur/Contrôleur des modifications :
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Sujet : Demande d’enregistrement de domaine de recherche pour LDAP
Nome de domaine de recherche :
Chaîne de domaine de filtre :
Adresse postale et électronique de la personne à contacter pour des précisions :
Spécification : (RFC, I-D, URI)
Auteur/Contrôleur des modifications :
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Sujet : Demande d’enregistrement de choixde filtre pour LDAP
Nom du choix de filtre :
Adresse postale et électronique de la personne à contacter pour des précisions :
Spécification : (RFC, I-D, URI)
Auteur/Contrôleur des modifications :
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Sujet : Demande d’enregistrement d’opération ModifyRequest pour LDAP
Nom de l’opération ModifyRequest :
Adresse postale et électronique de la personne à contacter pour des précisions :
Spécification : (RFC, I-D, URI)
Auteur/Contrôleur des modifications :
Commentaires : (Tout commentaire que le demandeur juge pertinent pour la demande.)
Cet appendice informatif donne le résumé des changements survenus depuis la RFC 3383.
- Les pratiques en matière d’identifiant d’objet ont été mises à jour pour exiger l’enregistrement de tous les descripteurs définis dans les RFC et recommander que tous les autres descripteurs (exceptés ceux de l’espace de nom d’utilisation privée) soient enregistrés. De plus, toutes les demandes d’enregistrement multiple du même descripteur sont maintenant soumises à révision d’expert.
- Les pratiques de mécanisme de protocole ont été mises à jour pour y inclure les valeurs du type d’attribut 'supportedFeatures'.
- Les registres des préfixes LDAP Syntax, Search Scope, Filter Choice, ModifyRequest operation, et authzId ont été ajoutés.
- Les références aux RFC qui composent les spécifications techniques de LDAP ont été mises à jour avec les dernières révisions.
- Les références à ISO 10646 ont été remplacées par [Unicode].
- L’appendice "Valeurs allouées" qui donnait les valeurs initiales des registres a été supprimé.
- De nombreux changements rédactionnels ont été faits.
Adresse de l’auteur
Kurt D. Zeilenga
OpenLDAP Foundation
mél : Kurt@OpenLDAP.org
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 ; 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 fourni par la Administrative Support Activity (IASA) de l'IETF.