MBOX-Line: From nicolson at google.com  Mon Jun 30 14:19:54 2014
To: imap-protocol@u.washington.edu
From: =?UTF-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= <nicolson@google.com>
Date: Fri Jun  8 12:34:53 2018
Subject: [Imap-protocol] UTF8=ACCEPT and modified utf-7 mailbox names
In-Reply-To: <50b7b4b0-ec42-4447-a0f1-b9241f1d1984@gulbrandsen.priv.no>
References: <CACU8CfQ-ybGqgOhAU+Kug+BEopXLNGEJ7LFb0Jbby4LVa8m+4g@mail.gmail.com>
	<50b7b4b0-ec42-4447-a0f1-b9241f1d1984@gulbrandsen.priv.no>
Message-ID: <CACU8CfSic52Y3+fScveyeHxjWq_MASvCvJYPX=3DjaukpX+8+w@mail.gmail.com>

Good, definitely makes more sense that way. Why enable the extension if
you're not willing to use UTF-8?.


On Mon, Jun 30, 2014 at 2:13 PM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
wrote:

> On Monday, June 30, 2014 10:23:39 PM CEST, Jamie Nicolson (???) wrote:
>
>> Suppose a server supports RFC 6855 (UTF8=ACCEPT) and the client has
>> ENABLEd it. Is it still permissible for the client to send modified UTF-7
>> encoded mailbox names, or is the client then required to use UTF-8 for
>> mailbox names?
>>
>
> IMO, required to use UTF8...
>
>
>  I'm wondering if the server code should bother running mailbox names
>> through the UTF-7 decoder after UTF-8 mode has been enabled. If the server
>> is going to decode the mailbox names, then the client must continue to
>> escape '&' characters as "&-".
>>
>
> ... because that escaping is not in 6855.
>
> Arnt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140630/fe64c727/attachment.html>
