Subject: Re: c-client literals in LIST ?

From: "Edmund GRIMLEY-EVANS" <[email-masked]>
Date: Wed, 09 Aug 2000 16:46:37 +0100

How will UTF-8 be implemented in IMAP?

Will the character '&' continue to be encoded as "&-" even when UTF-8
is in use? If not, how will you avoid the ambiguity of "&-"? How will you
encode the characters 0x00-0x1f and 0x7f?

Also, it wasn't clear to me from RFC 2060 whether the "Unicode 16-bit
octets" [sic] are always single characters or whether surrogates can be
used to represent characters above 0xffff. (I suspect that surrogates are
allowed and I should modify some code I wrote ...)

Edmund

---

From: Mark Crispin <[email-masked]>
Date: Fri, 11 Aug 2000 10:36:36 -0700 (PDT)

> allowed and I should modify some code I wrote ...)

The bogus "Unicode 16-bit octets" text of RFC 2060 was fixed in the draft of
the updated base specification.

Yes, surrogates are allowed.  So, if you convert to a 16-bit form, you must
convert to UTF-16, not UCS-2.

If you're trying to assume a continued relationship between string length and
number of characters, not even UCS-4 will do that for you.  Remember combining
characters (deep sigh)!

---

From: "Edmund GRIMLEY-EVANS" <[email-masked]>
Date: Mon, 14 Aug 2000 09:26:46 +0100

> convert to UTF-16, not UCS-2.

Thanks. Another thing for my TODO list.

> number of characters, not even UCS-4 will do that for you.  Remember combining

Since I'm using slang/curses, I'm more interested in the number of character
cells that a string requires for display, which is even less directly related to
the length of the representation ...

Are you going to answer my questions about how UTF-8 will be implemented
in IMAP?

Edmund