Re: [Extra] I-D Action: draft-ietf-extra-imap-64bit-03.txt

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

On 4 Mar 2018, at 9:26, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Email mailstore and eXtensions To 
> Revise or Amend WG of the IETF.
>
>         Title           : 64bit body part and message sizes in IMAP4
>         Authors         : Alexey Melnikov
>                           Jayantheesh S B
> 	Filename        : draft-ietf-extra-imap-64bit-03.txt
> 	Pages           : 7
> 	Date            : 2018-03-04
>
> Abstract:
>    This document defines an IMAPv4rev1 extension that extends the
>    existing IMAPv4rev1 32 Bit message and body part sizes to 63 bit.
>    Both the base IMAP specification (RFC 3501) and several extensions
>    are updated.

I reviewed this document.

This document fails to state how the server should respond if a message 
in a mailbox has a size larger than 32-bit when a traditional IMAP 
client accesses that mailbox. What value does the server provide for the 
SIZE FETCH attribute in this case? Can a server return NO on select of a 
mailbox with a jumbo message when the client is a "legacy" client? Where 
are the examples of this behavior in the specification? What is the 
end-user experience for this? If a legacy end-user has a shared mailbox 
and allows another user to append a "jumbo" message to the shared 
mailbox, will that create a hidden channel problem? Would we need a 
separate ACL bit or flag of some sort to grant permission to insert 
"jumbo" messages into a mailbox to avoid such problems?

This isn't merely changing the protocol, it's changing the implied 
persistent mail store format in an incompatible fashion. This has 
serious backwards compatibility issues for clients not updated to 
support this. A change like this requires both a solid justification and 
discussion of the compatibility implications (see RFC 6855). I believe 
this document is incomplete and inappropriate for advancement until it 
covers both topics. Setting a precedent that it's ok to change the 
implied persistent mail store semantics without strong justification is 
something I oppose.

I note that this does not appear to change the IMAP UID to be 64-bit 
although it doesn't say why. This is also an omission from the document.

Finally, if we're getting into the business of changing persistent 
storage semantics, I'd like to do it as few times as possible to 
minimize overall disruption to the infrastructure. There's a clear need 
for a unique message identifier that is not mailbox-specific. That's 
also an incompatible change to the implied persistent storage semantics. 
If we're going to make that change at some point in the future 
(something I would support on the grounds of compatibility with both 
JMAP and deployed mail services with tag-based mailboxes), I'd like to 
see both proposed incompatible persistent storage format changes made at 
the same time to minimize the disruption to the infrastructure.

I also note that this change forces an IMAP URL resolver to either 
unconditionally send "enable 64bit" (if the capability is present) or to 
try once and retry with "enable 64bit" if the first attempt fails in a 
way that is recognizable (something presently not specified). Both 
options are a significant increase in the complexity of such a URL 
resolver.

At this point, I find this proposal to be high cost/disruption with no 
stated benefit or justification. I presently oppose advancement of this 
proposal.

		- Chris