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

[Bron Gondwana <[e-mail]>]

On Tue, May 15, 2018, at 09:54, Chris Newman wrote:
> On 10 May 2018, at 19:01, Bron Gondwana wrote:
>> My opinion is - just define this response as a 63 bit number.
>> 
>> Crappy thing here with RFC4466 is:
>> 
>>   tagged-ext-simple   = sequence-set / number
>> 
>> And "number" is defined in RFC3501:
>> 
>> number          = 1*DIGIT ; Unsigned 32-bit integer ; (0 <= n <
>> 4,294,967,296)
>> 
>> Which means that the response SHOULD be:
>> 
>> "SIZE" SP "(" number63 ")"  rather than "SIZE" SP number63 to be
>> tagged-ext.
> 
> Clients have a parser. That parser will either support 32-bit
> numbers or> 63-bit numbers. Clients implementing SIZE should just support 63-bit
> numbers; that's less client code than supporting 32-bit numbers
> outside> parens and 63-bit numbers inside parens; thus less risk of bugs. The
> extra parentheses make the parser more complex for no good reason. The> extra parentheses make the extension incompatible with an already
> implemented extension in my server for no good reason (yes, I'm
> willing> to make incompatible changes to private extensions, but only if
> there is> a technical reason to do so). I object to adding the extra parentheses> for those two reasons.

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.
Bron.


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]