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

["Chris Newman" <[e-mail]>]

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.

		- Chris

> Bron.
>
>
> On Fri, 11 May 2018, at 08:40, Chris Newman wrote:
>> On 10 May 2018, at 10:30, Stephan Bosch wrote:
>>> Op 05/05/2018 om 01:46 schreef Chris Newman:
>>>> On 4 May 2018, at 16:42, Chris Newman wrote:
>>>>
>>>>> I just noticed we implemented this in 2005 (under the 
>>>>> "X-SUN-IMAP">>>> capability). Looking at the implementation, 
>>>>> there's a significant
>>>>> bug in the specification. Mailbox sizes can easily exceed 4GB; so
>>>>> the ABNF for status-att-list needs to be replaced as follows:
>>>>>
>>>>>    status-att-list = status-att SP number63 *(SP status-att SP
>>>>> number63)
>>>>>         ;; number63 is only permitted with extension status
>>>>> attributes
>>>>>         ;; that explicitly allow it; such as SIZE
>>>>
>>>> Oh, just noticed RFC 4466 redefines that, so you instead need a
>>>> normative reference to RFC 4466 and then do:
>>>>
>>>>    status-att-val /= "SIZE" SP number63
>>>
>>> A 4Gb mailbox is still quite huge these days, but you're right. The
>>> QUOTA capability has the same problem: how did you address that?
>>
>> Quota Storage partially dodges the problem by using 1K rather than 1
>> byte units. However, the fact it doesn't allow 63-bit storage
>> numbers is> a specification bug (due to proof-by-example: the IMAP 
>> data
>> model allows> a mailbox with 4G messages each of 4G size). 
>> Implementations should
>> ignore specification bugs like that (ours does). However, the 32-bit
>> limit on UIDs, message size, and message sequence numbers is
>> part of the> fundamental IMAP data model. Changes to those values 
>> require an
>> incompatible change to the IMAP data model that can break previously
>> standards-compliant implementations. The IETF generally doesn't make
>> that sort of change without a negotiated extension and 
>> implementations> that ignore fundamental data models in the standards 
>> without
>> negotiation> are usually bad Internet citizens.
>>
>>> That would have been solved by the 64BIT capability, but that
>>> one's on>> hold now
>>
>> There's no reason we can't have this spec use a 63-bit number at the
>> time we write it. Clients won't get this data unless they ask
>> for it and> servers won't send it unless they've advertised it. This 
>> requires no
>> change to the IMAP data model so no separate negotiation is needed 
>> to> use 63-bit numbers here. It's just an extra line of ABNF and with 
>> no
>> impact on data model and very little impact on implementations. A
>> normative dependency on a draft that changes the IMAP data model is 
>> a> change to SIZE that I would oppose. But use of a 32-bit integer
>> is a bug> in the SIZE draft (again via proof-by-example).
>>
>> - Chris
>>
>>> Bron, Alexey, opinions?
>>>
>>> Regards,
>>>
>>> Stephan
>>>
>>>>
>>>>         - Chris
>>>>
>>>>>    number63  = 1*DIGIT
>>>>>                           ;; Positive
>>>>> unsigned 63-bit integer
>>>>>                           ;; (0 <= n <=
>>>>> 9,223,372,036,854,775,807).
>>>>>
>>>>>         - Chris
>>>>>
>>>>> On 26 Apr 2018, at 10:10, Alexey Melnikov wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I've been following discussions on this document and it is ready
>>>>>> for
>>>>>> IETF Last Call, which I just initiated.
>>>>>>
>>>>>> One nit: I believe the following reference is now Normative,
>>>>>> due to>>>>> added SHOULD level requirement:
>>>>>>
>>>>>>  [QUOTA]
>>>>>>
>>>>>> Please update the document to reflect this next time the 
>>>>>> document>>>>> is
>>>>>> revised.
>>>>>>
>>>>>> Best Regards,
>>>>>> Alexey, as AD.
>>>>>>
>>>>>> _________________________________________________
>>>>>> Extra mailing list
>>>>>> [e-mail]
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=B73C8TOrpzVRz_O5v_4esOIRwnbdcZoZaulZWKyZwBY&s=Av_oW8rLHO6EMocPg9SJXED-Ta7xK6PRHohZ6tFZmmM&e=>>>>
>>>>> _________________________________________________
>>>>> Extra mailing list
>>>>> [e-mail]
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=ErU-4WHaHwqAH1nltCBHaf7zbhatpz2gGlB_BH0n3uI&s=HPU9C98qqq9ZOoEpMPOpUKits0ILuqWjGwmCx6_ZCvo&e=>>>
>>>> _________________________________________________
>>>> Extra mailing list
>>>> [e-mail]
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=5HJofT5ocTAB71bioSeN2ztVNEW92Tx14L2kdo_8_PQ&s=VsTTjiVSxN0fQkrv_AoqVm9VLp5Rw5qTjsqJJEODbT4&e=>
>> _________________________________________________
>> Extra mailing list
>> [e-mail]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=iuOZ5F20PkM5wdQEwZxEPtbn6Zkqct206gpiSREDRcM&s=tFJXEAphLbOeNohg_H0fX9hOKWGsxGtr8rozXS687OA&e=
>
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   [e-mail]


> _______________________________________________
> Extra mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=iuOZ5F20PkM5wdQEwZxEPtbn6Zkqct206gpiSREDRcM&s=tFJXEAphLbOeNohg_H0fX9hOKWGsxGtr8rozXS687OA&e=