Perhaps a more general way of focusing on one question under discussion
is, "Should any Markup Language be a subtype of Text?" Put aside, for
a moment, the fact that such subtypes already exist. The current
discussion recognizes a spectrum of, shall we say, markup complexity:
text/plain no markup
text/enriched limited markup
text/html some markup
text/x-sgml yet more markup, maybe a lot
text/x-yaml yet another...with gobs of markup
With this view the questions become, where and how do we draw the line.
About "extended text", the MIME spec says, "text with embedded
formatting and presentation information ... are to some extent readable
even without the software that intreprets them". One could easily
quibble about the details here. Urls aren't formatting information.
Is SGML markup format? The SGML community argues forcefully that SGML
is logical, not format, markup.
Let's ignore these details and look at the larger issue, "How do we
define operationally, 'to some extent readable'?" I suggest a rough
consensus exists that it's a judgment call, but finding a rough
consensus on a *particular* markup language will be difficult. So
difficult, in fact, that I suggest a higher standard for
text/NOTplain.
The standard for text/NOTplain should be, "Do we ask vendors to
implement it *inside* their user agents?". Under that standard any
text/NOTplain subtype must be a standards track RFC. That will
include requiring base and interoperable implemenations. It will
insure that a time will come when the large portion of the installed
base will be able to handle it "out of the box". It also insures that
the IETF community is aligned.
Best.../Ed