I think we
should first define a "core" set of primitives, and have a header
Content-Type: text/enhanced; version=1
and then people could experiment with
Content-Type: text/enhanced; version=x-2
Micro-suggestion: If you want to go this way, structure the version
notation so that you can distinguish between supersets ("core" plus some
stuff) and changed versions (modifications to the core).
Actually, that's exactly what I intended. The string "enhanced"
indicates the core, and the version indicates the superset (version 1
being equivalent to the core).
"Modifications to the core" would use a different subtype name (i.e.
But I would make a different argument for simplicity: Let's try to keep
this down to features that are clearly needed by a very large fraction
of the text-based messages that float around the network. Ideas that
are "nice" should be ruthlessly excluded and dumped onto SGML and
similar strong formatters.
Well, I almost agreed with you, but when you think about it, *if*
repeat *if* text/enhanced catches on, and people want to improve it,
we had better have some sort of extension mechanism in place from the
beginning. And *if* SGML never catches on, we'd be glad that we
allowed extension of text/enhanced.
Note that I'm *not* saying that SGML will never catch on. (I used the
word "if" very, very carefully.)
(By the way, is it possible to write an SGML definition (DTD?) geared
towards the *...* syntax? Are SGML's syntax rules *that* flexible?)