MBOX-Line: From dave at cridland.net  Mon Nov 14 08:48:35 2011
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] [noob] multiple fetch responses for the same
	message?
In-Reply-To: <alpine.OSX.2.00.1111140822340.38075@hsinghsing.panda.com>
References: <43724F01-C3E3-4039-8919-51E528C56C54@mac.com>
	<1321215266.30428.140660998383617@webmail.messagingengine.com>
	<755EBF71-00B6-4A4A-940A-CA8B5B62B10D@mac.com>
	<4EC02C84.1090209@gulbrandsen.priv.no>
	<alpine.OSX.2.00.1111131306210.38075@hsinghsing.panda.com>
	<29330.1321262033.662442@puncture>
	<alpine.OSX.2.00.1111140822340.38075@hsinghsing.panda.com>
Message-ID: <29330.1321289315.045850@puncture>

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  
> 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.

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.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

