MBOX-Line: From MRC at CAC.Washington.EDU  Mon Apr 10 15:10:08 2006
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] LIST Clarification
In-Reply-To: <web-35035906@mail.stalker.com>
References: <443A7A2D.2070708@consilient.com> <web-35034698@mail.stalker.com>
	<Pine.OSX.4.64.0604101053530.2906@pangtzu.panda.com>
	<web-35035906@mail.stalker.com>
Message-ID: <Pine.WNT.4.65.0604101441160.4904@Tomobiki-Cho.CAC.Washington.EDU>

On Mon, 10 Apr 2006, Vladimir A. Butenko wrote:
> One of the biggest problem with any protocol are "useful exceptions". It has 
> been proven too many times that whereever a problem (or misunderstanding) can 
> emerge, it will emerge.

I agree.

This is where Postel's robustness principle comes in.  Sadly, many people 
misunderstand it to mean that protocol engines should be tolerant of 
syntax errors as opposed to being a razor for dealing with ambiguous 
interpretations.

> If a server happens to use case-insensitive names, and, as a result, all 
> operations (including the pattern match) are case insensitive, then search 
> results can be different when compared to case-sensitive systems.

I forget why we decided to say "uppercase" instead of "case-insensitive" 
for pattern matching with INBOX.  But the wording leaves no doubt that we 
did decide that, and the result is ambiguity in the search results.

> The IMAP protocol does not explicitly specify what the REAL NAME of the 
> "incoming mailbox" is. If it would specify that the name is INBOX, it would 
> eliminate a lot of misunderstanding. Unfortunately, it does not.

Ummm...well...

I consider the difference between "real name" and INBOX to be an 
implementation detail; in the protocol itself, there is no difference.

> The initial request was sent to our support 
> group because the author of the question used "Inbox" as the reference to the 
> incoming mailbox. And while it works fine with all SELECT & Co commands, it 
> worked OK with LIST only because it was used on a case-insensitive platform. 
> Switching to a case-sensitive platform revealed the problem.
> [snip]
> This is exactly the answer we have given: using any name instead of INBOX is 
> a call for trouble.

I agree completely!

> BUT: there is nothing in the IMAP specs that explicitly 
> says so. And many people who do not know (and have no reason to know) about 
> all historical details behind the name "INBOX" in all caps, may conclude that 
> it's OK to use Inbox as that special mailbox name, especially because many UI 
> applications render it this way.

Hmm.  What do other people think?  Should there be a statement in the LIST 
command to this effect?

> The question here is simple:
> if
> a LIST "" "%n%ox"
> should show any name for the incoming mailbox should it
> show INBOX? Or Inbox? Or InBox? Or InBOx?

My personal opinion (NOT "Mr. IMAP Protocol") says that it should always 
return "INBOX", and this is the one true canonical name.

My personal option also says that a LIST pattern of "Inbox" or "%n%ox" 
matches INBOX.

Mr. IMAP Protocol, on the other hand, says that it does not matter what is 
returned; "INBOX" and "InBoX" and "Inbox" are all the same name and that 
the client can make no assumptions based on the case of the pattern when 
it comes to INBOX.

Mr. IMAP Protocol also says that the client can not assume that "Inbox" or 
"%n%ox" will match INBOX.

After Mark and Mr. IMAP Protocol strangle each other, they come out with a 
joint statement of "it's ambiguous that way, so clients shouldn't do it."

> The "special case" of INBOX is a terrible thing, causing many problems in any 
> case, so we should try to be as strict as possible about it, and not add 
> additional "reasonable exceptions".

I don't think that I was adding any "reasonable exceptions".  Rather, I 
was simply trying to apply Postel's robustness principle.  The important 
thing here is for the client to "be conservative" since there is no way to 
guarantee particular server performance.

> Clients should carefully process these names, NOT assuming anything not 
> already specified in the standard.

Agreed.

> More,
> a) what about:
> INBOX/mailbox
> InBox/mailbox
> INBOX/mailBOX
> InBox/mailBOX
> (our interpretation - 1 and 2 are the same mailbox, 3 and 4 are the same 
> mailbox, they all are the same mailbox on a case-insensitive system).

My interpretation:

I agree that they are all the same mailbox on a case-insensitive system.

I don't know how many mailboxes (2 or 4) it may be on a case-sensitive 
system; I think that it is implementation-dependent.  Had I thought about 
it at the time, I would have prohibited INBOX from being a "dual-use" 
name.  I agree that your interpretation is superior.

> b) what about:
> ~user@domain/INBOX
> ~user@domain/INBoX
> ~user@domain/INBOX/Mailbox
> ~user@domain/INBoX/Mailbox
> or whatever notation is used with that server to access "foreign" mailboxes.
> (our interpretation - 1 and 2, 3 and 4 they are the same, the INBOX name is a 
> special name not on the top of the mailbox name hierearchy, but on the top of 
> the hierarchy for a particular "mailbox set" or "account").

In this case, I definitely do not know.  I think that it's implementation 
dependent.  I don't know if "~" showing up in NAMESPACE makes a 
difference.

> Bottom line - we all agree here, I hope:
> always use INBOX as the name of the "incoming mail" mailbox.

Yes!

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

