Subject: [Extra] Call for opinions: decision about what to do with 64bit

From: Bron Gondwana <[email-masked]>
Date: Fri, 23 Mar 2018 06:11:54 +1100

This is the thread for discussing what to do with with the 64bit
proposed extension.  The strongest opinion in the room was to park the
document for now.
So I'm calling here to see if there's any objections to parking, with a
side note that anyone objecting to parking needs to convince people to
work on it, and we're pretty busy right now!
Bron.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 22 Mar 2018 19:56:46 +0000

Bron Gondwana writes:
> So I'm calling here to see if there's any objections to 
> parking, with a side note that anyone objecting to parking needs 
> to convince people to work on it, and we're pretty busy right 
> now!

IMO, larger message sizes are either important enough to include in 
imap4rev2 or unimportant enough to ignore altogether. Extensions are 
harmful by default, and need justification for their very existence. I 
don't bother to argue the point.

Arnt

---

From: Sean Leonard <[email-masked]>
Date: Thu, 22 Mar 2018 14:58:45 -0700

> On Mar 22, 2018, at 12:56 PM, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> Bron Gondwana writes:
>> So I'm calling here to see if there's any objections to parking, with a side note that anyone objecting to parking needs to convince people to work on it, and we're pretty busy right now!
> 
> IMO, larger message sizes are either important enough to include in imap4rev2 or unimportant enough to ignore altogether. Extensions are harmful by default, and need justification for their very existence. I don't bother to argue the point.

With these brief alternatives outlined, I am in favor of including it in IMAP4rev2. Storage needs are only increasing over time, not decreasing. Looking at the evolution of hard drive/SSD interfaces, for example, one can see numerous points in the industry where someone increased the bit width, only to find another barrier at the next generation. Nobody is going to go beyond 64-bit and it is the next step up by 32 orders of binary magnitude, so let’s just do it as a CAPABILITY in IMAP4rev2.

I also would like to suggest updating the ABNF in draft-ietf-extra-imap-64bit from:
  number64    = 1*DIGIT

to:

  number64    = 1*19DIGIT

as that would help with abnfgen and other tools not to go hog wild with the numbers. (Writing the ABNF to limit to exactly 9,223,372,036,854,775,807 is possible, but not so practical.)

Sean

---

From: "Chris Newman" <[email-masked]>
Date: Fri, 23 Mar 2018 00:21:34 +0000

On 22 Mar 2018, at 19:56, Arnt Gulbrandsen wrote:
> Bron Gondwana writes:
>> So I'm calling here to see if there's any objections to parking, with 
>> a side note that anyone objecting to parking needs to convince people 
>> to work on it, and we're pretty busy right now!
>
> imap4rev2 or unimportant enough to ignore altogether.

I agree with this point. By itself I think larger size is unimportant 
enough to ignore.

However, the suggestion was made to make "ENABLE IMAP4rev2" subsume 
"ENABLE UTF8=ACCEPT". There are a number of reasons that may be 
compelling enough to include in IMAP4rev2. In the event we do that in 
IMAP4rev2, then the incremental cost of supporting larger message sizes 
becomes negligible (because a mailbox format change and dealing with 
messages incompatible with IMAP4rev1 is necessary anyway) and I'd have 
no objection to it hitching a ride.

I do not believe it's a good idea to subsume "ENABLE UTF8=ACCEPT" into 
IMAP4rev2 until we have detailed feedback from at least one 
implementation. As one of the co-editors of RFC 6855, I believe it is a 
solid spec but know it's complex and there will be unexpected 
subtleties. We need implementation feedback on those subtleties before 
letting it become part of the IMAP4rev2 baseline. For example, the fact 
that we did not define a way to represent an MUTF-7-encoded hierarchy 
delimiter in RFC 6855 is a detail I did not realize until the issue was 
mentioned in EXTRA today (I don't think that's a big deal, but advice 
for that scenario may be appropriate). That's the sort of thing 
implementation experience uncovers.

		- Chris

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 23 Mar 2018 07:35:01 +0000

Chris Newman writes:
> I do not believe it's a good idea to subsume "ENABLE 
> UTF8=ACCEPT" into IMAP4rev2 until we have detailed feedback from 
> at least one implementation.

Do you remember the jabber session during last call? You, Barry, I and 
perhaps one or two more people. Last call had been issued, I did an 
implementation, found a plurality of issues, raised them, and they were all 
fixed, that same week. I was overwhelmed.

What is the separator issue? I didn't notice, but then I'm the the kind of 
nogoodnik that just treats mailbox names as strings and issues LIST * "" 
instead of pondering hierarchies.

By my count there have been two major and five minor implementations so 
far. Four different servers are telnettable on the open net. You can find 
three implementations on github if you look hard enough.

Arnt