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

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

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=