72 lines
3.4 KiB
Plaintext
72 lines
3.4 KiB
Plaintext
MBOX-Line: From brong at fastmail.fm Mon Oct 31 16:11:49 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bron Gondwana <brong@fastmail.fm>
|
|
Date: Fri Jun 8 12:34:47 2018
|
|
Subject: [Imap-protocol] BODY.PEEK[section]<origin.size> FETCH response
|
|
In-Reply-To: <alpine.OSX.2.00.1110311532190.9034@hsinghsing.panda.com>
|
|
References: <8F0DA5FA-FB07-4AFA-9C58-8F0927998343@ghoti.org><alpine.OSX.2.00.1110301823210.9034@hsinghsing.panda.com><CABa8R6uyrHJ6AqQoGfMcLztG-zovaVK4FEFep8ibpYc2-6b7ig@mail.gmail.com><alpine.OSX.2.00.1110311352000.9034@hsinghsing.panda.com><CABa8R6ugaAADsrvaS1Nnau5bi7k9728b+x00NcG1Nbxfk9xwsA@mail.gmail.com><75E51A44-91E4-48D1-BA82-789C82583ABC@iki.fi>
|
|
<alpine.OSX.2.00.1110311532190.9034@hsinghsing.panda.com>
|
|
Message-ID: <1320102709.31835.140660992941501@webmail.messagingengine.com>
|
|
|
|
On Monday, October 31, 2011 3:49 PM, "Mark Crispin" <mrc+imap@panda.com> wrote:
|
|
> On Tue, 1 Nov 2011, Timo Sirainen wrote:
|
|
> > I haven't tested GMail with imaptest for a while now (few years?), but I
|
|
> > don't think the bugs it reports are about the mailbox model, or anything
|
|
> > else that can't be fixed somewhat easily.
|
|
>
|
|
> Sigh, Timo, you had to give away the secret. I was hoping to bait this
|
|
> trap a bit longer.
|
|
|
|
And that's why I think you're a wanker - because I don't want to bait anybody.
|
|
I want a better mail experience for users, and I suspect Brendan does too,
|
|
within the constraints he's working with.
|
|
|
|
> Since the cat is out of the bag: there is nothing in the mailbox model
|
|
> which does not comply with IMAP, or which can not be presented in an
|
|
> IMAP-compliant manner. IMAP is silent on the mailbox model for a reason.
|
|
|
|
It's silent in the way that XSLT is silent on the implementation language.
|
|
Not explicitly mentioned, but with heaps of design decisions which show
|
|
a clear background with
|
|
|
|
> The problems with Gmail's server are, by and large, flat out bugs. There
|
|
> are a few design faults; but they are completely unnecessary and could be
|
|
> amended while keeping the Gmail model.
|
|
|
|
I suspect we could, with a bit of productive discussion, get Brendan to
|
|
fix some of these. It's gone midnight here, but I'm going to see if I
|
|
can dig out some details on how Cyrus handles literal coding and talk to
|
|
Brendan directly about how hard that would be to add to gmail and fix
|
|
the 8bit quoted values issue. Particularly if we can do it without
|
|
melting any more polar caps than required.
|
|
|
|
> > I guess the one test I could
|
|
> > remove is the search for substrings, since even Mark doesn't think it's
|
|
> > worth the trouble nowadays.
|
|
>
|
|
> FWIW, I always considered the implementation of string searching to be
|
|
> implementation dependent. The only requirement was that simple
|
|
> case-independent substring is recognized as compliant. I never intended
|
|
> that a server be forbidden from implementing a smarter search (e.g.,
|
|
> fuzzy) that returns more matching messages.
|
|
|
|
Interesting. That makes me feel a bit more comfortable about ignoring the
|
|
full RFC 5051 i;unicode-casemap on searches, and only using it for sort.
|
|
|
|
Thanks.
|
|
|
|
I was leaning that way anyway, but it means I can make the Cyrus
|
|
implementation fully 5051 complient without user visible changes.
|
|
|
|
I've already switched to storing the parsed UTF-8 values into the cache file
|
|
rather than search-normalised forms, so I can choose the sort algorithm to
|
|
apply later. This will come in handy if we try to put other collation
|
|
algorithm support in later.
|
|
|
|
Bron.
|
|
--
|
|
Bron Gondwana
|
|
brong@fastmail.fm
|
|
|
|
|