Re: Charter Proposal for a new IMAP related Working Group

Hi All,

If we are going to include IMAP_REPLACE and IMAP_SNIPPET draft as part of the proposed WG, then kindly update the charter proposal and share it across. 

Regards,
Jay

-----Original Message-----
From: Stuart Brandt [mailto:[email protected]] 
Sent: Monday, April 13, 2015 6:39 PM
To: [email protected]
Cc: 'Alexey Melnikov'
Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group

Is there any interest in an additional APPEND related extension to support replacement of stored messages (e.g. Drafts, Notes). In the past year or so we've seen:
a) a significant increase in the number of sessions doing automatic saving of drafts, some of which don't have much error handling for mobile network flakiness and end up orphaning the original copy.
b) more sessions interacting with a "Notes" folder in same manner.
c) some cloud based apps replacing messages as soon as they're discovered after delivery (presumably to add their own "metadata" in the form of client-specific headers)

For all the reasons that MOVE (RFC 6851) made sense, I think a REPLACE extension would make sense for providing an atomic alternative to the current APPEND/STORE/EXPUNGE trio required to replace messages.

I have the beginnings of a draft written up, but given the creation of this working group would be willing to accelerate getting it out there.

Any interest?

- Stuart


On 3/30/15 10:08 PM, Alexey Melnikov 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?
>
> 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