But the analogy is gravely flawed in any case -- text/html
has proved to have no value whatsoever. And this goes far
beyond the notion of "good" and "bad" use.
I think the millions of messages sent using text/html would
disprove the notion that "text/html has proved to have no value
whatsoever".
Actually, the type's use proves nothing, since as I pointed out
previously, it isn't necessary to use the type to get the
right effect.
The point is that there is a use driven by a need. Your statement
that "text/html has proved to be of no value whatsoever" is simply
false. The fact is that text/html (while being used in ways other
than strictly intended), has served a tremendous use in allowing
people to exchange richer email messages than text/plain.
And you are arguing a strawman here. I never said that sending HTML
was of no use, only that the labelling of it as text/html was and
is unnecessary.
"unnecessary" != "no value whatsoever"
The community adopted text/html because they weren't presented
with any other mechanism (or at least, the alternatives weren't
presented anywhere nearly as clearly or forcibly). The community
made great use out of it.
Anyway, the genie *is* out of the bag.
For HTML it is. Doesn't mean it is out of the bag for other
types. We should learn from our mistakes.
I agree. I think *the* mistake (at the MIME level)with HTML
is *not* text/html, but rather one of specification and under
education: text/html could have been registered, and the
specification could have clearly stated that alternatives
existed for use when the amount of markup rendered the message
essentially uninterpretable.
That said, I would argue that the real mistake is in abusing
HTML in the first place, but that practise is well established
now.
Because it isn't what we told them to do. We told them to use
text/html, so that's what they did.
Right. They were not presented with a choice, and *that* is the
historical mistake.
But we also said that the HTML had to be legible. That didn't
happen.
Sure, but what else could have happened? Vendors were shoe-horning
HTML support onto existing tools, and there was a marketing need to
get products shipping with support for exchanging HTML content.
The point is now we know better, so we should not let it happen
again.
I strongly agree with you. That to me means presenting
1) choices for types
2) clear guidelines on their use.
I have faith that when presented with those two things, developers
will do what is right.
I believe my argument discounts it quite effectively.
Well, belief is a very personal, very subjective thing. I do *not*
believe your argument discounts it at all. Your arguments seem to
me to be an overreaction to something I think we can all agree is
less than perfect.
In addition, I haven't noticed a lot of support for other
quarters for your approach.
Perhaps people are just tired of debate and are moving with their
feet? XML 1.0 *has* been around for a long time, and SGML, even
longer.
Developers come to the IETF looking for guidance in standards
conformant deployment. In lieu of a standard, a draft will
suffice. In lieu of a draft, rough concensus will suffice.
I think the developer community has largely already made up
it's mind.