On Tue, 16 Sep 2003, Arnt Gulbrandsen wrote:>>> Agreed. What is being discussed is whether INBOX/ must also be returned.
>> Well, is there anything that says it must? I find no wording to that effect.
> This is what Rob has been saying all along.
Yes. IMHO, Rob is right.
Then that the concensus is that IMAP should be less useful and ambiguous.
If not, then please think about the consequences of what you are saying vis-a-vis a mail store in which a \NoSelect name may exist without children.
If a store can contain entities that are both \noselect and \noinferior, then IMHO it follows that said store is not (exclusively) a mail store.
So, why should the IMAP server be telling the IMAP client about entities that have nothing to do with mail? If the IMAP server knows that /pro/con is \noselect \noinferiors, the IMAP server knows enough to hide that entire thing.
Yes, that would mean magic errors like this:
C: a CREATE /pro/con S: a NO mailbox name unavailable
But then that's similar to these errors, all of which may exist today:
C: a CREATE /pro/con S: a NO /pro already has 32767 subdirectories
C: a CREATE /pro/com S: a NO file system out of inodes
C: a CREATE /pro/con S: a NO CON: is a device
I think you were right when you wrote RFC3501.
--Arnt
