Hello Vladimir -
Once again, I would like to thank you for your thoughful analysis and
comments.
I've read your message, and I don't think that there is anything that
justifies recalling the document from the IESG; so it will not go into the new
RFC. However, I certainly will keep your message, and will use it in the next
set of changes. Note that there will need to be at least two RFCs after this
one before IMAP becomes a Full Standard.
About the issues that you raised:
a) Neither the document, nor the protocol, takes any position about a trailing
hierarchy delimiter in the mailbox name in the DELETE or RENAME commands. The
special semantics for the trailing hierarchy delimiter only apply to CREATE.
In general, however, anything that is not defined by the protocol is defined
by the implementation. Since the protocol has no definition of what trailing
hierarchy delimiter in the name means for DELETE or RENAME, it falls under the
category of "things that clients shouldn't do."
b) It was intended that RENAME should preserve UIDVALIDITY and UIDs. However,
this is wrong if the new name previously existed with a higher UIDVALIDITY
value. So, it appears that a server has to assign a new UIDVALIDITY.
Unfortunately, should that requirement be added, it would instantly render
multiple servers non-compliant, in addition to servers that already fail to
comply with the atomic requirement.
My feeling is that RENAME should be removed from the protocol in a future
version of the specification, on the grounds that it is fundamentally broken.
However, doing so will be controversial, and I think that we should defer
action.
c) The definition of the special case of INBOX renaming was *not* "based on a
certain implementation" but rather was an attempt to weasel around earlier
problems with the definition of RENAME.
Your guess at how UW imapd works in this case is incorrect. UW imapd will
refuse to rename any mailbox that is selected by any client, *including* the
client doing the rename. Thus, it can only rename INBOX if nothing (including
the current session) has INBOX selected. The rename is then just a matter of
doing the rename and creating a new empty INBOX.
Thus, UW imapd's implementation of RENAME is more or less the same as what
CommuniGate Pro does.
d) You asked about this case:
CREATE aa (aa is "dual-use")
CREATE aa/bb
DELETE aa (which makes aa be \NoSelect)
and then what happens if the client does:
CREATE aa
I agree with you that it is desirable that "aa" becomes a "dual-use" name once
again; however this is also implementation-specific. Otherwise, this would
establish a requirement that a mail store be able to create a "dual-use"
mailbox in an existing "directory".
If the server responds with an OK, then that is what happened. Since there
was no trailing hierarchy delimiter, the name aa must be selectable; therefore
the CREATE made the name be "dual-use" once again.
However, the server has (always has) the right to respond with a NO. So, a
mail store that does not allow "upgrade" of a \NoSelect name to "dual use" has
the perogative to respond with a NO.
Once again, thank you for your comments. I agree that we should address all
of these issues in the future, but I don't think that these issues justify any
further delay of the RFC 2060 replacement.
-- Mark --
