Zum Hauptinhalt springen

1. Einleitung

Dieses Dokument behandelt die X.500-Verzeichnisinformationsmodelle [X.501], wie sie vom Lightweight Directory Access Protocol (LDAP) [RFC4510] verwendet werden.

Das Verzeichnis ist „eine Sammlung offener Systeme, die bei der Bereitstellung von Verzeichnisdiensten zusammenarbeiten“ [X.500]. Die im Verzeichnis enthaltenen Informationen werden zusammenfassend als Verzeichnisinformationsbasis (Directory Information Base, DIB) bezeichnet. Ein Verzeichnisbenutzer, bei dem es sich um einen Menschen oder eine andere Entität handeln kann, greift über einen Client (oder Verzeichnisbenutzeragenten (Directory User Agent, DUA)) auf das Verzeichnis zu. Der Client interagiert im Namen des Verzeichnisbenutzers mit einem oder mehreren Servern (oder Verzeichnissystemagenten (Directory System Agents, DSA)). Ein Server hält ein Fragment der DIB vor.

Die DIB enthält zwei Klassen von Informationen:

  1) Benutzerinformationen (z. B. Informationen, die von Benutzern
bereitgestellt und verwaltet werden). Abschnitt 2 beschreibt
das Modell der Benutzerinformationen.

2) administrative und betriebliche Informationen (z. B.
Informationen, die zur Verwaltung und/oder zum Betrieb des
Verzeichnisses verwendet werden). Abschnitt 3 beschreibt das
Modell der administrativen und betrieblichen
Verzeichnisinformationen.

Diese beiden Modelle, die als allgemeine Verzeichnisinformationsmodelle bezeichnet werden, beschreiben, wie Informationen im Verzeichnis dargestellt werden. Sie bilden einen Rahmen für weitere Informationsmodelle. Abschnitt 4 behandelt das Unterschema-Informationsmodell und die Unterschema-Ermittlung. Abschnitt 5 behandelt das DSA-(Server-)Informationsmodell.

Andere X.500-Informationsmodelle (beispielsweise Informationsmodelle für Zugriffssteuerung, Verteilungswissen und Replikationswissen) können für die Verwendung in LDAP angepasst werden. Die Spezifikation, wie diese Modelle auf LDAP anzuwenden sind, bleibt zukünftigen Dokumenten vorbehalten.

1.1. Beziehung zu anderen LDAP-Spezifikationen​

Dieses Dokument ist ein integraler Bestandteil der technischen LDAP-Spezifikation [RFC4510], welche die zuvor in RFC 3377 definierte technische LDAP-Spezifikation vollständig obsoletiert.

Dieses Dokument obsoletiert die Abschnitte 3.2 und 3.4 von RFC 2251 sowie Teile der Abschnitte 4 und 6. Anhang A.1 fasst die Änderungen an diesen Abschnitten zusammen. Der verbleibende Teil von RFC 2251 wird durch die Dokumente [RFC4511], [RFC4513] und [RFC4510] obsoletiert.

Dieses Dokument obsoletiert die Abschnitte 4, 5 und 7 von RFC 2252. Anhang A.2 fasst die Änderungen an diesen Abschnitten zusammen. Der verbleibende Teil von RFC 2252 wird durch [RFC4517] obsoletiert.

Dieses Dokument obsoletiert die Abschnitte 5.1, 5.2, 7.1 und 7.2 von RFC 2256. Anhang A.3 fasst die Änderungen an diesen Abschnitten zusammen. Der verbleibende Teil von RFC 2256 wird durch [RFC4519] und [RFC4517] obsoletiert.

Dieses Dokument obsoletiert RFC 3674 vollständig. Anhang A.4 fasst die Änderungen seit RFC 3674 zusammen.

1.2. Beziehung zu X.501​

Dieses Dokument übernimmt Material aus [X.501] mit und ohne Anpassung, soweit dies zur Beschreibung dieses Protokolls erforderlich ist. Diese Anpassungen (und alle weiteren hier enthaltenen Unterschiede) gelten für dieses Protokoll und nur für dieses Protokoll.

1.3. Konventionen​

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind entsprechend der Beschreibung in BCP 14 [RFC2119] auszulegen.

Schemadefinitionen werden in LDAP-Beschreibungsformaten (wie in Abschnitt 4.1 definiert) angegeben. Die hier angegebenen Definitionen sind zur besseren Lesbarkeit formatiert (mit Zeilenumbrüchen versehen). Die in diesen Definitionen referenzierten Übereinstimmungsregeln und LDAP-Syntaxen sind in [RFC4517] spezifiziert.

1.4. Gemeinsame ABNF-Produktionen​

Mehrere Syntaxen in diesem Dokument werden mithilfe der erweiterten Backus-Naur-Form (Augmented Backus-Naur Form, ABNF) [RFC4234] beschrieben. Diese Syntaxen (sowie eine Reihe von in anderen Dokumenten definierten Syntaxen) beruhen auf den folgenden gemeinsamen Produktionen:

  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)

Objektbezeichner (OIDs) [X.680] werden in LDAP in einem Punkt-Dezimalformat dargestellt, das der folgenden ABNF entspricht:

  numericoid = number 1*( DOT number )

Kurznamen, auch als Deskriptoren bezeichnet, werden als besser lesbare Aliase für Objektbezeichner verwendet. Bei Kurznamen wird die Groß- und Kleinschreibung nicht berücksichtigt; sie entsprechen der folgenden ABNF:

  descr = keystring

Wenn entweder ein Objektbezeichner oder ein Kurzname angegeben werden kann, wird die folgende Produktion verwendet:

  oid = descr / numericoid

Während die Form im Allgemeinen vorzuziehen ist, wenn die Verwendung auf Kurznamen beschränkt ist, die sich auf Objektbezeichner beziehen, welche gleichartige Objekte identifizieren (z. B. Attributtypbeschreibungen, Beschreibungen von Übereinstimmungsregeln oder Objektklassenbeschreibungen), sollte die Form verwendet werden, wenn die Objektbezeichner mehrere Arten von Objekten identifizieren können oder kein eindeutiger Kurzname (Deskriptor) verfügbar ist.

Implementierungen SHOULD mehrdeutig verwendete Kurznamen (Deskriptoren) (wie oben erörtert) als nicht erkannt behandeln.

Kurznamen (Deskriptoren) werden in Abschnitt 6.2 ausführlicher behandelt.