35 lines
1.4 KiB
Plaintext
35 lines
1.4 KiB
Plaintext
MBOX-Line: From mrc at Washington.EDU Sun Feb 3 14:06:02 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.133012pst."58696"@synergy1.parc.xerox.com>
|
|
References: <08Feb3.133012pst."58696"@synergy1.parc.xerox.com>
|
|
Message-ID: <alpine.OSX.1.00.0802031403290.16772@pangtzu.panda.com>
|
|
|
|
On Sun, 3 Feb 2008, Bill Janssen wrote:
|
|
> I'm looking at the various uses of CHARSET in IMAP. It appears to
|
|
> occur in two places: the SEARCH command, and the FETCH response. I
|
|
> think it can also appear in the message literal in the APPEND command.
|
|
> So those are the only three places where an IMAP server (or client)
|
|
> might see non-ASCII byte streams. Everything else is ASCII.
|
|
|
|
That's probably correct for the base specification. Don't forget such
|
|
things as URLFETCH and CATENATE, which are forms of FETCH and APPEND
|
|
respectively.
|
|
|
|
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.
|
|
|
|
In particular, UTF-8 mailbox names will probably happen sooner rather than
|
|
later.
|
|
|
|
-- 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.
|
|
|