RE: ModifyDN -- subtrees or not?

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:36 AM 2001-09-14, Chris Harding wrote:
>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,

A server cannot arbitrarily respond to a request.  It must respond
with an appropriate response.  That message should contain an
appropriate result code indicating the nature of the response.

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

Obviously, no one should assume that all servers implement the
same subset of functionality.  Where particular subsets of
functionality are needed, applicability statements should be
specified.  Then the developer can target peers implementing
the applicability statement.

>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".

I do not view this as a requirement for a server to perform an
operation which it is unwilling or unable to perform.  A server
is clearly free to refuse to perform (or attempt to perform)
a request for ANY reason and is only obligated to return an
appropriate response with an indication as to why it refused
to perform the request.  If the most appropriate result code is unwillingToPerform, than that's what should be returned.

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

Then how did you define a read-only profile?

>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 a bad assumption to read 'will' as SHALL.  If SHALL was intended
it most likely would have been used.

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

Feel free to make specific suggestions....

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

Other than by publishing an RFC, not that I'm aware of.