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