Hello, On Thu, 24 Oct 2002 12:35:32 -0700 (PDT) Mark Crispin <[EMAIL PROTECTED]> wrote:
Hello Vladimir -Once again, I would like to thank you for your thoughful analysis and comments.
The pleasure is all mine.
b) It was intended that RENAME should preserve UIDVALIDITY and UIDs. However,CommuniGate Pro will not comply either, but on the second thought - is this that important? I mean (and IMAP specs say this somewhere) that the unique ID for a message is a catenation of the mailboxname, mailbox UIDValidity, and the message ID. So, if the mailbox is renamed, these "global unique IDs" are not preserved in any case. Thus, requiring to CHANGE the UIDValidity (or, for those servers that keep track of removed mailbox, change UIDVALIDITY if the mailbox with this name already existed and assign "higher" UIDVALIDITY) should NOT (as far as I can see) break any client.
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.
I.e. I *hope* that there is no client that relies on the fact that UIDVALIDITY and UIDs are preserved during RENAME. If we specify that the UIDVALIDITY MUST be changed, it should not cause any problem for any client (again - as far as I can see). Yes, this will make some servers (including ours) non-compliant. So, what the heck? Let's make them compliant.
The problem is with "good clients". Those that rely only on the name-validity-UID trio. And in the RARE situation of mailbox renaming resulting in substitution of a just deleted mailbox with a mailbox having the SAME UIDVALIDITY those "good", compliant clients have problems. They have them NOW. Some side - either the server one or the client one MUST be modified. But the client part cannot be modified - clients cannot learn that the mailbox has been "replaced". So, the server side must be modified. And the specs must outline - how.
Let me say it again, the situation with RENAME producing these problems for clients is RARE. There is definitely no rush to fix the specs right now.
My feeling is that RENAME should be removed from the protocol in a futureI wouldn't be so pessimistic. It's just one small issue being overlooked there, and I seriously doubt it caused any problem on any IMAP installation up to this date. So, a small change it specs done today or in the next round
version of the specification, on the grounds that it is fundamentally broken.
of IMAP spec revision is all that's needed to fix the situation.
I can only say that IMHO there is no call for an urgent action, that's it. The protocol modification process is beyond the scope of my expertise.However, doing so will be controversial, and I think that we should defer action.
Your guess at how UW imapd works in this case is incorrect. UW imapd willCool. Then I'd recommend to document it this way, rather then via the "copying" procedure. Again - no rush.
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:Mark, I understand this, and my intention is NOT to make the "dual-use" mailboxes mandatory. The problem is that in one part of protocol the meaning of "name/" was specified. And this has opened the Pandora's box.
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.
First, it IMPLIES, that a mailbox name "member" cannot be empty. It's an obvious requirement (I havenot checked, but I guess that the syntax rule do not allow it). But: since the "path separators" are PART of protocols, the protocol should specify the meaning of:
"/name"
and
"name/"
names. Even if it says that it is implementation-specific, it's OK. But I'd prefer to see this as an addition to the section 5.1.
First, it takes about "exporting". Are "LIST" command results considered
to be "exports"?
Second. If the protocol permits CREATE aaa/, then what will the LIST command
return? Yes, we all know that it will return (\NOSELECT) "aaa", not "aaa/" but it's not specified anywhere in the protocol.
My suggestion is to add the clause that the mailbox name consists of one or more non-empty mailbox "path part" names (the term should definitely be changed to something better), separated with a single-character hierarchical separator. This thing alone will make "/aa" and "aaa/" names ILLEGAL.
Then, let's define the "mailbox folder name" that consists of a mailbox name with a trailing hierarchical separator. The standard explicitly allows the use of "mailbox folder name" in the CREATE command. The standard explicitly phohibtis "mailbox folder name"s in the SELECT and EXAMINE commands (by just NOT touching their definitions that allow "mailbox name" only). The standard says that SOME implementation MAY allow the use of "mailbox folder name" in the RENAME and DELETE commands, and the semantics is [implementation-specific | <specify the semantics here>].
BTW, it would be nice to specify that
RENAME "a" "a/b"
is illegal. Most of implementations rely on the OS to catch this. but some OSes (let's not point fingers here :-) do not catch that, and the servers return "OK". The mailbox files are lost -for the server, and, often, for the OS, too. Some other OSes even get into a loop.
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 issuesPlease see above. There is no perfect thing under the moon (YMMV). And polishing the protocol specs (especially specs of a protocol as complex as IMAP) can be endless. There should be milestones, and I do not see that all things that I've pointed to are too critical to delay the release of the existing version of the protocol that has much more critical changes/clarifications.
justify any further delay of the RFC 2060 replacement.
-- Mark --
Sincerely, Vladimir
