On Fri, 19 Sep 2003, Peter Stuge wrote: >Shouldn't they be considered related when it's a single folder on disk?
If a client subscribes to Inbox, which it is free to do at any time with any IMAP server, then LSUB should display it as is: 1 SUBSCRIBE Inbox 1 OK SUBSCRIBE completed 2 LSUB "" "*" * LSUB (\Unmarked) "/" "Inbox" 2 OK LSUB completed Now the LIST response is still as it is: 3 LIST "" "*" * LIST (\Unmarked) "/" "INBOX" 3 OK LIST completed Some clients, for example Outlook, use "Inbox" instead of "INBOX", which they are completely free to do, because INBOX is a case insensitive name. In this case, if Binc used the canonical version, LSUB would return "INBOX". Converting Inbox to INBOX is not necessary for the server, and I have experienced that Outlook 98 did not register that INBOX was indeed subscribed to, from the LSUB response. The first versions of Binc did both validate the mailbox and canonicalize the name. The client asked for one thing, the server did another. Semantically they are the same, but since the server has no reason for doing this conversion, it shouldn't. And since it's perfectly good IMAP, this is the way Binc will continue to function (no conversion). If, however, a client that speaks perfectly good IMAP runs into a case where this type of behavior is not good, then it's time to reconsider. Until now, I have seen no such behavior. Outlook crashing because there's a slash in the LSUB response - I don't know how it got there and I'd like to find out, but that's a serious client bug and Binc has no workarounds for client bugs. >I.e. if the client believes that a folder is called "/folder" and subscribes >to it, shouldn't Binc (after canonicalizing interally) play along and also >show the folder named the same way? I realize this isn't very clean, but I >understand why clients become confused when they ask for one thing and >receive another. (Because Binc canonicalizes in one place, but not the >other.) It rather goes the other way around. If the client subscribes to "/folder", then it must have heard of "/folder" from an earlier LIST response. If Binc says there's a mailbox called "folder" and the client subscribes to "/folder", then that's what the client expects to see in the LSUB response. And this is no problem today. The client can COPY, SELECT, APPEND and so on, to "/folder", and it works fine. The fact that Binc internally knows that "/folder" is the same as "folder" and "folder/" and "folder///" and "/folder/" is something I'd take for granted. But Binc should not, as 'ls' should not, manipulate its output based on what it thinks the client expects to see. Andy :-) -- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."
