MBOX-Line: From dave at cridland.net  Mon Nov 14 01:13:53 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.1111131306210.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>
Message-ID: <29330.1321262033.662442@puncture>

On Sun Nov 13 21:30:49 2011, Mark Crispin wrote:
> On Sun, 13 Nov 2011, Arnt Gulbrandsen wrote:
>> It's safe for flags+rest. but not so safe for e.g. uid+rest:
>> * 42 FETCH (UID 100)
>> * 42 FETCH (RFC822.SIZE 12345)
> 
> Those pair responses is completely compliant. Any client which has  
> the
> slightest problem with it is broken.
> 
> Servers can do this. There are servers that do it.

As a note without conclusion, there are two variations of this which  
are significant when considered as the response to a UID FETCH:

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.

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.

In pragmatic terms, if I were doing a revision of IMAP, I'd have  
these as MUST NOT send, SHOULD accept. (That is, I'd document that  
existing deployed clients choke on such constructs, therefore these  
actively harm interoperability; on the other hand servers exist that  
send such things, and clients ought to be capable to accepting it). I  
know this is nastier than people adhering to the specification in the  
first place, but I think it'd be more practical at this stage.

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

