IETF Logo Mail Archive

Re: [imap5] Feature set? - was Re: Designing a new replacement protocol for IMAP

Brandon Long <blong@google.com> Fri, 24 February 2012 00:09 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 1F15721F866E for <imap5@ietfa.amsl.com>; Thu, 23 Feb 2012 16:09:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.892
X-Spam-Level:
X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[AWL=0.086, 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 qC-ZnvF11Et6 for <imap5@ietfa.amsl.com>; Thu, 23 Feb 2012 16:09:46 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 363FB21F8581 for <imap5@ietf.org>; Thu, 23 Feb 2012 16:09:46 -0800 (PST)
Received: by qcsq13 with SMTP id q13so204939qcs.31 for <imap5@ietf.org>; Thu, 23 Feb 2012 16:09:45 -0800 (PST)
Received-SPF: pass (google.com: domain of blong@google.com designates 10.229.111.165 as permitted sender) client-ip=10.229.111.165;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of blong@google.com designates 10.229.111.165 as permitted sender) smtp.mail=blong@google.com; dkim=pass header.i=blong@google.com
Received: from mr.google.com ([10.229.111.165]) by 10.229.111.165 with SMTP id s37mr2669747qcp.80.1330042185850 (num_hops = 1); Thu, 23 Feb 2012 16:09:45 -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:x-system-of-record; bh=R0hop3jr/7zhib6lHr3KmvObRI5yRi8TZfrJXaB/Cp0=; b=xjc9/D+Q1aERs1WAgOsvIwm5j3hwxwZGKeaon+PyspW1+l6klsOOSvjU+CKyJs7QCu BMjiuWNOftA0CZssT4bzGdgqzJkkebbYt5kIRORcSeT/kluPZtxZG/ljahwF8jypZLRC zkblK+0d/RN8HWisqOmMtcaWqICFu0pUmtWNE=
Received: by 10.229.111.165 with SMTP id s37mr2291806qcp.80.1330042185755; Thu, 23 Feb 2012 16:09:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.111.165 with SMTP id s37mr2291797qcp.80.1330042185596; Thu, 23 Feb 2012 16:09:45 -0800 (PST)
Received: by 10.229.216.201 with HTTP; Thu, 23 Feb 2012 16:09:45 -0800 (PST)
In-Reply-To: <16456.1330038954.623322@puncture>
References: <3077.1329391344.173214@puncture> <4F3CEB35.9080200@qbik.com> <1329394296.953.140661037317197@webmail.messagingengine.com> <4F3CFD35.10501@qbik.com> <alpine.LSU.2.00.1202161626400.30682@hermes-2.csi.cam.ac.uk> <4F3D6E57.8010301@qbik.com> <alpine.LSU.2.00.1202171127330.30682@hermes-2.csi.cam.ac.uk> <4F3F4F8F.3040601@qbik.com> <1329550573.30138.140661038121885@webmail.messagingengine.com> <alpine.LSU.2.00.1202191832430.12769@hermes-2.csi.cam.ac.uk> <20120219192604.GA11323@launde.brong.net> <alpine.LSU.2.00.1202201048480.31357@hermes-2.csi.cam.ac.uk> <4F465269.1040901@flaska.net> <4F465EBC.7090206@att.com> <16456.1330038954.623322@puncture>
Date: Thu, 23 Feb 2012 16:09:45 -0800
Message-ID: <CABa8R6vqMQYRJp-3zpA-GwzKfGTToXTbiGFssHF+375qdRcmYw@mail.gmail.com>
From: Brandon Long <blong@google.com>
To: Dave Cridland <dave@cridland.net>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmf4yodB4FTTUK36/08dWg9IErH3mNsiPnIOdwquslYdGYU+BXZzklMm7/m6xJEpI9Hs+MaPcBGHJsEj0T+NyJfh+V39XTAtVUMivqy+opNnr/MuSIVcU0/fWmsBDGUmrAEx+AE
Cc: "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>
Subject: Re: [imap5] Feature set? - was Re: 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: Fri, 24 Feb 2012 00:09:47 -0000

On Thu, Feb 23, 2012 at 3:15 PM, Dave Cridland <dave@cridland.net> wrote:
> On Thu Feb 23 15:43:56 2012, Tony Hansen wrote:
>>
>> Totally off topic: I wish I knew how to get them to fix that.
>
>
> And now you know...

I'm sure there are other corner cases as well, just looking through
the code there are all sorts of caveats and such to work around bugs
generated by specific clients.

To bring this back on-topic, if the goal is simpler, is it simpler for
the server to implement parsing or to punt that to the client?

This specific case could have been solved by the client implementing a
viewer for rfc822, though obviously its heavier weight if the embedded
message has many other levels.

OTOH, its simpler on clients if they don't have to implement all of
the work-arounds for broken mail that we do.

Or maybe a much simpler flattened structure for messages as parsed by
the server and you can download the whole thing to parse the original
if you want higher fidelity.

Of course, if we aren't parsing the messages on the server, we have to
ask why we're implementing IMAP5 and not POP4 (still not sure if that
statement will make Marc laugh or cringe).

Brandon

v2.23.0 | Report a Bug | By Email