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

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 Apr 2013 17:16:54 +0100

Hi,
I've decided to start on update to LITERAL+ based on the recent mailing 
list discussion. Please let me know what you think.

-------- Original Message --------
Subject: 	I-D Action: draft-melnikov-rfc2088bis-00.txt
Date: 	Tue, 23 Apr 2013 09:12:30 -0700
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
	Author(s)       : John G. Myers
                           Alexey Melnikov
	Filename        : draft-melnikov-rfc2088bis-00.txt
	Pages           : 5
	Date            : 2013-04-23

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.

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

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

---

From: Dan Karp <[email-masked]>
Date: Tue, 23 Apr 2013 09:22:40 -0700 (PDT)

> I've decided to start on update to LITERAL+ based on the recent mailing list
> discussion. Please let me know what you think.

I think that if you're revising LITERAL+, it might not be a bad idea to set
a hard cap on both the size of a single LITERAL+ literal and the number of
LITERAL+ literals permissible in a single command.

- Dan

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 Apr 2013 18:02:21 +0100

> LITERAL+ literals permissible in a single command.
I don't think we can retroactively introduce the limit for all 
implementations. We can however add a new capability (or something 
similar) for advertising limits for implementations that want to enforce 
them. (And this is one of my ToDo items).

We can of course add recommendations about minimal limits, etc. But 
these should not break existing implementations, IMHO.

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 23 Apr 2013 20:08:41 +0300

On 23.4.2013, at 20.02, Alexey Melnikov <[email-masked]> wrote:

> I don't think we can retroactively introduce the limit for all implementations. We can however add a new capability (or something similar) for advertising limits for implementations that want to enforce them. (And this is one of my ToDo items).
> 
> We can of course add recommendations about minimal limits, etc. But these should not break existing implementations, IMHO.

Any hardcoded limits (or recommendations) will become outdated in a few years. At some point I'm sure people would rather waste sending 1GB of traffic than wait for the latency roundtrip.

---

From: Dan Karp <[email-masked]>
Date: Tue, 23 Apr 2013 11:25:14 -0700 (PDT)

> Any hardcoded limits (or recommendations) will become outdated in a few
> years. At some point I'm sure people would rather waste sending 1GB of
> traffic than wait for the latency roundtrip.

If we're trying to clarify the original RFC, it's better to make the
constraints on non-synchronizing literals explicit.  A client may be
fine sending an extra 1GB of data... or it might not.  Likewise for a
server.  It seems like a good idea to give client authors enough context
that they don't make the mistake of sending a too-large LITERAL+ literal
in the first place.

If we want to draw the line between non-synchronizing literals for
commands and non-synchronizing literals for data, I don't see a problem
with setting a hard upper limit for non-synchronizing literal size in
the RFC.  If we don't want to draw such a line, then perhaps an untagged
response (e.g. "* [MAXLITERAL 10000000]") sent upon authentication.

But we really should tell the client what the limits are.

- Dan

---

From: Michael M Slusarz <[email-masked]>
Date: Tue, 23 Apr 2013 13:18:04 -0600

> response (e.g. "* [MAXLITERAL 10000000]") sent upon authentication.

I'm with Timo that I don't think there should be hardcoded limits  
within the RFC itself.  But I agree with you, and I don't think Timo  
is arguing otherwise, that a server can, and most likely should,  
advertise limits on what it will accept.  The latter allows the data  
limitations to be scaled to whatever resource constraints exist in the  
future (say: 802.11zzz connections, with 5000 Gb/s bandwidth).  And if  
a server wants to accept gigabytes of data, more power to it - that is  
their design choice and they shouldn't be prevented from doing so.

I think if we are going to announce limits, then it makes sense to  
advertise separate limits for
1) APPEND data and
2) everything else.

The latter would aid clients in determining the maximum command size  
allowed on a server, rather than the nebulous "shouldn't send more  
than 1000 octets" we currently have in RFC 2683 -- the  
assumption/requirement being that the literal command limit should be  
equal to a server's maximum allowable command size.

michael

___________________________________
Michael Slusarz [[email-masked]]

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 23 Apr 2013 22:15:26 +0000

while we're talking about such things, we should revisit the hard-limit 
on any IMAP message of 4GB (max unsigned 32 bits).

I think the time will come quite soon where this limit is unsufficient

As for LITERAL+ limits, our implementation drops to file over a 
threshold, so can go as large as there is free disk space.  It would be 
more work to figure out a limit to advertise than it's worth for us, so 
lack of advertisement should mean no restriction.

Until there is some sort of append / catenate there's no opportunity to 
split the literals up anyway.

Adrien

------ Original Message ------
From: "Michael M Slusarz" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 24/04/2013 7:18:04 a.m.
Subject: Re: [imapext] I-D Action: draft-melnikov-rfc2088bis-00.txt
>within the RFC itself. But I agree with you, and I don't think Timo is 
>arguing otherwise, that a server can, and most likely should, advertise 
>limits on what it will accept. The latter allows the data limitations 
>to be scaled to whatever resource constraints exist in the future (say: 
>802.11zzz connections, with 5000 Gb/s bandwidth). And if a server wants 
>to accept gigabytes of data, more power to it - that is their design 
>choice and they shouldn't be prevented from doing so.
>
>allowed on a server, rather than the nebulous "shouldn't send more than 
>1000 octets" we currently have in RFC 2683 -- the 
>_______________________________________________
>imapext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/imapext