Re: imapext Digest, Vol 32, Issue 14

The charter text looks ok.
Both the deliverable are related to each other.

Thanks
-Naren

On Tue, Mar 31, 2015 at 3:00 PM, <[email protected]> wrote:

> Send imapext mailing list submissions to
>         [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/imapext
> or, via email, send a message with subject or body 'help' to
>         [email protected]
>
> You can reach the person managing the list at
>         [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of imapext digest..."
>
> Today's Topics:
>
>    1. Charter Proposal for a new IMAP related Working Group
>       (Alexey Melnikov)
>
>
> ---------- Forwarded message ----------
> From: Alexey Melnikov <[email protected]>
> To: IMAPEXT <[email protected]>
> Cc:
> Date: Tue, 31 Mar 2015 03:08:19 +0100
> 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
>
>

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