[Imap-protocol] [noob] multiple fetch responses for the same
mrc+imap at panda.com
Mon Nov 14 08:36:34 PST 2011
On Mon, 14 Nov 2011, Dave Cridland wrote:
> 1) Sending everything in one response, but not having UID first.
> * 42 FETCH (RFC822.SIZE 12345 UID 100)
> This is entirely legitimate, and trips up some clients.
Such clients deserve to be tripped up.
> 2) Sending as Mark's example, but reversed:
> * 42 FETCH (RFC822.SIZE 12345)
> * 42 FETCH (UID 100 ENVELOPE (...))
> This will trip up some clients; but in practise the RFC822.SIZE
> response will simply be discarded. Still, this is particularly
> pathological anyway.
It is pathological if RFC822.SIZE was not requested by the UID FETCH. It
is forbidden by the statement that I quoted in RFC 3501.
> In pragmatic terms, if I were doing a revision of IMAP, I'd have
> these as MUST NOT send, SHOULD accept.
That statement in RFC 3501 was added because certain individuals
threatened to poo their diapers otherwise. It has caused more problems
than it solved. It helped create a fantasy that message sequence numbers
can be ignored. That is not the IMAP model, and a great deal of IMAP's
functionality is lost by doing so. If you really want that, use HTTP.
UID is not an access key. It is a message property. In the examples above,
RFC822.SIZE 12345 and UID 100 are both properties of message 42.
RFC822.SIZE 12345 is not a property of UID 100.
Now, it may be useful to determine that the message with property UID 100
also has the property RFC822.SIZE 12345. But that only happens through the
common access key of message 42.
-- Mark --
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
More information about the Imap-protocol