Subject: [Extra] Some comments on draft-ietf-extra-imap-64bit

From: Stephan Bosch <[email-masked]>
Date: Fri, 15 Sep 2017 18:06:56 +0200

Hi,

I gave draft-ietf-extra-imap-64bit a quick look. I have a few comments 
on the syntax specification.

First of all, the elements fetch-att, msg-att-static, and search-key are 
just copy-pasted from RFC 3501. Those are meant to have number64 instead.

I wonder whether it would be a good idea to have intermediary elements 
called e.g. `msg-size = number64' and `msg-lines = number64', so that 
future changes/extensions to the message size and line count syntax 
aren't such a pain anymore.

The "capability" syntax element is not extended (arguably not all 
specifications do this).

Finally, the following IMAP capabilities have syntax that is affected by 
this extension:

QUOTA - https://www.ietf.org/rfc/rfc2087.txt
BINARY - https://www.ietf.org/rfc/rfc3516.txt (not only literal8)
URL-PARTIAL - https://www.ietf.org/rfc/rfc5550.txt -> 
https://www.ietf.org/rfc/rfc5092.txt (partial-range)
APPENDLIMIT - https://www.rfc-editor.org/rfc/rfc7889.txt

Regards,

Stephan.

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 15 Sep 2017 16:25:17 +0000

On 9/15/17, 12:07 PM, "Extra on behalf of Stephan Bosch" <[email-masked] on behalf of [email-masked]> wrote:

I too have a couple comments. If it’s called the 64bit extension, why are the numbers limited to 63 bits? Why not the full 64-bit range?

I’m sure there’s a good reason (or perhaps not).

	Tony Hansen

---

From: Michael Slusarz <[email-masked]>
Date: Fri, 15 Sep 2017 10:29:18 -0600 (MDT)

> On September 15, 2017 at 10:25 AM "HANSEN, TONY L" <[email-masked]> wrote:
> 
> 

Probably for the same reasons outlined here:

https://tools.ietf.org/html/rfc7162#section-3.1

Although that design decision should be made explicit in the text of this graph (or at least a reference to decision as outlined in 7162).

michael

---

From: Michael Slusarz <[email-masked]>
Date: Fri, 15 Sep 2017 10:31:26 -0600 (MDT)

> On September 15, 2017 at 10:29 AM Michael Slusarz <[email-masked]> wrote:
> 
> 

Ugh.

s/graph/draft/

---

From: Bron Gondwana <[email-masked]>
Date: Sun, 17 Sep 2017 01:15:16 +1000

Yeah, round tripping via a signed 64 bit value is nice.

On Sat, 16 Sep 2017, at 02:25, HANSEN, TONY L wrote:
> On 9/15/17, 12:07 PM, "Extra on behalf of Stephan Bosch"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> I too have a couple comments. If it’s called the 64bit
> extension, why are> the numbers limited to 63 bits? Why not the full 64-bit range?
> 
> _________________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 16 Sep 2017 16:30:23 +0100

> On 16 Sep 2017, at 16:15, Bron Gondwana <[email-masked]> wrote:
> 

Basically for compatibility with Java.

>> I too have a couple comments. If it’s called the 64bit extension, why are
>> the numbers limited to 63 bits? Why not the full 64-bit range?
>> 
>> _______________________________________________
>> Extra mailing list
>> [email-masked]
> _______________________________________________
> Extra mailing list
> [email-masked]

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sat, 16 Sep 2017 08:51:49 -0700

> On Sep 16, 2017, at 8:30 AM, Alexey Melnikov <[email-masked]> wrote:
> 

From a practical standpoint, nobody is going to miss that extra bit if sizes are restricted to 2^63 (vs ^64)

From a purists point of view, using a signed int to represent something that cannot possibly be negative is wrong.  Back in the days of the IMAP interop events, throwing protocol elements with sizes of 2^32 ±1 and +0 was guaranteed to take out at least half the server implementations on the floor.

--lyndon

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sat, 16 Sep 2017 08:56:32 -0700

> On Sep 16, 2017, at 8:51 AM, Lyndon Nerenberg <[email-masked]> wrote:
> 
> with sizes of 2^32 ±1 and +0

Sorry, my fat fingers meant to type ±2 for the +0 there :-P

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 18 Sep 2017 01:23:11 +0000

Suggested text changes:

Intro:
OLD: IMAP [RFC3501<https://tools.ietf.org/html/rfc3501>] only allows body parts or message sizes which are
OLD:   32bit. This document introduces an IMAP extension that allows for
OLD:   message and body part sizes to be 63bit.

NEW: IMAP [RFC3501<https://tools.ietf.org/html/rfc3501>] only allows body parts or message sizes which are
NEW:   expressible in a 32bit unsigned value. This document introduces an IMAP extension that allows for
NEW:   message and body part sizes to be expressible in an unsigned value that can be held in a 64bit signed value.
NEW:   (Because of the sign bit in 2s-complement notation, this has an effective size of 63bits.)

                Tony Hansen

From: Extra <[email-masked]> on behalf of Alexey Melnikov <[email-masked]>
Date: Saturday, September 16, 2017 at 11:27 AM
To: Bron Gondwana <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Extra] Some comments on draft-ietf-extra-imap-64bit

On 16 Sep 2017, at 16:15, Bron Gondwana <[email-masked]<mailto:[email-masked]>> wrote:
Yeah, round tripping via a signed 64 bit value is nice.
Basically for compatibility with Java.

On Sat, 16 Sep 2017, at 02:25, HANSEN, TONY L wrote:
On 9/15/17, 12:07 PM, "Extra on behalf of Stephan Bosch"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    I gave draft-ietf-extra-imap-64bit a quick look. I have a few
    comments

Tony Hansen

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Sep 2017 13:01:51 +0100

Hi Stephan,

On 15/09/2017 17:06, Stephan Bosch wrote:
> First of all, the elements fetch-att, msg-att-static, and search-key 
> are just copy-pasted from RFC 3501. Those are meant to have number64 
> instead.
Yes, fixed.

> aren't such a pain anymore.
Might be a good idea. If you send me the specific ABNF fragment, this 
will speed up the process.

> The "capability" syntax element is not extended (arguably not all 
This is typically done in prose.

> Finally, the following IMAP capabilities have syntax that is affected 
> by this extension:
>
Good point, I will have a look.
> BINARY - https://www.ietf.org/rfc/rfc3516.txt (not only literal8)

Looking at the ABNF:

    append         =/  "APPEND" SP mailbox [SP flag-list]
                       [SP date-time] SP literal8

    fetch-att      =/  "BINARY" [".PEEK"] section-binary [partial]
                       / "BINARY.SIZE" section-binary

    literal8       =   "~{" number "}" CRLF *OCTET
                       ; <number> represents the number of OCTETs
                       ; in the response string.

    msg-att-static =/  "BINARY" section-binary SP (nstring / literal8)
                       / "BINARY.SIZE" section-binary SP number

    partial        =   "<" number "." nz-number ">"

    resp-text-code =/  "UNKNOWN-CTE"

    section-binary =   "[" [section-part] "]"

I don't think we need 64bit section numbers, but I missed updating 
"partial".

> APPENDLIMIT - https://www.rfc-editor.org/rfc/rfc7889.txt
Yes, these need to be looked at as well.

Best Regards,
Alexey

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 25 Sep 2017 12:44:41 +1000

I've created https://github.com/ietfextra/tracking/issues/4 for this

On Sat, 16 Sep 2017, at 02:29, Michael Slusarz wrote:
>> On September 15, 2017 at 10:25 AM "HANSEN, TONY L"
>> <[email-masked]> wrote:>> 
>> 
>> On 9/15/17, 12:07 PM, "Extra on behalf of Stephan Bosch" <extra-
>> [email-masked] on behalf of [email-masked]> wrote:>> 
>>   comments>> 
>> I too have a couple comments. If it’s called the 64bit extension, why
>> are the numbers limited to 63 bits? Why not the full 64-bit range?>> 
> Although that design decision should be made explicit in the
> text of this> graph (or at least a reference to decision as outlined in 7162).
> 
> michael
>

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 25 Sep 2017 12:48:25 +1000

And for the extensions:

https://github.com/ietfextra/tracking/issues/5

(it's easy to close these off, just good to track them)

>>  comments on the syntax specification.>> 
>>  instead.> Yes, fixed.
>> I wonder whether it would be a good idea to have intermediary
>> elements called e.g. `msg-size = number64' and `msg-lines =
>> number64', so that future changes/extensions to the message size and
>> line count syntax aren't such a pain anymore.> Might be a good idea. If you send me the specific ABNF fragment, this
> will speed up the process.> 
>
>> specifications do this).> This is typically done in prose.
> 
> 
>> by this extension:>> 
>> BINARY - https://www.ietf.org/rfc/rfc3516.txt (not only literal8)> 
> Looking at the ABNF:
> 
>
>    append         =/  "APPEND" SP mailbox [SP flag-list] [SP date-
>    time] SP literal8  fetch-att      =/  "BINARY" [".PEEK"] section-
>    binary [partial] / "BINARY.SIZE" section-binary  literal8       =
>    "~{" number "}" CRLF *OCTET ; <number> represents the number of
>    OCTETs ; in the response string.  msg-att-static =/  "BINARY" section-
>    binary SP (nstring / literal8) / "BINARY.SIZE" section-binary SP
>    number  partial        =   "<" number "." nz-number ">"  resp-text-
>    code =/  "UNKNOWN-CTE"  section-binary =   "[" [section-part] "]"
>> 
> 
> "partial".> 
>> https://www.ietf.org/rfc/rfc5092.txt (partial-range)>>  APPENDLIMIT - https://www.rfc-editor.org/rfc/rfc7889.txt