(Btw. It took me a little time to read this. There seems to be a bug in the program that encoded the word na�ve: It generated "esc $ B o esc ( B", which is not permitted according to RFC1468, "o" being an odd number of bytes. That tripped up my mail reader - the rest of the message was unreadable. I had to dig around a little before I found out what the problem was.)
Mark Crispin writes:
Great lengths? My na�ve impression is rather the opposite - it presents a single, fairly simple view.
I doubt that anyone who reads the rules about hierarchy and LIST would call it "simple."
I have, and I do call it "fairly simple". It would, IMO, be unfair to expect much simpler rules.
There are many people who think IMAP is hideously complex; I'm not one of them. The task is complex, so IMAP cannot escape a certain complexity. Solving the task takes time, so a number of mistakes will be made, which also adds some complexity. (Above and beyond that inescapable minimum,) I do think IMAP is about as simple as one can fairly expect.
You just proved my point. A client has to deal with a great deal of heterogenuity in the server's mail store.
I don't see that I did. I do see that we have a misunderstanding - I didn't mean that IMAP is as simple as, say, the protocol for TCP port 17 (served by /usr/games/fortune), and I think we can agree about that.
IMAP does tell the server the following:...
I'd quarrel about some of them, but it's more sidetracking.
Hierarchies can be "hard" (such as UW imapd's export of the UNIX filesystem) or "soft" (such as Cyrus).
And a client doesn't need to tell the difference. Lovely.
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".
A \NoSelect name with no children is certainly "never of no use". In fact, it is very useful; you can create names inside it.
That's \noselect \hasnochildren, and I agree that that's useful. \noselect \noinferiors is different: In that, you cannot create names.
A client needs to know about such names. Otherwise, a client must do two RTTs if a \NoSelect with no children foo/ does not show up in foo/%, since the client does not know if an empty response means "foo does not exist" or "foo is empty".
That I don't see. If the client has foo/% configured in, as you mentioned in a different message, why would it even care about foo and the reason for its nonexistence? foo/% is what's configured in, foo/% is what the client cares about.
If you feel that it is unreasonable for LIST to distinguish between
"does not exist" and empty, please tell the developers of UNIX to fix
this bug in ls:
% ls foo
ls: foo: No such file or directory
%
Unix gets it right - it reports all errors in the same way. Not like this magic you seem to be advocating, where there are three kinds of nonexistence, detected in different ways:
1. Object does not exist, but can. 2. Object does not exist, and cannot, because a different object occupies the name. 3. Object does not exist, and cannot, for any other reason.
--Arnt
