Anhang A. Änderungen

Dieser Anhang ist nicht normativ.

Dieses Dokument schreibt Teile von RFC 2251, RFC 2252 und RFC 2256 nahezu vollständig neu, um die technische Spezifikation insgesamt klarer zu gestalten. Der Anhang fasst die wesentlichen Änderungen der hier übernommenen Teile zusammen. Für die übrigen Teile siehe [RFC4510], [RFC4511], [RFC4517] und [RFC4519].

A.1. Änderungen gegenüber RFC 2251

Übernommen wurden die Abschnitte 3.2 und 3.4 sowie Teile der Abschnitte 4 und 6.

A.1.1. Abschnitt 3.2 von RFC 2251

Abschnitt 3.2 führte kurz in das von LDAP verwendete X.500-Datenmodell ein. Die frühere Spezifikation stützte sich auf [X.501], erklärte aber die Anpassung der X.500-Modelle an LDAP nicht klar. Dieses Dokument beschreibt sie ausführlicher, insbesondere wo Anpassungen nötig sind.

Abschnitt 3.2.1 beschrieb ein Attribut als „einen Typ mit einem oder mehreren zugeordneten Werten“. Für LDAP ist die Beschreibung als Attributbeschreibung — ein Typ mit null oder mehr Optionen — und einem oder mehreren zugeordneten Werten genauer.

Abschnitt 3.2.2 schrieb objectClasses und attributeTypes in Unterschema-Untereinträgen vor, obwohl X.500(93) sie als optional behandelt. Implementierungen der X.500(93)-Mechanismen stellen gewöhnlich beide bereit, doch die Interoperabilität verlangt dies nicht zwingend von jedem Server. Die Vorgabe wurde zur Übereinstimmung mit X.500(93) entfernt. Außerdem wurde klargestellt, dass das für einen Eintrag maßgebliche Unterschema durch Lesen des von dessen 'subschemaSubentry' referenzierten (Unter-)Eintrags ermittelt wird.

A.1.2. Abschnitt 3.4 von RFC 2251

Abschnitt 3.4 enthielt „serverspezifische Datenanforderungen“. Das Material wurde geändert in Abschnitt 5.1 übernommen.

Änderungen:

• Klarstellung, dass Wurzel-DSE-Attribute neben Zugriffskontrollen „weiteren Einschränkungen“ unterliegen;
• nur erkannte erweiterte Anforderungen müssen in 'supportedExtension' aufgeführt werden;
• nur erkannte Anforderungs-Steuerelemente müssen in 'supportedControl' aufgeführt werden;
• Wurzel-DSE-Attribute sind Betriebsattribute und werden nur auf namentliche Anforderung zurückgegeben;
• nicht alle Wurzel-DSE-Attribute sind benutzeränderbar;
• widersprüchlicher Text zu 'subschemaSubentry' im Wurzel-DSE wurde entfernt. Die frühere Spezifikation sagte, es verweise auf „diesem Server bekannte Unterschemaeinträge (oder Untereinträge)“. Dies widerspricht der beabsichtigten Verwendung und der formalen Definition als einwertiges Attribut [X.501]. Eine einfache, möglicherweise unvollständige Liste ist zudem wenig nützlich. Abschnitt 5.1 legt fest, dass es auf das für den Wurzel-DSE maßgebliche Unterschema verweist. Das allgemeine Ermittlungsverfahren bleibt verfügbar (siehe Abschnitt 4.4).

A.1.3. Abschnitt 4 von RFC 2251

Folgende Teile zum LDAP-Informationsmodell wurden übernommen:

• Beschränkung von Distinguished Values auf Attribute, deren Beschreibungen keine Optionen besitzen (Abschnitt 4.1.3);
• Datenmodellaspekte von Attributtypen (4.1.4), Attributbeschreibungen (4.1.5), Attributen (4.1.8) und Übereinstimmungsregel-Bezeichnern (4.1.9);
• Anforderungen an Benutzerschemata (4.1.6, 4.5.1 und 4.7).

Klarstellungen umfassen:

• Untertypbildung und AttributeDescriptions mit Optionen.

A.1.4. Abschnitt 6 von RFC 2251

Abschnitt 6.1 und der zweite Absatz von Abschnitt 6.2 wurden übernommen.

A.2. Änderungen gegenüber RFC 2252

Dieses Dokument übernimmt die Abschnitte 4, 5 und 7 von RFC 2252.

A.2.1. Abschnitt 4 von RFC 2252

Die Spezifikation wurde auf Augmented BNF [RFC4234] aktualisiert. Die Zeichenkettendarstellung eines OBJECT IDENTIFIER wurde verschärft, um wie in RFC 2252 beschrieben führende Nullen auszuschließen.

Die Syntax wurde geändert, um Semikolons (U+003B) auszuschließen und damit ihrer Beschreibung zu entsprechen: „descr ist die syntaktische Darstellung eines Objekt-Deskriptors, der aus Buchstaben und Ziffern besteht und mit einem Buchstaben beginnt“. Zugleich wurde die Aussage „eine AttributeDescription kann als Wert in einem NAME-Teil einer AttributeTypeDescription verwendet werden“ gelöscht. RFC 2252 definierte keine Semantik für Attributoptionen in NAME-Feldern.

RFC 2252 sagte, die -Form von SOLLTE (SHOULD) der -Form vorgezogen werden; kann jedoch mehrdeutig sein. Daher wurde dies in Abschnitt 1.4 durch die Aussage ersetzt, dass allgemein bevorzugt wird, aber verwendet werden sollte, wenn kein eindeutiges verfügbar ist. Abschnitt 6.2 („Kurznamen“) erörtert Deskriptorfragen ausführlicher.

Die ABNF für eine Zeichenkette in Anführungszeichen (qdstring) wurde aktualisiert, um den Escape-Mechanismus aus Abschnitt 4.3 von RFC 2252 abzubilden.

A.2.2. Abschnitt 5 von RFC 2252

Die dortigen Definitionen von Betriebsattributen wurden übernommen.

'namingContexts' wurde klargestellt: Ein DSA erster Ebene sollte zusätzlich zu anderen Werten "" für die DIT-Wurzel veröffentlichen.

'altServer' kann eine beliebige URI enthalten.

Bei 'supportedExtension' muss ein Server nur die OBJECT IDENTIFIER der erweiterten Anforderungen erkannter erweiterter Operationen auflisten.

Bei 'supportedControl' muss er nur die OBJECT IDENTIFIER erkannter Anforderungs-Steuerelemente auflisten.

Beschreibungen für 'structuralObjectClass' und 'governingStructureRule' wurden hinzugefügt.

Die Definition von 'subschemaSubentry' wurde korrigiert, damit SINGLE-VALUE und NO-USER-MODIFICATION in der richtigen Reihenfolge stehen.

A.2.3. Abschnitt 7 von RFC 2252

Dieser Abschnitt definierte 'subschema' und 'extensibleObject'; die Definitionen wurden in die Abschnitte 4.2 beziehungsweise 4.3 integriert. Seine Implementierungsanforderung an Objektklassen wurde in Abschnitt 7 übernommen.

Das Zusammenwirken von 'extensibleObject' mit ausgeschlossenen Attributen wurde klargestellt.

A.3. Änderungen gegenüber RFC 2256

Dieses Dokument übernimmt die Abschnitte 5.1, 5.2, 7.1 und 7.2 von RFC 2256.

Die Definition von 'objectClass' aus Abschnitt 5.1 wurde in Abschnitt 2.4.1 integriert. „Einer der Werte ist entweder 'top' oder 'alias'“ wurde durch die Aussage ersetzt, dass einer der Werte 'top' ist, da 'alias'-Einträge ebenfalls 'top' angehören.

Die Definition von 'aliasedObjectName' aus Abschnitt 5.2 wurde in Abschnitt 2.6.2 integriert.

Die Definition der Objektklasse 'top' aus Abschnitt 7.1 wurde in Abschnitt 2.4.1 integriert.

Die Definition der Objektklasse 'alias' aus Abschnitt 7.2 wurde in Abschnitt 2.6.1 integriert.

A.4. Änderungen gegenüber RFC 3674

Dieses Dokument nimmt keine wesentliche Änderung an der technischen Spezifikation von 'supportedFeatures' aus RFC 3674 vor.