Subject: Re: [imapext] Charter Proposal for a new IMAP related Working Group

From: Chris Newman <[email-masked]>
Date: Thu, 02 Apr 2015 23:33:56 -0700

--On March 31, 2015 3:08:19 +0100 Alexey Melnikov <[email-masked]>
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?

I've reviewed the append limit proposal already and will review a SNIPPET
proposal if one is written up. If someone else can commit to editing a SNIPPET
draft, I'll write charter text for it and review the draft. But no point
writing that text if there's no document editor.

		- Chris

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 13 Apr 2015 16:16:07 +0100

Hi Chris,

> writing that text if there's no document editor.
I can edit the SNIPPET draft, but I will not commit to doing the initial 
outline of it. So we still need for somebody to sketch out how this 
might look first.

---

From: Jayantheesh S B <[email-masked]>
Date: Mon, 13 Apr 2015 15:27:40 +0000

HI Alexey,

Below Charter Proposal for The IMAP APPEND extension (imapappend) working group, looks good.  

I am Ok with the proposal text as is.

Regards,
Jay

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Monday, March 30, 2015 10:08 PM
To: IMAPEXT
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.

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

Best Regards,
Alexey

---

From: Michael M Slusarz <[email-masked]>
Date: Mon, 13 Apr 2015 10:21:22 -0600

Quoting Alexey Melnikov <[email-masked]>:

> I can edit the SNIPPET draft, but I will not commit to doing the  
> initial outline of it. So we still need for somebody to sketch out  
> how this might look first.

Hi Alexey,

I talked with Timo regarding SNIPPET, which has been internally  
implemented in Dovecot, although not yet with an IMAP protocol API.  I  
would be willing to draft what is necessary in order to add to the  
group scope and begin a discussion on how to implement at the IMAP  
level.

Let me know if interested and what needs to be done.

michael

___________________________________
Michael Slusarz [[email-masked]]

---

From: Stuart Brandt <[email-masked]>
Date: Mon, 13 Apr 2015 18:38:50 -0400

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:
> 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
> 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.
>
> _______________________________________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/imapext

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 14 Apr 2015 10:48:12 +0200

Stuart Brandt writes:
> 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 have a perfectly formed draft, the result of considerable off-line 
discussion last year, but no real interest in taking it further. You can 
have it if you want it.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Apr 2015 13:07:37 +0100

Hi Stuart,

On 13/04/2015 23:38, Stuart Brandt wrote:
> support replacement of stored messages (e.g. Drafts, Notes). In the 
> past year or so we've seen:
> discovered after delivery (presumably to add their own "metadata" in 
> the form of client-specific headers)
>
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".

---

From: Jayantheesh S B <[email-masked]>
Date: Mon, 20 Apr 2015 15:06:07 +0000

Hi All,

Kindly share your comments regarding the Charter text proposed by Alexey. 

Regards,
Jay
-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Monday, March 30, 2015 10:08 PM
To: IMAPEXT
Subject: [imapext] Charter Proposal for a new IMAP related Working Group

Hi,

------
Comments:

Best Regards,
Alexey

---

From: Jamie Nicolson <[email-masked]>
Date: Mon, 20 Apr 2015 15:43:48 -0700

Thanks, I think this is a valuable area to address in a WG. We're
interested in both of these extensions for Gmail.

On Mon, Mar 30, 2015 at 7:08 PM, Alexey Melnikov <[email-masked]>
wrote:

> 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

---

From: Jamie Nicolson <[email-masked]>
Date: Mon, 20 Apr 2015 15:45:52 -0700

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

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

>> saving of drafts, some of which don't have much error handling for mobile
>> network flakiness and end up orphaning the original copy.
>> 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)
>>