Subject: Re: text/xhtml+xml vs. application/xhtml+xml
From: Mark Baker <[email-masked]>
To: Rick Jelliffe <[email-masked]>
Cc: [email-masked]
Date: Mon, 06 Nov 2000 11:23:17 -0500
List-Id: <ietf-xml-mime.imc.org>

Sorry for my tardy response ...

Rick Jelliffe wrote:
> Perhaps it would be better to redefine text/* to clarify that readability
> by naive readers is not the defining characteristic, but that the freedom
> of intermediate systems to transcode it (perhaps even at the cost of
> losing characters, how awful) is.

It sounds like you're suggesting that only text/* types can be
transcoded.  I disagree.  text/* types are currently (AFAIK) the only
types to be transcoded because the user agent has additional information
about the encodings on these types that allow it to always access the
content.  While it's true that processors of application/* types don't
have this additional information available to them, the use of "+xml"
changes that, and allows transcoding.

Note that this isn't written down anywhere.  However, in considering
application/xhtml+xml vs. text/xhtml+xml, I did thoroughly review the
MIME RFCs and draft-murata-xml to ensure that nothing precluded
application/xhtml+xml (or any application/*+xml type) described-content
from being transcoded.

I hope this is consistent with others' views.

MB

From: Keith Moore <[email-masked]>
To: Rick Jelliffe <[email-masked]>
cc: John Cowan <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: text/xhtml+xml vs. application/xhtml+xml 
Date: Thu, 02 Nov 2000 09:40:22 -0500
Sender: [email-masked]

> The people in my office love HTML mail. They do not use public mailing
> lists. It may be inconvenient for technocrats, but HTML is popular.

'technocrats' have nothing to do with it.

There are lots of data formats that work well in limited environments.
MIME allows consenting adults to happily exchange mail in a wide 
variety of limited use formats, including MS Word, Powerpoint, RTF,
PDF, and even HTML - and the ability to do this is popular.  But what 
is acceptable between consenting adults is not necessarily acceptable
in public.  

HTML might become acceptable eventually - once 99% of user agents 
can display it effectively, and without creating security or privacy
risks for those who read it.  Until that time, recipients are quite
justified in rejecting it, and they don't need to be technocrats to
do so.  Sending garbage to someone else's screen is simply rude.

Keith

p.s. I have used mh for many years and I haven't found anything more
effective for what I need to do.  Since mh's MIME support is pretty
primitive, I've been writing new versions of some of the mh commands.
I wrote a version of the 'show' command that handles MIME fairly 
well and which decodes and displays most HTML constructs.   What
I've found is that for the most part, the only messages which actually
make use of HTML (as opposed to sending HTML which displays identicallly
to the text/plain portion) are spam.  

so a user agent that refuses to display HTML (detects it and refuses
to display it, rather than displaying garbage) actually makes a fairly
effective spam filter.

Date: Thu, 2 Nov 2000 09:06:20 -0500
To: "[email-masked]" <[email-masked]>
From: Dave Peterson <[email-masked]>
Subject: Re: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

At 6:16 PM +0800 11/2/00, Rick Jelliffe wrote:
>On Wed, 1 Nov 2000, John Cowan wrote:

>  > Common practice for senders is to send mail in HTML, or both text and HTML.
>>  Common practice for receivers is to despise HTML mail; it is banned
>>  on most public mailing lists.
>
>The people in my office love HTML mail. They do not use public mailing
>lists. It may be inconvenient for technocrats, but HTML is popular.

But people whose mailer doesn't handle HTML mail get screwed--mail becomes
almost uninterpretable.  And visually handicapped people don't appreciate
having fonts and font sizes forced upon them.  Even I find that most people's
incoming HTML mail displays in a size too small to read, so I have to go
through the process of highlighting and resizing for every such message.
Occasionally I just trash them, and often I'm tempted to.

You should know your receiver before sending HTML mail.  If you don't know
that they can handle it easily, don't do it.  I doubt it's just the technocrats
running mailing lists that don't like the HTML; it's probably that they get
complaints from their users.  Who are people with hardware, software, or
visual restrictions that make HTML mail, like most accessibility-unfriendly
web sites, very much a pain in the neck or other part of the anatomy.
-- 
Dave Peterson
SGMLWorks!

[email-masked]

Date: Thu, 2 Nov 2000 18:16:26 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: John Cowan <[email-masked]>
cc: "[email-masked]" <[email-masked]>
Subject: Re: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

On Wed, 1 Nov 2000, John Cowan wrote:

> Rick Jelliffe wrote:
> 
> > What user frustration would it cause to bless common practise?
> 
> Common practice for senders is to send mail in HTML, or both text and HTML.
> Common practice for receivers is to despise HTML mail; it is banned
> on most public mailing lists.

The people in my office love HTML mail. They do not use public mailing
lists. It may be inconvenient for technocrats, but HTML is popular.

Rick Jelliffe

Date: Wed, 01 Nov 2000 16:34:27 -0500
From: John Cowan <[email-masked]>
Organization: Reuters Health Information
To: Rick Jelliffe <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

Rick Jelliffe wrote:

> What user frustration would it cause to bless common practise?

Common practice for senders is to send mail in HTML, or both text and HTML.
Common practice for receivers is to despise HTML mail; it is banned
on most public mailing lists.

-- 
There is / one art                   || John Cowan <[email-masked]>
no more / no less                    || http://www.reutershealth.com
to do / all things                   || http://www.ccil.org/~cowan
with art- / lessness                 \\ -- Piet Hein

Date: Thu, 2 Nov 2000 04:09:37 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: [email-masked]
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

On Wed, 1 Nov 2000, Simon St.Laurent wrote:

> I can't say I encourage anyone to use text/* for uses other than plain text
> at this point.

Yes, and actually I guess that dumb transcoding of xml is something that
should not be encouraged anyway. 

Rick Jelliffe

Date: Wed, 01 Nov 2000 15:04:10 -0500
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

At 03:53 AM 11/2/00 +0800, Rick Jelliffe wrote:
>On Wed, 1 Nov 2000, Dan Kohn wrote:
>
>> RFC 2646 was exactly about dealing with these practical issues of how to
>> role out new functionality within text/* without generating user
>> frustration.
>
>What user frustration would it cause to bless common practise?

I think Dan was describing the frustration of users who get to sort out
mostly incomprehensible junk in their email or in other areas.

I don't find HTML mail especially fun to read by hand, and I used to have
problems with people sending me RTF as text and expecting me to do
something with it. 

I'd say I was pretty frustrated, personally.  My current email program
(Eudora 4.1) still barfs on HTML email containing XML processing
instructions, like Microsoft Word 2000 output.  If that wasn't all spam,
I'd be really genuinely irritated.

I can't say I encourage anyone to use text/* for uses other than plain text
at this point.

Common practice is sometimes best practice, sometimes not.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books

From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Wed, 1 Nov 2000 15:02:05 -0500
Importance: Normal
Sender: [email-masked]

> Gavin, I just want to point out that no one is arguing that 
> MHTML is a bad thing.

I'm sorry for going down a rat hole. My reaction was to Keith's
statements...

  >I think the general consensus of the MIME community is that making HTML
  >a subtype of "text/" was a mistake.
  ...
  >So IMHO we should learn from this experience and make XHTML and other
  >XML-ish things subtypes of application/.

and I was just trying to point out that text/* is fine for some things...
for example text/xml *if* the text is generic/not application specific.
For example, if I have a multipart message with an XML document, and
a CSS stylesheet, I think text/xml would be fine for the XML (and
perhaps application/css for the CSS ;-)).

Apart from that I agree with the general direction.

Date: Thu, 2 Nov 2000 03:53:51 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: Dan Kohn <[email-masked]>
cc: [email-masked]
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

On Wed, 1 Nov 2000, Dan Kohn wrote:

> RFC 2646 was exactly about dealing with these practical issues of how to
> role out new functionality within text/* without generating user
> frustration.

What user frustration would it cause to bless common practise?

Rick Jelliffe

From: Dan Kohn <[email-masked]>
To: Rick Jelliffe <[email-masked]>
Cc: [email-masked]
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Wed, 1 Nov 2000 11:51:28 -0800 
Sender: [email-masked]

>Making text/* rely on being naively readable makes it only useful for
>plain text and Wiki. 

But unfortunately, that is precisely the situation, because unknown subtypes
of text default to text/plain, so the material MUST be understandable to
naive users.

We can all agree that it would be great to go back 8 years and have done x
or y differently, but then people in hell would like a glass of ice water
too.

RFC 2646 was exactly about dealing with these practical issues of how to
role out new functionality within text/* without generating user
frustration.

To quote Larry Masinter on a previous issue within the draft, "We live in a
complex world of our own making."

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

From: Dan Kohn <[email-masked]>
To: Gavin Thomas Nicol <[email-masked]>, [email-masked]
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Wed, 1 Nov 2000 11:24:05 -0800 
Sender: [email-masked]

Gavin, I just want to point out that no one is arguing that MHTML is a bad
thing.  It's just that in retrospect, we wish application/html had been
used.  But, just because we are locked into text/html, does not mean that we
need to repeat the same mistakes for new media types.

For a description of the evolving view of where text types are (and are not)
appropriate, see Section 3.3 of RFC 2646
<http://www.normos.org/ietf/rfc/rfc2646.txt> and Section 3 of
<http://www.imc.org/draft-murata-xml>.  (For a description of when to do
+xml, see Section 7 of the latter.)

Further, it has been stated that it is better to have a single registration
rather than registering under both text and application, since if we are
having trouble evaluating the tradeoffs, it seems unlikely that most
document authors would understand the subtlety.  I subscribe to section 3.2
of RFC 1958 on Architectural Principles of the Internet, which says, "If
there are several ways of doing the same thing, choose one."

>From my understanding, everyone else on this list agrees with this
direction, and sees a certain consistency there.  Rather than doing a line
by line rebuttal of certain points, could I suggest that you state an
alternative viewpoint for future registrations (such as "always do text
unless the material is binary"), and then we can compare that viewpoint to
the ones listed above.

Otherwise, the discussion becomes needlessly abstract.

		- dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

-----Original Message-----
From: Gavin Thomas Nicol [mailto:[email-masked]]
Sent: Wednesday, 2000-11-01 09:59
To: [email-masked]
Subject: RE: text/xhtml+xml vs. application/xhtml+xml

> This continued argument about the exact nature of past 
> mistakes is going nowhere fast, so I'm not going to
> bother to respond further to it.

Fine. One question though... 

Given

  1) choices for types
        text/xml
        application/xml
        application/foo+xml
  2) clear guidelines on their use.

do *you* have faith that developers
will do what is right?

Date: Thu, 2 Nov 2000 03:04:54 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: Gavin Thomas Nicol <[email-masked]>
cc: [email-masked]
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

On Wed, 1 Nov 2000, Gavin Thomas Nicol wrote:

> The point is that there is a use driven by a need. 

Can I jump on my hobby horse and say that text/html does serve a useful
purpose, but perhaps it is not the purpose for which it was created but
merely a side-effect: that being that it signals that transcoding and
newline massaging is allowed, in effect.

If it turns out that HTML does not fit into the definition or intent of
the text/* type, then I suggest that the definition of text/* does not
capture practise enough.  

Perhaps it would be better to redefine text/* to clarify that readability
by naive readers is not the defining characteristic, but that the freedom
of intermediate systems to transcode it (perhaps even at the cost of
losing characters, how awful) is.  The distinction therefore should be
the old, useful one of "text" versus "binary" with application/* being
binary.

Making text/* rely on being naively readable makes it only useful for
plain text and Wiki. 

Rick Jelliffe

From: [email-masked]
Date: Wed, 01 Nov 2000 10:00:27 -0700 (PDT)
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
To: Gavin Thomas Nicol <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > This continued argument about the exact nature of past
> > mistakes is going nowhere fast, so I'm not going to
> > bother to respond further to it.

> Fine. One question though...

> Given

>   1) choices for types
>         text/xml
>         application/xml
>         application/foo+xml
>   2) clear guidelines on their use.

> do *you* have faith that developers
> will do what is right?

I think the above is necessary but not sufficient. Past experience has shown
that no matter how clear you make the guidelines, people will misinterpret them
or not read them at all.

What does work is to add a registration process that people actively want to
use and sound review and feedback as part of that process. In hindsight, not
having this initally in MIME was what led to most past problems with media
types.

But we have such a process in place now, and it appears to be working. And I see
no reason to presume it won't continue to work.

				Ned

Date: Wed, 01 Nov 2000 13:24:00 -0500
To: <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

At 12:59 PM 11/1/00 -0500, Gavin Thomas Nicol wrote:
>Given
>
>  1) choices for types
>        text/xml
>        application/xml
>        application/foo+xml
>  2) clear guidelines on their use.
>
>do *you* have faith that developers
>will do what is right?

I do, actually.

I've spent a fair amount of time dealing with developers who got so used to
text/html that they figured text/xml was the way to go.

It doesn't take much explaining to get them to shift to application/xml for
light use and application/xyz+xml for cases where they want to identify
their types further.  

So far, that explaining's been on a one-on-one basis through email and
conference encounters, but the explaining hasn't been the hard part.  The
hard part is just getting people to think about it in the first place.

When we have an RFC to point to, I'm planning on posting more general
discussion of these issues to xml-dev, xml-l, and comp.text.xml.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books

From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Wed, 1 Nov 2000 12:59:28 -0500
Importance: Normal
Sender: [email-masked]

> This continued argument about the exact nature of past 
> mistakes is going nowhere fast, so I'm not going to
> bother to respond further to it.

Fine. One question though... 

Given

  1) choices for types
        text/xml
        application/xml
        application/foo+xml
  2) clear guidelines on their use.

do *you* have faith that developers
will do what is right?

From: [email-masked]
Date: Wed, 01 Nov 2000 09:18:17 -0700 (PDT)
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
To: Gavin Thomas Nicol <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

This continued argument about the exact nature of past mistakes is going
nowhere fast, so I'm not going to bother to respond further to it.

			Ned

From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Wed, 1 Nov 2000 11:40:06 -0500
Importance: Normal
Sender: [email-masked]

> > > 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.