Re: Charter Proposal for a new IMAP related Working Group

Hi All,

Kindly share your comments regarding the Charter text proposed by Alexey. 

Regards,
Jay
-----Original Message-----
From: Alexey Melnikov [mailto:[email protected]] 
Sent: Monday, March 30, 2015 10:08 PM
To: IMAPEXT
Subject: [imapext] Charter Proposal for a new IMAP related Working Group

Hi,

I've asked Barry earlier what he would like to do about
draft-jayantheesh-imap-appendlimit-extension-03 and other drafts and he asked for a charter for a new short term IMAP related WG. Here is a
proposal:


The Internet Message Access Protocol (IMAP), defined in RFC 3501, specifies a protocol for transferring email messages between a server that implements a message store, and a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming mailboxes, adding a message to a mailbox, and copying messages from one mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for transferring blocks of data. When sending a literal from a client to a server, RFC 3501 requires the client to wait for the server to send a command continuation request between sending the octet count and the string data.
This complicates client implementations and resulted in definition of LITERAL+ IMAP extension (RFC 2088) which specifies an alternate form of literal which does not require this network round trip. While this extension is quite commonly supported by servers, some implementations decided to disable it because it is frequently abused by naive clients that try to upload big messages without checking whether servers can accept big messages.

The IMAP APPEND extension (imapappend) working group has two related deliverables which are targeted at improving the current situation. One deliverable is based on draft-jayantheesh-imap-appendlimit-extension-03
and defines a way for servers to announce APPEND limit for a particular server or a particular mailbox. The second deliverable is based on draft-melnikov-rfc2088bis-01. It describes implementation choices for server supporting LITERAL+ extension and also defines LITERAL- extension which have similar properties, but is easier for servers to implement while preventing denial of service attacks from malicious and naive IMAP clients. Both deliverables will be Standards Track documents.

As part of the protocol development, implementation experience on both the client and server side is highly desireable, so that the actual operational value of this extension can be assessed. The working group will document the results of this experience on the working group wiki.

No other IMAP extension work is in scope for this working group.

------
Comments:


1) I don't particularly care if LITERAL- is standardized or not, but I would like the problem to be solved. If we can't agree on LITERAL-, then draft-melnikov-rfc2088bis can just become a revision of LITERAL+.

2) I've also heard some interest in standardizing the SNAPSHOT facility. 
I am ambivalent on whether it should be added to the above. (If you think it should, please suggest a new paragraph to add). I would like to keep the charter to no more than 3 deliverables.

Any opinions on the proposal?

Best Regards,
Alexey


_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext