On Apr 18, 2008, at 8:20 AM, Joel Reicher wrote:
It's indeterminate because any case string matches INBOX, but when
children are involved an exact case is required. INBOX matches
inbox and INBOX and Inbox and iNbOx and iNBOX.
This is why you should never create children of INBOX. It is an
undefined concept.
How is it shadowed?...
* LIST () "/" inbox
* LIST () "/" INBOX
1 OK LIST completed
The shadowing occurs if you attempt to access "inbox". You will
actually access "INBOX".
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?
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.
But I'm likely not understanding something basic.
-Mike
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
