Subject: WG ACTION: LDAP Extension (ldapext)

From: Cynthia Clark <[email-masked]>
Date: Fri, 07 Nov 1997 10:57:01 -0500

A new working group has been formed in the Applications Area of the IETF.
For additional information, contact the Area Directors
or the WG Chair.

LDAP Extension (ldapext)
------------------------
  
 Chair(s):
     Tim Howes <[email-masked]>
     M. Wahl <[email-masked]>
 
 Applications Area Director(s): 
     Keith Moore  <[email-masked]>
     Harald Alvestrand  <[email-masked]>
 
 Applications Area Advisor: 
     Harald Alvestrand  <[email-masked]>
 
 Mailing Lists: 
     General Discussion:[email-masked]
     To Subscribe:      [email-masked]
     Archive:           
 
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:

        draft-ietf-asid-ldapv3-lang-02.txt

- 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:

        draft-ietf-asid-ldapv3-referral-00.txt

- 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:

        draft-ietf-svrloc-discovery-01.txt

- LDAP APIs

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

- CLDAP

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                            

 Internet-Drafts:

  No Current Internet-Drafts.

 Request For Comments:

  None to date.

------- End of Forwarded Message