On Tue, 17 Jun 2003 14:53:28 -0700 (Pacific Daylight Time)
 Mark Crispin <[EMAIL PROTECTED]> wrote:

On your question about case-independence of INBOX, my view is that only
a 5-octet token with first octet "I" or "i", second octet "N" or "n",
third octet "B" or "b", forth octet "O" or "o", and final octet "X" or "x"
is defined as case-independent by the protocol.  All other tokens,
including tokens which contain those five octets as a substring, are
interpreted by the server implementation as it sees fit.

Consequently, as far as I'm concerned, a server which treats INBOX/foo and
inbox/foo as the same mailbox is compliant; but so is one that treats
these as different mailboxes.  Clients can't depend upon either behavior.

"Ouch!  Doctor, it hurts when I do that!"
"So don't do that."
:-)

I have nothing against that - I'd just ask you to add this to the next edition of IMAP protocol. Something like "interpretation of the word INBOX when it is a part of a hierarchical name or a part of namespace'd mailbox name is server-specific".


> Using the samples in the RFC3501, can one assume that
> if SELECT ~crispin/INBOX succeeds, then SELECT ~crispin/InBoX will >succeed,
> too and that it will select the same mailbox?


This is uglier, especially when we consider RFC 2342.  If ~ is advertised
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 :-)

UW imapd is inconsistant.  It doesn't do that INBOX match with the "~"
other user namespace.  However, if the "/"  other user namespace is used,
then UW imapd does treat /crispin/INBOX and /crispin/InBoX as the same.

Sounds like a client can't depend upon that either.

That's why I ask this fact to be added to the specs.


CommuniGate Pro paranoiacly uses the "canonizeInbox()" function to convert all those InBoXes on the top of account mailbox hierarchy to "INBOX" in all situations. But it was not because of some client, but because of the internal structure that assumes that all mailboxes are case-sensitive (unless the file system used dictates case-insensitivity), and some internal routines would fail if InBoX would be used instead of INBOX. But this is an internal thing, so it's OK if other servers do not follow this rule - just tell the client developers that it is implementation-specific.

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. But, gee, it's THEIR (client developers) problem, so we do not care, right? ;-)

-- Mark --

Sincerely, Vladimir

Reply via email to