2.1.9 LDAP Extension (ldapext)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 01-Mar-99


Tim Howes <howes@netscape.com>
M. Wahl <Mark.Wahl@innosoft.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Patrik Faltstrom <paf@swip.net>

Mailing Lists:

General Discussion:ietf-ldapext@netscape.com
To Subscribe: ietf-ldapext-request@netscape.com

Description of Working Group:

LDAP version 3 has laid a solid foundation for directory access on the Internet. More work is needed to provide a full Internet directory service. The LDAP Extension working group will define and standardize extensions to the LDAP version 3 protocol and extensions to the use of LDAP on the Internet. The group will also extend and standardize the existing de facto application program interface to LDAP. The planned work items include the following areas, many of which have been previously discussed for some time in the ASID working group:

- Authentication

LDAPv3 contains an extensible SASL-based authentication framework. This work item will be to document the forms of client authorization provided by specific SASL mechanisms.

- Access control

LDAPv3 defines an information model and an authentication model, allowing information to be protected via access control. But LDAPv3 defines no standard representation or semantic for this access control information. This work item will be to define such a standard access control model.

- Server-side sorting of search results - Paged retrieval of search results

In order to more efficiently support the assumptions of users viewing search results as a sorted, scrollable list, servers sort and provide a paged view onto search results. This work item will define the LDAPv3 message controls to allow a client to request a particular sort order, and to allow a client to retrieve search results one page at a time. The group will base its work on the following drafts:

draft-ietf-asid-ldapv3-sorting-00.txt draft-ietf-asid-ldapv3-simple-paged-01.txt

- Language tags

LDAPv3 carries character data in UTF-8 format, allowing the full range of international characters to be represented. This work item will be to define attribute descriptions allowing the data returned from or input to an LDAPv3 directory to be tagged identifying the language of the data, and to define an LDAP message control allowing a client to specify a preferred language. The group will base its work on the following draft:


- Dynamic directories

LDAPv3 supports static directory information that persists in its value over a relatively long period of time until it is removed. Some applications (e.g., Internet conferencing) require dynamic information that changes often and persists only as long as it is being refreshed. The deliverable from this work item will be LDAPv3 message controls and extended operations allowing the specification and refresh of dynamic directory information. The group will base its work on the following drafts:

draft-ietf-asid-ldapv3ext-04.txt draft-ietf-asid-ldap-dynatt-00.txt

- Referral and knowledge reference maintenance

LDAPv3 is defined as an access protocol in which referrals may be returned directing a client from one directory server to others. It does not specify how this referral information is represented in the directory. The deliverable from this work item is a document defining the mechanisms by which referrals (sometimes known as knowledge references) may be maintained in a server. The group will base its work on the following draft:


- LDAP server discovery

Like most other Internet protocols, LDAPv3 is silent on the bootstrapping issue of how a client locates an LDAP server to talk to. Yet this step is necessary for any client to successfully use the directory without a priori knowledge of the directory server address it should use. The group will work in conjunction with the SVRLOC group on defining the method by which LDAP clients discover LDAP servers, based on the following document:



LDAP has an associated de facto standard C API, defined in RFC 1823. The existence of this API has proved to be of great value in spurring LDAP client development. As new features are added in LDAPv3 and the extensions discussed elsewhere in this charter, the API will need to be updated to make these new protocol features available to clients. As application development in other languages, Java in particular, occurs, the need for a standard API increases. The deliverable from this work item will be documents updating RFC 1823 for LDAPv3, documents defining API extensions to support protocol extensions, and a document defining a similar API for Java. The group will base its work on the following documents:

draft-ietf-asid-ldap-c-api-00.txt draft-ietf-asid-ldap-java-api-00.txt draft-ietf-asid-ldapv3-api-ext-00.txt


LDAPv3 defines transport over TCP. In some situations, the overhead involved in setting up and tearing down TCP connections is prohibitive, requiring a lighter-weight transport. The deliverable from this work item will be a document defining transport of the LDAPv3 protocol over connectionless UDP transport. The group will expand on the work developed for LDAPv2 in RFC 1798.

- Signed directory information

In many environments clients require the ability to validiate the source and integrity of information provided by the directory. The deliverable will be a document describing an LDAP message control which allows for the retrieval of digitally signed information.

Other areas such as deployment and schema definition and review will be handled by other groups. Other areas may be added after approval by the area directors if and when they turn out to be necessary for the deployment of LDAP and feasible for the group to tackle. In particular, replication may be considered for addition to the group's charter if and when a viable approach to the problem is demonstrated.

Goals and Milestones:

Nov 97


Submit ID on paged retrieval of search results

Nov 97


Submit ID on dynamic directories

Nov 97


Submit ID on referrals and knowledge references

Nov 97


Submit ID on sorting of search results

Nov 97


Submit ID on language tags

Nov 97


Submit ID on Java LDAP API

Nov 97


Submit ID on C LDAP API

Dec 97


Meet at 40th IETF (DC)

Dec 97


Submit ID on sorting of search results to IESG for consideration as a Proposed Standard

Dec 97


Submit ID on paged retrieval of search results to IESG for consideration as a Proposed Standard

Dec 97


Submit ID on referrals and knowledge references to IESG for consideration as a Proposed Standard

Dec 97


Submit ID on C LDAP API to IESG for publication as a RFC

Dec 97


Submit ID on Java LDAP API to IESG for publication as a RFC

Dec 97


Submit ID on dynamic directories to IESG for consideration as a Proposed Standard

Dec 97


Submit ID on access control requirements

Dec 97


Submit ID on signed directory information

Dec 97


Submit ID on recommended authentication methods

Mar 98


Submit ID on access control

Mar 98


Submit ID on recommended authentication methods to IESG for consideration as a Proposed Standard

Mar 98


Submit ID on signed directory information to IESG for consideration as a Proposed Standard

Mar 98


Submit ID on CLDAP

Jul 98


Submit ID on access control to IESG for consideration as a Proposed Standard

Jul 98


Submit ID on CLDAP to IESG for consideration as a Proposed Standard

Aug 98


Conclude group or update WG Charter


No Request For Comments

Current Meeting Report

IETF LDAPEXT Working Group
March 17, 1999

Minutes recorded by Mark Wahl <M.Wahl@innosoft.com>.

1. Summary of completed documents and charter items (Mark Wahl)

HTTP Digest is moving to Proposed Standard. There have been some changes to DIGEST-MD5 based on late-last-call comments from members of the working group, so an updated draft will be sent out that resolves them.

The C API will be reissued before another Last Call. There are currently two proposals for a Java API for LDAP. The authors are meeting later in the week with a goal for producing a single document.

The referral document is being split into two. The 'named reference' portion should be available within about a week, the 'mesh interconnection' will be available later.

There was concensus that the signed operations document should go to Experimental.

Mark Wahl will be getting comments on the merger of the persistent and triggered search documents, and there should be a combined document within a month.

The Virtual List view and Server-side sorting drafts will be going to Proposed Standard.

2. Charter review discussion

The Working Group has made progress on quite a few of the items on its charter. Mandatory-to-implement authentication method is done. Access control and referrals are in progress. There is a presentation on drafts written concerning server discovery later in the meeting.

2.1 Connectionless LDAP

No drafts have yet been written updating RFC 1798. There is some interest in working on this, in particular adding support for referrals. (Note that while CLDAP is not intended as a replacement for DNS, it could be used in future resource discovery protocols being discussed elsewhere in the IETF.)

Mark Wahl, Pat Connely and Roland Hedberg are interested in working on this and should have a draft by the next IETF, so there is concensus that it should be kept on the charter.

2.2 Families of Entries

The X.500 committee is working on a proposal for families of entries, and David Chadwick gave an overview of its approaches at the last IETF meeting. There was interest at that time in using families of entries in LDAP directory servers.

The rough concensus of the group appeared to indicate that the IETF should follow, and where possible participate, in the ISO development, and that it should not be added to the charter of the LDAPEXT working group at this time. A new working group could be formed later in the IETF following completion of the ISO work to evaluate this for LDAP, or a specification could be published as Informational.

2.3 Transactions

Earlier in the life of the LDAPEXT working group there were discussions on the use transactions in LDAP. These are primarily intended not in the 'database' sense with the ASID properties, but just as a way of grouping DIT modification operations as a unit.

There was a short discussion on the scope of the problem. There have not been many different deployments so far; Hitachi had implemented a specification but it did not use distributed transactions. Also, the plans in the LDUP working group for replication would increase availability of the directory information, but would not permit full transaction semantics to necessarily be provided, and might not allow synchronization guarantees to be maintained.

Transactions are not on the LDAPEXT charter at present.

2.4 Other proposed additions to charter

There are two other drafts - a 'complex' search specification for sending Java bytecodes to an LDAP server, and a proxy auth. document. Neither were discussed at this meeting.

The Area Director Patrik Falstrom noted that a Working Group cannot close down until there are no Internet Drafts outstanding in the ID-archive. Therefore, a document should not be submitted with a name of draft-ietf-ldapext-... unless it is already on the charter of LDAPEXT.

The LDAPEXT working group does not need to persist indefinitely: once the group is shut down, the mailing list can still remain active to discuss future proposed extensions.

3. Access Control (Ellen Stokes)

Slides concerning draft-ietf-ldapext-acl-model-02.txt

Changes to Model Draft (02)

- push from client to server
- control that rides with ldap_bind()
- server behavior for processing specifyCredentials control

- public (public access for all users)
- this ( self - user whose name matches entry being accessed)

The Model Today

- UpdateAccessControl
- GetEffectiveRights
- ListSubjectRights
- specifyCredentials

The Problem

The Proposed Modified Model

- Server responsible for mapping such LDIF ACI to server's own implementation
- updateAccessControl extended operation & control no longer needed
- Aids in application portability, interoperability, and management

Work Plan

- Need contributor(s)

Concerns were expressed that a subset of a server's policy will not be insecure if that policy cannot be replicated. This can in part be addressed by servers' advertising their supported policy mechanisms: a server should then not attempt to replicate data to another whose policy mechanism is different if the data is protected by policy information that could not be expressed in the form described by this model.

Several volunteers formed an engineering committee to revise the LDIF specifications.

4. Service Location (Eric Guttman)

There are several areas in which the design goals for Service Location Protocol (SLPv2) have led to alignment to LDAPv3. Directory Agents may be backed by LDAP servers: attributes and search filters are broadly compatible with LDAPv3 concepts, and SLP scopes could be mapped into distinguished names. Service Templates are schema definitions which specify the attributes which model particular services.

The document draft-ietf-svrloc-ldap-scheme-01.txt is a service template that describes how LDAP servers can be advertised by SLP. The LDAPEXT working group should review this document from SVRLOC to ensure that it is complete.

The document draft-ietf-svrloc-template-conversion-03.txt describes how to convert SVRLOC service templates into LDAP schemas. This document is based on SLPv1, so needs to be updated. It highlights a few differences between the two schema models, such as the use of keywords - zero-valued attributes in LDAP. It may be desirable to have SLP templates be a subset of LDAP schemas, and have LDAP schemas be designed to be compatible with SLP.

5. Tree Delete Control (Michael Armijo)

Michael would like to have this document (draft-armijo-ldap-treedelete-00.txt) moved forward as a Proposed Standard. The Area Directors need it to be reviewed by the LDAPEXT working group. Please in the next few weeks send comments to the author or to the mailing list.

6. Duplicate Entry Result Control (Jim Sermersheim)

There are two immediate applications of this control. One is to allow paging of an entry with an attribute of a large number of values (e.g. a group with many members): one PDU is returned for each value. The other is to specify an alternative behavior for sorting on a multi-valued attribute: one PDU is returned at each value's location in the sort order. A revised draft should go into last call and plan to move forward as a Proposed Standard. Ed Reed will send implementation experiences to the mailing list.


None received.