68 lines
2.5 KiB
Plaintext
68 lines
2.5 KiB
Plaintext
MBOX-Line: From dave at cridland.net Mon Mar 12 02:53:43 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Dave Cridland <dave@cridland.net>
|
|
Date: Fri Jun 8 12:34:38 2018
|
|
Subject: [Imap-protocol] mailbox hierarchy conventions?
|
|
In-Reply-To: <DAA27A54-569E-4175-917A-9C958932B9FF@iki.fi>
|
|
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>
|
|
Message-ID: <19934.1173693223.973130@peirce.dave.cridland.net>
|
|
|
|
On Mon Mar 12 06:14:24 2007, Timo Sirainen wrote:
|
|
> On 12.3.2007, at 5.56, Bill Janssen wrote:
|
|
>
|
|
>> Thanks, that's a nice list.
|
|
>>
|
|
>>> One workaround that there used to be was that several clients
|
|
>>> (kmail,
|
|
>>> Thunderbird at least) didn't like if UID field wasn't the first
|
|
>>> field in
|
|
>>> FETCH replies. After a while I gave up and just put it back to
|
|
>>> begin
|
|
>>> first.
|
|
>>
|
|
>> Didn't like it, how? I'm sending it last (on a UID FETCH if it's
|
|
>> not
|
|
>> explicitly specified), and Thunderbird seems happy. I send the
|
|
>> specified
|
|
>> items on a FETCH in the order they were requested.
|
|
>
|
|
> 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
|
|
|
|
Certainly in my client's case I'm not sure how well the code-path
|
|
that copes with the first will work. It'd handle it if it happened to
|
|
know which UID message number s had already, but otherwise I'm really
|
|
not sure. Mind you, I'm also not sure that my client could ever get a
|
|
body part without knowing the UID.
|
|
|
|
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.
|
|
|
|
Dave.
|
|
--
|
|
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
|
|
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
|
|
- http://dave.cridland.net/
|
|
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
|
|
|