Subject: RE: ModifyDN -- subtrees or not?

From: "Jim Sermersheim" <[email-masked]>
Date: Sat, 25 Aug 2001 10:55:02 -0600

That's fine. There's another problem though: There is language here and there that explicitly excuses the server from behaving certain ways in certain circumstances (note the language excusing LDAP servers acting as X.500 gateways from moving distributed subtrees). Whenever we have language explicitly excusing behavior, it creates an implication that anything not excused is required. I believe this causes confusion for the reader.

One thing we could do is to qualify this type of behavior-exception language with something like: "The server may not be able to process this request due to situations such as:...". The intent is to show the well-known exceptions, while not implying that there are no other exceptions.

The problem that originated this was that an interoperability test suite is being created, and the creators have made assumptions about *required* server behavior based on the operation semantics called out in RFC 2251. I believe what you are saying below, is that the operation semantics have no bearing on required server behavior. Correct?

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 8/24/01 8:41:17 AM >>>
I will argue against adding imperatives here (and other
such places). LDAP is defined such that servers can return
unwillingToPerform or other appropriate resultCode when
unable or unwilling to complete the request.  For protocol
interoperability, it is only necessary that both peers agree
on the meaning of the request and responses.  It does not
require that independent implementations behave in the exact
same manner when given the same request/response.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 25 Aug 2001 12:07:51 -0700

At 09:55 AM 8/25/2001, Jim Sermersheim wrote:
>One thing we could do is to qualify this type of behavior-exception language

Note that the text in question starts with "Note that...".

>with something like: "The server may not be able to process this request due to situations such as:...". The intent is to show the well-known exceptions, while not implying that there are no other exceptions.

I guess I find the existing text confusing in that regard.  There
are clearly other exceptions (unwillingToPerform, other, access
controls, ...).

>The problem that originated this was that an interoperability test suite is being created, and the creators have made assumptions about *required* server behavior based on the operation semantics called out in RFC 2251.

Just because the specification details ModDN does not imply that
all servers MUST implement ModDN.  An example of such would be
a read-only server.

>I believe what you are saying below, is that the operation semantics have no bearing on required server behavior. Correct?

I am saying that protocol interoperability requires that each
peer understand the syntax and semantics of the protocol exchanges.
However, the protocol does not require that each peer fully implement
all semantics or behave in exactly the same manner.  Where specific
subsets of semantics are required by an application, an
applicability statement should be made detailing this subset.  The
LDAPv3 applicability for PKI is one example.  ("LDAP 2000" could
be viewed as applicability statement(s)).

Kurt