Re: [imapext] Three kinds of IMAP extensions

Stu Brandt <stuart.brandt@teamaol.com> Mon, 19 October 2015 16:33 UTC

Return-Path: <stuart.brandt@teamaol.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBFF1A89A6 for <imapext@ietfa.amsl.com>; Mon, 19 Oct 2015 09:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC5K3IThvAD5 for <imapext@ietfa.amsl.com>; Mon, 19 Oct 2015 09:33:22 -0700 (PDT)
Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2751A89E9 for <imapext@ietf.org>; Mon, 19 Oct 2015 09:33:22 -0700 (PDT)
Received: by qgbb65 with SMTP id b65so57085100qgb.2 for <imapext@ietf.org>; Mon, 19 Oct 2015 09:33:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=IZ7JEFynROzsgzYx738nFUTbLYKpAh+2fiGWqJHdXt0=; b=jjw+kJtOC1WCMeG2DvHXvDCZXg3cCGqeWuRR/3z0cH/8tSoCDmzHHkibJUCT7yL2A2 EaMAzD9zzZoJcI4iBwKheODvsW96N4VpZgKQKMr9N9YNtS0k/GIHmm7KPhFCUX4bnvOk YXRw4TMSv7IETPjfvpGOZeEBcNNly1DV3fe/ZLa0knBslXpnpemwP64/0SuptQ9kApRl pNNfFzIyHu+M7wPbb+ZcULMuwbuTNBYhU/xanhBBntoqjnF6AMa08/rMx4IY58g/QDJG d6keKCawrcrHbAnDUh2VmVfeMw86PwGhkcyGJyqtINKYs/aL3VdcU5W6lMLnUdJ55Ypw ucfA==
X-Gm-Message-State: ALoCoQkzeREtsZ2eg5ClcUhVRdXqIF0ZP0dAnnCmffvXsO4Wr5ixGY462a5HJyhzYfUSpU7rvSdR
X-Received: by 10.140.147.146 with SMTP id 140mr40054256qht.68.1445272401379; Mon, 19 Oct 2015 09:33:21 -0700 (PDT)
Received: from [10.172.98.17] (h-64-236-208-25.nat.aol.com. [64.236.208.25]) by smtp.gmail.com with ESMTPSA id p39sm14672130qkp.47.2015.10.19.09.33.20 for <imapext@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 09:33:20 -0700 (PDT)
To: imapext@ietf.org
References: <em51cd19ea-21f1-4dcb-b0d4-acc7a9358462@bodybag> <E4F7C2B6-9F78-4519-9D95-1F734B043419@isode.com> <wUSTrGQWU8VmT9w6Ih+AeYoaqXzoJqfF+PUA7F9W5ho=.sha-256@antelope.email>
From: Stu Brandt <stuart.brandt@teamaol.com>
Message-ID: <56251B50.5070800@teamaol.com>
Date: Mon, 19 Oct 2015 12:33:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <wUSTrGQWU8VmT9w6Ih+AeYoaqXzoJqfF+PUA7F9W5ho=.sha-256@antelope.email>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/xcZAG8xuUMk0NQqt1iz17s2nShk>
Subject: Re: [imapext] Three kinds of IMAP extensions
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 16:33:25 -0000

On 10/19/15 11:44 AM, arnt@gulbrandsen.priv.no wrote:
> The drafts folder does not count because nothing appended there is big
> enough to care about this extension.

Anything with photos or videos or other rich media/files in it runs the 
risk of being too large. Clients are increasingly doing incremental 
save-to-draft as users compose messages, so whatever the user composes 
ends up "in the cloud" within a few minutes.

>
> The other folders... suppose you are an iphone client, and you are to
> send mail, and it is big and you care about that. What do you do, upload
> twice, once to port 587 checking its limit and once to IMAP checking its
> limit? Or do you upload just to 587 and bcc yourself?

This is a different problem than what is being addressed by the draft, 
though I agree it's one that should be tackled by the group.

Somewhere in amongst SMTP BURL (rfc4468), IMAP Submit 
(https://www.ietf.org/archive/id/draft-kundrat-imap-submit-02.txt), and 
IMAP Catenate (rfc4469) seems to be some good concepts that will help 
address this other problem.

>
> This extension must be very simple to understand and implement if it is
> to be worthwhile against such questions. I have no idea whether even the
> simplest is simple enough.

For server dev, I'd think the simplest is to add 
"APPENDLIMIT=<your-servers-appendsize-limit>" where 
your-servers-appendsize-limit ideally comes from some existent limit 
configured in your server. This is what we implemented.

For client dev, I'd think the simplest is to look for "APPENDLIMIT=" 
capability and steer users away from trying to do operations that would 
require appending oversized messages -- "Your draft/note is too large to 
save" or "Sorry, that message is too large to copy from AccountA to 
AccountB. AccountB only accepts messages less than <appendlimit> bytes."

Perhaps I'm oversimplifying, though :)

>
> Arnt
>
> _______________________________________________
> imapext mailing list
> imapext@ietf.org
> https://www.ietf.org/mailman/listinfo/imapext