On Tue, 17 Jun 2003 15:41:45 -0700 (Pacific Daylight Time) Mark Crispin <[EMAIL PROTECTED]> wrote:
On Tue, 17 Jun 2003, Vladimir A. Butenko wrote:
Hmm. This is yet another thing that is implied from the syntax (note the definition of "mailbox". 5.1 should probably take some position as to whether a hierarchical element with the name INBOX complies to the same rules as INBOX by itself, or if that is server-dependent. I prefer the latter since this preserves the status quo, but this should be stated explicitly.
I have nothing against that.
> > as an "other user" namespace via RFC 2342, it suggests that >~crispin/INBOX
> > and ~crispin/InBoX should be the same thing.
> Nope. It does not say this explictly, so it does not suggest this :-)
The term "suggest" is often used for something that is not stated explicitly, but can be implied. Ideally we should have no such "suggestions".
"Miss X was seen near Mr.Y house around midnight". For me this phrase says
only what it says, though Mrs. Y would say that it certainly suggests certain things.
I do not see how the fact that the prefix ~cripin gives access to user crispin
account mailboxes suggests that ~crispin/INBOX and ~crispin/InBoX is the same thing, because we do not have anything about semantics of *mailbox names*, all we have is a clause in the IMAP *protocol* specs and all it says is
that the string "INBOX" used in certain commands is case-insenstive, and it says nothing about strings like ABC/INBOX neither about ~crispin/INBOX.
More. If we take CommuniGate Pro as a sample, the user can create "mailbox alias" "Mark" pointing to ~crispin or to [EMAIL PROTECTED], so Mark/INBOX will be the same as ~crispin/INBOX. While Bob/INBOX is a regular sub-mailbox of the local mailbox "BOB" in this account.
The point is that you choose to treat the name "INBOX" in a special way in the very first version of the IMAP protocol - for obvious reasons. But those reasons have nothing to do with the IMAP *protocol*, they are part of the mailbox storage semantics (something like "each account has a special mailbox INBOX in it, and whenever you access it, using whatever name path, this name is case-insensitive).
So, none of those RFCs (that are actually protocol definitions) imply that "INBOX" in ~crispin/INBOX is case sensitive. But if you *know* certain things about the reasons for the INBOX name being special (as Mrs.Y knows certains things about Ms.Y habbits and Miss X attitiude), you would say that those RFCs do suggest certain things.
> CommuniGate Pro paranoiacly uses the "canonizeInbox()" function to >convert
> all those InBoXes on the top of account mailbox hierarchy to "INBOX" in >all
> situations.
That's certainly within its right.
> On the other hand, it may create problems for all those clients that >allow
> users to type in mailbox names (rather than select them from a list) - >they
> would have to do the conversion themselves.
How's that?
Try to hack your pine client, so whenever it sees the word "INBOX" in the mailbox name, it changes it into InBox, and try to play with it accessing that mailbox in various ways, preferable - using a server that allows you to create submailboxs in INBOX. I bet you'll see your mailbox starting to duplicate.
Let's take a look at the server that treats INBOX/abc and InBox/abc as different mailboxes.
So (protocol is simplified) C: LIST "" "*" S: * LIST INBOX S: OK C: Create InBOX/abc S: OK C: LIST "" "*" S: * LIST INBOX S: * LIST (\NoSelect) InBoX (it MUST create a surrounding folder) S: * LIST InBox/abc S: OK C: Delete InBox/abc S: OK C: Delete InBox S: NO cannot remove INBOX
We are stuck with that "InBox" mailbox "folder" that we now cannot access, cannot rename and cannot delete.
So, we would say that the client would have to take care of this, checking that "InboX/abc" constructs are converted to INBOX/abc
And if we switch to names like ~crispin/InBoX, we will create mess even quicker.
The main point here is: if we say that InBoX/something is not the same as INBOX/something, then we can create the folder "InBoX" which is different from INBOX, and it cannot be accessed, renamed, or removed.
As a workaround, we could say that removing INBOX would remove all those InBoX folders, but the IMAP does not allow us to remove INBOX:
--
delete = "DELETE" SP mailbox
; Use of INBOX gives a NO error
--
or that Rename INBOX would rename them, too - but:
If the server implementation supports
inferior hierarchical names of INBOX, these are unaffected by a
rename of INBOX.and even if we remove this requirement, still we are in trouble, as we can have:
INBOX
InBox/
iNbox/
and "rename INBOX OLDBOX" will not be able to rename them all into OLDBOX and OLDBOX/
So, if the server does not treat the LOGICAL object "INBOX" in a special manner (case-insenstive), wherever that object is used, we run into a trouble - unless we tall all client developers to take care of these situations themselves.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Sincerely, Vladimir
