Hi Bill,
Of course, I don't believe that "enriched" should be a text sub-type, either.
Well, then what should it be? If you removed it, all that would remain would
be essentially be text/plain -- and perhaps text/simpletext -- but what would
be the point with it? Using plain text is fine as an alternative body part,
but it would be rather limiting if that's all there was.
I have two points:
1. RTF is a text format directly comparable with Enriched and ought to be
registered the same way. Having it confined to the application type is
essentially saying that it should be used only for attachments.
2. Text/Enriched is nice, but much too limited. If you're willing to take
the effort of implementing it, you might as well go all the way and adopt a
mature standard that is more capable. Enriched goes to great lengths to
avoid any metrics -- such as explicit font sizes, line heights, tab stops,
etc -- but I believe this to do more bad than good. Wouldn't it be better to
make the data as rich as possible and let the interpreter do as good job with
it as it can than to limit the data transmitted and thus lower the quality
with it?
That is to say, wouldn't it be better to be able to say things like "9 point,
Helvetica, indented 1 inch, in color <252, 95, 95>" than "small, indented,
red". With the former, I have some chance of communicating the actual
appearance of the text; with the latter, it's pretty much just guesswork --
and I'll never be able to do things like specific alignments for bulleted
lists. If you define a standard metric, you can induce things like "9 point"
=> "smaller", but you can't go the other way around without losing
information.
Or is it rather that the majority of MIME folk aren't very interested in
exchanging "higher resolution" text or see it as practically unobtainable?
--Lennart