Re: [Extra] AD review of draft-ietf-extra-imap-status-size-01

[Arnt Gulbrandsen <[e-mail]>]

On Tuesday 15 May 2018 03:14:18 CEST, Bron Gondwana wrote:
> I'm totally fine with all those reasons.  Do we need to do a 
> 4466bis for this, or do we let that get folded with the 64bit 
> extension work in general and IMAP4rev2?
>
> I'm pretty keen to say that "IMAP4rev2 will fix it" about 
> irrelevant things like this, but I think it's good to have the 
> discussion and have a clear answer for why we're going with a 
> number without parens - particularly since OBJECTID is doing 
> parans everywhere.

Try this:

If this extension uses 63-bit unsigned numbers, then that complicates the 
grammar, which needs an additional sentence to say that the number 
production comes from RFCxxx instead of 3501,  and the RFC, which needs to 
explain that the size is potentially big. But it simplifies the clients, 
which only need to parse and handle one case instead of two, and which only 
need to test one thing instead of two, and breaks nothing.

This is similar to the history of "" for UTF8=ACCEPT. There was separate 
syntax for quoting, it was dropped because it seemed to offer no 
advantages, and instead the "" was extended to allow UTF8. A success. As 
far as I know, none of the implementations have reported problems with 
that.

IMHO (note the H, that's h for humble) objectid doesn't have the same 
problem. The parens aren't necessary. They have no function, they're just 
there because some other parens add clarity in some other cases. But my 
personal opinion is that if unnecessary syntax is mandatory, then it adds 
no unit tests, and the required number of unit tests are an effective proxy 
for simplicity and reliability.

Arnt