MBOX-Line: From tss at iki.fi  Mon Mar 12 03:38:55 2007
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] mailbox hierarchy conventions?
In-Reply-To: <19934.1173693223.973130@peirce.dave.cridland.net>
References: <07Mar11.154843pst."57996"@synergy1.parc.xerox.com>
	<alpine.OSX.0.83.0703111704450.20984@pangtzu.panda.com>
	<07Mar11.162448pst."57996"@synergy1.parc.xerox.com>
	<alpine.OSX.0.83.0703111726370.20984@pangtzu.panda.com>
	<1173661726.17598.331.camel@hurina>
	<07Mar11.195659pst."57996"@synergy1.parc.xerox.com>
	<DAA27A54-569E-4175-917A-9C958932B9FF@iki.fi>
	<19934.1173693223.973130@peirce.dave.cridland.net>
Message-ID: <1173695936.17598.340.camel@hurina>

On Mon, 2007-03-12 at 09:53 +0000, Dave Cridland wrote:
> > Hmm. It probably was enough if the UID was in the "* FETCH" line. 
> > At  least if the message body was before UID it didn't like that. 
> > And by  not liking I mean it somehow mixed it up with previous 
> > message,  causing at least the message's size field to be wrong.
> > 
> > Looks like I'm now sending the items also in the requested order,  
> > except message headers and body come last always.
> 
> I've understood the following to be legal, but I suspect it'd cause 
> much breakage:
> 
> C: tag UID FETCH u BODY[1]
> S: * s FETCH BODY [1] {n}
> S: ...
> S: * s FETCH UID u
> S: tag OK

I'm not sure about "FETCH .. (UID BODY[1])", but for "UID FETCH" I think
that's pretty clearly invalid:

      The number after the "*" in an untagged FETCH response is always a
      message sequence number, not a unique identifier, even for a UID
      command response.  However, server implementations MUST implicitly
      include the UID message data item as part of any FETCH response
      caused by a UID command, regardless of whether a UID was specified
      as a message data item to the FETCH.

Anyway what I meant with my "* FETCH line" comment was that I used to do
this:

C: tag FETCH s (UID BODY[])
S: * s FETCH (BODY[] {n}
S: ... UID u)
S: tag OK

And that was breaking clients. I suppose when they saw BODY[] they
wanted to immediately associate it with some UID before reading anything
after the literal.

> I'm pretty sure that sending any implicit UID first, then everything 
> else all on the same FETCH response, is not going to break anyone.

Right. :)
-------------- 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/20070312/64343842/attachment.sig>
