On Mon June 6 2005 21:32, Ned Freed wrote:
You appear to have missed section 4.2, which says:
[...]
Far from giving text generators carte blanche to generate long lines in hopes
they'll be wrapped by the receiver, RFC 3676 reiterates and even strengthens
the recommendation (it cannot be a requirement since there are cases where
long
lines are unavoidable) that text/plain material use short lines.
My complaints with 3676 and its predecessor are that it force-fits content
markup (pages 6 through 11 of 3676) onto a format that explicitly is not
allowed content markup ("plain"; RFC 2046 sect. 4.1.3 "no interpretation
of embedded formatting commands, [...] or content markup should be
necessary for proper display"), is based on silly assertions, e.g.
sect. 3.3 "programs treat unknown subtypes of TEXT as an attachment" vs.
RFC 2045 sect. 4.1.4 "Unrecognized subtypes of 'text' should be treated
as subtype 'plain'" (modulo unrecognized charset issues),
interoperability-busting rules, e.g. sect. 4 "any content-transfer-encoding
used is irrelevant to the processing of flowed text" vs. RFC 2045 sect. 5
"MIME implementations must ignore any parameters whose names they do not
recognize" ("format" was not a parameter defined for text/plain when that
media type was defined, so it is reasonable for implementations to not
recognize it (i.e. ignore it) and treat transfer encoding as originally
specified), etc.
What RFC 3676 does is enhance the ability to display plain text on displays of
varying sizes. And none of these benefits would accrue if a different media
type had been used.
Given the bogosity of the "treat [...] as an attachment" claim, and the
reality that MIME conforming implementations treat unrecognized text
subtypes as text/plain, precisely why couldn't this markup format have
been handled as another subtype (e.g. text/flowed)?