MBOX-Line: From tss at iki.fi  Wed Jan  9 20:36:32 2008
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:41 2018
Subject: [Imap-protocol] Question on FETCH example in RFC3501
In-Reply-To: <Pine.BSO.4.64.0801092110230.31840@vanye.mho.net>
References: <b6f3249e0801091938m12cbccd6j4fff9f406cf0fee1@mail.gmail.com>
	<alpine.WNT.1.00.0801091945320.3080@Tomobiki-Cho.CAC.Washignton.EDU>
	<b6f3249e0801092004x584dac51t2156511e43b7a7d6@mail.gmail.com>
	<Pine.BSO.4.64.0801092110230.31840@vanye.mho.net>
Message-ID: <1199939792.8850.111.camel@hurina>

On Wed, 2008-01-09 at 21:23 -0700, Philip Guenther wrote:
> On Thu, 10 Jan 2008, Liam Clarke wrote:
> > Thanks for that - my vague fear is that a poorly behaved server could
> > mix responses to one request with responses for another, which
> > probably betrays my lack of experience with IMAP servers.
> 
> It's not 100% clear to me what you mean by "mix responses to one requests 
> with responses for another".  Can a server send back FETCH responses for 
> messages that you never asked about?  Yes!  Can it send back FETCH data 
> items that you never asked about?  Yes!  Indeed, those both commonly occur 
> for flags.

Also if client sends two commands, the server may mix them:

1 fetch 1:2 flags
2 fetch 1:2 uid
* 1 fetch (flags (\seen))
* 1 fetch (uid 100)
* 2 fetch (flags ())
* 2 fetch (uid 101)
2 ok
1 ok

Although I'm not sure if this is allowed:

1 fetch 1:2 flags
2 fetch 1:2 uid
* 1 fetch (flags (\seen) uid 100)
* 2 fetch (flags () uid 101)
2 ok
1 ok

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080110/ec9d4a37/attachment.sig>
