[issue44660] email.feedparser: support RFC 6532 section 3.5
Francis Johnson
report at bugs.python.org
Fri Jul 23 20:27:53 EDT 2021
Francis Johnson <business at francisjohnson.org> added the comment:
The first paragraph of section 3.5 states two positions that the RFC holds on Content-Transfer-Encodings:
(1) “allows newly defined MIME types to permit content-transfer-encoding;” and
(2) “allows content-transfer-encoding for message/global (see Section 3.7) [sic].”
The second position refers to and combines with section 3.7 (namely the “Encoding considerations” paragraph) to support my interpretation that implementations should accurately parse "message/global Emails with non-identity Content-Transfer-Encodings” (how I have paraphrased it). For quick reference, “non-identity” refers to the “quoted-printable” and “base64” Content-Transfer-Encodings.
The first position “suggests” a wider breadth, but I do not think its words “necessitate” it. For, the RFC lists only one “newly defined MIME type;” whereas a media/MIME type in general (in this case, all others) only affects the scope of RFCs that define/update it.
So I think my interpretation is precise if one defers to section 3 of the RFC.
Now, admittedly, two other sections in the RFC seem to contradict section 3.5 by broadening the scope (Abstract, p. 2; Introduction, s. 1, p. 3). I’m not super hung up on how to resolve the contradiction; but I think, at a minimum, the missing support for “message/global” should be added.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44660>
_______________________________________
More information about the Python-bugs-list
mailing list