Aller au contenu principal

4. Schéma d'annuaire

Selon la définition donnée dans [X.501] :

  Le schéma d'annuaire est un ensemble de définitions et de
  contraintes portant sur la structure du DIT, les différentes
  manières dont les entrées peuvent être nommées, les informations
  qu'une entrée peut contenir, les attributs utilisés pour représenter
  ces informations et leur organisation en hiérarchies afin d'en
  faciliter la recherche et la récupération, ainsi que les manières
  dont les valeurs d'attribut peuvent être comparées dans les
  assertions de valeur d'attribut et de règle de correspondance.

  NOTE 1 - Le schéma permet, par exemple, au système d'annuaire :

  - d'empêcher la création d'entrées subordonnées appartenant à une
    classe d'objet incorrecte (par exemple, un pays subordonné à une
    personne) ;

  - d'empêcher l'ajout à une entrée de types d'attribut inadaptés à
    la classe d'objet (par exemple, un numéro de série dans l'entrée
    d'une personne) ;

  - d'empêcher l'ajout d'une valeur d'attribut dont la syntaxe ne
    correspond pas à celle définie pour le type d'attribut (par
    exemple, une chaîne imprimable dans une chaîne de bits).

  Formellement, le schéma d'annuaire comprend un ensemble de :

  a) définitions de forme de nom, qui définissent les relations de
     nommage primitives des classes d'objet structurelles ;

  b) définitions de règle de structure du DIT, qui définissent les
     noms que peuvent avoir les entrées et les manières dont celles-ci
     peuvent être liées entre elles dans le DIT ;

  c) définitions de règle de contenu du DIT, qui étendent la
     spécification des attributs autorisés pour les entrées au-delà de
     ceux indiqués par les classes d'objet structurelles des entrées ;

  d) définitions de classe d'objet, qui définissent l'ensemble de base
     des attributs obligatoires et facultatifs qui doivent et peuvent,
     respectivement, être présents dans une entrée d'une classe donnée,
     et qui indiquent le type de classe d'objet défini ;

  e) définitions de type d'attribut, qui identifient l'identifiant
     d'objet par lequel un attribut est connu, sa syntaxe, les règles
     de correspondance associées, s'il s'agit d'un attribut
     opérationnel et, le cas échéant, son type, s'il s'agit d'un
     attribut collectif, s'il est autorisé à avoir plusieurs valeurs
     et s'il est dérivé ou non d'un autre type d'attribut ;

  f) définitions de règle de correspondance, qui définissent les
     règles de correspondance.

  Et dans LDAP :

  g) définitions de syntaxe LDAP, qui définissent les codages utilisés
     dans LDAP.

4.1. Définitions de schéma​

Les définitions de schéma de la présente section sont décrites à l'aide de l'ABNF et reposent sur les productions communes spécifiées à la section 1.2 ainsi que sur les productions suivantes :

  noidlen = numericoid [ LCURLY len RCURLY ]
len = number

oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid )

extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )

qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE

qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string

QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"

; Any UTF-8 encoded Unicode character
; except %x27 ("\'") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB

; Any ASCII character except %x27 ("\'") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F

Les définitions de schéma de la présente section partagent également un certain nombre de termes communs.

Le champ NAME fournit un ensemble de noms courts (descripteurs) à utiliser comme alias de l'OID.

Le champ DESC permet facultativement à l'administrateur de l'annuaire et/ou à l'implémenteur de fournir une chaîne descriptive. Bien que les spécifications puissent suggérer une chaîne descriptive, rien n'impose d'utiliser la chaîne suggérée (ni aucune autre chaîne descriptive).

Le champ OBSOLETE, s'il est présent, indique que l'élément n'est pas actif.

Les implémenteurs doivent noter que de futures versions du présent document pourront étendre ces définitions afin d'y inclure des termes supplémentaires. Les termes dont l'identifiant commence par "X-" sont réservés aux expérimentations privées et sont suivis des jetons et .

4.1.1. Définitions de classe d'objet​

Les définitions de classe d'objet sont écrites conformément à l'ABNF suivant :

 ObjectClassDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oids ] ; superior object classes
[ SP kind ] ; kind of class
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN

kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"

où : est l'identifiant d'objet attribué à cette classe d'objet ; NAME désigne les noms courts (descripteurs) qui identifient cette classe d'objet ; DESC est une courte chaîne descriptive ; OBSOLETE indique que cette classe d'objet n'est pas active ; SUP spécifie les superclasses directes de cette classe d'objet ; le type de classe d'objet est indiqué par ABSTRACT, STRUCTURAL ou AUXILIARY (la valeur par défaut est STRUCTURAL) ; MUST et MAY spécifient respectivement les ensembles de types d'attribut obligatoires et autorisés ; et décrit les extensions.

4.1.2. Types d'attribut​

Les définitions de type d'attribut sont écrites conformément à l'ABNF suivant :

 AttributeTypeDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; supertype
[ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule
[ SP "SYNTAX" SP noidlen ] ; value syntax
[ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions

usage = "userApplications" / ; user
"directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational

où : est l'identifiant d'objet attribué à ce type d'attribut ; NAME désigne les noms courts (descripteurs) qui identifient ce type d'attribut ; DESC est une courte chaîne descriptive ; OBSOLETE indique que ce type d'attribut n'est pas actif ; SUP oid spécifie le supertype direct de ce type ; EQUALITY, ORDERING et SUBSTR fournissent respectivement l'oid des règles de correspondance d'égalité, d'ordre et de sous-chaînes ; SYNTAX identifie la syntaxe de valeur par un identifiant d'objet et peut suggérer une limite supérieure minimale ; SINGLE-VALUE indique que les attributs de ce type sont limités à une seule valeur ; COLLECTIVE indique que ce type d'attribut est collectif [X.501][RFC3671] ; NO-USER-MODIFICATION indique que ce type d'attribut n'est pas modifiable par l'utilisateur ; USAGE indique l'utilisation de ce type d'attribut ; et décrit les extensions.

Chaque description de type d'attribut doit contenir au moins l'un des champs SUP ou SYNTAX. Si aucun champ SYNTAX n'est fourni, la description de type d'attribut prend sa valeur dans le supertype.

Si le champ SUP est fourni, les champs EQUALITY, ORDERING et SUBSTRING, lorsqu'ils ne sont pas spécifiés, prennent leur valeur dans le supertype.

L'utilisation userApplications, qui est la valeur par défaut, indique que les attributs de ce type représentent des informations utilisateur. Ce sont donc des attributs utilisateur.

Une utilisation directoryOperation, distributedOperation ou dSAOperation indique que les attributs de ce type représentent des informations opérationnelles et/ou administratives. Ce sont donc des attributs opérationnels.

L'utilisation directoryOperation indique que l'attribut de ce type est un attribut opérationnel de l'annuaire. L'utilisation distributedOperation indique que l'attribut de ce type est un attribut opérationnel d'utilisation partagé par les DSA. L'utilisation dSAOperation indique que l'attribut de ce type est un attribut opérationnel propre au DSA.

COLLECTIVE exige l'utilisation userApplications. L'utilisation de types d'attribut collectif dans LDAP est examinée dans [RFC3671].

NO-USER-MODIFICATION exige une utilisation opérationnelle.

Il convient de noter que n'énumère pas les règles de correspondance qui peuvent être utilisées avec ce type d'attribut dans un filtre de recherche extensibleMatch [RFC4511]. Cette énumération est effectuée au moyen de l'attribut 'matchingRuleUse' décrit à la section 4.1.4.

Le présent document affine la description de schéma de X.501 en exigeant que le champ SYNTAX d'une soit la représentation sous forme de chaîne d'un identifiant d'objet pour la définition de syntaxe de chaîne LDAP, avec une indication facultative de la limite supérieure minimale suggérée pour une valeur de cet attribut.

Il est possible d'indiquer une limite supérieure minimale suggérée du nombre de caractères d'une valeur dont la syntaxe est fondée sur une chaîne, ou du nombre d'octets d'une valeur pour toutes les autres syntaxes, en ajoutant cette limite entre accolades après l'OBJECT IDENTIFIER de la syntaxe dans une description de type d'attribut. Cette limite ne fait pas partie du nom de la syntaxe elle-même. Par exemple, "1.3.6.4.1.1466.0{64}" suggère que les implémentations de serveur devraient accepter une chaîne de 64 caractères, bien qu'elles puissent accepter des chaînes plus longues. Il convient de noter qu'un seul caractère de la syntaxe Directory String peut être codé sur plusieurs octets, car UTF-8 [RFC3629] est un codage de longueur variable.

4.1.3. Règles de correspondance​

Les règles de correspondance servent à exécuter des assertions de valeur d'attribut, par exemple lors d'une opération Compare. Elles sont également utilisées pour évaluer les filtres de recherche, déterminer les valeurs individuelles à ajouter ou à supprimer lors d'une opération Modify, et comparer les noms distinctifs.

Chaque règle de correspondance est identifiée par un identifiant d'objet (OID) et, facultativement, par un ou plusieurs noms courts (descripteurs).

Les définitions de règle de correspondance sont écrites conformément à l'ABNF suivant :

 MatchingRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "SYNTAX" SP numericoid ; assertion syntax
extensions WSP RPAREN ; extensions

où : est l'identifiant d'objet attribué à cette règle de correspondance ; NAME désigne les noms courts (descripteurs) qui identifient cette règle de correspondance ; DESC est une courte chaîne descriptive ; OBSOLETE indique que cette règle de correspondance n'est pas active ; SYNTAX identifie la syntaxe d'assertion (la syntaxe de la valeur d'assertion) par un identifiant d'objet ; et décrit les extensions.

4.1.4. Utilisations des règles de correspondance​

Une utilisation de règle de correspondance énumère les types d'attribut qui conviennent à un filtre de recherche extensibleMatch.

Les descriptions d'utilisation de règle de correspondance sont rédigées selon l'ABNF suivante :

 MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "APPLIES" SP oids ; attribute types
extensions WSP RPAREN ; extensions

où : est l'identifiant d'objet de la règle de correspondance associée à cette description d'utilisation de règle de correspondance ; NAME représente les noms courts (descripteurs) qui identifient cette utilisation de règle de correspondance ; DESC est une courte chaîne descriptive ; OBSOLETE indique que cette utilisation de règle de correspondance n'est pas active ; APPLIES fournit la liste des types d'attribut auxquels s'applique la règle de correspondance ; et décrit les extensions.

4.1.5. Syntaxes LDAP​

Les syntaxes LDAP des valeurs (d'attribut et d'assertion) sont décrites en ASN.1 [X.680] et peuvent comporter un codage en chaîne d'octets appelé codage propre à LDAP. Généralement, ce codage est limité à une chaîne de caractères Unicode [Unicode] sous forme UTF-8 [RFC3629].

Chaque syntaxe LDAP est identifiée par un identifiant d'objet (OID).

Les définitions de syntaxe LDAP sont rédigées selon l'ABNF suivante :

 SyntaxDescription = LPAREN WSP
numericoid ; object identifier
[ SP "DESC" SP qdstring ] ; description
extensions WSP RPAREN ; extensions

où : est l'identifiant d'objet attribué à cette syntaxe LDAP ; DESC est une courte chaîne descriptive ; et décrit les extensions.

4.1.6. Règles de contenu DIT​

Une règle de contenu DIT est une « règle régissant le contenu des entrées d'une classe d'objet structurelle particulière » [X.501].

Pour les entrées DIT d'une classe d'objet structurelle donnée, une règle de contenu DIT spécifie les classes d'objet auxiliaires auxquelles elles sont autorisées à appartenir et les attributs supplémentaires (par type) dont la présence dans les entrées est exigée, autorisée ou interdite.

La liste des attributs interdits ne peut inclure aucun attribut déclaré obligatoire dans la règle, la classe d'objet structurelle ou l'une des classes d'objet auxiliaires autorisées.

Chaque règle de contenu est identifiée par l'identifiant d'objet, ainsi que par les éventuels noms courts (descripteurs), de la classe d'objet structurelle à laquelle elle s'applique.

Une entrée ne peut appartenir qu'aux classes d'objet auxiliaires énumérées dans la règle de contenu qui la régit.

Une entrée doit contenir tous les attributs exigés par les classes d'objet auxquelles elle appartient, ainsi que tous les attributs exigés par la règle de contenu qui la régit.

Une entrée peut contenir tout attribut non interdit autorisé par les classes d'objet auxquelles elle appartient, ainsi que tous les attributs autorisés par la règle de contenu qui la régit.

Une entrée ne peut inclure aucun attribut interdit par la règle de contenu qui la régit.

Une entrée est régie, si elle est présente et active dans le sous-schéma, par la règle de contenu DIT qui s'applique à sa classe d'objet structurelle (voir la Section 2.4.2). Si aucune règle active n'est présente pour la classe d'objet structurelle de l'entrée, son contenu est régi par cette classe d'objet structurelle (et éventuellement par d'autres aspects des schémas utilisateur et système). Les règles de contenu DIT visant les superclasses de la classe d'objet structurelle d'une entrée ne s'appliquent pas à cette entrée.

Les descriptions de règle de contenu DIT sont rédigées selon l'ABNF suivante :

 DITContentRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "AUX" SP oids ] ; auxiliary object classes
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
[ SP "NOT" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions

où : est l'identifiant d'objet de la classe d'objet structurelle associée à cette règle de contenu DIT ; NAME représente les noms courts (descripteurs) qui identifient cette règle de contenu DIT ; DESC est une courte chaîne descriptive ; OBSOLETE indique que cette utilisation de règle de contenu DIT n'est pas active ; AUX spécifie la liste des classes d'objet auxiliaires auxquelles peuvent appartenir les entrées soumises à cette règle de contenu DIT ;

 MUST, MAY et NOT spécifient respectivement les listes des types
d'attribut dont la présence est exigée, autorisée ou interdite dans
les entrées soumises à cette règle de contenu DIT ; et
<extensions> décrit les extensions.

4.1.7. Règles de structure DIT et formes de nom​

Il est parfois souhaitable de réglementer l'emplacement des entrées d'objet et d'alias dans la DIT et la manière dont elles peuvent être nommées en fonction de leur classe d'objet structurelle.

4.1.7.1. Règles de structure DIT​

Une règle de structure DIT est une « règle régissant la structure de la DIT en spécifiant une relation autorisée entre une entrée supérieure et une entrée subordonnée. Une règle de structure relie une forme de nom, et donc une classe d'objet structurelle, à des règles de structure supérieures. Cela permet aux entrées de la classe d'objet structurelle identifiée par la forme de nom d'exister dans la DIT comme subordonnées d'entrées régies par les règles de structure supérieures indiquées » [X.501].

Les descriptions de règle de structure DIT sont rédigées selon l'ABNF suivante :

 DITStructureRuleDescription = LPAREN WSP
ruleid ; rule identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "FORM" SP oid ; NameForm
[ SP "SUP" ruleids ] ; superior rules
extensions WSP RPAREN ; extensions

ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number

où : est l'identifiant de cette règle de structure DIT ; NAME représente les noms courts (descripteurs) qui identifient cette règle de structure DIT ; DESC est une courte chaîne descriptive ; OBSOLETE indique que cette utilisation de règle de structure DIT n'est pas active ; FORM spécifie la forme de nom associée à cette règle de structure DIT ; SUP identifie les règles supérieures (par leur identifiant) ; et décrit les extensions.

Si aucune règle supérieure n'est identifiée, la règle de structure DIT s'applique à un point administratif autonome (par exemple, le sommet racine du sous-arbre contrôlé par le sous-schéma) [X.501].

4.1.7.2. Formes de nom​

Une forme de nom « spécifie un RDN autorisé pour les entrées d'une classe d'objet structurelle particulière. Une forme de nom identifie une classe d'objet nommée et un ou plusieurs types d'attribut à utiliser pour le nommage (c'est-à-dire pour le RDN). Les formes de nom sont des éléments de spécification primitifs employés dans la définition des règles de structure DIT » [X.501].

Chaque forme de nom indique la classe d'objet structurelle à nommer, un ensemble de types d'attribut exigés et un ensemble de types d'attribut autorisés. Un type d'attribut donné ne peut pas appartenir aux deux ensembles.

Les entrées régies par la forme doivent être nommées à l'aide d'une valeur de chaque type d'attribut exigé et de zéro ou plusieurs valeurs des types d'attribut autorisés.

Chaque forme de nom est identifiée par un identifiant d'objet (OID) et, éventuellement, par un ou plusieurs noms courts (descripteurs).

Les descriptions de forme de nom sont rédigées selon l'ABNF suivante :

 NameFormDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "OC" SP oid ; structural object class
SP "MUST" SP oids ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions

où : est l'identifiant d'objet qui identifie cette forme de nom ; NAME représente les noms courts (descripteurs) qui identifient cette forme de nom ; DESC est une courte chaîne descriptive ; OBSOLETE indique que cette forme de nom n'est pas active ; OC identifie la classe d'objet structurelle à laquelle cette règle s'applique ; MUST et MAY spécifient respectivement les ensembles d'attributs de nommage exigés et autorisés pour cette forme de nom ; et décrit les extensions.

Tous les types d'attribut des listes exigée ("MUST") et autorisée ("MAY") doivent être différents.

4.2. Sous-entrées de sous-schéma​

Les (sous-)entrées de sous-schéma servent à administrer les informations relatives au schéma de l'annuaire. Une même (sous-)entrée de sous-schéma contient toutes les définitions de schéma (voir la Section 4.1) utilisées par les entrées d'une partie donnée de l'arbre de l'annuaire.

Les serveurs qui suivent les modèles X.500(93) devraient (SHOULD) mettre en œuvre le sous-schéma au moyen des mécanismes de sous-schéma X.500 (détaillés à la Section 12 de [X.501]) ; ces entrées ne sont donc pas des entrées d'objet ordinaires, mais des sous-entrées (voir la Section 3.2). Les clients LDAP ne devraient pas (SHOULD NOT) supposer que les serveurs mettent en œuvre les autres aspects du sous-schéma X.500.

Les serveurs peuvent (MAY) autoriser la modification du sous-schéma. Les procédures de modification du sous-schéma sont décrites à la Section 14.5 de [X.501].

Un serveur qui détient les entrées maîtresses et permet aux clients de les modifier doit (SHALL) mettre en œuvre ces (sous-)entrées de sous-schéma et en donner l'accès, notamment en fournissant un attribut 'subschemaSubentry' dans chaque entrée modifiable. Les clients peuvent ainsi découvrir les attributs et les classes d'objet dont la présence est autorisée. Il est fortement recommandé (RECOMMENDED) que tous les autres serveurs mettent également cette fonction en œuvre.

La valeur de l'attribut 'subschemaSubentry' est le nom de la (sous-)entrée de sous-schéma qui contient le sous-schéma régissant l'entrée.

  ( 2.5.18.10 NAME 'subschemaSubentry'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )

La règle de correspondance 'distinguishedNameMatch' et la syntaxe DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) sont définies dans [RFC4517].

Le sous-schéma est conservé dans des (sous-)entrées appartenant à la classe d'objet auxiliaire subschema.

  ( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )

L'attribut opérationnel 'ldapSyntaxes' peut également être présent dans les entrées de sous-schéma.

Les serveurs peuvent (MAY) fournir des attributs supplémentaires (décrits dans d'autres documents) dans les (sous-)entrées de sous-schéma.

Les serveurs devraient (SHOULD) fournir les attributs 'createTimestamp' et 'modifyTimestamp' dans les (sous-)entrées de sous-schéma afin de permettre aux clients de tenir à jour leurs caches d'informations de schéma.

Les sous-sections suivantes donnent les définitions de type d'attribut de chacun des types d'attribut de définition de schéma.

4.2.1. 'objectClasses'​

Cet attribut contient les définitions des classes d’objet.

  ( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation )

La règle 'objectIdentifierFirstComponentMatch' et la syntaxe ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) sont définies dans [RFC4517].

4.2.2. 'attributeTypes'​

Cet attribut contient les définitions des types d’attribut.

  ( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation )

La règle 'objectIdentifierFirstComponentMatch' et la syntaxe AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) sont définies dans [RFC4517].

4.2.3. 'matchingRules'​

Cet attribut contient les définitions des règles de correspondance.

  ( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
USAGE directoryOperation )

La règle 'objectIdentifierFirstComponentMatch' et la syntaxe MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) sont définies dans [RFC4517].

4.2.4 'matchingRuleUse'

Cet attribut contient les définitions des utilisations de règles de correspondance.

  ( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )

La règle 'objectIdentifierFirstComponentMatch' et la syntaxe MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) sont définies dans [RFC4517].

4.2.5. 'ldapSyntaxes'​

Cet attribut contient les définitions des syntaxes LDAP.

  ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
USAGE directoryOperation )

La règle 'objectIdentifierFirstComponentMatch' et la syntaxe SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) sont définies dans [RFC4517].

4.2.6. 'dITContentRules'​

Cet attribut énumère les règles de contenu du DIT présentes dans le sous-schéma.

  ( 2.5.21.2 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation )

La règle 'objectIdentifierFirstComponentMatch' et la syntaxe DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) sont définies dans [RFC4517].

4.2.7. 'dITStructureRules'​

Cet attribut énumère les règles de structure du DIT présentes dans le sous-schéma.

  ( 2.5.21.1 NAME 'dITStructureRules'
EQUALITY integerFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
USAGE directoryOperation )

La règle 'integerFirstComponentMatch' et la syntaxe DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) sont définies dans [RFC4517].

4.2.8 'nameForms'

Cet attribut énumère les formes de nom en vigueur.

  ( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation )

La règle 'objectIdentifierFirstComponentMatch' et la syntaxe NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) sont définies dans [RFC4517].

4.3. Classe d’objet 'extensibleObject'​

La classe d’objet auxiliaire 'extensibleObject' autorise les entrées qui lui appartiennent à contenir n’importe quel attribut utilisateur. Son ensemble de types d’attribut autorisés est implicitement celui de tous les types d’attribut d’usage userApplications.

  ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )

Les attributs obligatoires des autres classes d’objet de l’entrée restent requis et tous les attributs interdits restent proscrits.

4.4. Découverte du sous-schéma​

Pour découvrir le DN de la (sous-)entrée de sous-schéma qui contient le sous-schéma régissant une entrée, un client lit l’attribut opérationnel 'subschemaSubentry' de celle-ci. Pour lire les attributs de schéma, les clients DOIVENT (MUST) émettre une opération Search [RFC4511] où baseObject est le DN de la (sous-)entrée, scope vaut baseObject, filter vaut "(objectClass=subschema)" [RFC4515] et attributes énumère les noms demandés. Remarque : le filtre "(objectClass=subschema)" permet aux serveurs LDAP servant de passerelle vers X.500 de détecter une demande d’informations de sous-entrée.

Les clients NE DEVRAIENT PAS (SHOULD NOT) supposer qu’un sous-schéma publié est complet, que le serveur prend en charge tous les éléments publiés ou qu’il ne prend pas en charge un élément non publié.