From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 35507@debbugs.gnu.org
Subject: bug#35507: Gnus mojibakifies UTF-8 text/x-patch attachments from Thunderbird
Date: Wed, 01 May 2019 20:32:22 +0300 [thread overview]
Message-ID: <83d0l2qdw9.fsf@gnu.org> (raw)
In-Reply-To: <44a26585-7980-378c-9262-a567ddd3e617@cs.ucla.edu> (message from Paul Eggert on Tue, 30 Apr 2019 12:20:58 -0700)
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 30 Apr 2019 12:20:58 -0700
>
> Although Internet RFC 2046 section 4.1.2 says the default charset for
> text/* media types is US-ASCII, Internet RFC 6557 section 3 amends this
> to say that registered text/* media types should require a charset
> specification (or should say it's not needed because the payload has
> that info, which obviously doesn't apply here). It later says that if
> there is a strong reason to have a charset default, the default should
> be UTF-8.
(You meant RFC 6657, I believe.)
That's not exactly my reading of the RFC language. First, it sounds
like the text there is primarily intended for the sending MUA, not for
the receiving MUA. And second, this text:
In order to improve interoperability with deployed agents, "text/*"
media type registrations SHOULD either
a. specify that the "charset" parameter is not used for the defined
subtype, because the charset information is transported inside
the payload (such as in "text/xml"), or
b. require explicit unconditional inclusion of the "charset"
parameter, eliminating the need for a default value.
In accordance with option (a) above, registrations for "text/*" media
types that can transport charset information inside the corresponding
payloads (such as "text/html" and "text/xml") SHOULD NOT specify the
use of a "charset" parameter, nor any default value, in order to
avoid conflicting interpretations should the "charset" parameter
value and the value specified in the payload disagree.
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.
Regardless of what approach is chosen, all new "text/*" registrations
MUST clearly specify how the charset is determined; relying on the
default defined in Section 4.1.2 of [RFC2046] is no longer permitted.
However, existing "text/*" registrations that fail to specify how the
charset is determined still default to US-ASCII.
seems to say that:
. it is preferable, for new types of text/* media, not to have any
default charset, unless there's a strong reason to the contrary
. all new text/* registrations must specify how the charset is
determined, and not rely on the default from RFC 2046
Is text/x-patch a "new media type" or not? If it is not new, then
where is it defined? I couldn't find it on the IANA site.
If it _is_ "new", my reading of the RFC is that we should not define
or expect any defaults, which means this bug is squarely in
Thunderbird's yard, and we shouldn't change Gnus to arbitrarily assume
UTF-8 as the default.
> I have filed a Thunderbird bug report for this, as Thunderbird should
> specify a charset; see
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1167982>. However, Gnus
> should be a polite citizen and handle these attachments nicely rather
> than converting the non-ASCII UTF-8 characters to mojibake.
Does Gnus have a command to re-decode an already decoded MIME part?
If not, it should. But other than that, I don't see why we should
change Gnus in this regard, certainly not unconditionally assuming
UTF-8.
next prev parent reply other threads:[~2019-05-01 17:32 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-30 19:20 bug#35507: Gnus mojibakifies UTF-8 text/x-patch attachments from Thunderbird Paul Eggert
2019-05-01 0:35 ` Andy Moreton
2019-05-01 15:22 ` Robert Pluim
2019-05-01 15:45 ` Andy Moreton
2019-05-01 16:42 ` Andy Moreton
2019-05-01 17:36 ` Eli Zaretskii
2019-05-01 23:54 ` Andy Moreton
2019-05-02 3:07 ` Noam Postavsky
2019-05-02 7:17 ` Andy Moreton
2019-05-02 11:04 ` Eli Zaretskii
2019-05-02 15:43 ` Andy Moreton
2019-05-02 15:57 ` Eli Zaretskii
2019-05-02 16:08 ` Andy Moreton
2019-05-02 16:50 ` Eli Zaretskii
2019-05-02 17:13 ` Eric Abrahamsen
2019-05-02 17:45 ` Andy Moreton
2019-05-02 16:10 ` Basil L. Contovounesios
2019-05-02 16:50 ` Eli Zaretskii
2019-05-02 17:20 ` Eli Zaretskii
2019-05-03 13:55 ` Basil L. Contovounesios
2019-05-02 16:29 ` Robert Pluim
2019-05-02 16:53 ` Eli Zaretskii
2019-05-02 12:01 ` Noam Postavsky
2019-05-02 15:40 ` Eli Zaretskii
2019-05-03 14:02 ` Basil L. Contovounesios
2019-05-03 15:14 ` Eli Zaretskii
2019-05-03 15:20 ` Basil L. Contovounesios
2019-05-01 17:34 ` Eli Zaretskii
2019-05-02 6:35 ` Robert Pluim
2019-05-01 17:33 ` Eli Zaretskii
2019-05-01 17:32 ` Eli Zaretskii [this message]
2019-05-01 18:26 ` Paul Eggert
2019-05-01 19:05 ` Eli Zaretskii
2019-05-01 19:47 ` Andreas Schwab
2019-05-01 19:57 ` Eli Zaretskii
2019-05-02 23:24 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83d0l2qdw9.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=35507@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.