Francis Johnson <busin...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue44660> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
