Subject: [imapext] Fwd: I-D Action: draft-melnikov-rfc2088bis-01.txt

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Dec 2014 18:35:44 +0000

I revived and updated LITERAL+ extension. I also added LITERAL- 
extension (same as LITERAL+, but disallowed in APPEND).

-------- Original Message --------
Subject: 	I-D Action: draft-melnikov-rfc2088bis-01.txt
Date: 	Wed, 17 Dec 2014 10:29:29 -0800
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : IMAP4 non-synchronizing literals
         Authors         : John G. Myers
                           Alexey Melnikov
	Filename        : draft-melnikov-rfc2088bis-01.txt
	Pages           : 7
	Date            : 2014-12-17

Abstract:
    The Internet Message Access Protocol (RFC 3501) contains the
    "literal" syntactic construct for communicating strings.  When
    sending a literal from client to server, IMAP requires the client to
    wait for the server to send a command continuation request between
    sending the octet count and the string data.  This document specifies
    an alternate form of literal which does not require this network
    round trip.

    This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-.
    The former allows the alternate form of literals in all IMAP command.
    The latter is the same as LITERAL+, but disallow the alternate form
    in IMAP APPEND.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-melnikov-rfc2088bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-melnikov-rfc2088bis-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-melnikov-rfc2088bis-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 18 Dec 2014 12:57:00 +0100

> extension (same as LITERAL+, but disallowed in APPEND).

Why is LITERAL- like that intead of being restricted to short literals? Say 
up to 16k.

The problem in RFC 1047 affects APPEND too. A limit comparable to typical 
TCP transmission windows would be appropriate, I think.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Dec 2014 12:14:12 +0000

On 18/12/2014 11:57, Arnt Gulbrandsen wrote:
> Why is LITERAL- like that intead of being restricted to short 
> literals? Say up to 16k.
Allowing smaller non synchronizing literal sizes in APPEND might work, 
but the problem is that this still allows for abuse if the limit is 
exceeded.

Are people interested in changing LITERAL- to allow smaller messages 
being uploaded with non synchronizing literals (bigger messages can 
still be uploaded using RFC 3501 synchronizing literals)?
> The problem in RFC 1047 affects APPEND too. A limit comparable to 
> typical TCP transmission windows would be appropriate, I think.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 18 Dec 2014 13:31:47 +0100

On Thursday, December 18, 2014 1:14:12 PM CEST, Alexey Melnikov wrote:
> Allowing smaller non synchronizing literal sizes in APPEND 
> might work, but the problem is that this still allows for abuse 
> if the limit is exceeded.

Not really, not if the limit is comparable to typical TCP send windows. A 
badly behaving client can send one TCP window's worth of stuff to the 
server anyway.

Specifically, the client can send
    a append inbox () "01-01-2000" {9999999999999999999999999999+}
no matter whether which part of that line is forbidden, and the server has 
to eat one whole TCP window before it can throw the client out.

Arnt

---

From: Michael M Slusarz <[email-masked]>
Date: Thu, 18 Dec 2014 13:15:52 -0700

Quoting Arnt Gulbrandsen <[email-masked]>:

>> Allowing smaller non synchronizing literal sizes in APPEND might  
>> work, but the problem is that this still allows for abuse if the  
>> limit is exceeded.
>
> Not really, not if the limit is comparable to typical TCP send  
> windows. A badly behaving client can send one TCP window's worth of  
> stuff to the server anyway.
>
> no matter whether which part of that line is forbidden, and the  
> server has to eat one whole TCP window before it can throw the  
> client out.

I do like having the option of allowing small messages to be directly  
appended with LITERAL+.  That's the way I've coded APPENDs currently.

Arnt's selection of 16k seems reasonable when viewed through the  
network lens.  Although with multipart/alternative and/or HTML  
messages being more prevalent these days, this probably means that the  
majority of sent-mail like APPENDs won't fall under this 16k  
exception.  So wondering if that means a large limit is needed (64k?)  
or whether we are adding complexity for optimizing only a limited  
number of APPEND transactions and this would be overkill.

michael

___________________________________
Michael Slusarz [[email-masked]]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 18 Dec 2014 21:50:53 +0100

If the limit is larger than typical TCP windows the gain isn't large any 
more.

Once you're out of the send-window range, you already have several 
roundtrips, and adding one for the literal isn't that much. 5 is only 20% 
more than 4, but 2 is 100% more than 1.

A limit of 32k may make sense. (I wrote 16k because it's a nice binary 
number around halfway between 4500 and 32k.)

BTW, do you have the impression that the mail people sent has grown in size 
that much? The mail people receive, sure, but the mail people (humans) 
send, particularly from mobile devices, seems rather like ten years ago to 
me. A bit bigger, not much. I admit I have no dependable data on that.

Arnt

---

From: Michael M Slusarz <[email-masked]>
Date: Thu, 18 Dec 2014 18:40:55 -0700

Quoting Arnt Gulbrandsen <[email-masked]>:

> If the limit is larger than typical TCP windows the gain isn't large  
> any more.
>
> roundtrips, and adding one for the literal isn't that much. 5 is  
> only 20% more than 4, but 2 is 100% more than 1.
>
> A limit of 32k may make sense. (I wrote 16k because it's a nice  
> binary number around halfway between 4500 and 32k.)

How much slower is a level 7 roundtrip than a level 4 roundtrip?   
(That question is probably dependent on the quality of both the server  
and client's IMAP protocol implementation, so there might not be a  
satisfactory answer.)

> BTW, do you have the impression that the mail people sent has grown  
> in size that much? The mail people receive, sure, but the mail  
> people (humans) send, particularly from mobile devices, seems rather  
> like ten years ago to me. A bit bigger, not much. I admit I have no  
> dependable data on that.

I thought I had data on that from a large ISP I work with, but I don't  
have it handy of course.

My personal experience is that I seem to be replying to HTML-ish  
messages a bunch these days that contain about 9 duplicated 20-line  
signatures (sigh).  Most users are just going to include all of that  
without trimming so once a thread reaches several replies I feel that  
message is easily nearing the 16k limit.  (Or think of HTML signatures  
that include a small embedded image, which is fairly common in  
business usage.)

Although a quick check of my personal sent-mail mailbox shows that  
only about 4% of my messages are over 16k.  With the caveat that I  
have much more text/plain mailing list activity, and reply trimming,  
than a "normal" user.

But even if that number is 50%, I guess I am convinced that this is  
enough of a savings to make a LITERAL- exception optimization useful.   
Especially since the place where saving a network packet helps the  
most -- mobile -- is precisely the location where the message lengths  
are likely smaller and thus more likely to fall under the exception.

michael

---

From: Dave Cridland <[email-masked]>
Date: Fri, 19 Dec 2014 09:26:34 +0000

On 17 December 2014 at 18:35, Alexey Melnikov <[email-masked]>
wrote:
>
>  I revived and updated LITERAL+ extension. I also added LITERAL- extension
> (same as LITERAL+, but disallowed in APPEND).
>
>
Given the current discussions, wouldn't LITERAL- be better expressed as a
LITERAL+ with a limited size? I accept that the normal case for a large
literal is APPEND,  but the issue is a general one with the size of the
literal rather than the specific case of APPEND, isn't it?

This could even be an advertised token-sequence limit, but that's probably
too hard to express. Possible, though, to limit the amount of
non-synchronized literal data with an entire command, which'd handle the
MULTIAPPEND case as well.

To give an specific case, a client can always side-step a simple APPEND
LITERAL+ limit by just using CATENATE in a fairly abusive manner.

Dave.