minutes from LDAPEXT meeting

[Mark Wahl <M.Wahl@INNOSOFT.COM>]

Attached are the minutes I recorded from the LDAPEXT meeting in Orlando.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.


IETF LDAPEXT Meeting Minutes
December 9, 1998

Reported by Mark Wahl

1. Introduction

Two topics was added to the draft agenda that had been sent to the list 
earlier in the week: families of entries and X.500(2000) update.

Discussion on root DSE attributees was referred to the list.

2. Mark Wahl briefly summarized the drafts that had completed last call.

The mandatory-to-implement authentication (MTI) drafts, 
draft-ietf-ldapext-authmeth-03.txt, draft-ietf-ldapext-ldapv3-tls-04.txt 
and draft-leach-digest-sasl-01.txt had gone through last call and would 
be sent to the Area Directors to be progresed as Proposed Standard RFCs. 
This resolved the issue of a lack of MTI non-cleartext password 
authentication mechanism that was present when the LDAPv3 drafts were 
completed.

The drafts on language tags, dynamic entries and simple paging had already
completed working group last call, and had been waiting for the MTI 
authentication issue to be resolved.

At the time of the meeting, the following drafts were in last call:
draft-ietf-ldapext-vlv-02.txt, draft-ief-ldapext-sorting-01.txt, 
draft-ietf-ldapext-x509-sasl-00.txt, draft-ietf-ldapext-c-api-01.txt
and draft-itef-ldapext-acl-reqts-01.txt.

3. Ellen Stokes gave an updated proposal for an Access Control model.

This proposal is baesd on defining a standard way of manipulating access
control, without requiring a standard access control information transfer 
encoding between the managing client and server.

Access control policy information would conceptually be stored in the 
directory, but clients would use controls and extended operations  
to set access controls, get effective access rights and list 
subject's rights.

This would not forbid there being one (or more) possible formats in which the
data would actually be stored in servers, but would allow clients to 
interoperate to a degree with servers whose access control format was 
unknown to them.

A straw poll showed there was interest by implementors in this approach.

Discussion focused on two main topics, the need for a common representation
format, and the form of subject identity.

A common representation of access control information is needed for  
replication, either through the replication protocol being developed in 
LDUP, or informally in LDIF files, which do not exchange operations, but
the entries themselves.

The subject identity in the proposal is in the form of a DN.  Security
protocols being done in CAT and other working groups use a more generic
( mechanism + mechanism-specific identity object ) format.  Another 
approach would be to have clients ask the server to map their authentication
mechanism-specific identity into a DN, which the client could then use in
access control operations.

4. Mark Smith reviewed the LDAP C API draft status.

LDAP C API Slides
Presented at IETF 43 in Orlando by Mark Smith <mcs@netscape.com>

Slide 1 of 3 (overview): 

  - Draft has been around for a long time and is widely deployed.

  - Tradeoff between compatibility and perfection of API.

  - Pressure from both sides.

  - Current draft passes the "It is useful and it works for many people"
    test with flying colors.


Slide 2 of 3 (open issues that are currently listed in the draft and
  proposed resolution): 

  - 23.1 Threading ==> extension doc.
  - 23.2 TLS ==> extension doc.
  - 23.3 Referrals client control ==> add now?
  - 23.4 IPv6 compatibility ==> address now
  - 23.5 SASL API std? ==> later
  - 23.6 Non-UTF8 charsets ==> note and put in extension doc.
  - 23.7 LDAP session options ==> ?
  - 23.8 Rebind callback ==> add now
  - 23.9 API extension mechanism ==> nearly done


Slide 3 of 3 (other open issues that were raised on the mailing list and
  proposed resolution):

  - A. Use of 'const' in LDAP ==> add as a SHOULD
  - B. LDAPv2 compatibility ==> ?
  - C. Use of 'int' vs. LDAPINT32 ==> ?
  - D. 'ldap.h' header file requirements ==> add now
  - E. Finer grained client side timelimits in ldap_set_option() ==> extension
  - F. Document incompatibilities with RFC 1823 ==> later
  - G. BER bug fixes and clarifications ==> address now
  - H. Improve non-blocking I/O and select/poll support (for
       multiprotocol applications) ==> extension
  - I. Opaqueness of structs; use of arrays ==> the right tradeoff has
       been made; do nothing.

5. Signed Operations

There were few issues noted with the signed operations document, and there
was rough concensus that EXPERIMENTAL was the best status for this 
document at present.  One concern was that the title did not quite reflect
the contents of this document.

6. Referrals

The referrals draft is being split into two parts: one part with the return
of referrals by servers holding hierarchically-arranged naming contexts,
the second with the return of referrals holding mesh or index information.

7. Jim Sermersheim presented his draft on the return of Duplicate Entries
in search results.  This was intended for generating a sorted listing 
when the sort key attributes are multi-valued, and for handling group
entries with many members.

There was also interest in having range queries on attribute values, so
that a client could retrieve some but not all values.  This would help
with managing an entry with a attribute containing a large number of 
values, but not with the sorting problem.

There was concensus that this would should progress on the standards
track.

8. David Chadwick requested the group's input on the issue of 
representing Compound Attributes, which collect a set of related attributes
in a package that is distinct from another set of attributes associated 
with an entry.  (An example might be a person's sets of work and home 
contact details.)

The X.500 standards community was considering two approaches:

 1) Attributes could contain an id and a set of attributes.  There 
    would be new controls like allInnerValues for operating on 
    attributes inside of attributes.

 2) A family of entries.  Below a parent entry would be children entry, one
    for each attribute group.  

A preference was expressed for the family of entries approach.  This would 
allow existing DIT schema and access control rules to govern these compound 
attributes more easily.

There was concensus to investigate this issue for LDAP directories as part 
of the LDAPEXT working group.  

Also, Mark Wahl took an action to document the use of attribute option labels 
as another simple approach of building compound attributes.

9. David Chadwick presented the other new services being added into the 
X.500(2000) specifications.  

These include: related entries, a mapping of X.500 protocols (DAP,DSP,DOP, and
DISP) directly over TCP/IP without the middle layers of stack, extensions for 
F.510 (the telephone directory-assistance operations), and multi-master 
replication, based on design input from Telstra.

10. A deadline was sent for 2 weeks to have an update on the merge of the
persistent and triggered search documents.