86 lines
3.3 KiB
Plaintext
86 lines
3.3 KiB
Plaintext
MBOX-Line: From alexey.melnikov at isode.com Fri Nov 9 08:48:20 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Alexey Melnikov <alexey.melnikov@isode.com>
|
|
Date: Fri Jun 8 12:34:40 2018
|
|
Subject: [Imap-protocol] Internationalizing IMAP (was GMail)
|
|
In-Reply-To: <d1klUHoFkFbXOtQmbn1Bww.md5@libertango.oryx.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>
|
|
<d1klUHoFkFbXOtQmbn1Bww.md5@libertango.oryx.com>
|
|
Message-ID: <47348F54.1010007@isode.com>
|
|
|
|
Arnt Gulbrandsen wrote:
|
|
|
|
> 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.
|
|
|
|
IMHO, a big switch might be easier to implement and test (both on the
|
|
server side and on the client side).
|
|
|
|
I've discussed this with Chris Newman in context of
|
|
draft-ietf-eai-imap-utf8 and I think Chris also had the opinion that
|
|
this is the way to go.
|
|
|
|
>> 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.
|
|
|
|
+1.
|
|
|
|
> I didn't like RLIST+RLSUB, so I find it hard to be charmed by this crowd.
|
|
|
|
Indeed. That is exactly why I started co-editing of the LISTEXT document.
|
|
|
|
>> 3) Make CONVERT do ENVELOPE/BODY[STRUCTURE] for those who want it,
|
|
>> and add a UTF8 option to LISTEXT.
|
|
>
|
|
FYI, the latest [expired] version of draft-ietf-eai-imap-utf8 defines a
|
|
LISTEXT option.
|
|
|
|
>> 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.
|
|
|
|
I prefer the choice # 1, followed by 3 and then followed by 2.
|
|
|
|
|