68 lines
2.6 KiB
Plaintext
68 lines
2.6 KiB
Plaintext
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>
|