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

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.
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
>>>>> Extra@ietf.org
>>>>> 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
>>>> Extra@ietf.org
>>>> 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
>>> Extra@ietf.org
>>> 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
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com