[Imap-protocol] [noob] multiple fetch responses for the same
dave at cridland.net
Mon Nov 14 08:48:35 PST 2011
On Mon Nov 14 16:36:34 2011, Mark Crispin wrote:
> 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.
I don't disagree... But I'm also pragmatic enough to consider that
insufficient motivation to avoid tripping them up if practical.
>> 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.
Well, it's just plain wrong if it's been requested, and it's weird if
it hasn't been.
> UID is not an access key. It is a message property. In the examples
> 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.
Again, I don't disagree - even if internally in Polymer, the UID *is*
the primary key.
But it seems a relatively simple way of improving interoperability
without actively causing any worse problems.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Imap-protocol