On Fri, 21 Feb 2003, Andreas Aardal Hanssen wrote: > If INBOX is truly a namespace only, then selecting INBOX only, not > INBOX.INBOX, does not make sense to me. In Courier-IMAP, INBOX and > INBOX.INBOX are equivalent. How is that for consistency?
That seems consistent to me. If no namespace is given, the personal namespace is assumed. INBOX means the system mailbox. INBOX. is the namespace prefix, and is equivalent to "". So INBOX and INBOX.INBOX *are* the same thing. > 2 LIST "" "INBOX" > * LIST (\Unmarked \HasChildren) "." "INBOX" > 2 OK LIST completed > 2 LIST "" "INBOX.INBOX" > 2 OK LIST completed > 3 CREATE "INBOX.INBOX" > 3 NO Cannot create this folder. > > Ok - that makes sense. > > 3 LIST "" INBOX.INBOX > 3 OK LIST completed > > So it's not there, yet I can select it. > > 4 SELECT "INBOX.INBOX" OK, that, I grant you, is inconsistent. > Those two are the same mailbox, accessed with two different names. Now if > I create a Maildir++ subdirectory called INBOX, that is, Maildir/.INBOX/, > this happens: > > 7 LIST "" "INBOX.INBOX" > * LIST (\HasNoChildren) "." "INBOX.INBOX" OK, that's another bug. Courier should ignore Maildir/.INBOX/. > So Courier-IMAP suddenly advertises this mailbox as selectable. What > happens if I select this new mailbox that suddenly showed up? > > 8 SELECT INBOX.INBOX > * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent) > * OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited > * 2254 EXISTS > * 0 RECENT > * OK [UIDVALIDITY 1045844866] Ok > 8 OK [READ-WRITE] Ok > > Hey - since INBOX and INBOX.INBOX are equivalent in Courier-IMAP, it > _will_ display it in LIST but not allow me to select it. > > 9 STATUS INBOX (MESSAGES) > * STATUS "INBOX" (MESSAGES 2254) > 10 STATUS INBOX.INBOX (MESSAGES) > * STATUS "INBOX.INBOX" (MESSAGES 2254) They look correct to me. > Where's my new mailbox? Why did Courier-IMAP first _not_ advertise > INBOX.INBOX, then when I created it with another client, it _did_ > advertise it, but it won't let me select it. Bugs. > Now I'm curious about this command: > > 11 RENAME INBOX INBOX.INBOX > 11 NO This feature is not yet supported. NO is the correct response, but the reason given is incorrect. You can't rename a folder to an extant folder. This implies that you can't rename a folder to itself either. BAD might be an acceptable response - "arguments invalid". > This is also funny: > > 11 CREATE INBOX.INBOX.INBOX > 11 OK "INBOX.INBOX.INBOX" created. > 12 LIST "" "*" > * LIST (\HasNoChildren) "." "INBOX.INBOX.INBOX" > * LIST (\HasNoChildren) "." "INBOX.qconfirm" > * LIST (\HasNoChildren) "." "INBOX.Trash" > * LIST (\Marked \HasChildren) "." "INBOX" > * LIST (\Noselect \HasChildren) "." "INBOX.INBOX" > 12 OK LIST completed All bad. Isn't "INBOX" a good namespace to have, eh? :-) > This is the sort of brain dead behavior that I will not have in Binc IMAP. That might be difficult, while maintaining at the same time "drop-in" compatibility with Courier. > For now, Binc will only allow submailboxes of INBOX, until we can agree on > a proper way to support root level mailboxes. Might not a better way to be to *disallow* subdirectories of INBOX, until we can agree how to sanely have them? Isn't the ambiguity of "INBOX" the root of all the confusion - in our minds and in the code? -- Charlie Brady
