On Wed, Dec 14, 2011, at 11:21, Stefan Sperling wrote:
> On Wed, Dec 14, 2011 at 12:10:25PM +0200, Daniel Shahaf wrote:
> > Andreas' attachment declared itself as
> > Content-Type: text/x-patch; charset=us-ascii; name="german-fuzzy-0.diff"
> > but contained literal [ü»«] characters.
> > Andreas, you should consider fixing that, so it's easier to process
> > your patches.
> This could also be an interoperability problem between mutt and gmx.
> The charset is correct as far as the encoded base64 form is concerned.
> Should the charset= header apply to the encoded or the decoded form?
> Of course, always assuming ascii for the encoded form makes sense for
> base64. But what about other encodings? Not sure what RFCs say here.
The charset= applies to the decoded form. If you were to introduce
base128 which encodes arbitrary files into an 8-bit encoding, you'd use
Content-Transfer-Encoding: 8bit on the message as a whole (and
Content-Transfer-Encoding: base128 on the attachment MIME part).
In particular: consider the case of a binary attachment. It won't be
text/plain and hence won't have a charset= parameter. But the MIME
headers still have to say how it's encoded (literally, base64, quoted-
Received on 2011-12-14 12:22:37 CET