[Imap-protocol] Internationalizing IMAP (was GMail)

[Alexey Melnikov]

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.