On Fri, 19 Sep 2003, Henry Baragar wrote:
>I would like to take back my "OK" and "That makes sense", since I am
>longer sure that it makes sense. Why is it legitimate for bincIMAP to
>strip leading and trailing delimiters, but not an IMAP client? Should not
I do not follow you here - Binc treats /folder, folder and folder/ the
same. Binc does not really care what people subscribe to today. It's all
okay. You can subscribe to "/folder" if you like, but if you then disallow
people to subscribe to folders with a "/" in them, then that's a bug in
your client.
If Outlook subscribed to "/folder" when the path was reported by Binc to
be "folder", then that's a buglet in Outlook. But if Binc actually
reported a mailbox called "/folder", then that's a buglet in Binc. Binc
should report the folders with relative paths.
For Outlook to select /INBOX, /Inbox or /folder is perfectly allowed.
So an attempt to answer your question - Binc does not strip any leading
nor trailing delimiters for SUBSCRIBE or UNSUBSCRIBE. It does not for
LSUB, and it doesn't for LIST. Internally, Binc may have to strip the
delimiters to map the input name to a file name, but that's nothing the
client ever sees.
>a "LIST" command include a "/folder" (not "folder" as is the case now in
>bincIMAP) if "/folder" is recorded in the subscribed file? The Unix folks
No, LIST output and the contents of the subscribed file are not related in
this sense. If I subscribe to "thisfolderdoesnotexist" when it doesn't
exist, then it doesn't make sense for Binc to display it in LIST, which
lists the depository's actual contents.
>learned long ago that allowing a filename to include a directory delimiter
>could lead to some bad situations.
>Mind you, I don't know how you reconcile this with allowing "//" in the
>middle of a folder path. Once again, some clients don't allow you to
The slash character is neither allowed in IMAPdir or Maildir++. If Binc
allows "//" in the folder path then this is a bug in Binc.
>create such a folder path, while allowing you to subscribe. Outlook
>crashes again in this situation.
>All of this is a manifestation of an incomplete IMAP specification, isn't
>it?
The IMAP specification was written to accompany so many different types of
backends that the end result is very vague. There are in my opinion too
many SHOULD and too few MUST, but I still understand the historical reason
for these boundary cases.
No client should ever crash no matter what the server says.
Andy - curious to what caused the "/folder" item to appear in the
subscribed file. :-)
--
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."
