Re: Folding of long lines in message bodies

> 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