I agree with Jim - I think that the language should be tightened. regards, John -----Original Message----- From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Jim Sermersheim Sent: Wednesday, August 22, 2001 11:04 PM To: skip.slone@lmco.com; ietf-ldapbis@OpenLDAP.org 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" <skip.slone@lmco.com> 8/22/01 11:57:36 AM >>> 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature