On Thu, 11 Dec 2003, Marcel Crasmaru wrote:IMHO the following clarification > A UID is NOT sent in the following cases: > unsolicited FETCH responses should be explicitly stated in the next version of the IMAP specification.
The problem with doing this is that there are many other such rules which should normally fall under the heading of "common sense" that could be added. There are numerous complaints about the specification being bloated; do we really want to add prohibitions against every possible example?
There's a lot of middle ground between nothing and all.
For example, what about a server which sends BODY[] for every message in the mailbox as part of the response for every command (even a NOOP) while in selected state? Common sense would say that this is not done -- does the specification have to forbid it?
That's a simple quality of service issue. The protocol doesn't forbid poor-quality implementations.
Consider a server that advertises IMAP4 and IMAP4rev1. The client is to be IMAP4. Does the server have the right to unilaterally send IMAP4rev1 style partial data (which an IMAP4 client would never request), on the grounds that "everybody should talk IMAP4rev1"?
If the server advertises IMAP4, it has to follow up. Whether "everyone should talk IMAP4rev1" is irrelevant. The server made a promise and that's all.
On the other hand, if neither the server nor its vendor advertises IMAP4 support, the server may send IMAP4rev1 data.
First, it is hard (at least for me) to infer this rule from the current RFC.
Why else would there be a UID message data item?
To make it possible for servers to support both old and new clients, perhaps? Note: Allowing such support doesn't mandate such support.
--Arnt
