[Users] Mailing patches and utf-8

[Ricardo Mones]

  Hi Michael,

On Sat, Sep 29, 2012 at 11:41:50PM +0200, Michael Gmelin wrote:
> Hi,
> 
> I mailed a patch containing utf-8 characters recently and at the
> receiving side the characters got garbled. Claws itself shows the patch
> correctly.
> 
> The mime structure is:
> 
> ...
> Mime-Version: 1.0
> Content-Type: multipart/mixed; boundary="MP_/l2SRWsGWoVAuwHaSxfL=MMK"
> 
> --MP_/l2SRWsGWoVAuwHaSxfL=MMK
> Content-Type: text/plain; charset=US-ASCII

  This is not really necessary, as default charset for text/plain is alredy
US-ASCII (See: http://tools.ietf.org/html/rfc2046#section-4.1.2 and
newer http://tools.ietf.org/html/rfc6657#section-4)

> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> Blablablablabla
> 
> --MP_/l2SRWsGWoVAuwHaSxfL=MMK
> Content-Type: text/x-patch

  IMO, the problem is here, which doesn't specify a charset, and being an x-
subtype doesn't have any specification written [0].

> So the attachment has no charset whatsoever (which I think is correct,
> since quote printable itself is 7bit ASCII and in the absence of any
> further charset specification the receiving end should either assume
> ASCII or UTF-8 (which both - when applied transparently - shouldn't
> yield the results I've seen). Based on the results it seems that the
> receiving side converts it to a different default charset.
> 
> So, am I correct to assume that Claws handled this correctly and that I
> should contact the maintainer of the receiving side to figure out what
> went wrong?

  As said, AFAIK there's no specification for x-patch subtype, so I guess
that lacking charset parameter the receiver should at most assume ASCII
(the default for text/plain). If you say applying ASCII the results are
not what they see, then, yes, they're converting with the wrong charset.

  Requesting UTF-8 display without charset=UTF-8 parameter is a bit
strong IMO. It would conform to RFC 6657 3: «Thus, new subtypes of the
"text" media type SHOULD NOT define a default "charset" value.  If there
is a strong reason to do so despite this advice, they SHOULD use the "UTF-8"
[RFC3629] charset as the default.», but this is not a must, this is from 2
months ago, and again the x-patch is not a defined subtype.

  If receiver has some fallback encoding or fallbacks to an environment
encoding which matches attachment encoding this could be handled correctly.
  
  Unfortunately there's no way to set the attachment charset in Claws Mail
attachment properties dialog, so you can assign the proper encoding for
them.

  regards,

[0] http://www.iana.org/assignments/media-types/text/index.html
-- 
  Ricardo Mones 
  ~
  Absence of evidence is not evidence of absence.          Carl Sagan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20121002/109c7048/attachment.sig>