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.


