Considerations for Lightweight Directory Access Protocol (LDAP) Extensions
draft-zeilenga-ldap-ext-10

INTERNET-DRAFT                                      Kurt D. Zeilenga
Intended Category: BCP                           OpenLDAP Foundation
Expires in six months                                2 February 2006

                    Considerations for LDAP Extensions
                     <draft-zeilenga-ldap-ext-10.txt>

Status of this Memo

  This document is intended to be, after appropriate review and
  revision, submitted to the RFC Editor for publication as a BCP.
  Distribution of this memo is unlimited.  Technical discussion of this
  document will take place on the IETF LDAP Extensions mailing list
  <ldapext@ietf.org>.  Please send editorial comments directly to the
  author <Kurt@OpenLDAP.org>.

  By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware have
  been or will be disclosed, and any of which he or she becomes aware
  will be disclosed, in accordance with Section 6 of BCP 79.

  Internet-Drafts are working documents of the Internet Engineering Task
  Force (IETF), its areas, and its working groups. Note that other
  groups may also distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet-Drafts as reference material
  or to cite them other than as "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/1id-abstracts.html

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html

  Copyright (C) The Internet Society (2006).  All Rights Reserved.

  Please see the Full Copyright section near the end of this document
  for more information.

Zeilenga                     LDAP Extensions                    [Page 1]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 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 schema.  This document
  discusses considerations for designers of LDAP extensions.

Table of Contents

  [[Page numbers to be filled in by RFC-Editor]]

  Status of this Memo
  Abstract
  Table of Contents
  1. Background and Intended Use
  2. General Considerations
  2.1. Scope of Extension
  2.2. Interaction between extensions
  2.3. Discovery Mechanism
  2.4. International Considerations
  2.5. use of Basic Encoding Rules
  2.6. Use of Formal Languages
  2.7. Examples
  2.8. Registratin of Protocol Values
  3. LDAP Operation Extensions
  3.1. Controls
  3.2. Extended Operations
  3.3. Intermediate Responses
  3.4. Unsolicited Notifications
  4. Extending LDAP ASN.1 definition
  4.1. Result Codes
  4.2. LDAP Message Types
  4.3. Authentication Methods
  4.4. General ASN.1 Extensibility
  5. Schema Extensions
  5.1. LDAP Syntaxes
  5.2. Matching Rules
  5.3. Attribute Types
  5.4. Object Classes
  6. Other Extension Mechanisms
  6.1. Attribute Description Options
  6.2. Authorization Identities
  6.3. LDAP URL Extensions
  7. Security Considerations
  8. Acknowledgements
  9. Author's Address
  10. References

Zeilenga                     LDAP Extensions                    [Page 2]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

  Full Copyright
  Intellectual Property Rights

1. Background and Intended Use

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

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

  LDAP allows additional schema to be defined [Models].  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 [Models].

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

  LDAP supports establishment of Transport Layer Security (TLS)
  [Protocol][AuthMeth].  TLS [TLS] is extensible.

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

  Lastly, LDAP allows for certain extensions to the protocol's Abstract
  Syntax Notation - One (ASN.1) [X.680] definition to be made.  This
  facilitate 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 which 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 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"

Zeilenga                     LDAP Extensions                    [Page 3]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

  refers to a control attached to a server generated message sent to a
  client.

  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
  which 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 interaction
  with other extensions.

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

  Except where 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 [Models] is used to advertised
  supported controls.  The 'supportedExtension' attribute [Models] is

Zeilenga                     LDAP Extensions                    [Page 4]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

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

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] provides a mechanism for tagging
  text (and other) values with language information.  Extensions which
  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 to
  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
  [Roadmap], 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 [LDAPDN].
  Example LDAP filter strings SHOULD conform to the syntax defined in
  [Filter].  Example LDAP URLs SHOULD conform to the syntax defined in
  [LDAPURL].  Entries SHOULD be represented using LDIF [RFC2849].

2.8. Registration of Protocol Values

  Designers SHALL register protocol values of their LDAP extensions in

Zeilenga                     LDAP Extensions                    [Page 5]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

  accordance with BCP 64 [BCP64bis].  Specifications which create new
  extensible protocol elements SHALL extend existing or establish new
  registries for values of these elements in accordance with BCP 64
  [BCP64bis] and BCP 26 [RFC2434].

3. LDAP Operation Extensions

  Extensions SHOULD use controls in defining extensions which 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 which would return for a DN a set of LDAP URLs to services
  which may hold the entry named by this DN) could be designed as either
  a search operation or a new operation.  As the feature doesn't
  complement the search operation (e.g., the operation is not contrived
  to search for entries held in the Directory Information Tree), it is
  likely more appropriate to define a new operation using the extended
  operation mechanism.

3.1. Controls

  Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for
  extending existing operations.  The existing operation can be a base
  operation defined in [Protocol] (e.g., search, modify, etc.)  or an
  extended operation (e.g. Start TLS [Protocol], Password Modify
  [RFC3062]), or an operation defined as an extension to a base or
  extended operation.

  Extensions SHOULD NOT return Response controls unless the server has
  specific knowledge that the client can make use of the control.
  Generally, the client requests the return of a particular response
  control by providing a related request control.

  An existing operation MAY be extended to return IntermediateResponse
  messages [Protocol, Section 4.13].

  Specifications of controls SHALL NOT attach additional semantics to
  criticality of controls beyond those defined in [Protocol, Section

Zeilenga                     LDAP Extensions                    [Page 6]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

  4.1.11].  A specification MAY mandate the criticality take on a
  particular value (e.g., TRUE or FALSE) where appropriate.

3.1.1  Extending Bind Operation with Controls

  Controls attached to the request and response messages of a Bind
  Operation [Protocol] are not protected by any security layers
  established by that Bind operation.

  Specifications detailing controls extending the Bind operation SHALL
  detail that the Bind negotiated security layers do not protect the
  information contained in these controls and SHALL detail how the
  information in these controls is protected or why the information does
  not need protection.

  It is RECOMMENDED that designers consider alternative mechanisms for
  providing the function.  For example, an extended operation issued
  subsequent to the Bind operation, hence protected by the security
  layers negotiated by the Bind operation, might be used to provided the
  desired function.

  Additionally, designers of Bind control extensions MUST also consider
  how the controls' semantics interact with individual steps of a multi-
  step Bind operation.  It is noted that some steps are optional and
  hence may require special attention in the design.

3.1.2  Extending the Start TLS Operation with Controls

  Controls attached to the request and response messages of a Start TLS
  Operation [Protocol] are not protected by the security layers
  established by the Start TLS operation.

  Specifications detailing controls extending the Start TLS operation
  SHALL detail that the Start TLS negotiated security layers do not
  protect the information contained in these controls and SHALL detail
  how the information in these controls is protected or why the
  information does not need protection.

  It is RECOMMENDED that designers consider alternative mechanisms for
  providing the function.  For example, an extended operation issued
  subsequent to the Start TLS operation, hence protected by the security
  layers negotiated by the Start TLS operation, might be used to
  provided the desired function.

3.1.3  Extending the Search Operation with Controls

Zeilenga                     LDAP Extensions                    [Page 7]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

  The Search operation processing has two distinct phases:
    - finding the base object; and
    - searching for objects at or under that base object.

 Specifications of controls extending the Search Operation should
 clearly state in which phase(s) the control's semantics apply.
 Semantics of controls which are not specific to the Search Operation
 SHOULD apply in the finding phase.

3.1.4  Extending the Update Operations with Controls

 Update operations have properties of atomicity, consistency, isolation,
 and durability ([ACID]).
    - atomicity: all or none of the DIT changes requested are made,
    - consistency: the resulting DIT state must be conform to schema and
      other constraints,
    - isolation: intermediate states are not exposed,
    - durability: the resulting DIT state is preserved until
      subsequently updated.

  When defining a control which requests additional (or other) DIT
  changes be made to the DIT, these additional changes SHOULD NOT be
  treated as part of a separate transaction.  The specification MUST be
  clear as whether the additional DIT changes are part of the same or a
  separate transaction as the DIT changes expressed in the request of
  the base operation.

  When defining a control which requests additional (or other) DIT
  changes be made to the DIT, the specification MUST be clear as to the
  order in which these and the base changes are to be applied to the
  DIT.

3.1.4  Extending the Response-less Operations with Controls

  The Abandon and Unbind operations do not include a response message.
  For this reason, specifications for controls designed to be attached
  to Abandon and Unbind requests SHOULD mandate that the control's
  criticality be FALSE.

3.2. Extended Operations

  Extended Operations [Protocol, Section 4.12] is the RECOMMENDED
  mechanism for defining new operations.  An extended operation consists
  of an ExtendedRequest message, zero or more IntermediateResponse
  messages, and an ExtendedResponse message.

Zeilenga                     LDAP Extensions                    [Page 8]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

3.3. Intermediate Responses

  Extensions SHALL use IntermediateResponse messages instead of
  ExtendedResponse messages to return intermediate results.

3.4. Unsolicited Notifications

  Unsolicited notifications [Protocol, Section 4.4] offer a capability
  for the server to notify the client of events not associated with
  operation currently being processed.

  Extensions SHOULD be designed such that unsolicited notifications are
  not be returned unless the server has specific knowledge that the
  client can make use of the notification.  Generally, the client
  requests the return of particular unsolicited notification by
  performing a related extended operation.

  For example, a time hack extension could be designed to return
  unsolicited notifications at regular intervals which were enabled by
  an extended operation (which possibly specified the desired interval).

4. Extending LDAP ASN.1 definition

  LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
  definition [Protocol, Appendix B] to be made.

4.1. Result Codes

  Extensions which specify new operations or enhance existing operations
  often need to define new result codes.  The extension SHOULD be
  designed such that a client has a reasonably clear indication of the
  nature of the successful or non-successful result.

  Extensions SHOULD use existing result codes to indicate conditions
  which are consistent with the intended meaning [Protocol][X.511] of
  these codes.  Extensions MAY introduce new result codes [BCP64bis]
  where no existing result code provides an adequate indication of the
  nature of the result.

  Extensions SHALL NOT disallow nor otherwise restrict the return of
  general service result codes, especially those reporting a protocol,
  service, or security problem, or indicating the server is unable or
  unwilling to complete the operation.

Zeilenga                     LDAP Extensions                    [Page 9]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

4.2. LDAP Message Types

  While extensions can specify new types of LDAP messages by extending
  the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally
  unnecessary and inappropriate.  Existing operation extension
  mechanisms (e.g., extended operations, unsolicited notifications, and
  intermediate responses) SHOULD be used instead.  However, there may be
  cases where an extension does not fit well into these mechanisms.  In
  such cases, a new extension mechanism SHOULD be defined which can be
  used by multiple extensions which have similar needs.

4.3. Authentication Methods

  The Bind operation currently supports two authentication methods,
  simple and SASL.  SASL [SASL] is an extensible authentication
  framework used by multiple application-level protocols (e.g. BEEP,
  IMAP, SMTP).  It is RECOMMENDED that new authentication processes be
  defined as SASL mechanisms.  New LDAP authentication methods MAY be
  added to support new authentication frameworks.

  The Bind operation primary function is to establish the LDAP
  association [AuthMeth].  No other operation SHALL be defined (or
  extended) to establish the LDAP association.  However, other
  operations MAY be defined to establish other security associations
  (e.g., IPSEC).

4.4.  General ASN.1 extensibility

  Section 4 of [Protocol] states:
      In order to support future extensions to this protocol,
      extensibility is implied where it is allowed per ASN.1 (i.e.
      sequence, set, choice, and enumerated types are extensible).  In
      addition, ellipses (...)  have been supplied in ASN.1 types that
      are explicitly extensible as discussed in [BCP64bis].  Because of
      the implied extensibility, clients and servers MUST (unless
      otherwise specified) ignore trailing SEQUENCE components whose
      tags they do not recognize.

  Designers SHOULD avoid introducing extensions which rely on
  unsuspecting implementations to ignore trailing components of SEQUENCE
  whose tags they do not recognize.

5. Schema Extensions

  Extensions defining LDAP schema elements SHALL provide schema
  definitions conformant with syntaxes defined in [Models, Section 4.1].

Zeilenga                     LDAP Extensions                   [Page 10]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

  While provided definitions MAY be reformatted (line wrapped) for
  readability, this SHALL be noted in the specification.

  For definitions allow a NAME field, new schema elements SHOULD provide
  one and only one name.  The name SHOULD be short.

  Each schema definition allows a DESC field.  The DESC field, if
  provided, SHOULD contain a short descriptive phrase.  The DESC field
  MUST be regarded as informational.  That is, the specification MUST be
  written such that its interpretation is the same with and without the
  provided DESC fields.

  The extension SHALL NOT mandate that implementations provide the same
  DESC field in schema they publish.  Implementors MAY replace or remove
  the DESC field.

  Published schema elements SHALL NOT be redefined.  Replacement schema
  elements (new OIDs, new NAMEs) SHOULD be defined as needed.

  Schema designers SHOULD reuse existing schema elements where
  appropriate.  However, any reuse MUST not alter the semantics of the
  element.

5.1. LDAP Syntaxes

  Each LDAP syntax is defined in terms of ASN.1 [X.680].  Each extension
  detailing an LDAP syntax MUST specify the ASN.1 data definition
  associated with the syntax.  A distinct LDAP syntax SHOULD be created
  for each distinct ASN.1 data definition (including constraints).

  Each LDAP syntax SHOULD have a string encoding defined for it.  It is
  RECOMMENDED that this string encoding be restricted to a UTF-8
  [RFC3629] encoded Unicode [Unicode] characters.  Use of Generic String
  Encoding Rules (GSER) [RFC3641][RFC3642] or other generic string
  encoding rules to provide string encodings for complex ASN.1 data
  definitions is RECOMMENDED.  Otherwise, it is RECOMMENDED that the
  string encoding be described using a formal language (e.g., ABNF
  [ABNF]).  Formal languages SHOULD be used in specifications in
  accordance with IESG guidelines [FORMAL].

  If no string encoding is defined, the extension SHALL specify how the
  transfer encoding is to be indicated.  Generally, the extension SHOULD
  mandate use of ;binary or other transfer encoding option.

5.2. Matching Rules

Zeilenga                     LDAP Extensions                   [Page 11]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

  Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and
  SUBSTRING) may be associated with an attribute type.  In addition,
  LDAP provides an extensible matching rule mechanism.

  The matching rule specification SHOULD detail which kind of matching
  rule it is and SHOULD describe which kinds of values it can be used
  with.

  In addition to requirements stated in the LDAP technical
  specification, equality matching rules SHOULD be commutative.

5.3. Attribute Types

  Designers SHOULD carefully consider how the structure of values is to
  restricted.  Designers SHOULD consider that servers will only enforce
  constraints of the attribute's syntax.  That is, an attribute intended
  to hold URIs, but which has directoryString syntax, is not restricted
  to values which are URIs.

  Designers SHOULD carefully consider which matching rules, if any, are
  appropriate for the attribute type.  Matching rules specified for an
  attribute type MUST be compatible with the attribute type's syntax.

  Extensions specifying operational attributes MUST detail how servers
  are to maintain and/or utilize values of each operational attribute.

5.4. Object Classes

  Designers SHOULD carefully consider whether each attributes of an
  object class is required ("MUST") or allowed ("MAY").

  Extensions specifying object classes which allow (or require)
  operational attributes MUST specify how servers are to maintain and/or
  utilize entries belonging to these object classes.

6. Other Extension Mechanisms

6.1. Attribute Description Options

  Each option is identified by a string of letters, numbers, and
  hyphens.  This string SHOULD be short.

6.2. Authorization Identities

Zeilenga                     LDAP Extensions                   [Page 12]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

  Extensions interacting with authorization identities SHALL support the
  LDAP authzId format [AuthMeth].  The authzId format is extensible.

6.3. LDAP URL Extensions

  LDAP URL extensions are identified by a short string, a descriptor.
  Like other descriptors, the string SHOULD be short.

7. Security Considerations

  LDAP does not place undue restrictions on the kinds of extensions
  which can be implemented.   While this document attempts to outline
  some specific issues which designers need to consider, it is not (and
  cannot be) all encompassing.  Designers MUST do their own evaluation
  of the security considerations applicable to their extension.

  Designers MUST NOT the assume that the LDAP "core" technical
  specification [Roadmap] adequately addresses the specific concerns
  surrounding their extension nor assume that their extension has no
  specific concerns.

  Extensions specification, however, SHOULD note whether or not security
  considerations specific to the feature they are extending, as well as
  general LDAP security considerations, apply to the extension.

8. Acknowledgments

  The author thanks the IETF LDAP community for their thoughtful
  comments.

  This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce
  Greenblatt.

9.  Author's Address

  Kurt D. Zeilenga
  OpenLDAP Foundation

  Email: Kurt@OpenLDAP.org

10. References

  [[Note to the RFC Editor: please replace the citation tags used in

Zeilenga                     LDAP Extensions                   [Page 13]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

  referencing Internet-Drafts with tags of the form RFCnnnn where
  possible.]]

10.1. Normative References

  [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14 (also RFC 2119), March 1997.

  [RFC2434]     Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26 (also RFC
                2434), October 1998.

  [RFC2849]     Good, G., "The LDAP Data Interchange Format (LDIF) -
                Technical Specification", RFC 2849, June 2000.

  [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
                10646", RFC 3629 (also STD 63), November 2003.

  [RFC3641]     Legg, S., "Generic String Encoding Rules for ASN.1
                Types", RFC 3641, October 2003.

  [RFC3642]     Legg, S., "Common Elements of GSER Encodings", RFC 3642,
                October 2003.

  [Features]    Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
                December 2003.

  [RFC3866]     Zeilenga, K., Ed., "Language Tags and Ranges in the
                Lightweight Directory Access Protocol (LDAP)", RFC 3866,
                July 2004.

  [ABNF]        Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 4234, October 2005.

  [Roadmap]     Zeilenga, K. (editor), "LDAP: Technical Specification
                Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
                progress.

  [Models]      Zeilenga, K. (editor), "LDAP: Directory Information
                Models", draft-ietf-ldapbis-models-xx.txt, a work in
                progress.

  [Protocol]    Sermersheim, J. (editor), "LDAP: The Protocol",
                draft-ietf-ldapbis-protocol-xx.txt, a work in progress.

  [AuthMeth]    Harrison, R. (editor), "LDAP: Authentication Methods and
                Connection Level Security Mechanisms",

Zeilenga                     LDAP Extensions                   [Page 14]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

                draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.

  [Syntaxes]    Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
                draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.

  [LDAPprep]    Zeilenga, K., "LDAP: Internationalized String
                Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work
                in progress.

  [LDAPDN]      Zeilenga, K. (editor), "LDAP: String Representation of
                Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
                work in progress.

  [LDAPURL]     Smith, M. (editor), "LDAP: Uniform Resource Locator",
                draft-ietf-ldapbis-url-xx.txt, a work in progress.

  [Filters]     Smith, M. (editor), LDAPbis WG, "LDAP: String
                Representation of Search Filters",
                draft-ietf-ldapbis-filter-xx.txt, a work in progress.

  [BCP64bis]    Zeilenga, K., "IANA Considerations for LDAP",
                draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.

  [SASL]        Melnikov, A. (Editor), "Simple Authentication and
                Security Layer (SASL)",
                draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.

  [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
                3.2.0" is defined by "The Unicode Standard, Version 3.0"
                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
                as amended by the "Unicode Standard Annex #27: Unicode
                3.1" (http://www.unicode.org/reports/tr27/) and by the
                "Unicode Standard Annex #28: Unicode 3.2"
                (http://www.unicode.org/reports/tr28/).

  [FORMAL]      IESG, "Guidelines for the use of formal languages in
                IETF specifications",
                <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt>,
                2001.

  [X.511]       International Telecommunication Union -
                Telecommunication Standardization Sector, "The
                Directory: Abstract Service Definition", X.511(1993)
                (also ISO/IEC 9594-3:1993).

  [X.680]       International Telecommunication Union -
                Telecommunication Standardization Sector, "Abstract
                Syntax Notation One (ASN.1) - Specification of Basic

Zeilenga                     LDAP Extensions                   [Page 15]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

                Notation", X.680(2002) (also ISO/IEC 8824-1:2002).

  [X.690]       International Telecommunication Union -
                Telecommunication Standardization Sector, "Specification
                of ASN.1 encoding rules: Basic Encoding Rules (BER),
                Canonical Encoding Rules (CER), and Distinguished
                Encoding Rules (DER)", X.690(2002) (also ISO/IEC
                8825-1:2002).

10.2. Informative References

  [RFC3062]     Zeilenga, K., "LDAP Password Modify Extended Operation",
                RFC 3062, February 2000.

  [ACID]        Section 4 of ISO/IEC 10026-1:1992.

  [GUIDE]       Greenblatt, B., "LDAP Extension Style Guide",
                draft-greenblatt-ldapext-style-xx.txt, an (expired) work
                in progress.

  [TLS]         Dierks, T. and, E. Rescorla, "The TLS Protocol Version
                1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
                progress.

Full Copyright

  Copyright (C) The Internet Society (2006).

  This document is subject to the rights, licenses and restrictions
  contained in BCP 78, and except as set forth therein, the authors
  retain all their rights.

  This document and the information contained herein are provided on an
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
  ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property Rights

Zeilenga                     LDAP Extensions                   [Page 16]
INTERNET-DRAFT         draft-zeilenga-ldap-ext-10        2 February 2006

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights.  Information
  on the procedures with respect to rights in RFC documents can be found
  in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use of
  such proprietary rights by implementers or users of this specification
  can be obtained from the IETF on-line IPR repository at
  http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at
  ietf-ipr@ietf.org.

Zeilenga                     LDAP Extensions                   [Page 17]