RE: HTML in MIME messages

[Steve Dorner <[e-mail]>]

At 1:01 PM 11/15/94, Mark K. Joseph wrote:
>1) HTML really does require machine processing to properly
>   present the information it encodes.  For example, HTML can
>   contain an indication of where text is BOLD or italics.

So can TEXT/enriched.

>  This has a likeness to postscript.

Only hell has a likeness to postscript.  :-)  PostScript presents unique
problems, and is clearly not text by almost any definition of the term.

>2) HTML can contain URLs (or URIs) which require machine processing
>   to obtain data, for example an FTP to pull over an image in GIF format.
>   I see no parallel to standard TEXT (have I missed something here?).

I know of much "plaintext" software that understands what URL's mean.  It
is also useful to copy a URL out of an HTML document, and paste it into a
web browser.  In fact, it is these two acts that make me most believe that
text is the right placement for HTML.  I want the URL's to be displayed on
the user's screen, if nothing else.

>3) The notation used in HTML is meaningless to the unsophisticated
>   user (like my mom!).  It will only confuse the unsophisticated
>   user if his/her mail reader just displays the raw HTML.

What is the choice?  The unsophisticated user (like my wife!) is certainly
not going to know that it really is *safe* to display HTML on her screen,
thus rendering the information in the body part not *confusing*, but rather
*inaccessible*.

>4) HTML is a mark up language that "just" happens to be in ASCII.
>   If it didn't use ASCII then we wouldn't even be having this
>   discussion.

Your quote placement indicates that you realize that HTML didn't "just
happen" to be ascii.  It's deliberately ascii, so that it can be composed
and, if need be, viewed, without special software.  Sounds familiar.

I don't think there's any way we can justify text/enriched and
application/html.  They go in the same bins.

There's been some noise that the reason text/enriched goes under text is
because it's supposed to be kept simple by the composing software.  My
position is that a) it is defined in such a way that it will be *less*
simple on any given text than more powerful markup languages and b)
composers are going to ignore such qualitative requirements in droves.

If you want to argue that the ONLY subtype of text should be plain, and
that absolutely nothing other than textual content is allowed in a text
part, you will have some company.  But that's not what the spec currently
says and no one has convinced me that's what it ought to say.

-- It seems silly to me to have a text type and allow only one subtype.
-- If no markup is allowed, then text/enriched should be application/enriched.
-- Every type that requires newline canonicalization will have to be
explicitly known to every mailer.
-- Every type that requires charset information will have to be explicitly
known to every mailer.

--
Steve Dorner, Qualcomm Incorporated.  "Oog make mission statement."