Re: Charter Proposal for a new IMAP related Working Group

Yes, please post. REPLACE sounds very useful for drafts.

On Tue, Apr 14, 2015 at 5:07 AM, Alexey Melnikov <[email protected]>
wrote:

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

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