Subject: RE: ModifyDN -- subtrees or not?

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 14 Sep 2001 16:12:29 -0700

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.

---

From: Chris Harding <[email-masked]>
Date: Mon, 17 Sep 2001 11:28:16 +0100

Hi, Kurt -

Thanks for this reply, which clarifies things a little.

>same subset of functionality.

This has to be true.

>Where particular subsets of

The DIF charter includes the words:

     The Directory Interoperability Forum enables and promotes open and 
interoperable
     directories based on open standards. This

         * makes directories more usable,
         * ensures that any applications written to use an open directory 
can run with any
           directory without regard to the supplier, and
         * makes it easy for software developers to create those applications.

The desire to ensure that any applications written to use an open directory 
can run with any directory without regard to the supplier is why we have 
defined The Open Brand for LDAP 2000, identifying a minimum level of server 
functionality that applications can assume. We don't want to force people 
just to implement or just to use this functionality. We do want to make it 
possible for people who want to develop server-independent applications to 
do so, by defining a set of functions that they can rely on. I guess this 
could be what you mean by an applicability statement - but it is more than 
a statement of applicability for some particular purpose, it is a statement 
of general applicability.

> >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".
>
>to perform the request.  If the most appropriate result code is 
>unwillingToPerform, than that's what should be returned.

The definition of the RFCs is the province of the IETF. But it will be 
helpful to everyone if that definition is clear. I am not arguing for a 
particular interpretation here, but pointing out that an interpretation 
other than the one you outline is positively suggested by some of the 
wording of the RFC, and is not in conflict with any other wording. If two 
possible interpretations can be maintained, then the RFC is ambiguous.

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

This was a document produced by X/Open before the DIF was formed. It does 
not form part of the definition of The Open Brand for LDAP 2000.

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

I have been involved with standards for a long time, now. In my experience, 
standards have often been approved with "wills" in places that should have 
had "shalls" (or "MUSTs", per IETF practice). It is very difficult to use 
precise wording consistently. Generally, if you see a "will" used other 
than simply to express futurity, all you can be sure of is that the wrong 
word has been used. You don't know whether the right word is "shall" or 
"should" or "may" or "can".

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

My suggestion is that you clarify whether the RFC requires servers to 
implement Move Subtree (and other operations that are the subjects of 
protocol requests). I don't have a view on whether it should or should not 
require them.

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

That's my understanding also. But in view of the importance of this point, 
I want to be sure!

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:[email-masked] 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
========================================================================

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 17 Sep 2001 10:57:40 -0700

At 03:28 AM 2001-09-17, Chris Harding wrote:
>My suggestion is that you clarify whether the RFC requires servers to implement Move Subtree (and other operations that are the subjects of protocol requests).

While I think the language used could be improved, I believe
the technical specification is reasonable clear that a server
can refuse to successfully complete any operation for any
reason and is only obligated to return an appropriate response.

An implementation is free to return a non-successful result in
response to any and all subtree move (rename) requests.  This may
be due to mapping onto a directory system which cannot support
this request [RFC 2251, 3.3].  I note that many LDAP servers
do not support subtree move (rename).

Kurt