Re: Charter Proposal for a new IMAP related Working Group

--On March 31, 2015 3:08:19 +0100 Alexey Melnikov <[email protected]>
wrote:

> 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?

I've reviewed the append limit proposal already and will review a SNIPPET
proposal if one is written up. If someone else can commit to editing a SNIPPET
draft, I'll write charter text for it and review the draft. But no point
writing that text if there's no document editor.

		- Chris

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