Re: Charter Proposal for a new IMAP related Working Group

Hi Stuart,

On 13/04/2015 23:38, Stuart Brandt wrote:
> 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.
I think you should post the draft regardless of whether or not it is 
included in the charter. Personally I would like to see something before 
saying "yes I am interested" or "no".
> 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

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