On Tue, 17 Jun 2003, Vladimir A. Butenko wrote: > I have nothing against that - I'd just ask you to add this to the next > edition of IMAP protocol. Something like "interpretation of the word INBOX > when it is a part of a hierarchical name or a part of namespace'd mailbox > name is server-specific".
Hmm. This is yet another thing that is implied from the syntax (note the definition of "mailbox". 5.1 should probably take some position as to whether a hierarchical element with the name INBOX complies to the same rules as INBOX by itself, or if that is server-dependent. I prefer the latter since this preserves the status quo, but this should be stated explicitly. > > > Using the samples in the RFC3501, can one assume that > > > if SELECT ~crispin/INBOX succeeds, then SELECT ~crispin/InBoX will > > > succeed, too and that it will select the same mailbox? > > This is uglier, especially when we consider RFC 2342. If ~ is advertised > > as an "other user" namespace via RFC 2342, it suggests that ~crispin/INBOX > > and ~crispin/InBoX should be the same thing. > Nope. It does not say this explictly, so it does not suggest this :-) The term "suggest" is often used for something that is not stated explicitly, but can be implied. Ideally we should have no such "suggestions". > CommuniGate Pro paranoiacly uses the "canonizeInbox()" function to convert > all those InBoXes on the top of account mailbox hierarchy to "INBOX" in all > situations. That's certainly within its right. > On the other hand, it may create problems for all those clients that allow > users to type in mailbox names (rather than select them from a list) - they > would have to do the conversion themselves. How's that? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
