[Imap-protocol] re: GMail
arnt at gulbrandsen.priv.no
Mon Oct 29 04:08:07 PDT 2007
Uh, we've gone from "need utf-8 flags" to "should convert message data
to utf-8 in the server" in a very short time, and personally I see very
little justification for the latter.
Mark Crispin writes:
> On Sun, 28 Oct 2007, Arnt Gulbrandsen wrote:
>> But an extension to say only "use UTF-8 for mailboxes and flags
>> (instead of mUTF-7)" makes even more sense. UTF-8 flags have real
> Well, there's several possible ways to go about doing all this.
> Consider all of these to be strawmen.
I thought about the same options when I implemented mUTF-7, except that
your strawman for 2 is slightly better than what I had in mind.
> 1) An "ENABLE UTF-8" command that throws a big switch. Rather unIMAPish.
IFF a big switch is the right way to solve it, I like this, but... hm...
how shall I say this? IMO, the value of ENABLE is O(1/n), where n is
the number of times it is used, so I'd prefer to keep n small.
> 2) UTF8 FETCH, UTF8 LIST, UTF8 LSUB commands. IMAPish, but somewhat
> pessimistic about the future of certain extensions.
That also needs UTF8 SELECT (for the flag-related responses), UTF8
LISTRIGHTS, UTF8 STATUS and perhaps UTF8 GENURLAUTH and UTF8 URLFETCH.
I didn't like RLIST+RLSUB, so I find it hard to be charmed by this crowd.
> 3) Make CONVERT do ENVELOPE/BODY[STRUCTURE] for those who want it, and
> add a UTF8 option to LISTEXT. Somewhat optimistic about these
(This doesn't handle UTF-8 flag and mailbox names.)
I speculate that the audience for doing message data conversion in the
server is the same as the audience for CONVERT. Most clients support
local mailboxes or POP, and so they don't get any benefit.
So my tentative conclusion is to say that 1 is a lesser evil than 2,
make the change affect only LIST, FLAGS and PERMANENTFLAGS responses,
and leave message data conversion to the people who want convert.
More information about the Imap-protocol