From: Kai Henningsen (kaih@khms.westfalen.de)
Date: Sat Apr 07 2001 - 02:37:00 CDT
rra@stanford.edu (Russ Allbery) wrote on 04.04.01 in <ylg0fo2hyi.fsf@windlord.stanford.edu>:
(that was in news.software.readers, comp.sys.mac.apps; originally about
form feed)
> Overriding followup to poster since this is a fairly interesting point.
>
> In news.software.readers, Thomas LEMOINE <thomas@wkaz.net> writes:
> > beaker@llama.pilz.cack (bkrrrrr) writes:
>
> >> I don't see any advantage to letting the hordes of people wandering
> >> into USENET with half-baked "newsreaders" mangle the standards.
>
> > In which RFC is your so-called standard documented?
>
> It isn't. There was some discussion of adding it to USEFOR, which I
> oppose unless it's there purely as informational material and is not
> normative.
>
> This is a conflict with MIME, and MIME should win. A text message
> declared to be text/plain without format attributes is an unstructured
> blob of text. Requiring additional interpretation to portions of the body
> that is not specified in the description of text/plain is a horribly bad
> idea and conflicts directly with the guarantees of the MIME standard.
>
> If someone wishes to standardize such things as quoting characters,
> attribution lines, signature delimiters, spoiler characters, and other
> sorts of ad hoc structure in unstructured text, they should go the route
> of formally defining a MIME type (or more likely an attribute for
> text/plain since software will handle that better) that states what formal
> definition they're using. In the absence of that, you're making software
> guess, with more and more complicated heuristics. This is precisely the
> sort of random, poorly implemented, and generally incompatible behavior
> that MIME was designed to get away from, and in this area MIME is
> completely 100% correct to avoid it.
>
> I have a similar problem with any standard that *requires* that something
> be done with signatures. If the message is declared text/plain with no
> attributes, you don't know that that's a signature, and nothing in the
> standard says that you can make that determination. Requiring ad hoc
> parsing is the fundamentally wrong approach. It's simply bad engineering.
As much of this "informal markup" stuff is also useful in mail, the usefor
*standard* may not be the right place for this anyway, but I suspect I'll
find most interested people here.
Format=flowed (which includes signature and quote characters) went out as
proposed standard; I don't know if that would really buy us anything here,
so I suspect an informational RFC would be just fine.
Stuff I'd like to see in such a thing:
Spoiler-char use of form feed
*bold* _underlined_ and /slanted/ text
Possibly mention various backspace-highlighting methods as not really
appropriate to this format
Anything else? Anyone else interested in this? Any bright ideas on how
this should interact with f=f?
MfG Kai