Aller au contenu principal

1. Introduction

Le présent document traite des modèles d'information d'annuaire X.500 [X.501] tels qu'ils sont utilisés par le protocole léger d'accès à un annuaire (LDAP) [RFC4510].

L'annuaire est « un ensemble de systèmes ouverts qui coopèrent afin de fournir des services d'annuaire » [X.500]. Les informations détenues dans l'annuaire sont collectivement appelées base d'informations d'annuaire (Directory Information Base, DIB). Un utilisateur de l'annuaire, qui peut être une personne ou une autre entité, accède à l'annuaire par l'intermédiaire d'un client (ou agent utilisateur d'annuaire (Directory User Agent, DUA)). Pour le compte de l'utilisateur de l'annuaire, le client interagit avec un ou plusieurs serveurs (ou agents système d'annuaire (Directory System Agents, DSA)). Un serveur détient un fragment de la DIB.

La DIB contient deux catégories d'informations :

  1) les informations utilisateur (par exemple, les informations
fournies et administrées par les utilisateurs). La section 2
décrit le modèle des informations utilisateur ;

2) les informations administratives et opérationnelles (par
exemple, les informations utilisées pour administrer et/ou
exploiter l'annuaire). La section 3 décrit le modèle des
informations administratives et opérationnelles de l'annuaire.

Ces deux modèles, appelés modèles génériques d'information d'annuaire, décrivent la manière dont les informations sont représentées dans l'annuaire. Ils fournissent un cadre à d'autres modèles d'information. La section 4 traite du modèle d'information de sous-schéma et de la découverte du sous-schéma. La section 5 traite du modèle informationnel de DSA (serveur).

D'autres modèles d'information X.500 (tels que les modèles d'information relatifs au contrôle d'accès, aux connaissances de distribution et aux connaissances de réplication) peuvent être adaptés pour être utilisés dans LDAP. La spécification de la manière dont ces modèles s'appliquent à LDAP est laissée à de futurs documents.

1.1. Relation avec les autres spécifications LDAP​

Le présent document fait partie intégrante de la spécification technique LDAP [RFC4510], qui rend entièrement obsolète la précédente spécification technique LDAP définie par la RFC 3377.

Le présent document rend obsolètes les sections 3.2 et 3.4 de la RFC 2251, ainsi que certaines parties des sections 4 et 6. L'annexe A.1 récapitule les modifications apportées à ces sections. Le reste de la RFC 2251 est rendu obsolète par les documents [RFC4511], [RFC4513] et [RFC4510].

Le présent document rend obsolètes les sections 4, 5 et 7 de la RFC 2252. L'annexe A.2 récapitule les modifications apportées à ces sections. Le reste de la RFC 2252 est rendu obsolète par [RFC4517].

Le présent document rend obsolètes les sections 5.1, 5.2, 7.1 et 7.2 de la RFC 2256. L'annexe A.3 récapitule les modifications apportées à ces sections. Le reste de la RFC 2256 est rendu obsolète par [RFC4519] et [RFC4517].

Le présent document rend entièrement obsolète la RFC 3674. L'annexe A.4 récapitule les modifications intervenues depuis la RFC 3674.

1.2. Relation avec X.501​

Le présent document reprend des éléments de [X.501], avec ou sans adaptation, dans la mesure nécessaire à la description de ce protocole. Ces adaptations (ainsi que toute autre différence présente dans ce document) s'appliquent à ce protocole, et uniquement à celui-ci.

1.3. Conventions​

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" employés dans le présent document doivent être interprétés comme indiqué dans le BCP 14 [RFC2119].

Les définitions de schéma sont fournies au moyen des formats de description LDAP (tels que définis à la section 4.1). Les définitions présentées ici sont mises en forme (avec retour à la ligne) pour en faciliter la lecture. Les règles de correspondance et les syntaxes LDAP référencées dans ces définitions sont spécifiées dans [RFC4517].

1.4. Productions ABNF communes​

Plusieurs syntaxes du présent document sont décrites à l'aide de la forme Backus-Naur augmentée (Augmented Backus-Naur Form, ABNF) [RFC4234]. Ces syntaxes (ainsi qu'un certain nombre de syntaxes définies dans d'autres documents) reposent sur les productions communes suivantes :

  keystring = leadkeychar *keychar
leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )

ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"

SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "

NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""")
SHARP = %x23 ; octothorpe (or sharp sign) ("#")
DOLLAR = %x24 ; dollar sign ("$")
SQUOTE = %x27 ; single quote ("'")
LPAREN = %x28 ; left paren ("(")
RPAREN = %x29 ; right paren (")")
PLUS = %x2B ; plus sign ("+")
COMMA = %x2C ; comma (",")
HYPHEN = %x2D ; hyphen ("-")
DOT = %x2E ; period (".")
SEMI = %x3B ; semicolon (";")
LANGLE = %x3C ; left angle bracket ("<")
EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket (">")
ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace "{"
RCURLY = %x7D ; right curly brace "}"

; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)

OCTET = %x00-FF ; Any octet (8-bit data unit)

Les identifiants d'objet (OID) [X.680] sont représentés dans LDAP au moyen d'un format décimal pointé conforme à l'ABNF suivant :

  numericoid = number 1*( DOT number )

Les noms courts, également appelés descripteurs, servent d'alias plus lisibles pour les identifiants d'objet. Ils sont insensibles à la casse et respectent l'ABNF suivant :

  descr = keystring

Lorsqu'il est possible de spécifier soit un identifiant d'objet, soit un nom court, la production suivante est utilisée :

  oid = descr / numericoid

Bien que la forme soit généralement préférable lorsque l'utilisation est limitée à des noms courts qui désignent des identifiants d'objet identifiant des objets de même nature (par exemple, des descriptions de type d'attribut, de règle de correspondance ou de classe d'objet), la forme devrait être utilisée lorsque les identifiants d'objet peuvent identifier plusieurs natures d'objets ou lorsqu'aucun nom court (descripteur) non ambigu n'est disponible.

Les implémentations SHOULD traiter comme non reconnus les noms courts (descripteurs) employés de manière ambiguë (comme indiqué ci-dessus).

Les noms courts (descripteurs) sont examinés plus en détail à la section 6.2.