MBOX-Line: From ingo.schurr at schlund.de  Tue Apr 11 01:26:34 2006
To: imap-protocol@u.washington.edu
From: Ingo Schurr <ingo.schurr@schlund.de>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] Re: LIST Clarification
In-Reply-To: <Pine.WNT.4.65.0604101441160.4904@Tomobiki-Cho.CAC.Washington.EDU>
References: <443A7A2D.2070708@consilient.com> <web-35034698@mail.stalker.com>
	<Pine.OSX.4.64.0604101053530.2906@pangtzu.panda.com>
	<web-35035906@mail.stalker.com>
	<Pine.WNT.4.65.0604101441160.4904@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <20060411082634.GB23615@fone>

Hi all,

> >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.

This might be implementation-dependent, but IMHO any implementation
choosing to see 4 mailboxes in the example above will create some
problems.

RFC3501 says:
      If the server's hierarchy separator character appears elsewhere in
      the name, the server SHOULD create any superior hierarchical names
      that are needed for the CREATE command to be successfully
      completed.  In other words, an attempt to create "foo/bar/zap" on
      a server in which "/" is the hierarchy separator character SHOULD
      create foo/ and foo/bar/ if they do not already exist.

That is, creating "InBox/mailBOX" SHOULD create "InBox". If the
implementation chooses to not identify "InBox/mailBOX" with
"INBOX/mailBOX", it 
  o either does ignore this paragraph 
  o or it will at creation time of this folder also create "InBox". 

In the latter case, how would a client access InBox, even worse,
delete InBox?

After playing around with this for a while, I for myself decided, that
the only way of implementing the INBOX magig without running into all
kinds of nightmares is to stick to the upper-case variant. I.e., not
identifying "InBox/foo" with "INBOX/foo" is crying out loud for trouble.

Therefore I strongly vote for clarifying this case in the RFC. Not the
_word_ INBOX should be special, but the hierarchical name.

I agree that protocoll-wise this restriction is not needed and that
it's up to the implementation to make the desicion. But I belive there
are only two feasible solutions (being case-insensitive or having only
one _hierarchical_ name matching [Ii][Nn][Bb][Oo][Xx]) and pinning
this down in the RFC would save some trouble.

Not this discussion, though, so yes, I'm a bit off topic.

Best regards,
Ingo

