35 lines
1.5 KiB
Plaintext
35 lines
1.5 KiB
Plaintext
MBOX-Line: From janssen at parc.com Sun Feb 3 15:01:07 2008
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bill Janssen <janssen@parc.com>
|
|
Date: Fri Jun 8 12:34:41 2018
|
|
Subject: [Imap-protocol] non-ASCII byte sequences in IMAP?
|
|
In-Reply-To: <alpine.OSX.1.00.0802031403290.16772@pangtzu.panda.com>
|
|
References: <08Feb3.133012pst."58696"@synergy1.parc.xerox.com>
|
|
<alpine.OSX.1.00.0802031403290.16772@pangtzu.panda.com>
|
|
Message-ID: <08Feb3.150115pst."58696"@synergy1.parc.xerox.com>
|
|
|
|
> However, if I were you, I would NOT make any ASCII assumptions in a new
|
|
> implementation. Implement with the assumption that ALL strings are UTF-8
|
|
> by default, but that for the time being you can only send ASCII except in
|
|
> the defined circumstances you mentioned above.
|
|
|
|
Thanks. Actually, at the moment, I'm looking at Python's imaplib
|
|
client-side library. Python, in the move to the next major version,
|
|
is adding an explicit sequence-of-bytes type (instead of the 8-bit
|
|
string type it previously used), and I'm looking at how to do
|
|
appropriate bytes-to-string conversions in data read from the wire.
|
|
|
|
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.
|
|
|
|
> 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?
|
|
|
|
Bill
|
|
|