Re: [Extra] draft-ietf-extra-quota: 64 bit numbers

Timo Sirainen <timo@sirainen.com> Tue, 23 June 2020 11:49 UTC

Return-Path: <timo@sirainen.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F473A1876 for <extra@ietfa.amsl.com>; Tue, 23 Jun 2020 04:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SFwiUYHLqDlk for <extra@ietfa.amsl.com>; Tue, 23 Jun 2020 04:49:05 -0700 (PDT)
Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id B9CD03A109F for <extra@ietf.org>; Tue, 23 Jun 2020 04:49:04 -0700 (PDT)
Received: from [172.20.10.2] (unknown [85.76.109.0]) by sirainen.com (Postfix) with ESMTPSA id 84D502B3C8B for <extra@ietf.org>; Tue, 23 Jun 2020 11:49:00 +0000 (UTC)
From: Timo Sirainen <timo@sirainen.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AFBD451A-699E-4CB3-A295-B7B6CB62E5F2"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 23 Jun 2020 14:48:59 +0300
References: <D5959732-6733-4747-B0F9-7302A0471767@sirainen.com> <dd80189f-7aed-b49c-da12-0d2dc80be907@isode.com> <41C5AB52-3FA9-4711-A254-492CF6B64F01@sirainen.com> <51f094eb-0d25-43e2-a763-61281df16201@gulbrandsen.priv.no> <99e0d0aa-cc3e-daed-9251-1ffba481b7d2@isode.com> <29511fb8-f027-4081-8bda-1b459768e84f@dogfood.fastmail.com>
To: extra@ietf.org
In-Reply-To: <29511fb8-f027-4081-8bda-1b459768e84f@dogfood.fastmail.com>
Message-Id: <396060DA-BACB-4B42-A2EB-1CF4AE4E956C@sirainen.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/uLYDEiAWmyACYkXl6ZJbV58Kah0>
Subject: Re: [Extra] draft-ietf-extra-quota: 64 bit numbers
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2020 11:49:07 -0000

On 23. Jun 2020, at 14.37, Bron Gondwana <brong@fastmailteam.com> wrote:
> 
> On Tue, Jun 23, 2020, at 20:20, Alexey Melnikov wrote:
>> Hi Arnt,
>> 
>> On 22/06/2020 14:40, Arnt Gulbrandsen wrote:
>> 
>> > On Monday 22 June 2020 14:23:25 CEST, Timo Sirainen wrote:
>> >> On 22. Jun 2020, at 15.11, Alexey Melnikov 
>> >> <alexey.melnikov@isode.com <mailto:alexey.melnikov@isode.com>> wrote:
>> >>> On 17/06/2020 22:30, Timo Sirainen wrote:
>> >>>  ...
>> >>
>> >> Yes. I think this 63/64bit issue was discussed some time ago already. 
>> >> Maybe related to some other extension.
>> >
>> > How about making ALL 32-bit numbers 63-bit in 4rev2? This may require 
>> > nothing more than an entry in Appendix D.
>> 
>> My proposal for 64bit sizes everywhere 
>> (https://datatracker.ietf.org/doc/draft-ietf-extra-imap-64bit/ <https://datatracker.ietf.org/doc/draft-ietf-extra-imap-64bit/>) got 
>> rejected a few years back, partially due to reasons of backward 
>> compatibility with IMAP4rev1. I don't think we are yet at the point 
>> where we can just do this..
>> 
>> If we want to incorporate this now, I would like to see rather strong 
>> support for this from this WG.
> 
> Just to summarise the reason it got rejected, it was something like "suppose you get something created by a V2 client which is larger than 32 bits - what does the v1 client see?  The bigger item?, nothing?, a truncated version at 2^32-1?".  The can has worms in it :(

One possibility is that we could allow 63bit numbers for FETCH results, but not for APPEND. So it would be future compatible with reading large mails, even if IMAP couldn't be used to save them directly.