RE: ModifyDN -- subtrees or not?

["Slone, Skip" <skip.slone@lmco.com>]

Interesting food for thought all the way around...

I think we need to be careful with respect to how much we let servers off
the hook when it comes to semantics.  Taken to the extreme, a server can
claim conformance to LDAPv3 if all it does is reply "unwillingToPerform" in
response to every syntactically valid LDAPv3 request.  Such a server would
arguably be interoperable at the protocol level, since it would not cause
any failures of the protocol engine; however, it would clearly not be very
useful.  At the other extreme, if a server did nothing but return a success
result in response to each syntactically correct update request, one could
again argue the virtues of protocol interoperability, without having any
sense of semantic compatibility.

What I think we need is a clear set of directives that unambiguously bind
semantics to the various syntactic constructs.  Strict subsetting of
functionality is okay, but allowing two servers to choose different
behaviors -- yet return the same result -- is a recipe for trouble.   I
think a careful "if ... then" construction of RFC 2119 language can preclude
such problems, while still allowing implementers to develop products that
implement specific subsets of the specification. Applicability statements
(such as LDAP 2000) will then have a solid foundation on which to build.

 -- Skip 


-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
Sent: Saturday, August 25, 2001 3:08 PM
To: Jim Sermersheim
Cc: ietf-ldapbis@OpenLDAP.org
Subject: 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