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


