rfc4521.txt

samba最新软件

Network Working Group                                        K. Zeilenga
Request for Comments: 4521                           OpenLDAP Foundation
BCP: 118                                                       June 2006
Category: Best Current Practice


                          Considerations for
        Lightweight Directory Access Protocol (LDAP) Extensions

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Lightweight Directory Access Protocol (LDAP) is extensible.  It
   provides mechanisms for adding new operations, extending existing
   operations, and expanding user and system schemas.  This document
   discusses considerations for designers of LDAP extensions.


























Zeilenga                 Best Current Practice                  [Page 1]

RFC 4521                    LDAP Extensions                    June 2006


Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................3
   2. General Considerations ..........................................4
      2.1. Scope of Extension .........................................4
      2.2. Interaction between extensions .............................4
      2.3. Discovery Mechanism ........................................4
      2.4. Internationalization Considerations ........................5
      2.5. Use of the Basic Encoding Rules ............................5
      2.6. Use of Formal Languages ....................................5
      2.7. Examples ...................................................5
      2.8. Registration of Protocol Values ............................5
   3. LDAP Operation Extensions .......................................6
      3.1. Controls ...................................................6
           3.1.1. Extending Bind Operation with Controls ..............6
           3.1.2. Extending the Start TLS Operation with Controls .....7
           3.1.3. Extending the Search Operation with Controls ........7
           3.1.4. Extending the Update Operations with Controls .......8
           3.1.5. Extending the Responseless Operations with Controls..8
      3.2. Extended Operations ........................................8
      3.3. Intermediate Responses .....................................8
      3.4. Unsolicited Notifications ..................................9
   4. Extending the LDAP ASN.1 Definition .............................9
      4.1. Result Codes ...............................................9
      4.2. LDAP Message Types .........................................9
      4.3. Authentication Methods ....................................10
      4.4. General ASN.1 Extensibility ...............................10
   5. Schema Extensions ..............................................10
      5.1. LDAP Syntaxes .............................................11
      5.2. Matching Rules ............................................11
      5.3. Attribute Types ...........................................12
      5.4. Object Classes ............................................12
   6. Other Extension Mechanisms .....................................12
      6.1. Attribute Description Options .............................12
      6.2. Authorization Identities ..................................12
      6.3. LDAP URL Extensions .......................................12
   7. Security Considerations ........................................12
   8. Acknowledgements ...............................................13
   9. References .....................................................13
      9.1. Normative References ......................................13
      9.2. Informative References ....................................15









Zeilenga                 Best Current Practice                  [Page 2]

RFC 4521                    LDAP Extensions                    June 2006


1.  Introduction

   The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an
   extensible protocol.

   LDAP allows for new operations to be added and for existing
   operations to be enhanced [RFC4511].

   LDAP allows additional schema to be defined [RFC4512][RFC4517].  This
   can include additional object classes, attribute types, matching
   rules, additional syntaxes, and other elements of schema.  LDAP
   provides an ability to extend attribute types with options [RFC4512].

   LDAP supports a Simple Authentication and Security Layer (SASL)
   authentication method [RFC4511][RFC4513].  SASL [RFC4422] is
   extensible.  LDAP may be extended to support additional
   authentication methods [RFC4511].

   LDAP supports establishment of Transport Layer Security (TLS)
   [RFC4511][RFC4513].  TLS [RFC4346] is extensible.

   LDAP has an extensible Uniform Resource Locator (URL) format
   [RFC4516].

   Lastly, LDAP allows for certain extensions to the protocol's Abstract
   Syntax Notation - One (ASN.1) [X.680] definition to be made.  This
   facilitates a wide range of protocol enhancements, for example, new
   result codes needed to support extensions to be added through
   extension of the protocol's ASN.1 definition.

   This document describes practices that engineers should consider when
   designing extensions to LDAP.

1.1.  Terminology

   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 BCP 14 [RFC2119].  In
   this document, "the specification", as used by BCP 14, RFC 2119,
   refers to the engineering of LDAP extensions.

   The term "Request Control" refers to a control attached to a client-
   generated message sent to a server.  The term "Response Control"
   refers to a control attached to a server-generated message sent to a
   client.






Zeilenga                 Best Current Practice                  [Page 3]

RFC 4521                    LDAP Extensions                    June 2006


   DIT stands for Directory Information Tree.
   DSA stands for Directory System Agent, a server.
   DSE stands for DSA-Specific Entry.
   DUA stands for Directory User Agent, a client.
   DN stands for Distinguished Name.

2.  General Considerations

2.1.  Scope of Extension

   Mutually agreeing peers may, within the confines of an extension,
   agree to significant changes in protocol semantics.  However,
   designers MUST consider the impact of an extension upon protocol
   peers that have not agreed to implement or otherwise recognize and
   support the extension.  Extensions MUST be "truly optional"
   [RFC2119].

2.2.  Interaction between extensions

   Designers SHOULD consider how extensions they engineer interact with
   other extensions.

   Designers SHOULD consider the extensibility of extensions they
   specify.  Extensions to LDAP SHOULD themselves be extensible.

   Except where it is stated otherwise, extensibility is implied.

2.3.  Discovery Mechanism

   Extensions SHOULD provide adequate discovery mechanisms.

   As LDAP design is based upon the client-request/server-response
   paradigm, the general discovery approach is for the client to
   discover the capabilities of the server before utilizing a particular
   extension.  Commonly, this discovery involves querying the root DSE
   and/or other DSEs for operational information associated with the
   extension.  LDAP provides no mechanism for a server to discover the
   capabilities of a client.

   The 'supportedControl' attribute [RFC4512] is used to advertise
   supported controls.  The 'supportedExtension' attribute [RFC4512] is
   used to advertise supported extended operations.  The
   'supportedFeatures' attribute [RFC4512] is used to advertise
   features.  Other root DSE attributes MAY be defined to advertise
   other capabilities.






Zeilenga                 Best Current Practice                  [Page 4]

RFC 4521                    LDAP Extensions                    June 2006


2.4.  Internationalization Considerations

   LDAP is designed to support the full Unicode [Unicode] repertory of
   characters.  Extensions SHOULD avoid unnecessarily restricting
   applications to subsets of Unicode (e.g., Basic Multilingual Plane,
   ISO 8859-1, ASCII, Printable String).

   LDAP Language Tag options [RFC3866] provide a mechanism for tagging
   text (and other) values with language information.  Extensions that
   define attribute types SHOULD allow use of language tags with these
   attributes.

2.5.  Use of the Basic Encoding Rules

   Numerous elements of LDAP are described using ASN.1 [X.680] and are
   encoded using a particular subset [Protocol, Section 5.2] of the
   Basic Encoding Rules (BER) [X.690].  To allow reuse of
   parsers/generators used in implementing the LDAP "core" technical
   specification [RFC4510], it is RECOMMENDED that extension elements
   (e.g., extension specific contents of controlValue, requestValue,
   responseValue fields) described by ASN.1 and encoded using BER be
   subjected to the restrictions of [Protocol, Section 5.2].

2.6.  Use of Formal Languages

   Formal languages SHOULD be used in specifications in accordance with
   IESG guidelines [FORMAL].

2.7.  Examples

   Example DN strings SHOULD conform to the syntax defined in [RFC4518].
   Example LDAP filter strings SHOULD conform to the syntax defined in
   [RFC4515].  Example LDAP URLs SHOULD conform to the syntax defined in
   [RFC4516].  Entries SHOULD be represented using LDIF [RFC2849].

2.8.  Registration of Protocol Values

   Designers SHALL register protocol values of their LDAP extensions in
   accordance with BCP 64, RFC 4520 [RFC4520].  Specifications that
   create new extensible protocol elements SHALL extend existing
   registries or establish new registries for values of these elements
   in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434
   [RFC2434].








Zeilenga                 Best Current Practice                  [Page 5]

RFC 4521                    LDAP Extensions                    June 2006


3.  LDAP Operation Extensions

   Extensions SHOULD use controls in defining extensions that complement
   existing operations.  Where the extension to be defined does not
   complement an existing operation, designers SHOULD consider defining
   an extended operation instead.

   For example, a subtree delete operation could be designed as either
   an extension of the delete operation or as a new operation.  As the
   feature complements the existing delete operation, use of the control
   mechanism to extend the delete operation is likely more appropriate.

   As a counter (and contrived) example, a locate services operation (an
   operation that would return for a DN a set of LDAP URLs to services