[Bug 10954] plain text processing breaks text/plain; format=flowed

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10954

--- Comment #5 from Julian Reschke <julian.reschke@gmx.de> 2010-10-04 07:17:26 UTC ---
(In reply to comment #4)

Note that we're starting to get off-topic. The main point of this bug was to
point out that it cites the format=flowed spec as normative, but then doesn't
seem to appear to allow flowed handling.

> I think the IETF mindset of just copying the email stuff over to HTTP has been
> a mistake. (See CRLF line breaks and US-ASCII default for text/*, for one.)

In retrospective, that's true. But I'm sure this sounded like a good, pragmatic
idea when it was introduced.

> format=flowed exists because legacy email protocols wanted the payloads to have
> limited line lengths. HTTP has no such limitation, so it's OK to send long
> chunks of text between line breaks over HTTP.

Indeed. We're doing cleanup where we can, compare for instance RFC2231 and 5987
(the continuation line mechanism is gone).

> If you meant backwards-compatibility with UAs that don't soft-wrap long lines,
> I can see a potential use case there, but is there a reason to believe that Web
> authors who aren't IETF WG participants would use format=flowed over HTTP if UA
> supported it?

Among those who currently serve text/plain with wide lines? Probably.

> > As far as I understand, that would be a change over what's being done today.
> 
> A style change--not a DOM change.

Just asking. It's not always clear what kind of change is considered to be
acceptable. For instance, I'm very surprised that anybody is interested in the
DOM generated for text/plain (or is even assuming there is one).

> > I'm not sure how the DOM exposed for something that hasn't got any support
> > today is really relevant.
> 
> Suppose the spec said UAs are allowed but not required to implement a
> PLAINTEXT_flowed state alongside the PLAINTEXT state and could use
> PLAINTEXT_flowed for text/plain; format=flowed. The PLAINTEXT_flowed state
> removed line breaks preceded by a space. Now the DOM for text/plain;
> format=flowed resources would be different in UAs that do the
> allowed-but-not-required thing and UAs that don't.

Yes. So? After sll, that's an effect of what the author of the document wanted.
Why not trust her/him?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 4 October 2010 07:17:29 UTC