MBOX-Line: From mrc at Washington.EDU  Sun Feb  3 15:07:48 2008
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@Washington.EDU>
Date: Fri Jun  8 12:34:41 2018
Subject: [Imap-protocol] non-ASCII byte sequences in IMAP? 
In-Reply-To: <08Feb3.150115pst."58696"@synergy1.parc.xerox.com>
References: <08Feb3.133012pst."58696"@synergy1.parc.xerox.com>
	<alpine.OSX.1.00.0802031403290.16772@pangtzu.panda.com>
	<08Feb3.150115pst."58696"@synergy1.parc.xerox.com>
Message-ID: <alpine.OSX.1.00.0802031503090.16772@pangtzu.panda.com>

On Sun, 3 Feb 2008, Bill Janssen wrote:
> I think that explicitly using ASCII where the spec calls for it, and
> raising errors for incorrect non-ASCII codings, will result in fewer
> subtle bugs in programs that use this client library.

I would substitute "UTF-8" for "ASCII" in the above statement.  Only 
generate ASCII unless non-ASCII is explicitly permitted, but allow 
incoming UTF-8 even for "ASCII" fields.

For example, do NOT send a non-ASCII flag name, but don't keel over if a 
UTF-8 flag name shows up from a server.  And if such names do start 
showing up, we can discuss switching off your "do not send non-ASCII flag 
name" code.

>> In particular, UTF-8 mailbox names will probably happen sooner rather than
>> later.
> Fine, but that will be an extension.  I imagine there's some
> discussion of using standard RFC 2231 mail header charset quoting when
> transferring such mailbox names across the wire?

I think that there's more interest in just switching to UTF-8 and be done 
with it.  I don't think that we're there yet though.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

