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

RE: ModifyDN -- subtrees or not?

Hi, Kurt -

Thanks for this reply, which clarifies things a little.


Obviously, no one should assume that all servers implement the
same subset of functionality.


This has to be true.

Where particular subsets of
functionality are needed, applicability statements should be
specified.  Then the developer can target peers implementing
the applicability statement.


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.

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

Then how did you define a read-only profile?

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.

It is a bad assumption to read 'will' as SHALL.  If SHALL was intended
it most likely would have been used.

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

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

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?

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

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