[prev in list] [next in list] [prev in thread] [next in thread] 

List:       imap
Subject:    Re: [Imap-protocol] Apple's iCloud server non-compliant!
From:       Mark Crispin <mrc+imap () panda ! com>
Date:       2011-10-31 23:32:14
Message-ID: alpine.OSX.2.00.1110311605540.9034 () hsinghsing ! panda ! com
[Download RAW message or body]

On Tue, 1 Nov 2011, Bron Gondwana wrote:
> Not really - you're already scanning to see if it's particularly long.
> We shove everything more than 1024 bytes into a literal in Cyrus,
> without even parsing it.  And you need to parse the whole thing for
> " characters anyway unless you're going to be REALLY bogus about it,
> so your CPU argument doesn't hold any water.

+1.

Don't forget \ too.

>  Easy to just set the
> "must_send_literal" flag when you see the first 8 bit character, at
> which point you can stop scanning and just shove the bytes onto the
> wire with a {size}\r\n in front.

Yup.

Quoted strings are an abomination. They may be more human-readable, but
parsers do better with Hollerith type strings (e.g., literals) that do not
require prescanning.

I probably would abolish atoms as well, except for reserved tokens in
IMAP. Most software these days doesn't use atoms for astrings even when it
can be an atom.

> Ahh, error messages.  No, I don't know what to do about that either - but
> I'm not so concerned so long as you don't eject endline characters in them.

I would not object to an extension that says "all the world is now UTF-8
instead of ASCII" that redefines CHAR to CHAR8. In fact, I thought that
was what the i18n extension did at its second level.

There remains a problem with 8-bit characters that are not UTF-8.

My ideal is "death to all charsets other than UTF-8". We are closing in on
15 years from RFC 1930. People should have gotten the word by now. To be
honest, I am shocked that we still have this discussion today and have not
forced UTF-8 everywhere.

> Cyrus rejects messages with a bare \n I think.

Good. All the world is not UNIX. More to the point, the Internet standard
newline is \r\n.

>> The real peach though is probably MULTIAPPEND which wants us to allow
>> a virtual infinite amount of data upload in a single transaction.
>> Even if we figured out a way to handle that given our constraints, we
>> wouldn't want to do it since the worst possible outcome there is to
>> throw the entire thing away on failure.  Just spend a couple hours
>> uploading it again!

If MULTIAPPEND is redesigned, the following changes are desirable:

[1] Require that the total size be declared in advance. The only (IMHO)
valid reason for a server to error on a MULTIAPPEND is "storage not
available". Most clients that MULTIAPPEND have ready access to the sizes
and can easily enumerate/sum these.

[2] Allow IMAP URLAUTHs ala CATENATE. This would be valuable for the use
case of transfer from one IMAP server to another (as opposed to upload
from the client). Most of the real-world use of MULTIAPPEND is this use
case; it's actually pretty rare to upload from a client.

[3] Have a mechanism to restart a MULTIAPPEND that got dropped. Require
that a client must restart within a certain time frame (TBD) and is
forbidden from doing another MULTIAPPEND if a "paused" MULTIAPPEND is in
progress. Add appropriate mechanisms to support all this.

IMHO, these changes would reduce most of the objections to MULTIAPPEND
while keeping its desired attribute of multi-message atomicity.

If someone cared to create a new MULTIAPPEND with these characteristics, I
would help with the document, and for my part encourage migration from the
current MULTIAPPEND to the new form.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-protocol mailing list
Imap-protocol@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
[prev in list] [next in list] [prev in thread] [next in thread]