72 lines
2.9 KiB
Plaintext
72 lines
2.9 KiB
Plaintext
MBOX-Line: From blong at google.com Tue Nov 27 14:34:29 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:49 2018
|
|
Subject: [Imap-protocol] Re: Suspend/Restore feature proposal
|
|
In-Reply-To: <20121127124811.Horde.VuMexjqX6lKpL2uX-qPgPw2@bigworm.curecanti.org>
|
|
References: <20121115215854.Horde.zz6B0O0tmt3ylHiEXzXhQQ4@bigworm.curecanti.org>
|
|
<CABa8R6tHP2My0k2LqT1RzHoLQZA+X_jwUMU0cydm2sAwo8f4Fg@mail.gmail.com>
|
|
<20121116143137.Horde.7Kb3aEW5DhM6CnuA2hAx4Q8@bigworm.curecanti.org>
|
|
<e122fa25-9110-4b36-855d-0e7e273c5805@flaska.net>
|
|
<20121121155417.Horde.ZeW7JqTPNxTAI-hTtrAT-Q9@bigworm.curecanti.org>
|
|
<68035860-387d-43a9-8bb7-00744a7868b9@flaska.net>
|
|
<20121126173224.Horde.BbqbGly8D0JG4aqG7fxoMw1@bigworm.curecanti.org>
|
|
<CABa8R6vCJJ_oQqiMW2Ofqu1Se-hm+h8dYx7DN6qDVT4so2mDtg@mail.gmail.com>
|
|
<20121126184814.Horde.pVkfF8iCAZNxKh-rRJmQ2g1@bigworm.curecanti.org>
|
|
<1354010571.12520.140661158658949.22643EF6@webmail.messagingengine.com>
|
|
<20121127124811.Horde.VuMexjqX6lKpL2uX-qPgPw2@bigworm.curecanti.org>
|
|
Message-ID: <CABa8R6u6Z6994d1dSVXV0wMYNSJzmCSJ8Z_H8PhsBay9Ga=4nQ@mail.gmail.com>
|
|
|
|
The shear number of extensions for IMAP is kind of a problem in itself, as
|
|
is the combinatorial complexity that implies.
|
|
|
|
One mechanism to help with that, in terms of the chicken-egg problem, would
|
|
be if CAPABILITY were a two way street, like ID is. I could then see what
|
|
capabilities cilents have implemented to see if its worth implementing them
|
|
on the server.
|
|
|
|
Not going to change CAPABILITY now, though we could standardize an ID
|
|
keyword for that, I suppose.
|
|
|
|
Ie:
|
|
|
|
a ID ("client" "mail.app" "version" "1.2.3" "capability" "LITERAL+
|
|
CONDSTORE ETC")
|
|
|
|
Anyways, I imagine the reason no one did it was what was the client benefit
|
|
of supporting another path when the standard path is supported everywhere.
|
|
|
|
Brandon
|
|
|
|
|
|
On Tue, Nov 27, 2012 at 11:48 AM, Michael M Slusarz
|
|
<slusarz@curecanti.org>wrote:
|
|
|
|
> Quoting Bron Gondwana <brong@fastmail.fm>:
|
|
>
|
|
> On Tue, Nov 27, 2012, at 02:48 AM, Michael M Slusarz wrote:
|
|
>>
|
|
>>> (full
|
|
>>> disclosure: the recent Cyrus break is weird because it sent a BYE and
|
|
>>> terminated instead of a failed command, so that wasn't previously
|
|
>>> scanned for so we weren't catching this until recently. so we're not
|
|
>>> perfect either.).
|
|
>>>
|
|
>>
|
|
>> I'm kinda embarassed about this one! I forgot to put the GUID calculation
|
|
>> call in the APPEND BINARY path, because nothing ever tested it and it
|
|
>> appeared nobody was using it, because we didn't have a single complaint or
|
|
>> failure with it until just a few weeks ago.
|
|
>>
|
|
>
|
|
> There's probably some deeper (sad) IMAP implementation story to be learned
|
|
> here. RFC 3516 was published April 2003, and 9 years later we're the first
|
|
> one to ever use literal8's in an APPEND?
|
|
>
|
|
> michael
|
|
>
|
|
>
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20121127/7c8ece9f/attachment.html>
|