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
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ù :
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ù :
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
Le présent document affine la description de schéma de X.501 en
exigeant que le champ SYNTAX d'une
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ù :
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ù :
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ù :
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ù :
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ù :
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ù :
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é.