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

From: Timo Sirainen <[email-masked]>
Date: Thu, 18 Jun 2020 00:30:58 +0300

>    The usage of a resource MUST be represented as a 32 bit unsigned
>    integer.

I think we should go for 64 bit numbers already. RES-STORAGE is now limited to 4 terabytes, which is rather high value for a single user's limit for now, but I could imagine it being a possibility in some more years. Maybe even already in email systems that use only a few users. Also there's already an example:

      C: G0001 GETQUOTA "!partition/sda4"
      S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
      S: G0001 OK Getquota complete

The 4 TB limit can already be easily reached if describing a filesystem size.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 22 Jun 2020 13:11:40 +0100

> The 4 TB limit can already be easily reached if describing a filesystem size.

Sounds good. Shall we make it 63 bits to make it easier to implement for 
Java based implementations?

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 22 Jun 2020 15:23:25 +0300

On 22. Jun 2020, at 15.11, Alexey Melnikov <[email-masked]> wrote:
> Sounds good. Shall we make it 63 bits to make it easier to implement for Java based implementations?

Yes. I think this 63/64bit issue was discussed some time ago already. Maybe related to some other extension.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 22 Jun 2020 15:40:36 +0200

On Monday 22 June 2020 14:23:25 CEST, 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.

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 22 Jun 2020 17:08:25 +0300

On 22. Jun 2020, at 16.40, Arnt Gulbrandsen <[email-masked]> wrote:
> How about making ALL 32-bit numbers 63-bit in 4rev2? This may require nothing more than an entry in Appendix D.

I wouldn't make sequences or UIDs more than 32bit. I don't see much benefits, only a lot of extra complexity and waste of memory/disk space.

I wouldn't mind making message sizes (literals, RFC822.SIZE) 63bit though. Dovecot has actually internally done that already since the beginning.

---

From: Stephan Bosch <[email-masked]>
Date: Mon, 22 Jun 2020 19:51:42 +0200

> Yes. I think this 63/64bit issue was discussed some time ago already. Maybe related to some other extension.

This is mentioned in STATUS=SIZE, and in draft IMAP4rev2 by inference.

Regards,

Stephan.
> 
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 Jun 2020 11:20:58 +0100

Hi Arnt,

> nothing more than an entry in Appendix D.

My proposal for 64bit sizes everywhere 
(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.

Best Regards,

Alexey

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 23 Jun 2020 21:37:19 +1000

> 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 :(

Bron.

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [email-masked]

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 23 Jun 2020 14:48:59 +0300

On 23. Jun 2020, at 14.37, Bron Gondwana <[email-masked]> wrote:
>> >> On 22. Jun 2020, at 15.11, Alexey Melnikov 
>> >> <[email-masked] <mailto:[email-masked]>> wrote:
>> (https://datatracker.ietf.org/doc/draft-ietf-extra-imap-64bit/ <https://datatracker.ietf.org/doc/draft-ietf-extra-imap-64bit/>) got 
>> where we can just do this..
>> 

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.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 23 Jun 2020 14:59:07 +0200

On Tuesday 23 June 2020 13:48:59 CEST, Timo Sirainen wrote:
> 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.

That's more or less what I had in mind.

I think APPEND should be free to reject very large arguments, but the 
definition of "very large" should be an implementation matter, not a 
protocol matter. The protocol should allow the client to send 
{723894723489237} in the prelude to appending, and then the server can say 
NO [LIMIT], but cannot say BAD [CLIENTBUG].

Servers that also serve 4r1 (all, I suppose) would of course have 
appropriate limits. The practical effect of the change is to provide a 
simple, easily comprehensible change. "Make sure that your number parser 
can parse from 0 to 9223372036854775807."

Simplicity is a feature.

Arnt