[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ModifyDN -- subtrees or not?
At 09:55 AM 8/25/2001, Jim Sermersheim wrote:
>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
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