ietf-822
[Top] [All Lists]

Re: Folding of long lines in message bodies

2005-06-07 11:11:41

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"),

Note the "should be necessary". I see no prohibition here.

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),

Unfortunately this is far from silly. Quite a few programs suffer from this
defect. Attempts to get them to change have been made and AFAIK have been
totally unsuccessful.

interoperability-busting rules, e.g. sect. 4 "any content-transfer-encoding
used is irrelevant to the processing of flowed text"

This statement should be true of text/plain regardless of whether or not RFC
3676. Unfortunately there are known cases of programs conflating CTE usage with
formatting. This statement is an attempt to make it clear this is unacceptable.

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.

There is no vs or conflict to be found here. If you believe otherwise it sure
sounds like you're misinterpreting what RFC 3676. The irrelevance of the CTE
does NOT mean the CTE hshould not be processed in the usual way. Rather, it 
means that the actual CTE used should not be used as a basis for how the text
gets displayed.

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)?

Been there, tried that. Not once, not twice, but three times: text/richtext,
text/enriched, and text/simpletext. None of them were in any way succesful.
format=flowed, OTOH, has been somewhat succesful. Not as much as I'd like, and
I blame that mostly on format=flowed setting its sights a bit too low. There
should have been explicit text attempting to convert the horrible use of long
lines with the expectation that they will be wrapped for display by the
recipient.

                                Ned