That is an extremely harmful position to take.
Oh?
IMAP does **NOT** (NOT!!!) define the semantics of a mail store in any way. Rather, IMAP is a means to export/import a mail store.
IMAP would seem to define at least two things: there is an MSN, and there is a UID and associated UIDVALIDITY. (Yes, I'm aware that your code sends UIDNOTSTICKY for some mailboxes, but that's not in the standard.)
IMAP goes to great lengths to inform the client about the semantics of the server's particular mail store, so that the client can make intelligent decisions in dealing with it.
Great lengths? My na�ve impression is rather the opposite - it presents a single, fairly simple view. Consider mailbox names. An IMAP server does not tell a client:
1. whether mailbox names are case sensitive 2. what the maximum length of a mailbox name is 3. whether any names are reserved, and if so, which 4. which set of characters are permitted in mailbox names 5. how many mailboxes may be present as children of a single mailbox 6. which particular restriction caused the rejection of a CREATE
What does the server tell the client?
7. which mailboxes exist at the moment 8. sometimes some of the unavailable names (not all, because the server doesn't say whether those names are case-sensitive, and the client can't know whether the list is complete)
Seems simple and pretty consistent to me, except for point 8, which sticks out like a sore thumb.
There is no such thing as an "IMAP mail store." The Cyrus mail store is netnews applied to mail; it is not in any way blessed by IMAP as special or superior over any other. The same holds true for a mail store which exports the UNIX filesystem, or any of a myriad number of other possibilities.
I agree entirely.
A client MUST be able to handle all of these types of mail stores properly, using the tools provided by IMAP. A client MUST be able to deal with a mail store which has \NoSelect names with no children. A client MUST be able to deal with a mail store which has \NoInferiors names.
I agree entirely.
And I think point 8 above is an ugly wart on a clean and consistent design.
The client has to deal with NO on CREATE anyway, so the server should not be wasting network bandwidth and client memory with saying "such-and-such name can never be of use to you in any way".
--Arnt
