[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: ModifyDN -- subtrees or not?




Chris,

I agree with your sentiments.

The trick here is to be very precise without being overly prescriptive (i.e. allow room for different implementations to exist and provide "value-add" functions).

Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681



Chris Harding <c.harding@opengroup.org>
Sent by: owner-ietf-ldapbis@OpenLDAP.org

09/14/2001 06:36 AM

       
        To:        ietf-ldapbis@OpenLDAP.org
        cc:        
        Subject:        RE: ModifyDN -- subtrees or not?

       


Hi -

This issue has been discussed in depth in the ietf-ldapbis thread archived
at http://www.openldap.org/lists/ietf-ldapbis/200108/threads.html#00025. I
am now adding to this thread at the request of the Directory
Interoperability Forum, to point  out the problems that arise due to lack
of clarity in RFC 2251 regarding which elements of the protocol must be
supported.

The idea that a server may arbitrarily respond to a request or not is, to
put it mildly, not very helpful to the application developer. How can
anyone write an application that can can run with any directory without
regard to the supplier, if different suppliers are allowed to implement
different subsets of functionality, which may or may not be adequate for
the application in question?

If you then say that you don't know whether this idea is correct or not,
you make the situation very confusing.

This is particularly so as the words "a server will attempt to perform" in
RFC 2251 seem on the face of it specifically to rule out the result
"unwillingToPerform".

The server certification program defined by the DIF - The Open Brand for
LDAP 2000 - requires all features of the protocol not specifically
indicated as optional to be implemented. This is based on the assumption
that they are required by the RFC, as per the above wording. However the
DIF is very concerned to interpret the IETF RFCs on which its work is based
correctly. If its assumptions are not correct, then its conclusions must be
reappraised.

It is within the scope of the ldapbis group to remove the confusion, and
the directory community is looking to the ldapbis group to do so. The
charter of ldapbis is to deliver revised LDAPv3 specifications suitable for
consideration as a Draft Standard, and the wording of these revised
specifications should leave absolutely no room for doubt as regards
conformance requirements for LDAP servers and applications.

Meanwhile, bearing in mind the time needed for documents to reach Draft
Standard status, it would be valuable to have a formal statement of
interpretation from the IETF on this point in the near future. Is there a
way in which this can be done?

Regards,

Chris
+++++

========================================================================
           Dr. Christopher J. Harding
  T H E    Executive Director for the Directory Interoperability Forum
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:c.harding@opengroup.org Phone:  +44 118 950 8311 x2262
           WWW: http://www.opengroup.org Mobile: +44 774 063 1520
========================================================================
The Open Group Conference October 2001 - featuring
ACTIVE LOSS PREVENTION - Establishing Trust and Risk Management in eBusiness
Grand Hotel Krasnapolsky, Amsterdam, The Netherlands, 22-26 October 2001
http://www.opengroup.org/amsterdam2001
========================================================================