On Fri, 10 May 2019 12:58:22 -0400, Ken Hornstein said:
And many MIME-extension-fields may be present. https://www.rfc-editor.org/rfc/rfc2045.html#section-9 suggests that's a header matching /^content-/i, including `Content-: foo', I presume, unless some RFC says a header can't end in a `-'.Huh, that's a new one for me. RFC 5322 says:
Section 9 is essentially reserving a namespace for MIME-specific
headers.
9. Additional MIME Header Fields
Future documents may elect to define additional MIME header fields
for various purposes. Any new header field that further describes
the content of a message should begin with the string "Content-" to
allow such fields which appear in a message header to be
distinguished from ordinary RFC 822 message header fields.
MIME-extension-field := <Any RFC 822 header field which
begins with the string
"Content-">
So the two of you are in what's often referred to as "violently in agreement" :)
Yeah, I am TRYING to understand the reasoning for the deletion of the Content-Type header; it was clearly deliberate and existed way back in MH 6.8.3 (and earlier; the earliest version I can find of mhn.c had that
My under-caffeinated mind is whispering about a myth regarding ancient software on SunOS that stuck in things like 'Content-Type: uuencode' when using its pre-MIME scheme for sending non-text data. Of course, that was before recorded history^W^WGoogle, so records are sketchy, incomplete, and contradictory. There is even rumor that that some machines stored 6 6-bit or 5 7-bit bytes in one memory location, and as a result special incantations were needed if you wished to converse with a font of knowledge known as "simtel20".
pgpikcgxORrax.pgp
Description: PGP signature
-- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers