Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
RFC 2252
| Document | Type |
RFC - Proposed Standard
(December 1997; Errata)
Updated by RFC 3377
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized with errata bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2252 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group M. Wahl
Request for Comments: 2252 Critical Angle Inc.
Category: Standards Track A. Coulbeck
Isode Inc.
T. Howes
Netscape Communications Corp.
S. Kille
Isode Limited
December 1997
Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions
1. Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1997). All Rights Reserved.
IESG Note
This document describes a directory access protocol that provides
both read and update access. Update access requires secure
authentication, but this document does not mandate implementation of
any satisfactory authentication mechanisms.
In accordance with RFC 2026, section 4.4.1, this specification is
being approved by IESG as a Proposed Standard despite this
limitation, for the following reasons:
a. to encourage implementation and interoperability testing of
these protocols (with or without update access) before they
are deployed, and
b. to encourage deployment and use of these protocols in read-only
applications. (e.g. applications where LDAPv3 is used as
a query language for directories which are updated by some
secure mechanism other than LDAP), and
Wahl, et. al. Standards Track [Page 1]
RFC 2252 LADPv3 Attributes December 1997
c. to avoid delaying the advancement and deployment of other Internet
standards-track protocols which require the ability to query, but
not update, LDAPv3 directory servers.
Readers are hereby warned that until mandatory authentication
mechanisms are standardized, clients and servers written according to
this specification which make use of update functionality are
UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
Implementors are hereby discouraged from deploying LDAPv3 clients or
servers which implement the update functionality, until a Proposed
Standard for mandatory authentication in LDAPv3 has been approved and
published as an RFC.
2. Abstract
The Lightweight Directory Access Protocol (LDAP) [1] requires that
the contents of AttributeValue fields in protocol elements be octet
strings. This document defines a set of syntaxes for LDAPv3, and the
rules by which attribute values of these syntaxes are represented as
octet strings for transmission in the LDAP protocol. The syntaxes
defined in this document are referenced by this and other documents
that define attribute types. This document also defines the set of
attribute types which LDAP servers should support.
3. Overview
This document defines the framework for developing schemas for
directories accessible via the Lightweight Directory Access Protocol.
Schema is the collection of attribute type definitions, object class
definitions and other information which a server uses to determine
how to match a filter or attribute value assertion (in a compare
operation) against the attributes of an entry, and whether to permit
add and modify operations.
Section 4 states the general requirements and notations for attribute
types, object classes, syntax and matching rule definitions.
Section 5 lists attributes, section 6 syntaxes and section 7 object
classes.
Additional documents define schemas for representing real-world
objects as directory entries.
Wahl, et. al. Standards Track [Page 2]
RFC 2252 LADPv3 Attributes December 1997
4. General Issues
This document describes encodings used in an Internet protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
Attribute Type and Object Class definitions are written in a string
representation of the AttributeTypeDescription and
ObjectClassDescription data types defined in X.501(93) [3].
Implementors are strongly advised to first read the description of
Show full document text