On Fri, 18 Apr 2008, Michael Cashwell wrote:
I must be being dense here, but isn't having an inferior to INBOX named identically but with only case differences a very special case? Wouldn't it make more sense to prohibit only that similar to how a case-preserving but case-insensitive file system won't let you create "foo" where "Foo" already exists?
The problem is not with the children, but rather the parent. You are assuming, falsely, that there is something magic that will take "inbox/foo" and know that it really must be "INBOX/foo" even though there is nothing in the IMAP specification (or most UNIX filesystems) that says so.
Even if imapd attempted to impose such magic, there is nothing that it can do about filesystem operations outside of IMAP. That is the underlying cause of the problem.
Having inferiors to INBOX called anything else would not be ambiguous, right? To prohibit ALL inferiors on INBOX just to avoid this one instance of case-ambiguity seems like overkill.
That's like saying it is overkill to have laws against drunk driving, because you can drive safely while drunk. Even if that is true in your particular case, it is not true in the general case.
It is never a good idea to create greater complexity to overcome the problems brought about by adding earlier complexity.
IMAP was never intended to allow children of INBOX. In fact, IMAP was never intended to allow children of any mailbox. It was a terrible mistake to have allowed dual-use mailboxes in the specification in the first place.
-- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
