Subject: ModifyDN -- subtrees or not?

From: "Slone, Skip" <[email-masked]>
Date: Wed, 22 Aug 2001 13:57:36 -0400

An issue has recently come up in the Directory Interoperability Forum
concerning what RFC 2251 really says on the matter of using ModifyDN to move
subtrees.  As I read it, there's no clear conformance statement (a la RFC
2119) one way or another. The entire discussion in paragraph 4.9 is in plain
English (with no use of RFC 2119 keywords such as MUST).  On that topic,
draft-ietf-ldapbis-protocol-02.txt is no clearer.

It seems to me this is an issue that needs clarifying.  Any thoughts?

 -- Skip Slone

---

From: "Roger Harrison" <[email-masked]>
Date: Wed, 22 Aug 2001 13:55:00 -0600

Doing a subtree move operation is not always trivial, and even when it's possible it may not be very efficient. In my testing it appears that this is not supported by many/most LDAP server implementations. I think it would be good to explicitly identify the requirement level (MUST, SHOULD, MAY) for the sub-tree movement part of this operation.
 
Roger Harrison

>>> "Slone, Skip" <[email-masked]> 08/22/01 11:57AM >>> 

-- Skip Slone

---

From: "Slone, Skip" <[email-masked]>
Date: Thu, 23 Aug 2001 09:29:56 -0400

I agree as well. Although we were looking at a specific instance, it seems
we've uncovered a general weakness in the spec.

 -- Skip

-----Original Message-----
From: John Strassner [mailto:[email-masked]] 
Sent: Thursday, August 23, 2001 9:28 AM
To: Jim Sermersheim; [email-masked]; [email-masked]
Subject: RE: ModifyDN -- subtrees or not?

I agree with Jim - I think that the language should be tightened.

regards,
John

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jim Sermersheim
Sent: Wednesday, August 22, 2001 11:04 PM
To: [email-masked]; [email-masked]
Subject: Re: ModifyDN -- subtrees or not?

Hmm, a bigger question might be: do we need to add 2119 imperatives and
tight language to the entire doc? For example, The delete operation
similarly says "The Delete Operation *allows* a client to *request* the
removal of an entry..." To the purist, this leaves things wide open-- to the
degree that I could willy-nilly decide to not let people delete entries with
a Q in the rdn on odd-numbered days. An interoperability test could only
test that the PDU can be succesfully sent from the client and an appropriate
response recieved from the server. The Delete Response does say that the
server *will* attempt to perform the entry removal, but this is not a MUST.
(I'm sort of using a silly example to highlight the point).

As an aside, I also see that there is no note stating that the operation may
fail due to a move (subtree or otherwise) resulting in invalid containment.

Jim

>>> "Slone, Skip" <[email-masked]> 8/22/01 11:57:36 AM >>>

 -- Skip Slone

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 24 Aug 2001 07:41:17 -0700

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: "Slone, Skip" <[email-masked]>
Date: Wed, 29 Aug 2001 15:52:18 -0400

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:[email-masked]] 
Sent: Saturday, August 25, 2001 3:08 PM
To: Jim Sermersheim
Cc: [email-masked]
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