MBOX-Line: From arnt at gulbrandsen.priv.no  Sun Oct 28 02:38:19 2007
To: imap-protocol@u.washington.edu
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Date: Fri Jun  8 12:34:40 2018
Subject: [Imap-protocol] re: GMail
In-Reply-To: <alpine.WNT.0.9999.0710271748490.204456@Ningyo-no-Mori.Panda.COM>
References: <alpine.WNT.0.9999.0710241938220.520@Shimo-Tomobiki.Panda.COM>
	<fc2c80ae0710270911o23f0b366g942b2956ac3fa@mail.gmail.com>
	<alpine.WNT.0.9999.0710270924180.4788@Shimo-Tomobiki.Panda.COM>
	<5202.1193523708.069559@peirce.dave.cridland.net>
	<alpine.OSX.0.9999.0710271708460.11181@pangtzu.panda.com>
	<1193531029.25921.561.camel@hurina>
	<alpine.WNT.0.9999.0710271748490.204456@Ningyo-no-Mori.Panda.COM>
Message-ID: <RMRLrFbL0dA92HCVkk6Cgw.md5@libertango.oryx.com>

Mark Crispin writes:
> On Sun, 28 Oct 2007, Timo Sirainen wrote:
>> Converting message bodies would break cryptographic signatures. 
>> Converting headers automatically might also do bad things. I guess 
>> ENVELOPE, BODY and BODYSTRUCTURE could be returned converted, but I 
>> don't know if that helps much.
>
> Right, which is why FETCH should remain unchanged.

I haven't looked at CONVERT recently, but from what I remember, it can 
handle charset conversion. That leaves ENVELOPE, BODY, BODYSTRUCTURE, 
mailbox names and flags. So a new extension to say "give me those in 
UTF-8" makes sense to me.

But an extension to say only "use UTF-8 for mailboxes and flags (instead 
of mUTF-7)" makes even more sense. UTF-8 flags have real value. But I 
assume most clients need 8859-1 and 2047 support for other reason, 
andso changing the way ENVELOPE, BODY and BODYSTRUCTURE works doesn't 
really make life simpler for them.

Arnt

