64 lines
2.7 KiB
Plaintext
64 lines
2.7 KiB
Plaintext
MBOX-Line: From arnt at gulbrandsen.priv.no Mon Oct 29 04:08:07 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
|
Date: Fri Jun 8 12:34:40 2018
|
|
Subject: [Imap-protocol] re: GMail
|
|
In-Reply-To: <alpine.OSX.0.9999.0710280923190.11181@pangtzu.panda.com>
|
|
References: <alpine.WNT.0.9999.0710241938220.520@Shimo-Tomobiki.Panda.COM>
|
|
<fc2c80ae0710270911o23f0b366g942b2956ac3fa@mail.gmail.com>
|
|
<alpine.WNT.0.9999.0710270924180.4788@Shimo-Tomobiki.Panda.COM>
|
|
<5202.1193523708.069559@peirce.dave.cridland.net>
|
|
<alpine.OSX.0.9999.0710271708460.11181@pangtzu.panda.com>
|
|
<1193531029.25921.561.camel@hurina>
|
|
<alpine.WNT.0.9999.0710271748490.204456@Ningyo-no-Mori.Panda.COM>
|
|
<RMRLrFbL0dA92HCVkk6Cgw.md5@libertango.oryx.com>
|
|
<alpine.OSX.0.9999.0710280923190.11181@pangtzu.panda.com>
|
|
Message-ID: <d1klUHoFkFbXOtQmbn1Bww.md5@libertango.oryx.com>
|
|
|
|
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
|
|
>> value.
|
|
>
|
|
> 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
|
|
> extensions.
|
|
|
|
(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.
|
|
|
|
Arnt
|
|
|