Zum Hauptinhalt springen

4. Verzeichnisschema

Wie in [X.501] definiert:

  Das Verzeichnisschema ist eine Menge von Definitionen und
  Beschränkungen hinsichtlich der Struktur des DIT, der möglichen
  Arten der Benennung von Einträgen, der Informationen, die in einem
  Eintrag enthalten sein können, der zur Darstellung dieser
  Informationen verwendeten Attribute und ihrer Anordnung in
  Hierarchien zur Vereinfachung der Suche und des Abrufs der
  Informationen sowie der Arten, wie Attributwerte in
  Attributwertbehauptungen und Behauptungen von Übereinstimmungsregeln
  abgeglichen werden können.

  HINWEIS 1 - Das Schema ermöglicht dem Verzeichnissystem zum Beispiel:

  - die Erstellung untergeordneter Einträge mit der falschen
    Objektklasse zu verhindern (z. B. ein Land als untergeordneter
    Eintrag einer Person);

  - das Hinzufügen von Attributtypen zu einem Eintrag zu verhindern,
    die für die Objektklasse ungeeignet sind (z. B. eine Seriennummer
    zum Eintrag einer Person);

  - das Hinzufügen eines Attributwerts mit einer Syntax zu verhindern,
    die nicht der für den Attributtyp definierten Syntax entspricht
    (z. B. eine druckbare Zeichenfolge zu einer Bitfolge).

  Formal umfasst das Verzeichnisschema eine Menge von:

  a) Namensformdefinitionen, die elementare Benennungsbeziehungen für
     strukturelle Objektklassen definieren;

  b) DIT-Strukturregeldefinitionen, die festlegen, welche Namen
     Einträge haben dürfen und wie die Einträge im DIT miteinander in
     Beziehung stehen dürfen;

  c) DIT-Inhaltsregeldefinitionen, welche die Spezifikation der für
     Einträge zulässigen Attribute über die durch die strukturellen
     Objektklassen der Einträge angegebenen Attribute hinaus erweitern;

  d) Objektklassendefinitionen, welche die grundlegende Menge der
     obligatorischen und optionalen Attribute definieren, die in einem
     Eintrag einer bestimmten Klasse vorhanden sein müssen bzw.
     vorhanden sein dürfen, und die angeben, welche Art von
     Objektklasse definiert wird;

  e) Attributtypdefinitionen, welche den Objektbezeichner, unter dem
     ein Attribut bekannt ist, seine Syntax, die zugehörigen
     Übereinstimmungsregeln, die Eigenschaft als Betriebsattribut und
     gegebenenfalls dessen Typ, die Eigenschaft als kollektives
     Attribut, die Zulässigkeit mehrerer Werte und die etwaige
     Ableitung von einem anderen Attributtyp bestimmen;

  f) Definitionen von Übereinstimmungsregeln, welche
     Übereinstimmungsregeln definieren.

  Und in LDAP:

  g) LDAP-Syntaxdefinitionen, welche die in LDAP verwendeten
     Codierungen definieren.

4.1. Schemadefinitionen​

Die Schemadefinitionen in diesem Abschnitt werden mithilfe von ABNF beschrieben und beruhen auf den in Abschnitt 1.2 angegebenen gemeinsamen Produktionen sowie auf den folgenden Produktionen:

  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

Die Schemadefinitionen in diesem Abschnitt verwenden außerdem eine Reihe gemeinsamer Begriffe.

Das Feld NAME stellt eine Menge von Kurznamen (Deskriptoren) bereit, die als Aliase für den OID verwendet werden sollen.

Das Feld DESC ermöglicht dem Verzeichnisadministrator und/oder Implementierer optional die Angabe einer beschreibenden Zeichenfolge. Spezifikationen können zwar eine beschreibende Zeichenfolge vorschlagen, es besteht jedoch keine Anforderung, die vorgeschlagene (oder irgendeine) beschreibende Zeichenfolge zu verwenden.

Das Feld OBSOLETE zeigt, sofern vorhanden, an, dass das Element nicht aktiv ist.

Implementierer sollten beachten, dass zukünftige Versionen dieses Dokuments diese Definitionen um zusätzliche Begriffe erweitern können. Begriffe, deren Bezeichner mit "X-" beginnt, sind für private Experimente reserviert; ihnen folgen die Token und .

4.1.1. Objektklassendefinitionen​

Objektklassendefinitionen werden gemäß der folgenden ABNF geschrieben:

 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"

Dabei gilt: ist der dieser Objektklasse zugewiesene Objektbezeichner; NAME sind Kurznamen (Deskriptoren), die diese Objektklasse identifizieren; DESC ist eine kurze beschreibende Zeichenfolge; OBSOLETE zeigt an, dass diese Objektklasse nicht aktiv ist; SUP gibt die direkten Oberklassen dieser Objektklasse an; die Art der Objektklasse wird durch ABSTRACT, STRUCTURAL oder AUXILIARY angegeben (Standardwert ist STRUCTURAL); MUST und MAY geben die Mengen der erforderlichen bzw. zulässigen Attributtypen an; und beschreibt Erweiterungen.

4.1.2. Attributtypen​

Attributtypdefinitionen werden gemäß der folgenden ABNF geschrieben:

 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

Dabei gilt: ist der diesem Attributtyp zugewiesene Objektbezeichner; NAME sind Kurznamen (Deskriptoren), die diesen Attributtyp identifizieren; DESC ist eine kurze beschreibende Zeichenfolge; OBSOLETE zeigt an, dass dieser Attributtyp nicht aktiv ist; SUP oid gibt den direkten Obertyp dieses Typs an; EQUALITY, ORDERING und SUBSTR geben jeweils den oid der Übereinstimmungsregeln für Gleichheit, Reihenfolge und Teilzeichenfolgen an; SYNTAX identifiziert die Wertsyntax durch einen Objektbezeichner und kann eine minimale Obergrenze vorschlagen; SINGLE-VALUE zeigt an, dass Attribute dieses Typs auf einen einzelnen Wert beschränkt sind; COLLECTIVE zeigt an, dass dieser Attributtyp kollektiv ist [X.501][RFC3671]; NO-USER-MODIFICATION zeigt an, dass dieser Attributtyp nicht vom Benutzer geändert werden kann; USAGE gibt die Verwendung dieses Attributtyps an; und beschreibt Erweiterungen.

Jede Attributtypbeschreibung muss mindestens eines der Felder SUP oder SYNTAX enthalten. Wenn kein Feld SYNTAX angegeben ist, übernimmt die Attributtypbeschreibung ihren Wert vom Obertyp.

Wenn das Feld SUP angegeben ist, übernehmen die Felder EQUALITY, ORDERING und SUBSTRING, sofern nicht angegeben, ihren Wert vom Obertyp.

Die standardmäßige Verwendung userApplications zeigt an, dass Attribute dieses Typs Benutzerinformationen darstellen. Das heißt, es handelt sich um Benutzerattribute.

Eine Verwendung von directoryOperation, distributedOperation oder dSAOperation zeigt an, dass Attribute dieses Typs betriebliche und/oder administrative Informationen darstellen. Das heißt, es handelt sich um Betriebsattribute.

Die Verwendung directoryOperation zeigt an, dass das Attribut dieses Typs ein Verzeichnisbetriebsattribut ist. Die Verwendung distributedOperation zeigt an, dass das Attribut dieses Typs ein von DSAs gemeinsam genutztes Betriebsattribut ist. Die Verwendung dSAOperation zeigt an, dass das Attribut dieses Typs ein DSA-spezifisches Betriebsattribut ist.

COLLECTIVE erfordert die Verwendung userApplications. Die Verwendung kollektiver Attributtypen in LDAP wird in [RFC3671] behandelt.

NO-USER-MODIFICATION erfordert eine betriebliche Verwendung.

Zu beachten ist, dass die Übereinstimmungsregeln, die mit diesem Attributtyp in einem extensibleMatch-Suchfilter [RFC4511] verwendet werden können, nicht aufführt. Dies erfolgt über das in Abschnitt 4.1.4 beschriebene Attribut 'matchingRuleUse'.

Dieses Dokument präzisiert die Schemabeschreibung von X.501, indem es verlangt, dass das Feld SYNTAX in einer eine Zeichenfolgendarstellung eines Objektbezeichners für die Definition der LDAP-Zeichenfolgensyntax ist, mit einer optionalen Angabe der vorgeschlagenen minimalen Obergrenze eines Werts dieses Attributs.

Eine vorgeschlagene minimale Obergrenze für die Anzahl der Zeichen in einem Wert mit zeichenfolgenbasierter Syntax bzw. die Anzahl der Bytes in einem Wert für alle anderen Syntaxen kann angegeben werden, indem diese Grenze in einer Attributtypbeschreibung in geschweiften Klammern an den OBJECT IDENTIFIER der Syntax angehängt wird. Diese Grenze ist nicht Bestandteil des Syntaxnamens selbst. Beispielsweise empfiehlt "1.3.6.4.1.1466.0{64}", dass Serverimplementierungen eine Zeichenfolge mit einer Länge von 64 Zeichen zulassen sollten, wenngleich sie längere Zeichenfolgen zulassen können. Zu beachten ist, dass ein einzelnes Zeichen der Directory String-Syntax in mehr als einem Oktett codiert sein kann, da UTF-8 [RFC3629] eine Codierung variabler Länge ist.

4.1.3. Übereinstimmungsregeln​

Übereinstimmungsregeln werden bei der Ausführung von Attributwertbehauptungen verwendet, beispielsweise bei der Ausführung einer Compare-Operation. Sie werden außerdem bei der Auswertung von Suchfiltern, bei der Bestimmung der einzelnen Werte, die während einer Modify-Operation hinzugefügt oder gelöscht werden sollen, sowie beim Vergleich von Distinguished Names verwendet.

Jede Übereinstimmungsregel wird durch einen Objektbezeichner (OID) und optional durch einen oder mehrere Kurznamen (Deskriptoren) identifiziert.

Definitionen von Übereinstimmungsregeln werden gemäß der folgenden ABNF geschrieben:

 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

Dabei gilt: ist der dieser Übereinstimmungsregel zugewiesene Objektbezeichner; NAME sind Kurznamen (Deskriptoren), die diese Übereinstimmungsregel identifizieren; DESC ist eine kurze beschreibende Zeichenfolge; OBSOLETE zeigt an, dass diese Übereinstimmungsregel nicht aktiv ist; SYNTAX identifiziert die Behauptungssyntax (die Syntax des Behauptungswerts) durch einen Objektbezeichner; und beschreibt Erweiterungen.

4.1.4. Verwendungen von Übereinstimmungsregeln​

Eine Verwendung einer Übereinstimmungsregel führt die Attributtypen auf, die für die Verwendung mit einem extensibleMatch-Suchfilter geeignet sind.

Beschreibungen der Verwendung von Übereinstimmungsregeln werden gemäß der folgenden ABNF geschrieben:

 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

Dabei gilt: ist der Objektbezeichner der Übereinstimmungsregel, die dieser Beschreibung der Regelverwendung zugeordnet ist. NAME sind Kurznamen (Deskriptoren), die diese Verwendung der Übereinstimmungsregel bezeichnen. DESC ist eine kurze beschreibende Zeichenfolge. OBSOLETE gibt an, dass diese Verwendung der Übereinstimmungsregel nicht aktiv ist. APPLIES stellt eine Liste der Attributtypen bereit, auf welche die Übereinstimmungsregel anzuwenden ist. beschreibt Erweiterungen.

4.1.5. LDAP-Syntaxen​

LDAP-Syntaxen von Werten (Attribut- und Behauptungswerten) werden mittels ASN.1 [X.680] beschrieben und haben optional eine Oktettzeichenketten- Kodierung, die als LDAP-spezifische Kodierung bezeichnet wird. Üblicherweise ist die LDAP-spezifische Kodierung auf eine Zeichenfolge aus Unicode- Zeichen [Unicode] in UTF-8-Form [RFC3629] beschränkt.

Jede LDAP-Syntax wird durch einen Objektbezeichner (OID) bezeichnet.

LDAP-Syntaxdefinitionen werden gemäß der folgenden ABNF geschrieben:

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

Dabei gilt: ist der dieser LDAP-Syntax zugewiesene Objektbezeichner. DESC ist eine kurze beschreibende Zeichenfolge. beschreibt Erweiterungen.

4.1.6. DIT-Inhaltsregeln​

Eine DIT-Inhaltsregel ist eine „Regel, die den Inhalt von Einträgen einer bestimmten strukturellen Objektklasse bestimmt“ [X.501].

Für DIT-Einträge einer bestimmten strukturellen Objektklasse legt eine DIT-Inhaltsregel fest, welchen Hilfsobjektklassen die Einträge angehören dürfen und welche zusätzlichen Attribute (nach Typ) in den Einträgen erforderlich, zulässig oder unzulässig sind.

Die Liste ausgeschlossener Attribute darf kein Attribut enthalten, das in der Regel, der strukturellen Objektklasse oder einer der zulässigen Hilfsobjektklassen als obligatorisch aufgeführt ist.

Jede Inhaltsregel wird durch den Objektbezeichner sowie etwaige Kurznamen (Deskriptoren) der strukturellen Objektklasse bezeichnet, auf die sie anzuwenden ist.

Ein Eintrag darf nur Hilfsobjektklassen angehören, die in der für ihn geltenden Inhaltsregel aufgeführt sind.

Ein Eintrag muss alle Attribute enthalten, die von den Objektklassen, denen er angehört, sowie von der für ihn geltenden Inhaltsregel verlangt werden.

Ein Eintrag darf alle nicht ausgeschlossenen Attribute enthalten, die von den Objektklassen, denen er angehört, zugelassen werden, sowie alle von der für ihn geltenden Inhaltsregel zugelassenen Attribute.

Ein Eintrag darf kein Attribut enthalten, das durch die für ihn geltende Inhaltsregel ausgeschlossen ist.

Für einen Eintrag gilt die DIT-Inhaltsregel, die auf die strukturelle Objektklasse des Eintrags anzuwenden ist, sofern diese Regel im Unterschema vorhanden und aktiv ist (siehe Abschnitt 2.4.2). Ist für die strukturelle Objektklasse des Eintrags keine aktive Regel vorhanden, wird der Inhalt des Eintrags durch die strukturelle Objektklasse (und möglicherweise durch andere Aspekte des Benutzer- und Systemschemas) bestimmt. DIT-Inhaltsregeln für Oberklassen der strukturellen Objektklasse eines Eintrags sind auf diesen Eintrag nicht anwendbar.

Beschreibungen von DIT-Inhaltsregeln werden gemäß der folgenden ABNF geschrieben:

 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

Dabei gilt: ist der Objektbezeichner der strukturellen Objektklasse, die dieser DIT-Inhaltsregel zugeordnet ist. NAME sind Kurznamen (Deskriptoren), die diese DIT-Inhaltsregel bezeichnen. DESC ist eine kurze beschreibende Zeichenfolge. OBSOLETE gibt an, dass diese Verwendung der DIT-Inhaltsregel nicht aktiv ist. AUX gibt eine Liste von Hilfsobjektklassen an, denen Einträge angehören dürfen, die dieser DIT-Inhaltsregel unterliegen.

 MUST, MAY und NOT geben jeweils Listen von Attributtypen an, deren
Vorhandensein in Einträgen, die dieser DIT-Inhaltsregel unterliegen,
erforderlich, zulässig beziehungsweise ausgeschlossen ist.
<extensions> beschreibt Erweiterungen.

4.1.7. DIT-Strukturregeln und Namensformen​

Mitunter ist es wünschenswert, anhand ihrer strukturellen Objektklasse zu regeln, an welcher Stelle Objekt- und Alias-Einträge in der DIT platziert und wie sie benannt werden dürfen.

4.1.7.1. DIT-Strukturregeln​

Eine DIT-Strukturregel ist eine „Regel, die die Struktur der DIT bestimmt, indem sie eine zulässige Beziehung zwischen übergeordneten und untergeordneten Einträgen festlegt. Eine Strukturregel setzt eine Namensform und damit eine strukturelle Objektklasse zu übergeordneten Strukturregeln in Beziehung. Dadurch können Einträge der durch die Namensform bezeichneten strukturellen Objektklasse in der DIT als untergeordnete Einträge von Einträgen existieren, die den angegebenen übergeordneten Strukturregeln unterliegen“ [X.501].

Beschreibungen von DIT-Strukturregeln werden gemäß der folgenden ABNF geschrieben:

 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

Dabei gilt: ist der Regelbezeichner dieser DIT-Strukturregel. NAME sind Kurznamen (Deskriptoren), die diese DIT-Strukturregel bezeichnen. DESC ist eine kurze beschreibende Zeichenfolge. OBSOLETE gibt an, dass diese Verwendung der DIT-Strukturregel nicht aktiv ist. FORM gibt die mit dieser DIT-Strukturregel verknüpfte Namensform an. SUP bezeichnet übergeordnete Regeln (anhand der Regel-ID). beschreibt Erweiterungen.

Sind keine übergeordneten Regeln bezeichnet, ist die DIT-Strukturregel auf einen autonomen Verwaltungspunkt anzuwenden (z. B. den Wurzelknoten des vom Unterschema gesteuerten Teilbaums) [X.501].

4.1.7.2. Namensformen​

Eine Namensform „legt einen zulässigen RDN für Einträge einer bestimmten strukturellen Objektklasse fest. Eine Namensform bezeichnet eine benannte Objektklasse und einen oder mehrere Attributtypen, die zur Namensgebung (d. h. für den RDN) verwendet werden. Namensformen sind grundlegende Spezifikationselemente, die bei der Definition von DIT-Strukturregeln verwendet werden“ [X.501].

Jede Namensform gibt die zu benennende strukturelle Objektklasse, eine Menge erforderlicher Attributtypen und eine Menge zulässiger Attributtypen an. Ein bestimmter Attributtyp darf nicht in beiden Mengen enthalten sein.

Einträge, die der Form unterliegen, müssen unter Verwendung jeweils eines Werts aus jedem erforderlichen Attributtyp und null oder mehr Werten aus den zulässigen Attributtypen benannt werden.

Jede Namensform wird durch einen Objektbezeichner (OID) und optional einen oder mehrere Kurznamen (Deskriptoren) bezeichnet.

Beschreibungen von Namensformen werden gemäß der folgenden ABNF geschrieben:

 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

Dabei gilt: ist der Objektbezeichner, der diese Namensform bezeichnet. NAME sind Kurznamen (Deskriptoren), die diese Namensform bezeichnen. DESC ist eine kurze beschreibende Zeichenfolge. OBSOLETE gibt an, dass diese Namensform nicht aktiv ist. OC bezeichnet die strukturelle Objektklasse, auf die diese Regel anzuwenden ist. MUST und MAY geben die Mengen der für diese Namensform erforderlichen beziehungsweise zulässigen Namensattribute an. beschreibt Erweiterungen.

Alle Attributtypen in den Listen der erforderlichen ("MUST") und zulässigen ("MAY") Attribute müssen voneinander verschieden sein.

4.2. Unterschema-Untereinträge​

Unterschema-(Unter-)Einträge werden zur Verwaltung von Informationen über das Verzeichnisschema verwendet. Ein einzelner Unterschema-(Unter-)Eintrag enthält alle Schemadefinitionen (siehe Abschnitt 4.1), die von Einträgen in einem bestimmten Teil des Verzeichnisbaums verwendet werden.

Server, die X.500(93)-Modellen folgen, sollten (SHOULD) das Unterschema mittels der X.500-Unterschemamechanismen implementieren (wie in Abschnitt 12 von [X.501] ausführlich beschrieben), sodass es sich nicht um gewöhnliche Objekteinträge, sondern um Untereinträge handelt (siehe Abschnitt 3.2). LDAP-Clients sollten nicht (SHOULD NOT) davon ausgehen, dass Server andere Aspekte des X.500-Unterschemas implementieren.

Server dürfen (MAY) Änderungen am Unterschema zulassen. Verfahren zur Änderung des Unterschemas werden in Abschnitt 14.5 von [X.501] behandelt.

Ein Server, der Einträge als Master verwaltet und Clients die Änderung dieser Einträge gestattet, muss (SHALL) diese Unterschema-(Unter-)Einträge implementieren und den Zugriff darauf ermöglichen; dazu gehört die Bereitstellung eines Attributs 'subschemaSubentry' in jedem änderbaren Eintrag. Dadurch können Clients ermitteln, welche Attribute und Objektklassen vorhanden sein dürfen. Es wird dringend empfohlen (RECOMMENDED), dass auch alle anderen Server dies implementieren.

Der Wert des Attributs 'subschemaSubentry' ist der Name des Unterschema-(Unter-)Eintrags, der das für den Eintrag maßgebliche Unterschema enthält.

  ( 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 )

Die Übereinstimmungsregel 'distinguishedNameMatch' und die Syntax DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) sind in [RFC4517] definiert.

Das Unterschema wird in (Unter-)Einträgen gespeichert, die der Hilfsobjektklasse subschema angehören.

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

Das Betriebsattribut 'ldapSyntaxes' darf ebenfalls in Unterschemaeinträgen vorhanden sein.

Server dürfen (MAY) in Unterschema-(Unter-)Einträgen zusätzliche Attribute bereitstellen, die in anderen Dokumenten beschrieben sind.

Server sollten (SHOULD) die Attribute 'createTimestamp' und 'modifyTimestamp' in Unterschema-(Unter-)Einträgen bereitstellen, damit Clients ihre Zwischenspeicher mit Schemainformationen verwalten können.

Die folgenden Unterabschnitte enthalten Attributtypdefinitionen für jeden der Schemadefinitions-Attributtypen.

4.2.1. 'objectClasses'​

Dieses Attribut enthält Definitionen von Objektklassen.

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

'objectIdentifierFirstComponentMatch' und ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) sind in [RFC4517] definiert.

4.2.2. 'attributeTypes'​

Dieses Attribut enthält Definitionen von Attributtypen.

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

'objectIdentifierFirstComponentMatch' und AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) sind in [RFC4517] definiert.

4.2.3. 'matchingRules'​

Dieses Attribut enthält Definitionen von Übereinstimmungsregeln.

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

'objectIdentifierFirstComponentMatch' und MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) sind in [RFC4517] definiert.

4.2.4 'matchingRuleUse'

Dieses Attribut enthält Definitionen der Verwendung von Übereinstimmungsregeln.

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

'objectIdentifierFirstComponentMatch' und MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) sind in [RFC4517] definiert.

4.2.5. 'ldapSyntaxes'​

Dieses Attribut enthält Definitionen von LDAP-Syntaxen.

  ( 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 )

'objectIdentifierFirstComponentMatch' und SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) sind in [RFC4517] definiert.

4.2.6. 'dITContentRules'​

Dieses Attribut listet die im Unterschema vorhandenen DIT-Inhaltsregeln auf.

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

'objectIdentifierFirstComponentMatch' und DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) sind in [RFC4517] definiert.

4.2.7. 'dITStructureRules'​

Dieses Attribut listet die im Unterschema vorhandenen DIT-Strukturregeln auf.

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

'integerFirstComponentMatch' und DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) sind in [RFC4517] definiert.

4.2.8 'nameForms'

Dieses Attribut listet die geltenden Namensformen auf.

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

'objectIdentifierFirstComponentMatch' und NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) sind in [RFC4517] definiert.

4.3. Objektklasse 'extensibleObject'​

Die Hilfsobjektklasse 'extensibleObject' erlaubt ihren Einträgen, beliebige Benutzerattribute zu enthalten. Ihre zulässigen Attributtypen sind implizit alle Attributtypen mit der Verwendung userApplications.

  ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )

Die erforderlichen Attribute der anderen Objektklassen des Eintrags bleiben erforderlich; ausgeschlossene Attribute bleiben unzulässig.

4.4. Ermittlung des Unterschemas​

Zum Ermitteln des DN des Unterschema-(Unter-)Eintrags, der das für einen bestimmten Eintrag maßgebliche Unterschema enthält, liest ein Client dessen Betriebsattribut 'subschemaSubentry'. Zum Lesen von Schemaattributen MÜSSEN (MUST) Clients eine Search-Operation [RFC4511] ausführen: baseObject ist der DN des Unterschema-(Unter-)Eintrags, scope ist baseObject, filter ist "(objectClass=subschema)" [RFC4515] und attributes listet die gewünschten Schemaattribute auf. Hinweis: Der Filter "(objectClass=subschema)" ermöglicht LDAP-Servern mit X.500-Gateway, eine Anforderung von Untereintragsinformationen zu erkennen.

Clients SOLLTEN NICHT (SHOULD NOT) annehmen, dass ein veröffentlichtes Unterschema vollständig ist, der Server alle veröffentlichten Schemaelemente unterstützt oder kein unveröffentlichtes Element unterstützt.