Re: [imap5] Designing a new replacement protocol for IMAP

Brandon Long <blong@google.com> Thu, 16 February 2012 00:26 UTC

Return-Path: <blong@google.com>
X-Original-To: imap5@ietfa.amsl.com
Delivered-To: imap5@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB1421E807F for <imap5@ietfa.amsl.com>; Wed, 15 Feb 2012 16:26:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PqbsG4Rgzwa for <imap5@ietfa.amsl.com>; Wed, 15 Feb 2012 16:26:46 -0800 (PST)
Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B58AF21E801D for <imap5@ietf.org>; Wed, 15 Feb 2012 16:26:46 -0800 (PST)
Received: by qan41 with SMTP id 41so1751633qan.10 for <imap5@ietf.org>; Wed, 15 Feb 2012 16:26:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=yGosM/7IAHZGzjiVsl4kmatMit3g2EPHExccv9ysLVA=; b=0AbzC8ArbwuzXuAxA7DSRNX1lLMKBIoZlTaKnCpNl3yU0ygGJeP80Lr7dZgRF9J/x1 VsZWgBmYXe2Ohy9WwFBAsAzKd823DalhbuEiXDoYSZ1fYHxoArZlVtrcbHU4F1MGxexv IcmkNX8nQBG82R2l1+TQfvU0O54dCzkNQq/3I=
Received: by 10.229.111.165 with SMTP id s37mr173578qcp.80.1329352004343; Wed, 15 Feb 2012 16:26:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.111.165 with SMTP id s37mr173560qcp.80.1329352004104; Wed, 15 Feb 2012 16:26:44 -0800 (PST)
Received: by 10.229.216.201 with HTTP; Wed, 15 Feb 2012 16:26:43 -0800 (PST)
In-Reply-To: <4F3C2362.2060007@qbik.com>
References: <833EE8EEE88E4ADE5CDDDADB@caldav.corp.apple.com> <4F3835A1.7060804@qbik.com> <B764BD8C8B6047E659EABBE2@caldav.corp.apple.com> <4F397212.1030107@qbik.com> <20120213210805.GB13029@launde.brong.net> <alpine.LSU.2.00.1202151405550.30682@hermes-2.csi.cam.ac.uk> <1329315552.1444.140661036879893@webmail.messagingengine.com> <4F3BBFA4.8010107@isode.com> <1329316981.8310.140661036883625@webmail.messagingengine.com> <66F68487BF0EED4BA7D767E2410F30B3EFF259456A@FRSPX100.fr01.awl.atosorigin.net> <20120215211301.GA16253@launde.brong.net> <4F3C2362.2060007@qbik.com>
Date: Wed, 15 Feb 2012 16:26:43 -0800
Message-ID: <CABa8R6uoG_B1WWe1oHVOJVp-WzFrqCbVQ0pjbtpS7Y2sjROvww@mail.gmail.com>
From: Brandon Long <blong@google.com>
To: Adrien de Croy <adrien@qbik.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmtem1vNDuIZord5dX6QVtkkcUqcjP3AqqS0WFxamGrXn4uC4k0osHL27bMg4EqvStMZyvPxc1lqaiXS+tKIR0KYh1e9XPHh95nkLWmJYhVDj3dPsMcWHY2q4dGvZakrObYVrBh
Cc: "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>
Subject: Re: [imap5] Designing a new replacement protocol for IMAP
X-BeenThere: imap5@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion on drastically slimming-down IMAP." <imap5.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imap5>, <mailto:imap5-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/imap5>
List-Post: <mailto:imap5@ietf.org>
List-Help: <mailto:imap5-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imap5>, <mailto:imap5-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2012 00:26:52 -0000

This is the second time I've heard about concern that proxies would
break access to my mail data over http.

Take those issues out of the loop, use https instead.  That way, the
data's encrypted end-end anyways, which of course it should be.

I know people hate dealing with certs, but I think we're well past the
point at which people want their personal mail traveling unencrypted
from their mailstore to their client.

Brandon

On Wed, Feb 15, 2012 at 1:28 PM, Adrien de Croy <adrien@qbik.com> wrote:
>
> having dealt with support issues relating primarily to HTTP for the last 17
> years, I'd STRONGLY recommend against using anything HTTP based.  The number
> of proxies that break WebDAV makes it problematic alone.
>
> If some clients need HTTP-based access to some IMAP function, they can use a
> gateway.
>
> Then an administrator can choose whether to allow such access.  But clients
> using the protocol that provides it all don't need it.
>
> If you're a system admin, and there's a product you can install where you
> install 1 service, open 1 port and it provides everything you'd go for that
> right?
>
> If we play our cards right, it should be simple for some gateway to provide
> legacy interfaces to the new protocol.
>
> re the discussion about richness of protocol... sure you can do things at a
> lower level.  That typically requires more round-trips to the server though.
>
> unless the things are pipelined..... specifically designed to be, so a
> single meta command is sent as a bunch of micro commands... but therein lie
> a multitude of problems (e.g. enforcing security, synchronisation etc).
>
> Adrien
>
>
>
> On 16/02/2012 10:13 a.m., Bron Gondwana wrote:
>>
>> On Wed, Feb 15, 2012 at 09:59:56PM +0100, Michel Sébastien wrote:
>>>>>
>>>>> On 15/02/2012 14:19, Bron Gondwana wrote:
>>>>>>
>>>>>> On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote:
>>>>>>>
>>>>>>> Is there any reason to keep subscriptions in IMAP 5 ?
>>>>>>
>>>>>> I envisage "subscription" as either an annotation or a "Special Use"
>>>>>> on a folder rather than yet another axis of data.
>>>>>
>>>>> +1.
>>>
>>> Does it works with shared folders ?
>>
>> Sure, it's a private annotation.
>>
>>>> This is not a problem that's unique to email.  There's nothing really
>>>> special about email here unless you make it special.  Sure there's a bunch
>>>> of indexed and optimised ways of viewing that data - sort by trimmed
>>>> subject, encodings, etc.  All of which could be expressed as generic queries
>>>> against the data model with a query optimiser on the far end rather than
>>>> needing a custom syntax for everything...
>>>>
>>> Some others seems to think that webdav could be a candidate :
>>> http://www.webdav.org/other/faq.html#Q26
>>> A new layer on top of webdav, with some keywords registered at IANA. But
>>> I just don't like the trend to use HTTP for everything... despite its
>>> interest here.
>>
>> Yes, webdav is tempting for a few reasons - the downside is
>> a relatively high overhead.
>>
>> BEEP has also been mentioned.  A good advantage of both of
>> these is that you can transport unmodified MIME across them.
>> I'm wary of anything which will require the raw MIME bodies
>> of messages to be encoded across the wire - some sort of
>> length based literal syntax is very valuable.
>>
>> Of course it's hard to love something with examples like this:
>>
>>  S: RPY 0 1 . 221 185
>>
>>  S: Content-Type: application/beep+xml
>>  S:
>>  S:<profile uri='http://iana.org/beep/SASL/CRAM-MD5'>
>>  S:<![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
>>                                                jaS5uZXQ+</blob>]]>
>>  S:</profile>
>>  S: END
>>
>> It makes MIME header encoding look so lightweight in comparison.
>>
>>
>> Still... as I'm regretting learning, compatible is more important
>> than good.  If there exist libraries everywhere which can
>> reliably read and write that, and it's ugly enough that nobody
>> wants to do it themselves, then maybe - just maybe, you'll actually
>> get BETTER complience than if it's a simple enough protocol that
>> people roll almost-correct code by hand.
>>
>> Bron.
>> _______________________________________________
>> imap5 mailing list
>> imap5@ietf.org
>> https://www.ietf.org/mailman/listinfo/imap5
>
>
> --
> Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
> WinGate 7 is released! - http://www.wingate.com/getlatest/
>
> _______________________________________________
> imap5 mailing list
> imap5@ietf.org
> https://www.ietf.org/mailman/listinfo/imap5