Subject: Re: Finishing the XML-tagging discussion
From: [email-masked]
To: Harald Tveit Alvestrand <[email-masked]>
Cc: [email-masked]
Date: Wed, 22 Mar 2000 09:35:02 -0500
List-Id: <ietf-822.imc.org>

On Wed, 22 Mar 2000 12:49:52 +0100, Harald Tveit Alvestrand said:
> At 00:06 22.03.00 -0500, [email-masked] wrote:
> >I know of no way you could feed the headers to the XML program as
> >part of the input and still have valid XML.
> 
> the standard operating procedure in HTTP servers is to pass stuff like
> this in environment variables.

Right. But that's out-of-band, not part of the input file iteself.

Which is probably the Right Thing to do, as in-band is a Bad Idea (as Captain
Crunch taught the telcos ;)

/Valdis

Date: Wed, 22 Mar 2000 12:49:52 +0100
To: [email-masked], [email-masked] (Charles Lindsey)
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: [email-masked]
Sender: [email-masked]

At 00:06 22.03.00 -0500, [email-masked] wrote:
>I know of no way you could feed the headers to the XML program as
>part of the input and still have valid XML.

the standard operating procedure in HTTP servers is to pass stuff like
this in environment variables.
If I were to write a "CMI" (Common MIME interface) standard, I'd emulate that.
But I'm not.

            Harald
--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

From: [email-masked]
To: [email-masked] (Charles Lindsey)
cc: [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Wed, 22 Mar 2000 00:06:18 -0500
Sender: [email-masked]

On Tue, 21 Mar 2000 20:35:27 GMT, [email-masked] (Charles Lindsey)  said:
> If your system sees "application/xml" and has been configured to hand it
> off to a program "XML" (you can certainly configure Mozilla in that way)
> does the "XML" program get to see the complete message, including the
> Content-Type header (or does it just get to see the body).

Unfortunately, you're allowed to make approximately zero assumptions
regarding what an MUA has been written to do algorithm-wise.  I'd be quite
certain however that almost *no* MUAs would work this way.  If an attachment
is an image/jpeg, *exactly* a valid JPEG file is passed to the viewer.
if it's a text/html, only the HTML is passed to the renderer.

I know of no way you could feed the headers to the XML program as
part of the input and still have valid XML.  THe best you could hope
for is that the MUA (Mozilla, what have you) is able to do its OWN parsing
of the headers, and provide appropriate hints via command line switches
(similar to how, for instance, suggested filenames are passed for a
Content-Disposition: header).. This however involves code hacking on
both the MUA and the XML processor.  THis is further complicated
by the fact that your XML processor may very well be a generic handler
whos source you may not control, and who's vendor may not be interested
in cluttering up the command switches for all 397 different programs
that want to pass in special tweaks...  I know I'm limited to some
extent in what I can pass to Netscape if I ask it to open a window
and render HTML that I'm providing.  I'll have to check back after
I actually get Mozilla to build under AIX whether the same openUrl()
hack is supported for XML...

/Valdis

From: [email-masked]
Date: Tue, 21 Mar 2000 21:00:01 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> If your system sees "application/xml" and has been configured to hand it
> off to a program "XML" (you can certainly configure Mozilla in that way)
> does the "XML" program get to see the complete message, including the
> Content-Type header (or does it just get to see the body).

Few MIME handlers are capable of this. It is something that all of them should
support, but there's a gap between what should be available and what is.

Now, some handlers have limited capabilities of this sort. For example,
mailcap-based handlers often have the ability to put a particular parameter's
value on the command line using a substitution scheme.

> Because it "XML" gets to see the full Content-Type header, then you just
> make XML a shell script that examines the Content-Type header, spots the
> foobar and calls the foobar handler or, alternatively, if it doesn't see
> the foobar (or doesn't have a foobar handler to hand) then it calls the
> REAL (generic) xml handler.

Sorry, you cannot count on this ability.

				Ned

To: [email-masked]
Xref: clerew local.mime:386
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Finishing the XML-tagging discussion
Date: Tue, 21 Mar 2000 20:35:27 GMT
Lines: 40
Sender: [email-masked]

In <[email-masked]> "Simon St.Laurent" <[email-masked]> writes:

>At 08:17 AM 3/19/00 -0500, [email-masked] wrote:
>>If you go the "application/xml; Content-Feature=foobar" route, you're
>>DONE.  You don't have the added support handy, it just drops to
>>wherever you configured Mozilla to pass the stuff.  The grounds that
>>"its possible" here is that it's tagged as 'application/xml', which
>>should be sufficient for tagging that it's possible.  This is actually
>>*less* work to make work under Mozilla, at the expense of *not* passing
>>along a hint to Notepad/XMLSpy/whatever that it's a *FOOBAR* xml, not
>>just a generic xml.

>Rereading this paragraph raises further questions about the value of
>Content-Feature in my mind.  Less work under Mozilla, but not working with
>applications outside of a particular transaction framework (HTTP in this
>case) seems like an enormous overall loss to me.

Just a naive question here.

If your system sees "application/xml" and has been configured to hand it
off to a program "XML" (you can certainly configure Mozilla in that way)
does the "XML" program get to see the complete message, including the
Content-Type header (or does it just get to see the body).

Because it "XML" gets to see the full Content-Type header, then you just
make XML a shell script that examines the Content-Type header, spots the
foobar and calls the foobar handler or, alternatively, if it doesn't see
the foobar (or doesn't have a foobar handler to hand) then it calls the
REAL (generic) xml handler.
-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

Date: Tue, 21 Mar 2000 12:45:58 -0500
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 03:34 AM 3/21/00 -0500, [email-masked] wrote:
>If you haven't been in the industry long enough that it takes you more
>than 30 seconds to think of at least 5 vendors(*) of software who aren't
>dissuaded from doing something just because the standard says explicitly
>not to do that, you haven't been around enough to see *seriously* broken
>software.

I share your concerns with vendors who stray from standards, and spend far
too much of my time testing implementation conformance.

However, this paranoia about vendors doesn't mean that we shouldn't create
new standards or add new features to existing approaches.  It means that we
should be as clear as possible about what is specified, and make certain
that those new features will fit well within the context of those existing
approaches.

Vendors will stray, but at least we'll have something unambiguous to
compare them against.

So far as I can tell, this suffix is actually less prone to 'standards
drift' and has a greater chance of being adopted in the form in which it is
proposed than any of the parameter-based options presented as alternatives.

The existence of '*seriously* broken software' doesn't seem like an
argument against this particular innovation.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

From: [email-masked]
Date: Tue, 21 Mar 2000 10:39:34 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: John Cowan <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> [email-masked] wrote:

> > AFAIK, no. I don't see a reason to change an existing registration in any
> > case -- when we've made changes to the media types system in the past
> > we've grandfathered old registrations that don't "fit" the new rules.

> Not quite the issue.  VRML, which is not XML-compatible, is application/vrml.
> If VRML is reformulated to be XML-compatible (in a new version), do we
> then register application/vrml-xml?  I think we do.

Sure, and this is entirely consistent since what you're describing is a new
media type. (An old VRML handler certainly won't be able to process it...)

				Ned

Date: Tue, 21 Mar 2000 08:54:51 -0800
To: John Cowan <[email-masked]>, [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 11:43 AM 3/21/00 -0500, John Cowan wrote:
>Not quite the issue.  VRML, which is not XML-compatible, is application/vrml.
>If VRML is reformulated to be XML-compatible (in a new version), do we
>then register application/vrml-xml?  I think we do.

If/when that happens, it's not going to be called VRML any more; it's going
to be a new kind of thing.  I believe currently they go by the internal
monicker of "x3d"; so that would be

model/x3d-xml

The idea is to avoid the existence of both foo/bar and foo/bar-xml - SVG,
for example, plans to (already has?) register only image/svg-xml. -Tim

Date: Tue, 21 Mar 2000 11:43:23 -0500
From: John Cowan <[email-masked]>
Organization: Reuters Health Information
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

[email-masked] wrote:

> AFAIK, no. I don't see a reason to change an existing registration in any
> case -- when we've made changes to the media types system in the past
> we've grandfathered old registrations that don't "fit" the new rules.

Not quite the issue.  VRML, which is not XML-compatible, is application/vrml.
If VRML is reformulated to be XML-compatible (in a new version), do we
then register application/vrml-xml?  I think we do.

-- 

Schlingt dreifach einen Kreis um dies! || John Cowan <[email-masked]>
Schliesst euer Aug vor heiliger Schau,  || http://www.reutershealth.com
Denn er genoss vom Honig-Tau,           || http://www.ccil.org/~cowan
Und trank die Milch vom Paradies.            -- Coleridge (tr. Politzer)

From: [email-masked]
Date: Tue, 21 Mar 2000 06:41:09 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> On Mon, 20 Mar 2000 10:48:40 PST, [email-masked] said:
> > I note in passing that we've already registered some XML-based types
> > with an "XML" suffix, and no problems have been reported with this
> > usage.

> Has there been any registration of a 'foobar-xml' that duplicates
> an existing 'foobar', but with an XML wrapping?

AFAIK, no. I don't see a reason to change an existing registration in any
case -- when we've made changes to the media types system in the past
we've grandfathered old registrations that don't "fit" the new rules.

> If so, have any
> user agents been known to have been modified to use the -xml as the
> sort of trigger we have been discussing?

I always try to code stuff like this before making assertions as to its
ease of implementation. In this case I did so with the user agent I
use (PMDF MAIL). The changes for -xml handling were very simple and seemed
to work just fine.

I also attempted to code the changes for dispatching off of a global parameter
and adding a global parameter when sending. The former turns out to be doable
but kinda ugly; the latter isn't doable in my UA short of a new product release
because the format of a critical data file has to change to accomodate it. (I
don't have a complicated GUI to contend with either.)

FWIW, this also got me started looking at implementation of content-features
support in our software. This is, well, interesting. The facility is well
specified as far as I can tell, but part of it involves implementation of a
expression canonicalization routine. Now, I used to work on the symbolic
algebra system in a package called MATHLIB, so this is known territory for me,
but I wonder how well someone who's never done anything like this would handle
it. It certainly is way more complex than anything else we've discussed,
although its addition doesn't present a problem from an interface or file
compatibility standpoint.

And there's also the problem of generating feature expressions describing stuff
that varies from document to document -- as I see it this can be done either by
a generic analysis step or else by adding  some communications channels
composition programs can use. Both of these amount to pushing the problem off
to some other component, and I have to wonder whether or not composition agents
will actually evolve to the point of providing such information or analysis
programs of this sort will be written.

				Ned

From: [email-masked]
To: "Simon St.Laurent" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Tue, 21 Mar 2000 03:34:35 -0500
Sender: [email-masked]

On Mon, 20 Mar 2000 17:59:13 EST, "Simon St.Laurent" said:
> It's a plausible risk only if HTTP 1.1 or other protocols are explicitly
> reopened and modified.  Otherwise, it's pretty easy to point to the spec
> and say "No.  That's forbidden."  It might be a good idea to present these

If you haven't been in the industry long enough that it takes you more
than 30 seconds to think of at least 5 vendors(*) of software who aren't
dissuaded from doing something just because the standard says explicitly
not to do that, you haven't been around enough to see *seriously* broken
software.

Careful reading of the MIME specs will reveal that a *large* portion of
all the prohibitions against this, that, and the other thing aren't
there to prevent a good programmer from implementing something known to
be impossible.  The prohibitions are there to stop poor programmers
from implementing possible things incorrectly.

/Valdis

(*) Conglomerates such as IBM and Microsoft only count as one vendor
each, no matter how many offending companies/divisions they own.

From: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Tue, 21 Mar 2000 03:22:22 -0500
Sender: [email-masked]

On Mon, 20 Mar 2000 10:48:40 PST, [email-masked] said:
> I note in passing that we've already registered some XML-based types
> with an "XML" suffix, and no problems have been reported with this
> usage.

Has there been any registration of a 'foobar-xml' that duplicates
an existing 'foobar', but with an XML wrapping?  If so, have any
user agents been known to have been modified to use the -xml as the
sort of trigger we have been discussing?

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

Date: Tue, 21 Mar 2000 16:59:24 +0900
To: [email-masked], Keith Moore <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Cc: [email-masked], "Simon St.Laurent" <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 00/03/20 22:06 -0800, [email-masked] wrote:
> > now you're moving from the realm of specifying 'features' or
> > 'default handling' of the object into specifying layered encodings.
> > and this was something that we were very unwilling to do when
> > we defined MIME.  The feeling was that having an arbitrary
> > number of cascaded encodings was likely to be detrimental to
> > interoperability.
>
>I thought this too until I realized these were simply strawman names in
>Martin's example.

Exactly. Sorry for not having been clear enough.

Regards,   Martin.

From: [email-masked]
Date: Mon, 20 Mar 2000 22:06:41 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Keith Moore <[email-masked]>
Cc: "Martin J. Duerst" <[email-masked]>, [email-masked], "Simon St.Laurent" <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> now you're moving from the realm of specifying 'features' or
> 'default handling' of the object into specifying layered encodings.
> and this was something that we were very unwilling to do when
> we defined MIME.  The feeling was that having an arbitrary
> number of cascaded encodings was likely to be detrimental to
> interoperability.

I thought this too until I realized these were simply strawman names in
Martin's example. I wish he had used other names since the ones he chose invite
criticism of this sort. OTOH, we've been unable to come up with a good example
of a possible suffix that would be orthogonal to -xml...

In any case, MIME flatly forbids the specification of encodings as content
types, so this is a moot point.

				Ned

From: Keith Moore <[email-masked]>
To: "Martin J. Duerst" <[email-masked]>
cc: [email-masked], "Simon St.Laurent" <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Tue, 21 Mar 2000 00:56:53 -0500
Sender: [email-masked]

now you're moving from the realm of specifying 'features' or
'default handling' of the object into specifying layered encodings.
and this was something that we were very unwilling to do when
we defined MIME.  The feeling was that having an arbitrary
number of cascaded encodings was likely to be detrimental to 
interoperability.

Keith

Date: Tue, 21 Mar 2000 12:40:24 +0900
To: [email-masked], "Simon St.Laurent" <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 00/03/20 15:57 -0800, [email-masked] wrote:

>Let me try and state what I think the problem that have been brought up are:
>
>(1) We have to deal with what happens should another one of these suffixes
>     be defined at some point. Now, I have pointed out that we can define
>     things in such a way that this is defered until #2 comes along. But
>     if we want to tackle it now we certainly can. The simplest option is
>     to insist on these tags being in alphabetical order in any media type
>     name.

An alternative would be to state that these suffixes are to be
taken inside-out, or outside-in. Assuming outside-in, and
assuming 'charset', generic encodings, and RDF as strawman
examples, the sequence would be something like

text/example-rdf-xml-shift_jis-gzip

i.e. This stuff is RDF experssed in XML encoded in Shift_JIS
and compressed with gzip, or outside-in: To get at this stuff,
first decompress it with g(un)zip, then interpret it as
a sequence of characters encoded in Shift_JIS, then hand it
to an XML parser, and then to an RDF engine.

Regards,   Martin.

Date: Mon, 20 Mar 2000 22:58:05 -0500
To: Keith Moore <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 10:28 PM 3/20/00 -0500, Keith Moore wrote:
>> Again, please describe the impact.
>
>I have done so.  Repeatedly.  

Perhaps I am merely illiterate, but I haven't seen a single instance
proposed where the existence of the suffix, in the contexts proposed by the
I-D, actually breaks _anything_.  

If they're in the archives and I'm just incapable of finding it, I'd
appreciate a reference.  Pointing to them offlist is perfectly fine,
perhaps even preferable at this point.

In the meantime, I don't think you've proven your case of 'pollution'.  You
may well have proved that -xml doesn't solve all problems all the time (it
isn't intended to), but I don't think you've demonstrated that it causes
harm.  

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 22:28:27 -0500
Sender: [email-masked]

> Again, please describe the impact.

I have done so.  Repeatedly.  

Date: Tue, 21 Mar 2000 12:22:15 +0900
To: [email-masked], Keith Moore <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 00/03/20 15:21 -0800, [email-masked] wrote:

> > let me see if I understand you correctly: what you are saying is that
> > people will expect the new convention (whatever it is) to work and
> > control the recipient's MIME readers's fallback behavior even in
> > the presence of a  vast installed base that neither understands this
> > convention nor XML?
>
>No, that is not what I'm saying. What I'm saying is that a new agent, one that
>depends on the parameter being present, only works if it is present. And this
>then implies that a substantial number of agents need to send the tag in order
>for it to be useful. This won't happen soon if at all, so my agent that I 
>wrote
>which depends on the tag we've called for ends up not working.

All the experience that I have had and seen reported with the 'charset'
parameter suggests that this is indeed a problem. Adding another
parameter, and getting it to work, would take years. It is only
recently that e.g. Apache was updated to include an 'AddCharset'
directive to make it easier to set the charset on the Content-Type.

With -xml, you get immediate benefits. Webmasters will set the type
to image/svg-xml just because there is nothing else. Webmasters
won't be much inclined to add a parameter that looks obvious anyway.

Although I do not claim that 'charset' should have been a type
suffix (the benefits of having it orthogonal are big enough in
that case), I think all the experience from 'charset' clearly
points to -xml as the solution.

Regards,   Martin.

From: [email-masked]
Date: Mon, 20 Mar 2000 16:28:08 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Keith Moore <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > Requesting yet again.  Could we please have details of this horrible
> > problem inflicted by the -xml suffix?

> could we please have details of how conneg expressions or HTTP
> Accept headers could be used to say things like
> "I accept XML documents"?

accept-features: (syntax=xml)

My syntax is probably wrong but I'm sure you get the idea.

				Ned

From: [email-masked]
Date: Mon, 20 Mar 2000 15:57:29 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: "Simon St.Laurent" <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> Requesting yet again.  Could we please have details of this horrible
> problem inflicted by the -xml suffix?

Let me try and state what I think the problem that have been brought up are:

(1) We have to deal with what happens should another one of these suffixes
    be defined at some point. Now, I have pointed out that we can define
    things in such a way that this is defered until #2 comes along. But
    if we want to tackle it now we certainly can. The simplest option is
    to insist on these tags being in alphabetical order in any media type
    name.

(2) There is concern that this will lead to use of stuff like */*-xml in
    HTTP accept fields even if we specifically disallow it. I would like to
    address this by defining a conneg feature tag that says "the underlying
    syntax here is xml". This would be in addition to the "-xml" suffix, and
    would apply even to cases where media types aren't specified or where
    the -xml suffix isn't used.

If there are any other concrete problems I've missed them and would 
appreciate hearing about them.

				Ned

From: [email-masked]
Date: Mon, 20 Mar 2000 19:05:30 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > accept-features: (syntax=xml)

> yes, but you can't do that without either

> a) adding yet another frob to the object for this purpose
>    (which is separate from the content-type frob), or

Yep, which is why I've repeatedly proposed adding a feature tag for this
purpose in addition to the -xml suffix. 

Also note that adding a general content-type parameter doesn't work with conneg
either, since conneg only deals with media types, not their parameters. (This
is another one of those cases you don't seem to be worried about.) So this frob
is needed for conneg to work even with your proposal.

> b) teaching the conneg recognizer about the xml frob

Can't teach it about either the -xml suffix or the content-type parameter
very easily if at all. Conneg just doesn't work this way.

				Ned

From: Dan Kohn <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Finishing the XML-tagging discussion
Date: Mon, 20 Mar 2000 18:50:06 -0800
Sender: [email-masked]

>> but I have to wonder - how likely is it that such XML-ish things
>> will be generated by vanilla MIME user agents anyway?  isn't it
>> more likely that they will be generated by things that are XML-aware?

>They will be generated by XML-generation thingies but labelled by 
>MIME-generation thingies. I don't have to have a new user agent with
>XML-generation capabilities to use XML heavily.

As a specific example (which this thread has been conspicuously lacking), if
I attach an image/svg-xml file to this message and include the instructions
"Please copy the French text on the road sign", someone with an XML-aware
MIME client and an XML browser but no support for SVG can still probably
open the file and copy the text.  By contrast, I the sender have no way of
adding $superclass support to my existing mailer, let alone the receiver's.

I think the thread has probably laid clear most of the issues involved.
However, we can see from new people popping in mid-thread that these will
all be re-raised if and when we ever go to last call.

Therefore, I'm going to work with Simon and Murata-san to create an -03
draft that summarizes the alternatives to -xml and issues with them.  This
would most likely make sense as an appendix to the current draft.

Please let me know if you are unwilling for me to use text posted to the
list in these explanations (Ned, that especially mean you).  Also, although
we'll announce a new draft on ietf-822 as well, I'd suggest that
ietf-xml-mime would be the best list on which to continue this thread, given
that it was expressly created for that purpose.  People on ietf-822 are
probably (far too) aware of the situation by now.

		- dan
--
Daniel Kohn <mailto:[email-masked]>
tel:+1-425-602-6222  fax:+1-425-602-6223
http://www.dankohn.com 

Date: Mon, 20 Mar 2000 20:49:03 -0500
To: Keith Moore <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 08:29 PM 3/20/00 -0500, Keith Moore wrote:
>> I'm still looking for damage, though I'm concluding more and more that
>> there simply isn't any, and that this discussion is only circling.
>
>let me put it this way: some people are quite happy to pollute the MIME 
>content-type space, and to alter existing dispatching mechanisms and 
>existing content-negotiation mechanisms, in order to establish an ad hoc 
>recognition scheme for XML objects as quickly as possible.  others are 
>more concerned about the longevity of the overall MIME architecture and 
>want to see that the likely effects of such changes are carefully 
>considered before such changes are widely adopted or endorsed.

Carefully considered concerns are one thing, but evidence of actual damage
is another. Your bias is obvious, yet your concerns are unsubstantiated.

Do you have substantial evidence of real 'pollution'?  I'm quite happy to
carefully consider the impact of such pollution, but I have yet to see such
impact described in any credible detail.

Again, please describe the impact.

Thank you.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 20:29:24 -0500
Sender: [email-masked]

> I'm still looking for damage, though I'm concluding more and more that
> there simply isn't any, and that this discussion is only circling.

let me put it this way: some people are quite happy to pollute the MIME 
content-type space, and to alter existing dispatching mechanisms and 
existing content-negotiation mechanisms, in order to establish an ad hoc 
recognition scheme for XML objects as quickly as possible.  others are 
more concerned about the longevity of the overall MIME architecture and 
want to see that the likely effects of such changes are carefully 
considered before such changes are widely adopted or endorsed.

Keith

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 20:12:34 -0500
Sender: [email-masked]

> accept-features: (syntax=xml)

yes, but you can't do that without either
a) adding yet another frob to the object for this purpose
   (which is separate from the content-type frob), or
b) teaching the conneg recognizer about the xml frob

Keith

From: [email-masked]
Date: Mon, 20 Mar 2000 16:32:26 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Chris Lilley <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > > > An advisory parameter of this sort is a worthless parameter. If you cannot
> > > > depend on it appearing for every instance of a given content type you
> > > > cannot use it for anything.
> >
> > > that's not true.   if the parameter is missing then some opportunities
> > > to evaluate the object (in the absence of knowledge of the complete type)
> > > will be lost.  but that's not the same thing as "you cannot use it for
> > > anything".
> >
> > Something that I cannot count on being there is of no use to me, and, I
> > suspect, to anyone else who cares about this stuff. This has to be
> > dependable to be useful.

> by that argument nothing in MIME would be useful except the ability
> to handle text/plain; charset=us-ascii, since that's all that was
> there in RFC 822 and all that could be expected out of email recipients
> at the time MIME was deployed.

That is exactly how I would characterize MIME if it weren't the dominant format
in use today, and the only standardized format for multimedia in RFC822 mail.
Having more than one such format clearly would not be useful. (Indeed, this
exact argument has been used to keep other mechanisms at bay.)

> and I fail to see how special recognition of the -xml frob is any
> more likely than special treatment of a $superclass parameter.
> by your criteria above neither of these will be useful.

It's more likely to work because it's built into the media type, and generation
of correct media types is a solved problem.

> > > how is this kind of "failure" any different than the kind of failure
> > > that exists when a reader doesn't understand image/svg-xml and
> > > fails to recognize that the -xml suffix means that it can be
> > > treated as generic xml?
> >
> > It is different because I can do something about it -- I can upgrade
> > my software. Whereas in order to get benefit from your proposal I have
> > to upgrade the software that created the object I received -- software I
> > do not control. And in some cases I even have to upgrade the protocols
> > in use.

> okay.  I see that there is a higher barrier to adoption of
> $superclass than for -xml because the sender is more likely to
> be able to generate -xml than $superclass.

Finally!

> but I still think you overstate the hazard.  if someone sends you
> an image/svg content without the $superclass label you can still
> fix the problem on your end merely by defining a specific handler
> for image/svg.  true, it doesn't solve the problem for how to deal
> with large numbers of unanticipated XML-based types, but it will
> work on a small scale.

> but I have to wonder - how likely is it that such XML-ish things
> will be generated by vanilla MIME user agents anyway?  isn't it
> more likely that they will be generated by things that are XML-aware?

They will be generated by XML-generation thingies but labelled by 
MIME-generation thingies. I don't have to have a new user agent with
XML-generation capabilities to use XML heavily.

> > Then let's by all means add a content-features tag as well. Negotiation
> > problem solved.

> so you want to put the xml frob in two different places?

I'm not wild about having it in two places either, but we've already accepted
the fact that conneg duplicates a large number of other mechanisms, so this is
in some sense inevitable. For example, content-features potentially duplicates
content-type and accept-features potentially duplicates accept and
accept-charset. (But then again, accept-charset duplicates accept in some
cases.)

I guess my position is that since negotiation facilities came along late in the
game some level of duplication in them is acceptable, and since the handling of
such thing is yet to be coded we can accomodate such duplication as need be.

> seems like that introduces far more silly states than putting
> it in either of them.

On the other hand, there are places where either the content-type or
the features are unavailable.

> banning content negotiation's use of this information hardly seems like a
> constructive way forward.  what I'd like to see is a proposal for  adding
> these frobs that anticipates the needs of content negotiation rather than
> pretending that they don't exist.

> (this can still be done even if they are bundled in the content type name,
> but it it probably needs a slighly different syntax; for one thing,
> "-" already appears in a number of content-type names without being
> intended as a feature separator.)

I actually don't have a problem with this approach either, but it seems
to me it should be part of the content negotiation framework rather than
an isolated, ad-hoc extension to HTTP alone.

> my guess is that superclasses will often be omitted, but will rarely
> be incorrect when they are present.

I'm pretty much convinced this isn't going to be the case. I've seen several
instances of type transformation that are parameter-preserving. We're protected
from this now by the near-orthogonality of media type parameters, but this
would change with a superclass parameter of the sort you propose.

> > No, that is not what I'm saying. What I'm saying is that a new agent, one that
> > depends on the parameter being present, only works if it is present.

> why should an agent depend on the parameter being present (if it knows
> that the specific type is XML-based)?

Keith, you're the one that claims that the instant a new suffix is defined
people will start trying to use it in accept fields, even if such usage
is explicitly disallowed. Whereas all I'm claiming is that people might
just possibly try and use a field we standardize for its intended purpose, and
rely on it when they cannot.

You're the one who's making an apples and oranges argument here.

> > People do expect it. We have argued long and hard that a filename isn't
> > sufficient, and we've mostly won. Now that we've won we want to say,
> > "Surprise, we've changed our minds, you now need to generate these
> > parameters for things to work". This is unacceptable.

> we've always said that the content-type specification included the parameters,
> that the content-type name without the parameters was incomplete.

Unfortunately, while we've won the media type battle, this one we've lost. (It
probably would have helped if we'd had some instances early on where the
parameters were clearly vital in the handling of some atomic type or if we'd
defined the mailcap format so that it was clear that parameters are an
essential part of a media type. Gotta eat your own dog food...)

> so I don't
> see how we're changing our minds by defining new types that happen to have
> parameters - even if some of those parameters are shared with other types.

Basic existentialism here, I'm afraid -- our intentions might have been
good, but they are irrelevant at this point.

> anyway the content negotiation argument isn't about the particular syntax
> that is used. it's about whether, having defined this new frob for
> content-types, we then have to define new content negotiation
> mechanisms to recognize those frobs.  if we can come up with something
> that can be made to more-or-less work with existing HTTP accept and/or
> conneg expressisons, that would seem like a win.

Given the rarity of parameters in accept expresisons, I have to wonder how
well they actually work... 

But in any case, I again repeat that the suffix proposal is not intended
by anybody to be a replacement for the definition of a negotiation mechanism.
If having such a mechanism is a condition of acceptance of the proposal,
I'm sure we can define one that will work.

				Ned

Date: Mon, 20 Mar 2000 19:38:54 -0500
To: Keith Moore <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 07:16 PM 3/20/00 -0500, Keith Moore wrote:
>> Requesting yet again.  Could we please have details of this horrible
>> problem inflicted by the -xml suffix?
>
>could we please have details of how conneg expressions or HTTP
>Accept headers could be used to say things like
>"I accept XML documents"?

It's a good question, except (critically) that the suffix under discussion
doesn't provide any mechanisms for making such requests. 

All this suffix lets us do is sort out the XML from the non-XML without
sniffing.  As has been stated repeatedly for the last few days, sniffing is
neither reliable nor fun, and doesn't take advantage of commodity components.

I am quite content to have meaningfully labeled information even in the
absence of detailed discussions about those labels.  

I'm still looking for damage, though I'm concluding more and more that
there simply isn't any, and that this discussion is only circling.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 19:17:56 -0500
Sender: [email-masked]

> They would matter if and only if there wasn't a separate viable solution to 
> the negotiation problem. But there is such a solution. Why not simply 
> use it?

because *that* solution really does introduce more silly states.

Keith

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 19:16:41 -0500
Sender: [email-masked]

> Requesting yet again.  Could we please have details of this horrible
> problem inflicted by the -xml suffix?

could we please have details of how conneg expressions or HTTP
Accept headers could be used to say things like
"I accept XML documents"?

Keith

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Chris Lilley <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 19:15:25 -0500
Sender: [email-masked]

> > > An advisory parameter of this sort is a worthless parameter. If you cannot
> > > depend on it appearing for every instance of a given content type you
> > > cannot use it for anything.
> 
> > that's not true.   if the parameter is missing then some opportunities
> > to evaluate the object (in the absence of knowledge of the complete type)
> > will be lost.  but that's not the same thing as "you cannot use it for
> > anything".
> 
> Something that I cannot count on being there is of no use to me, and, I
> suspect, to anyone else who cares about this stuff. This has to be
> dependable to be useful.

by that argument nothing in MIME would be useful except the ability
to handle text/plain; charset=us-ascii, since that's all that was
there in RFC 822 and all that could be expected out of email recipients
at the time MIME was deployed.  

and I fail to see how special recognition of the -xml frob is any 
more likely than special treatment of a $superclass parameter.
by your criteria above neither of these will be useful.

> > > (Or worse, you will use it and fail when it isn't present.)
> 
> > how is this kind of "failure" any different than the kind of failure
> > that exists when a reader doesn't understand image/svg-xml and
> > fails to recognize that the -xml suffix means that it can be
> > treated as generic xml?
> 
> It is different because I can do something about it -- I can upgrade
> my software. Whereas in order to get benefit from your proposal I have
> to upgrade the software that created the object I received -- software I 
> do not control. And in some cases I even have to upgrade the protocols
> in use.

okay.  I see that there is a higher barrier to adoption of 
$superclass than for -xml because the sender is more likely to
be able to generate -xml than $superclass.  

but I still think you overstate the hazard.  if someone sends you
an image/svg content without the $superclass label you can still
fix the problem on your end merely by defining a specific handler
for image/svg.  true, it doesn't solve the problem for how to deal
with large numbers of unanticipated XML-based types, but it will 
work on a small scale.

but I have to wonder - how likely is it that such XML-ish things 
will be generated by vanilla MIME user agents anyway?  isn't it
more likely that they will be generated by things that are XML-aware?

> > > This is a complete red herring. Nobody is proposing that the suffix be
> > > used for negotiation purposes. Negotiation is a different problem than
> > > labelling.
> 
> > yes, they are different problems, but if we establish this syntatic
> > conventntion, people will want to use that convention in content
> > negotiation.  or to put it another way, a content-type feature
> > labelling convention  that works hand in hand with content negotiation
> > is vastly more useful than one which does not.
> 
> Then let's by all means add a content-features tag as well. Negotiation
> problem solved.

so you want to put the xml frob in two different places?
seems like that introduces far more silly states than putting
it in either of them. 

> > > Again, an advisory parameter of this sort accomplishes nothing.
> 
> > "nothing" seems to me like a gross exaggeration.
> 
> I see it as an understatement.

fine, but it's not exactly an illuminating explanation.

> > > > To put it another way, if it's absolutely important that every instance
> > > > of image/svg be externally labelled as XML then I'd agree with you.
> > > > But I don't see this as absolutely important.
> 
> > > I do.
> 
> > okay, why?
> 
> Because I like to build software that actually works most of the time.

funny, I do too.  OTOH, I realize that when I send someone a new
or unusual kind of MIME object that there's a chance they won't
be able to interpret it, and that I won't find this out immediately,
and I accept that as a fundamental limitation of MIME.

> > okay, how many HTTP servers can deal with
> 
> > Accept: */*-xml
> 
> Any compliant HTTP server can deal with it. Now, it may not give you  the
> result you want, but so what? This is nothing but a strawman argument; the
> proposal at hand doesn't specify any extensions to the accept field in HTTP. 
> If you think it is such a risk that such usage will appear then we can
> specifically ban it.

banning content negotiation's use of this information hardly seems like a 
constructive way forward.  what I'd like to see is a proposal for  adding 
these frobs that anticipates the needs of content negotiation rather than 
pretending that they don't exist.

(this can still be done even if they are bundled in the content type name,
but it it probably needs a slighly different syntax; for one thing,
"-" already appears in a number of content-type names without being
intended as a feature separator.)

> > > Thus far all you have cited are easily surmountable
> > > problems, like the ordering of future additional suffixes (assuming there
> > > ever are any).
> 
> > yes, if we decide to use frobs on the content-type name it's not too
> > difficult to define a canonical ordering such that there's one unique
> > way of spelling any content-type name.  but if we do go in that direction
> > then I'd like us to go ahead and define that syntatic convention,
> > including the ordering
> 
> Fine with me.
> 
> > > > a concrete example of something that this breaks would be helpful
> > > > in getting me to understand your concerns.
> > >
> > > It breaks so many things in so many ways... Some exmaples:
> > >
> > > (1) Silly state problems. Consider the possible effect of image/jpeg;
> > >     $superclass=text/xml on a handler only prepared to accept XML text.
> > >     (And compare it with the effect of image/jpeg; charset=us-ascii on
> > >     any existing handler.)
> 
> > we need to compare apples to apples.  if the handler is only prepared
> > to accept XML text and the image/jpeg arrives with a $superclass=text/xml
> > type then it gets handled to the XML layer and that layer says
> > "invalid XML content" (and ideally the recipient gets a chance to save it).
> > if it sees image/jpeg; charset=us-ascii then it gets treated as
> > application/octet-stream and the recipient gets a chance to save it.
> 
> I'm sorry, but I _am_ comparing apples with apples. I've seen way too much
> software that simply crashes under such circumstances. (And so, I suspect, 
> have you.) Whereas the latter case causes no harm at all.

okay, I'm making assumptions about XML here - which is that XML readers
actually are built on parsing technology and can thus supply reasonable
error messages a high percentage of the time.  and that there are
cookies within XML that the XML parser will use to quickly distinguish
most obviously-not-valid-xml content from maybe-valid-xml content.

now if were were talking about subclasses of e.g. postscript or pdf I 
would indeed expect to see gobbledegook and crashes.  (since interpreters
for these langages often seem to crash even on perfectly valid documents)

and of course this would be a general purpose mechanism, not one specific
to xml.

but given that there's already a great deal of potential for mislabelling
in MIME, does this additional opportunity really increase the risk
that an object will be mislabelled?  i.e. how much more likely is it that 

a) the content-type is correct, but a $superclass parameter is present 
   and incorrect, than
b) the content-type is incorrect?

my guess is that superclasses will often be omitted, but will rarely
be incorrect when they are present.

> 
> > > (2) Problems with sending agents not including the tag. Suppose an application
> > >     is deployed that depends on the superclass tag. (This is inevitable once
> > >     the tag is defined, you can call it advisory until you are blue in the
> > >     face but if it is used at all it won't be taken as such.)
> 
> > let me see if I understand you correctly: what you are saying is that
> > people will expect the new convention (whatever it is) to work and
> > control the recipient's MIME readers's fallback behavior even in
> > the presence of a  vast installed base that neither understands this
> > convention nor XML?
> 
> No, that is not what I'm saying. What I'm saying is that a new agent, one that
> depends on the parameter being present, only works if it is present. 

why should an agent depend on the parameter being present (if it knows
that the specific type is XML-based)?

> And this then implies that a substantial number of agents need to send the 
> tag in order for it to be useful. This won't happen soon if at all, so my 
> agent that I wrote which depends on the tag we've called for ends up not 
> working.
> 
> > or that this would be like the user agents that could recognize
> > filename suffixes but refused  to look at the content-type?
> > people would expect their content to be read by the recipient
> > even if they could not label it correctly?
> 
> People do expect it. We have argued long and hard that a filename isn't
> sufficient, and we've mostly won. Now that we've won we want to say, 
> "Surprise, we've changed our minds, you now need to generate these 
> parameters for things to work". This is unacceptable.

we've always said that the content-type specification included the parameters,
that the content-type name without the parameters was incomplete.  so I don't
see how we're changing our minds by defining new types that happen to have 
parameters - even if some of those parameters are shared with other types.

> > (the latter strikes me as an argment against any sort of XML
> > convention at all - since you seem to be saying that if the convention
> > does exist that it will be (mis)used in preference to the primary
> > content-type )
> 
> The nice thing about the tag being part of the media type is that it leverages
> off of our years of insisting that proper media type labels be used. We define
> the convention and the rest of the problem takes care of itself.
> 
> > and how many user agents does this affect?  e.g., what percentage
> > of UAs cannot send out a text/plain attachment with a charset label?
> 
> A pretty large number, actually.
> 
> > > (3) Problems with places where parameters aren't expected/allowed. Once
> > >     the tag is required there will be pressure to generate it. This in turn
> > >     will lead to sending agents upgrading producing it and thereby cranking
> > >     out parameters for the first time. Some of these agents are now used to
> > >     generate values for fields that don't allow parameters. The upgrade will
> > >     cause these fields to become synatically invalid.
> 
> > such as in accept headers?
> 
> Strawman again. There's nothing syntactically invalid about putting funny
> wildcards in an accept header.

no, but as you point out, that doesn't have the desired result.

anyway the content negotiation argument isn't about the particular syntax 
that is used. it's about whether, having defined this new frob for
content-types, we then have to define new content negotiation
mechanisms to recognize those frobs.  if we can come up with something
that can be made to more-or-less work with existing HTTP accept and/or 
conneg expressisons, that would seem like a win.

Keith

From: [email-masked]
Date: Mon, 20 Mar 2000 15:45:53 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > Whereas I believe your proposal leapfrogs shortsighted into the realm
> > of lunacy.

> hey, I'm quite willing to entertain criticism and feedback, but
> a label like "lunacy" seems completely unjustified.  nor does
> it tell me much about the problems you see with it.  (and I
> am trying to understand these)  the most I've been able to glean
> thus far is that people will misuse parameters in various ways.
> even granted that this will happen, I still don't see that it's
> "lunacy" to consider that path.

Of course it isn't wrong to consider it. But make no mistake about it: You are
opening up MIME and redesigning it in a fundamental way here. Even if the
change was a sensible one this would be *extremely* dangerous, and I would
probably oppose it on these grounds even if I thought it was a good idea.

But IMO this change isn't even remotely sensible -- and I have explained why I
believe this in great detail already. But you continue to advocate it in spite
of all this. This I consider to be lunacy. You may not like this
characterization, but I call them as I see them, and that's how I see this.
(Actually, lunacy is the kindest term I could come up with.)

> and I'm also willing to consider alternative ways of doing this,
> including the -xml frob.

That is not what you have indicated.

> but I think it's worth looking at
> the implications of these alternatives with respect to content
> negotiation.  and I completely don't buy the arguments that people
> aren't going to want to recognize these frobs in content negotiation
> mechanisms, or that these considerations don't matter because they're
> not part of the current proposal.

They would matter if and only if there wasn't a separate viable solution to the
the negotiation problem. But there is such a solution. Why not simply use it?

				Ned

Date: Mon, 20 Mar 2000 18:48:36 -0500
To: Keith Moore <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Requesting yet again.  Could we please have details of this horrible
problem inflicted by the -xml suffix?

Thanks.  Without details, we can only circle.

>KM>>or to put it another way, if we're going to invent a new syntatical
>KM>>convention for describing content-type characteristics, let's 
>KM>>pick one that actually works with content negotiation 
>KM>>rather than one which requires drastic changes to content 
>KM>>negotiation frameworks.
>>
>SSL>I have yet to hear what those 'drastic changes' involve.  More details
>SSL>would be greatly appreciated.
>
>I would still appreciate details describing the consquences of this risk.  
>
>Thanks!

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

From: [email-masked]
Date: Mon, 20 Mar 2000 15:43:29 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Keith Moore <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > It's a plausible risk only if HTTP 1.1 or other protocols are explicitly
> > reopened and modified.  Otherwise, it's pretty easy to point to the spec
> > and say "No.  That's forbidden."

> that's not the risk I'm referring to.  The risk I'm talking about is the
> risk that people will want to reopen and modify those protocols for such
> purposes, but they will be left without a clean way of doing so.

Again, by all means specify a "this is XML" content feature tag of some sort.
This solves the negotiation problem without the need to open up anything.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked] (Kai Henningsen)
cc: [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 18:39:31 -0500
Sender: [email-masked]

> About as many as can deal with
> 
> Accept: */vnd.ms-*

now all we need is a Reject: header.

Keith

From: [email-masked]
Date: Mon, 20 Mar 2000 15:21:06 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Chris Lilley <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > > > Second, the definition of a global parameter namespace is far from the worst
> > > > thing about this. The biggest problem this approach has is that now you have
> > > > what amounts to a mandatory parameter, one which has to appear with every
> > > > appearance of a given media type and must have a specific value in those
> > > > cases.
> >
> > > actually, I don't view the parameter as mandatory; I view it as advisory.
> > > The right way to handle this is to treat it as an image/svg.  Depending
> > > on how you look at it, the information in the $superclass parameter is
> > > either a fallback way to handle the type if you don't know how to handle
> > > image/svg, or additional information that can be used by generic "index
> > > everything that is XML" processors.
> >
> > An advisory parameter of this sort is a worthless parameter. If you cannot
> > depend on it appearing for every instance of a given content type you
> > cannot use it for anything.

> that's not true.   if the parameter is missing then some opportunities
> to evaluate the object (in the absence of knowledge of the complete type)
> will be lost.  but that's not the same thing as "you cannot use it for
> anything".

Something that I cannot count on being there is of no use to me, and, I
suspect, to anyone else who cares about this stuff. This has to be
dependable to be useful.

> > (Or worse, you will use it and fail when it isn't present.)

> how is this kind of "failure" any different than the kind of failure
> that exists when a reader doesn't understand image/svg-xml and
> fails to recognize that the -xml suffix means that it can be
> treated as generic xml?

It is different because I can do something about it -- I can upgrade
my software. Whereas in order to get benefit from your proposal I have
to upgrade the software that created the object I received -- software I 
do not control. And in some cases I even have to upgrade the protocols
in use.

> > > > This is completely contrary to the entire intent of the parameter
> > > > space: Parameters were intended to convey information that isn't
> > > > invariant with the media type.
> >
> > > it's true that parameters were intended to convey type-specific information,
> > > but I don't see the harm in defining another set of parameters (disjoint
> > > from the type-specific parameters), which convey other information about
> > > the media type.
> >
> > Well, all I can say is that I do see the potential for tremendous harm in
> > doing it, many times more harm than I see in the suffix that you seem to
> > think is so bad.

> again, a concrete example would help.
 
I gave you three.

> > In order for this to be useful they have to affect every agent.

> again, how is this different than the -xml convention?

I've explained the differences repeatedly. I'm not going to do it again.

> > This is a complete red herring. Nobody is proposing that the suffix be
> > used for negotiation purposes. Negotiation is a different problem than
> > labelling.

> yes, they are different problems, but if we establish this syntatic
> conventntion, people will want to use that convention in content
> negotiation.  or to put it another way, a content-type feature
> labelling convention  that works hand in hand with content negotiation
> is vastly more useful than one which does not.

Then let's by all means add a content-features tag as well. Negotiation
problem solved.

> > Again, an advisory parameter of this sort accomplishes nothing.

> "nothing" seems to me like a gross exaggeration.

I see it as an understatement.

> > > To put it another way, if it's absolutely important that every instance
> > > of image/svg be externally labelled as XML then I'd agree with you.
> > > But I don't see this as absolutely important.

> > I do.

> okay, why?

Because I like to build software that actually works most of the time.

> > > > In summary, what this amounts to is nothing less that a complete
> > > > redesign of how  MIME works.
> >
> > > "complete redesign" seems a bit overstated.  It is a slightly different
> > > way of using parameters than originally envisioned.  But it doesn't
> > > interfere with the existing parameter space.
> >
> > Actually, I think I seriously understated it. It isn't just a complete
> > redesign, it is a revamping of the underlying principles and agreements
> > MIME is based on.

> I don't see how reserving a space of parameter names across the board
> amounts to a revamping of these underlying principles.

> (to clarify: I did not intend that such parameters would automagically
> apply to all content-types, but rather, that such names would be
> reserved, much as "charset" is reserved for text/* types.
> so that if a parameter with a reserved name were defined for
> a content-type its use would have to be consistent with the use
> already established for the reserved parameter name).

> > > And while I understand that many implementations don't have the ability
> > > to generate or the ability to interpret content-type parameters, I don't
> > > see how this breaks anything that works now.  by contrast, the -xml frob
> > > coupled with the desire for content-negotiation languages (http accept
> > > and conneg) to recognize anything that is XML does break things.
> > > I'm just trying to minimize breakage.
> >
> > Please cite a single, solitary example of where it breaks things. I'd like
> > to hear of one.

> okay, how many HTTP servers can deal with

> Accept: */*-xml

Any compliant HTTP server can deal with it. Now, it may not give you  the
result you want, but so what? This is nothing but a strawman argument; the
proposal at hand doesn't specify any extensions to the accept field in HTTP. If
you think it is such a risk that such usage will appear then we can
specifically ban it.

> > Thus far all you have cited are easily surmountable
> > problems, like the ordering of future additional suffixes (assuming there
> > ever are any).

> yes, if we decide to use frobs on the content-type name it's not too
> difficult to define a canonical ordering such that there's one unique
> way of spelling any content-type name.  but if we do go in that direction
> then I'd like us to go ahead and define that syntatic convention,
> including the ordering

Fine with me.

> > > a concrete example of something that this breaks would be helpful
> > > in getting me to understand your concerns.
> >
> > It breaks so many things in so many ways... Some exmaples:
> >
> > (1) Silly state problems. Consider the possible effect of image/jpeg;
> >     $superclass=text/xml on a handler only prepared to accept XML text.
> >     (And compare it with the effect of image/jpeg; charset=us-ascii on
> >     any existing handler.)

> we need to compare apples to apples.  if the handler is only prepared
> to accept XML text and the image/jpeg arrives with a $superclass=text/xml
> type then it gets handled to the XML layer and that layer says
> "invalid XML content" (and ideally the recipient gets a chance to save it).
> if it sees image/jpeg; charset=us-ascii then it gets treated as
> application/octet-stream and the recipient gets a chance to save it.

I'm sorry, but I _am_ comparing apples with apples. I've seen way too much
software that simply crashes under such circumstances. (And so, I suspect, have
you.) Whereas the latter case causes no harm at all.

> > (2) Problems with sending agents not including the tag. Suppose an application
> >     is deployed that depends on the superclass tag. (This is inevitable once
> >     the tag is defined, you can call it advisory until you are blue in the
> >     face but if it is used at all it won't be taken as such.)

> let me see if I understand you correctly: what you are saying is that
> people will expect the new convention (whatever it is) to work and
> control the recipient's MIME readers's fallback behavior even in
> the presence of a  vast installed base that neither understands this
> convention nor XML?

No, that is not what I'm saying. What I'm saying is that a new agent, one that
depends on the parameter being present, only works if it is present. And this
then implies that a substantial number of agents need to send the tag in order
for it to be useful. This won't happen soon if at all, so my agent that I wrote
which depends on the tag we've called for ends up not working.

> or that this would be like the user agents that could recognize
> filename suffixes but refused  to look at the content-type?
> people would expect their content to be read by the recipient
> even if they could not label it correctly?

People do expect it. We have argued long and hard that a filename isn't
sufficient, and we've mostly won. Now that we've won we want to say, "Surprise,
we've changed our minds, you now need to generate these parameters for
things to work". This is unacceptable.

> (the latter strikes me as an argment against any sort of XML
> convention at all - since you seem to be saying that if the convention
> does exist that it will be (mis)used in preference to the primary
> content-type )

The nice thing about the tag being part of the media type is that it leverages
off of our years of insisting that proper media type labels be used. We define
the convention and the rest of the problem takes care of itself.

> and how many user agents does this affect?  e.g., what percentage
> of UAs cannot send out a text/plain attachment with a charset label?

A pretty large number, actually.

> > (3) Problems with places where parameters aren't expected/allowed. Once
> >     the tag is required there will be pressure to generate it. This in turn
> >     will lead to sending agents upgrading producing it and thereby cranking
> >     out parameters for the first time. Some of these agents are now used to
> >     generate values for fields that don't allow parameters. The upgrade will
> >     cause these fields to become synatically invalid.

> such as in accept headers?

Strawman again. There's nothing syntactically invalid about putting funny
wildcards in an accept header.

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 18:38:21 -0500
Sender: [email-masked]

> Whereas I believe your proposal leapfrogs shortsighted into the realm
> of lunacy.

hey, I'm quite willing to entertain criticism and feedback, but
a label like "lunacy" seems completely unjustified.  nor does
it tell me much about the problems you see with it.  (and I
am trying to understand these)  the most I've been able to glean 
thus far is that people will misuse parameters in various ways.  
even granted that this will happen, I still don't see that it's 
"lunacy" to consider that path.

and I'm also willing to consider alternative ways of doing this, 
including the -xml frob.   but I think it's worth looking at
the implications of these alternatives with respect to content 
negotiation.  and I completely don't buy the arguments that people 
aren't going to want to recognize these frobs in content negotiation 
mechanisms, or that these considerations don't matter because they're 
not part of the current proposal.

Keith 

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 18:28:29 -0500
Sender: [email-masked]

> It's a plausible risk only if HTTP 1.1 or other protocols are explicitly
> reopened and modified.  Otherwise, it's pretty easy to point to the spec
> and say "No.  That's forbidden." 

that's not the risk I'm referring to.  The risk I'm talking about is the
risk that people will want to reopen and modify those protocols for such
purposes, but they will be left without a clean way of doing so.

Keith

From: [email-masked]
Date: Mon, 20 Mar 2000 15:18:05 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Keith Moore <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > Yes, and I also said quite explicitly that user agents requesting */*xml is
> > not a feature of the proposal.  I don't believe it's useful to defend use
> > cases that we are not proposing.

> the thing you are proposing creates a very obvious and plausible risk.

I disagree; I think there is no risk here at all. This is in sharp contrast to
your MIME parameter proposal, where damage isn't just obvious, it is
guaranteed.

> you aren't addressing that risk.  to me that seems shortsighted.

Whereas I believe your proposal leapfrogs shortsighted into the realm
of lunacy.

				Ned

Date: Mon, 20 Mar 2000 17:59:13 -0500
To: Keith Moore <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 03:30 PM 3/20/00 -0500, Keith Moore wrote:
>the thing you are proposing creates a very obvious and plausible risk.  
>you aren't addressing that risk.  to me that seems shortsighted.

It's a plausible risk only if HTTP 1.1 or other protocols are explicitly
reopened and modified.  Otherwise, it's pretty easy to point to the spec
and say "No.  That's forbidden."  It might be a good idea to present these
issues in the I-D, and make clearer that this document does not permit such
extensions, but this 'risk' is not inherent in the proposal itself.

However, I repeat:
KM>>or to put it another way, if we're going to invent a new syntatical
KM>>convention for describing content-type characteristics, let's 
KM>>pick one that actually works with content negotiation 
KM>>rather than one which requires drastic changes to content 
KM>>negotiation frameworks.
>
SSL>I have yet to hear what those 'drastic changes' involve.  More details
SSL>would be greatly appreciated.

I would still appreciate details describing the consquences of this risk.  

Thanks!

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

Date: 20 Mar 2000 22:27:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Finishing the XML-tagging discussion
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Keith Moore)  wrote on 20.03.00 in <[email-masked]>:

> okay, how many HTTP servers can deal with
>
> Accept: */*-xml

About as many as can deal with

Accept: */vnd.ms-*

I suspect (which would be not all that unreasonable for some variant of  
IE, for example).

MfG Kai

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 15:30:53 -0500
Sender: [email-masked]

> Yes, and I also said quite explicitly that user agents requesting */*xml is
> not a feature of the proposal.  I don't believe it's useful to defend use
> cases that we are not proposing.

the thing you are proposing creates a very obvious and plausible risk.  
you aren't addressing that risk.  to me that seems shortsighted.

Keith

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Chris Lilley <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 15:28:51 -0500
Sender: [email-masked]

> > > Second, the definition of a global parameter namespace is far from the worst
> > > thing about this. The biggest problem this approach has is that now you have
> > > what amounts to a mandatory parameter, one which has to appear with every
> > > appearance of a given media type and must have a specific value in those
> > > cases.
> 
> > actually, I don't view the parameter as mandatory; I view it as advisory.
> > The right way to handle this is to treat it as an image/svg.  Depending
> > on how you look at it, the information in the $superclass parameter is
> > either a fallback way to handle the type if you don't know how to handle
> > image/svg, or additional information that can be used by generic "index
> > everything that is XML" processors.
> 
> An advisory parameter of this sort is a worthless parameter. If you cannot
> depend on it appearing for every instance of a given content type you
> cannot use it for anything. 

that's not true.   if the parameter is missing then some opportunities
to evaluate the object (in the absence of knowledge of the complete type)
will be lost.  but that's not the same thing as "you cannot use it for
anything".

> (Or worse, you will use it and fail when it isn't present.)

how is this kind of "failure" any different than the kind of failure
that exists when a reader doesn't understand image/svg-xml and
fails to recognize that the -xml suffix means that it can be
treated as generic xml?

> > > This is completely contrary to the entire intent of the parameter
> > > space: Parameters were intended to convey information that isn't
> > > invariant with the media type.
> 
> > it's true that parameters were intended to convey type-specific information,
> > but I don't see the harm in defining another set of parameters (disjoint
> > from the type-specific parameters), which convey other information about
> > the media type.
> 
> Well, all I can say is that I do see the potential for tremendous harm in 
> doing it, many times more harm than I see in the suffix that you seem to 
> think is so bad.

again, a concrete example would help.  
 
> > > Third, this introduces the possibility of silly states in a major way.
> 
> > As far as I can tell, parameters already have tremendous potential for
> > silly states - nothing stops you from adding any parameter to any media
> > type (so you can for example have a charset parameter on an image).
> 
> While this may be a silly state in some sense, it is an entirely harmless one.
> The silly states this superclass nonsense introduces are anything but.
> 
> > But in practice, and despite widespread misuse of certain parameter
> > names with content-types that don't define those parameters, it doesn't
> > seem to cause big problems.  Unrecognized parameters are generally
> > ignored.
> 
> Exactly. We were careful to define parameters in this way so that bad
> behavior as a result of silly states was minimized. But this isn't possible
> with the sort of parameter you're proposing.

I don't buy it.  all of the examples of silly states I can think of 
are at worst equivalent to just mislabelling the content-type, which
already happens.  if you mislabel an object's content-type you should
expect to lose, and I don't see how having the ability to mislabel
parameters changes this.

now I will admit that having the extra parameter creates *additional*
states - for instance, if you as a sender don't want to encourage 
default processing of your xml document, you can omit the extra parameter.  
but while I'm not sure how much value there is in this, those states 
don't quite seem "silly" to me. 
 
> > > Fourth, the infrastructure upgrades to handle this are far nastier
> > > than you seem to think, and have to happen at both the sending and receiving
> > > end.
> 
> > I guess the question in my mind is whether those upgrades affect every
> > MIME handling agent or whether (for the time being) they only affect
> > things that care specifically about XML.
> 
> In order for this to be useful they have to affect every agent.

again, how is this different than the -xml convention?
in either case, an agent that doesn't understand the convention
will ignore it and not be able to benefit from the extra information.
and an agent that does understand the convention will use it.
in either case, the convention is "useful" for those agents
that implement it and is benign for those that don't.

in neither case can a sender expect generic XML processing as a fallback
because (unlike text/plain processing) XML processing is not required
of MIME user agents.

> > The latter set seems a lot
> > smaller than the former set, and I'm less worried about the impact of
> > this on XML-aware agents (which after are in an emerging space anyway)
> > than I am worried about the impact of -xml frobs on things that need
> > to do content-negotiation (which includes every HTTP client and server).
> 
> This is a complete red herring. Nobody is proposing that the suffix be
> used for negotiation purposes. Negotiation is a different problem than
> labelling.

yes, they are different problems, but if we establish this syntatic
conventntion, people will want to use that convention in content 
negotiation.  or to put it another way, a content-type feature
labelling convention  that works hand in hand with content negotiation
is vastly more useful than one which does not.

> 
> > > Fifth, as I said before, this doesn't work with places where only media
> > > types and not parameters are carried. Such places do exist and fixing
> > > them all is going to be nearly impossible.
> 
> > Since I see this parameter as advisory, to me it doesn't matter much.
> > Applications for which the advisory parameter is of sufficient utility
> > will get fixed to interpret or generate that parameter; those that don't
> > benefit sufficiently will not get fixed.
> 
> Again, an advisory parameter of this sort accomplishes nothing.

"nothing" seems to me like a gross exaggeration.  

> > To put it another way, if it's absolutely important that every instance
> > of image/svg be externally labelled as XML then I'd agree with you.
> > But I don't see this as absolutely important.
> 
> I do.

okay, why?

> > > In summary, what this amounts to is nothing less that a complete 
> > > redesign of how  MIME works.
> 
> > "complete redesign" seems a bit overstated.  It is a slightly different
> > way of using parameters than originally envisioned.  But it doesn't
> > interfere with the existing parameter space.
> 
> Actually, I think I seriously understated it. It isn't just a complete
> redesign, it is a revamping of the underlying principles and agreements 
> MIME is based on.

I don't see how reserving a space of parameter names across the board
amounts to a revamping of these underlying principles. 

(to clarify: I did not intend that such parameters would automagically
apply to all content-types, but rather, that such names would be
reserved, much as "charset" is reserved for text/* types.
so that if a parameter with a reserved name were defined for 
a content-type its use would have to be consistent with the use
already established for the reserved parameter name).

> > And while I understand that many implementations don't have the ability
> > to generate or the ability to interpret content-type parameters, I don't
> > see how this breaks anything that works now.  by contrast, the -xml frob
> > coupled with the desire for content-negotiation languages (http accept
> > and conneg) to recognize anything that is XML does break things.
> > I'm just trying to minimize breakage.
> 
> Please cite a single, solitary example of where it breaks things. I'd like
> to hear of one. 

okay, how many HTTP servers can deal with 

Accept: */*-xml

> Thus far all you have cited are easily surmountable
> problems, like the ordering of future additional suffixes (assuming there
> ever are any).

yes, if we decide to use frobs on the content-type name it's not too 
difficult to define a canonical ordering such that there's one unique
way of spelling any content-type name.  but if we do go in that direction
then I'd like us to go ahead and define that syntatic convention,
including the ordering

> 
> > a concrete example of something that this breaks would be helpful
> > in getting me to understand your concerns.
> 
> It breaks so many things in so many ways... Some exmaples:
> 
> (1) Silly state problems. Consider the possible effect of image/jpeg;
>     $superclass=text/xml on a handler only prepared to accept XML text.
>     (And compare it with the effect of image/jpeg; charset=us-ascii on
>     any existing handler.)

we need to compare apples to apples.  if the handler is only prepared
to accept XML text and the image/jpeg arrives with a $superclass=text/xml
type then it gets handled to the XML layer and that layer says
"invalid XML content" (and ideally the recipient gets a chance to save it).  
if it sees image/jpeg; charset=us-ascii then it gets treated as 
application/octet-stream and the recipient gets a chance to save it.

if on the other hand, we take both cases and feed them to 
"any existing handler" (say, a typical MIME mail reader)
then in the former case the $superclass is ignored and in the latter
case the charset is ignored.  in either case the content is either
fed to a jpeg reader, or to a generic image/* reader, or it is
treated as application/octet-stream.  

but since we're really trying to compare putting the xml frob into
a separate parameter vs. putting it into the content-type name, 
perhaps that should be one axis of the case analysis.  the other
obvious axis is existing MIME readers vs. MIME readers taught to
understand the new syntax.  
 
> (2) Problems with sending agents not including the tag. Suppose an application
>     is deployed that depends on the superclass tag. (This is inevitable once
>     the tag is defined, you can call it advisory until you are blue in the
>     face but if it is used at all it won't be taken as such.) 

let me see if I understand you correctly: what you are saying is that 
people will expect the new convention (whatever it is) to work and
control the recipient's MIME readers's fallback behavior even in
the presence of a  vast installed base that neither understands this
convention nor XML?

or that this would be like the user agents that could recognize
filename suffixes but refused  to look at the content-type?
people would expect their content to be read by the recipient
even if they could not label it correctly?

(the latter strikes me as an argment against any sort of XML
convention at all - since you seem to be saying that if the convention
does exist that it will be (mis)used in preference to the primary 
content-type )

and how many user agents does this affect?  e.g., what percentage
of UAs cannot send out a text/plain attachment with a charset label?

> Now consider
>     what happens when something that's incapable of generating the tag sends
>     to the agent that requires it.

the agent either knows how to handle that specific content-type, or it
treats it per the fallback rule for the top-level content-type, or it 
treates it as application/octet-stream.

but I fail to see why a well-behaved application would "require" 
the extra parameter.  if it knows what image/svg is, why would
it insist that the $superclass parameter be present?

> (3) Problems with places where parameters aren't expected/allowed. Once
>     the tag is required there will be pressure to generate it. This in turn
>     will lead to sending agents upgrading producing it and thereby cranking
>     out parameters for the first time. Some of these agents are now used to
>     generate values for fields that don't allow parameters. The upgrade will
>     cause these fields to become synatically invalid.

such as in accept headers? 

> 
> I could go on to list many more, but hopefully this gives some flavor
> of how bad I think this idea is.
> 
> 				Ned

Keith

Date: Mon, 20 Mar 2000 15:00:27 -0500
To: Keith Moore <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 02:50 PM 3/20/00 -0500, Keith Moore wrote:
>or to put it another way, if we're going to invent a new syntatical
>convention for describing content-type characteristics, let's 
>pick one that actually works with content negotiation 
>rather than one which requires drastic changes to content 
>negotiation frameworks.

I have yet to hear what those 'drastic changes' involve.  More details
would be greatly appreciated.

>and yet you just admitted that it would cause a problem if user agents 
>started requesting */*xml.

Yes, and I also said quite explicitly that user agents requesting */*xml is
not a feature of the proposal.  I don't believe it's useful to defend use
cases that we are not proposing.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: "Simon St.Laurent" <[email-masked]>, Keith Moore <[email-masked]>, Chris Lilley <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 14:52:18 -0500
Sender: [email-masked]

> I note in passing that we've already registered some XML-based types
> with an "XML" suffix, and no problems have been reported with this
> usage.

one or two -xml types don't hurt much.  but if we're going to have a
general naming for XML types, this might have a more profound effect.

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], Chris Lilley <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 14:50:56 -0500
Sender: [email-masked]

> At 01:33 PM 3/20/00 -0500, Keith Moore wrote:
> >if you want an expression that matches anything ending in -xml, 
> >as far as I can tell, existing http accept header semantics,
> >and existing conneg expressions, are not sufficient to recognize that.
> >
> >if you want it to be more general and anticipate the possibility
> >of multiple frobs (not just -xml) then you need something like
> >a regular expression matching capability 
> >(so you can look for things like "-xml(-|$)" )
> 
> I think we may encountered a problem in our underlying viewpoints.  You're
> talking about sending */*xml over the wire in headers, while I'm only
> talking about using */*xml to recognize XML documents when I get them.  

I am talking about both, but I think they're both problems.

or to put it another way, if we're going to invent a new syntatical
convention for describing content-type characteristics, let's 
pick one that actually works with content negotiation 
rather than one which requires drastic changes to content 
negotiation frameworks.

> I don't think the proposal as written breaks things any more than
> introducing a new MIME type would.

in a sense, it doesn't break anything.  in another sense, it 
creates a new feature of content-type names that can be exploited,
and people will demand that they be exploited.  so it requires 
changes of existing implementations.  and if the -xml feature catches 
on then it will creep into content-type negotiation schemes.  this is 
not an intended consequence, but it is a likely one.  

> Compared to the parameter option you keep proposing, I'd say this causes
> almost zero problems as far as interoperability and compatibility are
> concerned.

interoperability and compatibility aren't as much my concern as
feature creep and its effect on content-negotiation structures.

> If user agents start requesting */*xml, we do have a problem.  

why do you think they won't want to do that?

> However,
> that isn't what this I-D proposes - if users find that useful, they'll have
> to push for changes in the protocol infrastructure.  

yes, but if such changes are to be made, then perhaps it would be a good
idea to pick a syntax for declaring such features that doesn't require
changes to the protocol infrastructure - or at least, to consider what
those infrastructure changes would need to look like and evaluate the 
new syntax in light of those changes.

> All this suffix does is provide additional information identifying content
> as having an XML foundation.  I don't believe it has any other
> implications, nor do I believe it will interfere with other developing
> standards for content negotiation.

and yet you just admitted that it would cause a problem if user agents 
started requesting */*xml.

Keith

From: [email-masked]
Date: Mon, 20 Mar 2000 11:20:01 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Marshall Rose <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Chris Lilley <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked], Marshall Rose <[email-masked]>
Sender: [email-masked]

> > > suppose we were just to have something like:
> >
> > >     Content-type: image/svg; representation="xml"
> >
> > > where "representation" is just a plain old MIME parameter.
> >
> > > would you object to something along these lines?
> >
> > Yes. Most of the problems I have with global parameter still apply to this
> > usage.
> >
> > If we absolutely have to do this with a separate piece of information, I
> would
> > opt for a content-feature tag. That way there's a clear delineation
> between
> > when feature information is or is not present, and we don't mess up MIME
> > parameter space. And we need the feature tag anyway for negotiation
> purposes.

> hmmm.  my view of the example above is that XML is being used as the syntax
> but the semantics of the blob being passed are still SVG semantics.

I agree, but I fail to see how this changes things. I was talking about
having a media type other than application/xml _and_ a content-feature
field.

> at the risk of seeming insensitive with the exception of "text/xml", i would
> never expect to see a subtype of "xml" for any media type.

Again I agree. People are going to register separate media types for
the XML-based things they come up with. (This is already hapening.)

> of course, taking
> that line, i suppose that the example above should simply be

>     image/svg

> and that the processing element for that application should already know the
> possible syntaxes that it could encounter.

This is the crux of the -xml proposal. All it says is that if SVG always  has
XML syntax the name image/svg-xml may be used to indicate that in the media
type name and that the -xml suffix won't ever be used on anything that doesn't
have XML syntax. Nothing more and nothing less. It doesn't require that this
naming convention be used for all things XML, it says nothing about matching
such names as part of content negotiation, and it doesn't affect whether
or not a given XML variant gets its own media type name or not.

It seems that a lot of people are reading vastly more into this than is
there.

				Ned

Date: Mon, 20 Mar 2000 11:18:54 -0800
To: "Marshall Rose" <[email-masked]>, <[email-masked]>
From: Tim Bray <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Cc: <[email-masked]>, "Keith Moore" <[email-masked]>, "Chris Lilley" <[email-masked]>, "Simon St.Laurent" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Marshall Rose" <[email-masked]>
Sender: [email-masked]

At 11:10 AM 3/20/00 -0800, Marshall Rose wrote:
>hmmm.  my view of the example above is that XML is being used as the syntax
>but the semantics of the blob being passed are still SVG semantics.

I think that's more or less everyone's view.  Hence the reason why a 
top-level xml/ type turns out to be a bad idea.

>at the risk of seeming insensitive with the exception of "text/xml", i would
>never expect to see a subtype of "xml" for any media type. of course, taking
>that line, i suppose that the example above should simply be
>    image/svg

Once again, no-one seems to disagree. The proposal is 

 image/svg-xml

and I believe this is what SVG plans to file for.

>and that the processing element for that application should already know the
>possible syntaxes that it could encounter.

The idea is that it is in the general case useful to know whether something's
in XML syntax, regardless of the application & its semantic.  -Tim

From: [email-masked]
Date: Mon, 20 Mar 2000 11:09:21 -0800 (PST)
Subject: RE: Finishing the XML-tagging discussion
To: Miles Sabin <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> Simon St.Laurent wrote,
> > I've yet to hear of a meaningful 'breaking', and I'd like a
> > concrete example.
> >
> > As far as I can tell, -xml doesn't interfere with existing
> > systems at all.

> Depends what you mean by break, I guess. If an HTTP user agent
> sends a request with Accept: application/*-xml, then as things
> stand, it's as likely as not to get back a 400 Bad Request
> response.

Well, that would technically be a violation of the HTTP protocol. * isn't
a tspecial, and hence is allowed in a type or subtype token.

But of course the chances of this actually working aren't good, since
the HTTP specification says that only an asterisk by itself is a wildcard.

OTOH, the use of parameter matching, while defined, is called "rare"
in the specification and AFAIK is never used in practice (the one
parameter where it is obviously useful is charset, but that parameter
has a separate accept- field of its own). So I wonder how well trying to
match a parameter would work in practice.

				Ned

From: "Marshall Rose" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Keith Moore" <[email-masked]>, "Chris Lilley" <[email-masked]>, "Simon St.Laurent" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Marshall Rose" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Date: Mon, 20 Mar 2000 11:10:03 -0800
Sender: [email-masked]

> > suppose we were just to have something like:
>
> >     Content-type: image/svg; representation="xml"
>
> > where "representation" is just a plain old MIME parameter.
>
> > would you object to something along these lines?
>
> Yes. Most of the problems I have with global parameter still apply to this
> usage.
>
> If we absolutely have to do this with a separate piece of information, I
would
> opt for a content-feature tag. That way there's a clear delineation
between
> when feature information is or is not present, and we don't mess up MIME
> parameter space. And we need the feature tag anyway for negotiation
purposes.

hmmm.  my view of the example above is that XML is being used as the syntax
but the semantics of the blob being passed are still SVG semantics.

at the risk of seeming insensitive with the exception of "text/xml", i would
never expect to see a subtype of "xml" for any media type. of course, taking
that line, i suppose that the example above should simply be

    image/svg

and that the processing element for that application should already know the
possible syntaxes that it could encounter.

/mtr

From: [email-masked]
Date: Mon, 20 Mar 2000 10:52:22 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Marshall Rose <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Chris Lilley <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > > > One alternative - not necessarily one I am advocating, but just
> listing for
> > > > completeness - is to use a similar approach but swapped round:
> > > >
> > > > image/svg;ContentLanguage=xml
> >
> > > I favor something like this.  it seems like it will interact more
> > > cleanly with content negotiation mechanisms (as opposed to those
> > > mechanisms having to acquire new pattern-matching facilities)
> >
> > > it's true that as MIME is architected the parameter space is on a
> > > per-content-type basis.  but I don't see any great harm if we define
> > > some global parameter name space (say, parameter names that begin
> > > with "$" are global).  Then we could do something like:
> >
> > > content-type: image/svg; $superclass="application/xml"

> ned - i agree with your take that having global parameters is a major change
> to MIME.

> suppose we were just to have something like:

>     Content-type: image/svg; representation="xml"

> where "representation" is just a plain old MIME parameter.

> would you object to something along these lines?

Yes. Most of the problems I have with global parameter still apply to this
usage.

If we absolutely have to do this with a separate piece of information, I would
opt for a content-feature tag. That way there's a clear delineation between
when feature information is or is not present, and we don't mess up MIME
parameter space. And we need the feature tag anyway for negotiation purposes.

I still strongly prefer the suffix, however.

				Ned

Date: Mon, 20 Mar 2000 13:51:42 -0500
To: Keith Moore <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: Keith Moore <[email-masked]>, [email-masked], Chris Lilley <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 01:33 PM 3/20/00 -0500, Keith Moore wrote:
>if you want an expression that matches anything ending in -xml, 
>as far as I can tell, existing http accept header semantics,
>and existing conneg expressions, are not sufficient to recognize that.
>
>if you want it to be more general and anticipate the possibility
>of multiple frobs (not just -xml) then you need something like
>a regular expression matching capability 
>(so you can look for things like "-xml(-|$)" )

I think we may encountered a problem in our underlying viewpoints.  You're
talking about sending */*xml over the wire in headers, while I'm only
talking about using */*xml to recognize XML documents when I get them.  

I don't think the proposal as written breaks things any more than
introducing a new MIME type would.

Perhaps you're reading too much into this, from section 6:
I-D>Applications may match for types that
I-D>represent XML entities by comparing the subtype to the pattern
I-D>*/*-xml.

Yes, older tools wouldn't do anything in particular with the suffix.
Lacking any such regular expression capacities, they'd just see it as
another MIME type and ignore any concept of dispatching it to generic XML
processing.

This is the case with any innovation, not a compatibility breakdown.

Compared to the parameter option you keep proposing, I'd say this causes
almost zero problems as far as interoperability and compatibility are
concerned.

If user agents start requesting */*xml, we do have a problem.  However,
that isn't what this I-D proposes - if users find that useful, they'll have
to push for changes in the protocol infrastructure.  I think it would be
useful, and is a possibility opened by this proposal, but it is not part of
this proposal.

All this suffix does is provide additional information identifying content
as having an XML foundation.  I don't believe it has any other
implications, nor do I believe it will interfere with other developing
standards for content negotiation.

I'll be in San Jose at Software Development for the next few days, so won't
be online with my usual frequency.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

From: [email-masked]
Date: Mon, 20 Mar 2000 10:48:40 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: "Simon St.Laurent" <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked], Chris Lilley <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> At 01:14 PM 3/20/00 -0500, Keith Moore wrote:
> >by contrast, the -xml frob
> >coupled with the desire for content-negotiation languages (http accept
> >and conneg) to recognize anything that is XML does break things.
> >I'm just trying to minimize breakage.

> Could you please explain in detail what gets broken here?

> I've yet to hear of a meaningful 'breaking', and I'd like a concrete example.

> As far as I can tell, -xml doesn't interfere with existing systems at all.

I note in passing that we've already registered some XML-based types
with an "XML" suffix, and no problems have been reported with this
usage.

				Ned

From: [email-masked]
Date: Mon, 20 Mar 2000 10:25:24 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Chris Lilley <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > Second, the definition of a global parameter namespace is far from the worst
> > thing about this. The biggest problem this approach has is that now you have
> > what amounts to a mandatory parameter, one which has to appear with every
> > appearance of a given media type and must have a specific value in those
> > cases.

> actually, I don't view the parameter as mandatory; I view it as advisory.
> The right way to handle this is to treat it as an image/svg.  Depending
> on how you look at it, the information in the $superclass parameter is
> either a fallback way to handle the type if you don't know how to handle
> image/svg, or additional information that can be used by generic "index
> everything that is XML" processors.

An advisory parameter of this sort is a worthless parameter. If you cannot
depend on it appearing for every instance of a given content type you
cannot use it for anything. (Or worse, you will use it and fail when it
isn't present.)

> > This is completely contrary to the entire intent of the parameter
> > space: Parameters were intended to convey information that isn't
> > invariant with the media type.

> it's true that parameters were intended to convey type-specific information,
> but I don't see the harm in defining another set of parameters (disjoint
> from the type-specific parameters), which convey other information about
> the media type.

Well, all I can say is that I do see the potential for tremendous harm in doing
it, many times more harm than I see in the suffix that you seem to think is so
bad.

> > Third, this introduces the possibility of silly states in a major way.

> As far as I can tell, parameters already have tremendous potential for
> silly states - nothing stops you from adding any parameter to any media
> type (so you can for example have a charset parameter on an image).

While this may be a silly state in some sense, it is an entirely harmless one.
The silly states this superclass nonsense introduces are anything but.

> But in practice, and despite widespread misuse of certain parameter
> names with content-types that don't define those parameters, it doesn't
> seem to cause big problems.  Unrecognized parameters are generally
> ignored.

Exactly. We were careful to define parameters in this way so that bad
behavior as a result of silly states was minimized. But this isn't possible
with the sort of parameter you're proposing.

> > Fourth, the infrastructure upgrades to handle this are far nastier
> > than you seem to think, and have to happen at both the sending and receiving
> > end.

> I guess the question in my mind is whether those upgrades affect every
> MIME handling agent or whether (for the time being) they only affect
> things that care specifically about XML.

In order for this to be useful they have to affect every agent.

> The latter set seems a lot
> smaller than the former set, and I'm less worried about the impact of
> this on XML-aware agents (which after are in an emerging space anyway)
> than I am worried about the impact of -xml frobs on things that need
> to do content-negotiation (which includes every HTTP client and server).

This is a complete red herring. Nobody is proposing that the suffix be
used for negotiation purposes. Negotiation is a different problem than
labelling.

> > Fifth, as I said before, this doesn't work with places where only media
> > types and not parameters are carried. Such places do exist and fixing
> > them all is going to be nearly impossible.

> Since I see this parameter as advisory, to me it doesn't matter much.
> Applications for which the advisory parameter is of sufficient utility
> will get fixed to interpret or generate that parameter; those that don't
> benefit sufficiently will not get fixed.

Again, an advisory parameter of this sort accomplishes nothing.

> To put it another way, if it's absolutely important that every instance
> of image/svg be externally labelled as XML then I'd agree with you.
> But I don't see this as absolutely important.

I do.

> > In summary, what this amounts to is nothing less that a complete redesign of
> > how  MIME works.

> "complete redesign" seems a bit overstated.  It is a slightly different
> way of using parameters than originally envisioned.  But it doesn't
> interfere with the existing parameter space.

Actually, I think I seriously understated it. It isn't just a complete
redesign, it is a revamping of the underlying principles and agreements MIME is
based on.

> And while I understand that many implementations don't have the ability
> to generate or the ability to interpret content-type parameters, I don't
> see how this breaks anything that works now.  by contrast, the -xml frob
> coupled with the desire for content-negotiation languages (http accept
> and conneg) to recognize anything that is XML does break things.
> I'm just trying to minimize breakage.

Please cite a single, solitary example of where it breaks things. I'd like
to hear of one. Thus far all you have cited are easily surmountable
problems, like the ordering of future additional suffixes (assuming there
ever are any).

> a concrete example of something that this breaks would be helpful
> in getting me to understand your concerns.

It breaks so many things in so many ways... Some exmaples:

(1) Silly state problems. Consider the possible effect of image/jpeg;
    $superclass=text/xml on a handler only prepared to accept XML text.
    (And compare it with the effect of image/jpeg; charset=us-ascii on
    any existing handler.)

(2) Problems with sending agents not including the tag. Suppose an application
    is deployed that depends on the superclass tag. (This is inevitable once
    the tag is defined, you can call it advisory until you are blue in the
    face but if it is used at all it won't be taken as such.) Now consider
    what happens when something that's incapable of generating the tag sends
    to the agent that requires it.

(3) Problems with places where parameters aren't expected/allowed. Once
    the tag is required there will be pressure to generate it. This in turn
    will lead to sending agents upgrading producing it and thereby cranking
    out parameters for the first time. Some of these agents are now used to
    generate values for fields that don't allow parameters. The upgrade will
    cause these fields to become synatically invalid.

I could go on to list many more, but hopefully this gives some flavor
of how bad I think this idea is.

				Ned

From: Miles Sabin <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 18:35:37 -0000
Sender: [email-masked]

Simon St.Laurent wrote,
> I've yet to hear of a meaningful 'breaking', and I'd like a 
> concrete example.
> 
> As far as I can tell, -xml doesn't interfere with existing
> systems at all.

Depends what you mean by break, I guess. If an HTTP user agent 
sends a request with Accept: application/*-xml, then as things
stand, it's as likely as not to get back a 400 Bad Request
response.

That might not be breakage, but it's far from obvious (to me at 
least) that it helps us much.

Cheers,

Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
[email-masked]          http://www.cromwellmedia.com/

From: "Marshall Rose" <[email-masked]>
To: <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: "Chris Lilley" <[email-masked]>, "Simon St.Laurent" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Date: Mon, 20 Mar 2000 10:34:55 -0800
Sender: [email-masked]

> > > One alternative - not necessarily one I am advocating, but just
listing for
> > > completeness - is to use a similar approach but swapped round:
> > >
> > > image/svg;ContentLanguage=xml
>
> > I favor something like this.  it seems like it will interact more
> > cleanly with content negotiation mechanisms (as opposed to those
> > mechanisms having to acquire new pattern-matching facilities)
>
> > it's true that as MIME is architected the parameter space is on a
> > per-content-type basis.  but I don't see any great harm if we define
> > some global parameter name space (say, parameter names that begin
> > with "$" are global).  Then we could do something like:
>
> > content-type: image/svg; $superclass="application/xml"

ned - i agree with your take that having global parameters is a major change
to MIME.

suppose we were just to have something like:

    Content-type: image/svg; representation="xml"

where "representation" is just a plain old MIME parameter.

would you object to something along these lines?

/mtr

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked], Chris Lilley <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 13:33:06 -0500
Sender: [email-masked]

> Could you please explain in detail what gets broken here?

if you want an expression that matches anything ending in -xml, 
as far as I can tell, existing http accept header semantics,
and existing conneg expressions, are not sufficient to recognize that.

if you want it to be more general and anticipate the possibility
of multiple frobs (not just -xml) then you need something like
a regular expression matching capability 
(so you can look for things like "-xml(-|$)" )

Keith

Date: Mon, 20 Mar 2000 13:19:58 -0500
To: Keith Moore <[email-masked]>, [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: Keith Moore <[email-masked]>, Chris Lilley <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 01:14 PM 3/20/00 -0500, Keith Moore wrote:
>by contrast, the -xml frob
>coupled with the desire for content-negotiation languages (http accept
>and conneg) to recognize anything that is XML does break things.
>I'm just trying to minimize breakage.

Could you please explain in detail what gets broken here?

I've yet to hear of a meaningful 'breaking', and I'd like a concrete example.

As far as I can tell, -xml doesn't interfere with existing systems at all.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Chris Lilley <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 13:14:56 -0500
Sender: [email-masked]

> > content-type: image/svg; $superclass="application/xml"
> 
> First of all, this approach was discussed when MIME was first designed and 
> was roundly rejected at that time. At the time I was actually in favor of 
> doing this, but I've since decided that the people who were opposed to 
> it were right.

I don't recall this part of those discussions.

> Second, the definition of a global parameter namespace is far from the worst
> thing about this. The biggest problem this approach has is that now you have
> what amounts to a mandatory parameter, one which has to appear with every
> appearance of a given media type and must have a specific value in those
> cases. 

actually, I don't view the parameter as mandatory; I view it as advisory.
The right way to handle this is to treat it as an image/svg.  Depending
on how you look at it, the information in the $superclass parameter is 
either a fallback way to handle the type if you don't know how to handle
image/svg, or additional information that can be used by generic "index 
everything that is XML" processors.

> This is completely contrary to the entire intent of the parameter
> space: Parameters were intended to convey information that isn't 
> invariant with the media type.

it's true that parameters were intended to convey type-specific information,
but I don't see the harm in defining another set of parameters (disjoint
from the type-specific parameters), which convey other information about
the media type.

> Third, this introduces the possibility of silly states in a major way.

As far as I can tell, parameters already have tremendous potential for
silly states - nothing stops you from adding any parameter to any media 
type (so you can for example have a charset parameter on an image).
But in practice, and despite widespread misuse of certain parameter
names with content-types that don't define those parameters, it doesn't 
seem to cause big problems.  Unrecognized parameters are generally 
ignored.

> Fourth, the infrastructure upgrades to handle this are far nastier
> than you seem to think, and have to happen at both the sending and receiving
> end.

I guess the question in my mind is whether those upgrades affect every
MIME handling agent or whether (for the time being) they only affect 
things that care specifically about XML.  The latter set seems a lot
smaller than the former set, and I'm less worried about the impact of
this on XML-aware agents (which after are in an emerging space anyway)
than I am worried about the impact of -xml frobs on things that need
to do content-negotiation (which includes every HTTP client and server).

> Fifth, as I said before, this doesn't work with places where only media
> types and not parameters are carried. Such places do exist and fixing
> them all is going to be nearly impossible.

Since I see this parameter as advisory, to me it doesn't matter much.
Applications for which the advisory parameter is of sufficient utility
will get fixed to interpret or generate that parameter; those that don't 
benefit sufficiently will not get fixed.

To put it another way, if it's absolutely important that every instance 
of image/svg be externally labelled as XML then I'd agree with you.
But I don't see this as absolutely important.  

> In summary, what this amounts to is nothing less that a complete redesign of
> how  MIME works. 

"complete redesign" seems a bit overstated.  It is a slightly different
way of using parameters than originally envisioned.  But it doesn't
interfere with the existing parameter space.

And while I understand that many implementations don't have the ability 
to generate or the ability to interpret content-type parameters, I don't 
see how this breaks anything that works now.  by contrast, the -xml frob
coupled with the desire for content-negotiation languages (http accept
and conneg) to recognize anything that is XML does break things.
I'm just trying to minimize breakage.

a concrete example of something that this breaks would be helpful
in getting me to understand your concerns.

Keith

From: [email-masked]
Date: Mon, 20 Mar 2000 09:39:08 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Keith Moore <[email-masked]>
Cc: Chris Lilley <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > One alternative - not necessarily one I am advocating, but just listing for
> > completeness - is to use a similar approach but swapped round:
> >
> > image/svg;ContentLanguage=xml

> I favor something like this.  it seems like it will interact more
> cleanly with content negotiation mechanisms (as opposed to those
> mechanisms having to acquire new pattern-matching facilities)

> it's true that as MIME is architected the parameter space is on a
> per-content-type basis.  but I don't see any great harm if we define
> some global parameter name space (say, parameter names that begin
> with "$" are global).  Then we could do something like:

> content-type: image/svg; $superclass="application/xml"

First of all, this approach was discussed when MIME was first designed and was
roundly rejected at that time. At the time I was actually in favor of doing
this, but I've since decided that the people who were opposed to it were right.

Second, the definition of a global parameter namespace is far from the worst
thing about this. The biggest problem this approach has is that now you have
what amounts to a mandatory parameter, one which has to appear with every
appearance of a given media type and must have a specific value in those
cases. This is completely contrary to the entire intent of the parameter
space: Parameters were intended to convey information that isn't invariant
with the media type.

Third, this introduces the possibility of silly states in a major way.

Fourth, the infrastructure upgrades to handle this are far nastier
than you seem to think, and have to happen at both the sending and receiving
end.

Fifth, as I said before, this doesn't work with places where only media
types and not parameters are carried. Such places do exist and fixing
them all is going to be nearly impossible.

In summary, what this amounts to is nothing less that a complete redesign of
how  MIME works. And in case my position on this wasn't clear before, this is a
100% ABSOLUTE TOTAL SHOWSTOPPER for me. I will fight this in every way i
possibly can -- I really do think it is that bad of an idea. Frankly, I haven't
seen anything I believe is so destructive and confusing proposed since the use
of line or character counts were considered as an alternative to
boundary markers back in 1991.

				Ned

From: [email-masked]
Date: Mon, 20 Mar 2000 09:24:01 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Graham Klyne <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> At 09:07 AM 3/19/00 -0500, Simon St.Laurent wrote:
> >The other problem I have with Content-Feature is that it isn't clear to me
> >- based on my RFC dredgings, which may not be complete - whether or not
> >there is any kind of registration process or even official status for
> >Content-Feature.

> FYI:  RFC 2506;  also RFC 2533.

> (Content-feature is currently an I-D proposal that employs this framework
> to label MIME content.)

> And to try and dispel some misunderstandings:  I have suggested use of the
> CONNEG framework for _content negotiation_.  To me, the use of "-xml" as an
> aid to detecting generic XML seems a reasonable and useful idea;  I just
> think that using a naming convention as a basis for content negotiation
> would be pushing it too far.

I agree that the suffix isn't appropriate for negotiation; this should
be handled by some sort of feature tag.

				Ned

From: Keith Moore <[email-masked]>
To: Chris Lilley <[email-masked]>
cc: "Simon St.Laurent" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Mon, 20 Mar 2000 11:03:29 -0500
Sender: [email-masked]

> One alternative - not necessarily one I am advocating, but just listing for
> completeness - is to use a similar approach but swapped round:
> 
> image/svg;ContentLanguage=xml

I favor something like this.  it seems like it will interact more
cleanly with content negotiation mechanisms (as opposed to those
mechanisms having to acquire new pattern-matching facilities)

it's true that as MIME is architected the parameter space is on a 
per-content-type basis.  but I don't see any great harm if we define
some global parameter name space (say, parameter names that begin
with "$" are global).  Then we could do something like:

content-type: image/svg; $superclass="application/xml"

it's true that a lot of existing content-type dispatchers wouldn't
know how to deal with the parameter, but that doesn't seem like
such a big deal because it's easily added to the few MIME handlers
that know about XML.  similarly there are content-type labellers
that don't know about the concept of parameters but this provides
an opportunity for them to get fixed.  and since this is only a 
hint and the complete type is still specified in the foo/bar
portion of the content-type, the system can still "work" even 
in the absence of the $superclass label.

Keith

Date: Mon, 20 Mar 2000 13:44:27 +0100
From: Chris Lilley <[email-masked]>
Organization: W3C
To: "Simon St.Laurent" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

"Simon St.Laurent" wrote:

> 2) People have grown accustomed to the basic top-level types carrying
> meaningful information.  The Content-Feature approach would mean that
> Scalable Vector Graphics (SVG) would be application/xml;
> Content-Feature=svg  -- not not image/svg-xml.  The contents of those two
> descriptions are significantly different, though they purport to describe
> the same thing.  This doesn't apply in every case, since a lot of XML
> formats belong in application/, but it applies in a significant number of
> cases.

Good summary, I agree. the existing top-level types are a useful feature.

One alternative - not necessarily one I am advocating, but just listing for
completeness - is to use a similar approach but swapped round:

image/svg;ContentLanguage=xml

(which basically amounts to foo/bar;xml=yes)

--
Chris

Date: Mon, 20 Mar 2000 09:41:51 +0000
To: "Simon St.Laurent" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 09:07 AM 3/19/00 -0500, Simon St.Laurent wrote:
>The other problem I have with Content-Feature is that it isn't clear to me
>- based on my RFC dredgings, which may not be complete - whether or not
>there is any kind of registration process or even official status for
>Content-Feature.

FYI:  RFC 2506;  also RFC 2533.

(Content-feature is currently an I-D proposal that employs this framework 
to label MIME content.)

And to try and dispel some misunderstandings:  I have suggested use of the 
CONNEG framework for _content negotiation_.  To me, the use of "-xml" as an 
aid to detecting generic XML seems a reasonable and useful idea;  I just 
think that using a naming convention as a basis for content negotiation 
would be pushing it too far.

#g

------------
Graham Klyne
([email-masked])

From: Miles Sabin <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Cross classification (WAS: Finishing the XML-tagging discussion)
Date: Mon, 20 Mar 2000 10:12:53 -0000
Sender: [email-masked]

Simon St.Laurent wrote,
> 2) People have grown accustomed to the basic top-level 
> types carrying meaningful information.  The Content-Feature 
> approach would mean that Scalable Vector Graphics (SVG) 
> would be application/xml; Content-Feature=svg  -- not not 
> image/svg-xml.  The contents of those two descriptions are 
> significantly different, though they purport to describe
> the same thing.

To my mind this is the core of the problem. What we've got is 
*two* hierarchical classifications of resource types: the MIME 
type/subtype one; and the xml/xml-application one.

Unfortunately these two hierarchies are othogonal, as the svg 
example illustrates quite neatly. This means we won't be able 
to encode one in the other without either information loss or 
special processing of some sort.

Cheers,

Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
[email-masked]          http://www.cromwellmedia.com/

Date: Sun, 19 Mar 2000 09:59:31 -0800
Subject: Re: Finishing the XML-tagging discussion 
From: Dan Crevier <[email-masked]>
To: ietf-822 <[email-masked]>
Sender: [email-masked]

On 3/19/2000 12:58 AM, [email-masked] wrote:

> To summarize:
> 
> Most of us are of the opinion that indiscriminate sniffing of objects
> is a Bad Idea unless you're of the canine persuasion, and that some
> form of tagging is a Good Idea.  The question we seem to be hung up on
> is whether we should:
> 
> a) Use application/xml with Content-Feature tagging.  This would
> require more work for some MIME dispatchers to implement up front, but
> buys us automatic drop-back to generic XML if added support isn't
> available.  Non-upgraded clients would require (possibly) *one*
> intervention to add 'application/xml' to their "how to dispatch THIS
> one" tables to point at a generic XML application, but there's no
> guarantee that added features would be usable, even if installed, if
> their MIME handler doesn't do Content-Feature.
> 
> b) Use application/foobar-xml.  This apparently requires less work for
> some MIME dispatchers to support, at the expense of creating a "rule"
> that *-xml is all xml if you don't want to drop back to octet-stream.
> In addition, *non-upgraded* clients get to force hand-adding of this
> week's foobar-xml to a table of "how to dispatch THIS one" (even if
> it's Yet Another 'hand it to our XML application') if they want "better
> than octet-stream" handling.

What about:

c) Use application/foobar with a tag that says it's xml, like
Alternate-Type=text/xml.

The reason I think this is better is that a non-upgraded client will handle
a by passing all application/foobar documents to the generic xml handler
rather than the foobar handler, but if the primary type is listed as
application/foobar, a non-upgraded client will handle it correctly if a
foobar handler is installed and set up.  It will just fail to pass it off to
a generic xml handler if one isn't installed.  This seems like a much less
serious problem to me because there's not much the user can necessarily do
with a application/foobar document in a generic xml handler anyway.  It is
much more important to handle the case where the user has a handler for
foobar installed.  Also, if we use something like Alternate-Type, it
provides a much more general solution for similar problems in the future,
and the implementation would be very simple.  It could be Alternate-Types
with a comma delimited list, as someone else suggested, or there could be
multiple Alterate-Type tags allowed, and you just go through them in order.
You can think of this as being similar to multipart/alternative, but sharing
the same content and just changing the way it's interpreted.

Dan

Date: Sun, 19 Mar 2000 12:17:17 -0500
To: Elliotte Rusty Harold <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 11:25 AM 3/19/00 -0500, you wrote:
>I haven't been following this discussion too closely, but has a 
>top-level xml type been positively ruled out for any particular 
>reason? e.g. xml/rdf, xml/rss, xml/xhtml, etc.  It seems to me that 
>if we're going to so much trouble to make sure that generic XML 
>processors will recognize this with suffixes and so forth, maybe what 
>we really have is a different top-level type? The argument here would 
>that not all XML (e.g. SVG) is really text.

I've written a brief summary of how we got here, archived at:
http://www.imc.org/ietf-xml-mime/mail-archive/msg00345.html

For the top-level media types discussion, you might want to see the threads
listed below.  The top-level XML media type discussion sort of winds around
and through them, without clear resolution in a single thread,
unfortunately, but these are probably at least a useful set of threads to
explore.

Parameters for top-level XML media types?
http://www.imc.org/ietf-xml-mime/mail-archive/threads.html#00075

Top-level media types desirable?
http://www.imc.org/ietf-xml-mime/mail-archive/threads.html#00100

Perhaps we need an XML registration tree
http://www.imc.org/ietf-xml-mime/mail-archive/threads.html#00101

Application-specific media types
http://www.imc.org/ietf-xml-mime/mail-archive/threads.html#00111

Negotiated Content Delivery: Maximizing Information 
http://www.imc.org/ietf-xml-mime/mail-archive/threads.html#00121

Using CONNEG instead of MIME types for compound types & references
http://www.imc.org/ietf-xml-mime/mail-archive/threads.html#00133

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

From: [email-masked]
Date: Sun, 19 Mar 2000 08:42:54 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Elliotte Rusty Harold <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> I haven't been following this discussion too closely, but has a
> top-level xml type been positively ruled out for any particular
> reason?

Please review the list archives. This has been discussed extensively already,
and it is a waste of everyone else's time to repeat that discussion for
a third (at least) time.

				Ned

Date: Sun, 19 Mar 2000 11:25:10 -0500
To: [email-masked], [email-masked], [email-masked]
From: Elliotte Rusty Harold <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

I haven't been following this discussion too closely, but has a 
top-level xml type been positively ruled out for any particular 
reason? e.g. xml/rdf, xml/rss, xml/xhtml, etc.  It seems to me that 
if we're going to so much trouble to make sure that generic XML 
processors will recognize this with suffixes and so forth, maybe what 
we really have is a different top-level type? The argument here would 
that not all XML (e.g. SVG) is really text.

And from even further out in left field: why doesn't MIME allow 
sub-sub types? e.g. text/xml/rdf?

I can believe there are really good reasons this hasn't been 
proposed. However it does seem to me that we're struggling because we 
really need to attach four labels to a typical XML document:

1. That it's text
2. That it's XML
3. That it's some specific XML application
4. That it has a particular encoding

And MIME only gives us three places to work with.

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | [email-masked] | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
+----------------------------------+---------------------------------+

Date: Sun, 19 Mar 2000 09:27:16 -0500
To: [email-masked], [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: [email-masked]
Sender: [email-masked]

At 08:17 AM 3/19/00 -0500, [email-masked] wrote:
>If you go the "application/xml; Content-Feature=foobar" route, you're
>DONE.  You don't have the added support handy, it just drops to
>wherever you configured Mozilla to pass the stuff.  The grounds that
>"its possible" here is that it's tagged as 'application/xml', which
>should be sufficient for tagging that it's possible.  This is actually
>*less* work to make work under Mozilla, at the expense of *not* passing
>along a hint to Notepad/XMLSpy/whatever that it's a *FOOBAR* xml, not
>just a generic xml.

Rereading this paragraph raises further questions about the value of
Content-Feature in my mind.  Less work under Mozilla, but not working with
applications outside of a particular transaction framework (HTTP in this
case) seems like an enormous overall loss to me.

Am I reading this right?

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

Date: Sun, 19 Mar 2000 09:07:11 -0500
To: [email-masked], [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion 
Cc: [email-masked]
Sender: [email-masked]

At 08:17 AM 3/19/00 -0500, [email-masked] wrote:
>Most of us are of the opinion that indiscriminate sniffing of objects
>is a Bad Idea unless you're of the canine persuasion, and that some
>form of tagging is a Good Idea.  The question we seem to be hung up on
>is whether we should:
>
>a) Use application/xml with Content-Feature tagging.  This would
>require more work for some MIME dispatchers to implement up front, but
>buys us automatic drop-back to generic XML if added support isn't
>available.  Non-upgraded clients would require (possibly) *one*
>intervention to add 'application/xml' to their "how to dispatch THIS
>one" tables to point at a generic XML application, but there's no
>guarantee that added features would be usable, even if installed, if
>their MIME handler doesn't do Content-Feature.
>
>b) Use application/foobar-xml.  This apparently requires less work for
>some MIME dispatchers to support, at the expense of creating a "rule"
>that *-xml is all xml if you don't want to drop back to octet-stream.
>In addition, *non-upgraded* clients get to force hand-adding of this
>week's foobar-xml to a table of "how to dispatch THIS one" (even if
>it's Yet Another 'hand it to our XML application') if they want "better
>than octet-stream" handling.
>
>In *both* cases, client software that *has* been upgraded (for either
>the *-xml rule or to correctly dispatch based on a content-feature tag)
>will be able to hand it off to either a specific featureful XML application
>if available, or to a generic XML application if the bells-and-whistles
>aren't installed.  However, we're not sure yet which track involves less
>total aggrivation for upgrading.

I think that's a reasonable summary of what's going on, and I didn't repeat
the details above it because I think the summary cuts to the heart of the
problem.  (Once sniffing is discarded, anyway.)  We've kicked around a few
times, and mostly kicked it out.  My largest problems with Content-Feature
have to do with human interactions.  There are two aspects to this:

1) Many users have a hard enough time figuring out what MIME Content-Types
are, and adding another layer that only gets use with XML (today, anyway)
is going to be a hard sell to these folks.  Effectively, it's putting a
third layer on to the content type, and doing so in a way that doesn't look
like every other content type.  I'm just not convinced that people will
look past Content-Types.

2) People have grown accustomed to the basic top-level types carrying
meaningful information.  The Content-Feature approach would mean that
Scalable Vector Graphics (SVG) would be application/xml;
Content-Feature=svg  -- not not image/svg-xml.  The contents of those two
descriptions are significantly different, though they purport to describe
the same thing.  This doesn't apply in every case, since a lot of XML
formats belong in application/, but it applies in a significant number of
cases.

The other problem I have with Content-Feature is that it isn't clear to me
- based on my RFC dredgings, which may not be complete - whether or not
there is any kind of registration process or even official status for
Content-Feature.  We've already had several 'acronym collisions' in the XML
world (Steel Markup Language vs. Simple Markup Lanugage, for instance), and
I'd like to make certain these collisions don't all follow us into
MIME-based processing.  (I'm aware that x- is the wild west, but I'd like
to ensure that there's a safer option.)

There have been other objections to parameters along the way, and perhaps
they'll resurface now.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

From: [email-masked]
To: "Simon St.Laurent" <[email-masked]>
cc: [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Sun, 19 Mar 2000 03:58:20 -0500
Sender: [email-masked]

On Sat, 18 Mar 2000 10:58:48 EST, "Simon St.Laurent" <[email-masked]>  said:
> I meant this within a framework of XML processing that goes beyond generic
> document+style sheet->presentation.  There are many document-oriented
> applications out there where application/xml or text/xml is perfectly
> appropriate and does what their users need them to do.

OK.. If I'm interpreting what you said here, it's that many document-oriented
XML objects can be tagged as {application,text}/xml and sent out the door,
and that will suffice.
 
> Some of these may eventually develop the need for more specific MIME types,
> of course, but lots of them will likely stay in application/xml or
> text/xml.  Having the -xml suffix would also ease the integration of these
> new MIME types with other XML documents.
> 
> The main argument continues to hold for XML formats that receive more
> specific automated processing.

Now, based on another message that preceeded this, I think we agree
that "some XML objects could utilize further tagging because sniffing
around the inside of objects becomes ugly".  What's unclear (at least
to me, at the moment I write this) is whether you are specifically
advocating tagging such things with 'application/foobar-xml' or whether
just iterating that some tagging (possibly via Content-Feature: or
whatever) is needed.  Here, you seem to be saying -xml suffixes are
a Good Idea (and making a good case for it).  However...

On Sat, 18 Mar 2000 10:38:18 EST, "Simon St.Laurent" <[email-masked]>  said:
> I've been dreaming about that for a while.  Connect it to an editor, and I
> know a lot of people who'd love to buy the product.  Even if I didn't have
> an SVG editor handy, or some kind of generic image tool, I could tell the
> browser to pass it to my preferred XML editor - Notepad, XMLSpy, XMetaL,
> whatever - on grounds that the suffix suggests its possible.

> I wonder what it would take to build that into Mozilla?  Hmmmm....

If you go the "application/xml; Content-Feature=foobar" route, you're
DONE.  You don't have the added support handy, it just drops to
wherever you configured Mozilla to pass the stuff.  The grounds that
"its possible" here is that it's tagged as 'application/xml', which
should be sufficient for tagging that it's possible.  This is actually
*less* work to make work under Mozilla, at the expense of *not* passing
along a hint to Notepad/XMLSpy/whatever that it's a *FOOBAR* xml, not
just a generic xml.

<taking a deep breath>

To summarize:

Most of us are of the opinion that indiscriminate sniffing of objects
is a Bad Idea unless you're of the canine persuasion, and that some
form of tagging is a Good Idea.  The question we seem to be hung up on
is whether we should:

a) Use application/xml with Content-Feature tagging.  This would
require more work for some MIME dispatchers to implement up front, but
buys us automatic drop-back to generic XML if added support isn't
available.  Non-upgraded clients would require (possibly) *one*
intervention to add 'application/xml' to their "how to dispatch THIS
one" tables to point at a generic XML application, but there's no
guarantee that added features would be usable, even if installed, if
their MIME handler doesn't do Content-Feature.

b) Use application/foobar-xml.  This apparently requires less work for
some MIME dispatchers to support, at the expense of creating a "rule"
that *-xml is all xml if you don't want to drop back to octet-stream.
In addition, *non-upgraded* clients get to force hand-adding of this
week's foobar-xml to a table of "how to dispatch THIS one" (even if
it's Yet Another 'hand it to our XML application') if they want "better
than octet-stream" handling.

In *both* cases, client software that *has* been upgraded (for either
the *-xml rule or to correctly dispatch based on a content-feature tag)
will be able to hand it off to either a specific featureful XML application
if available, or to a generic XML application if the bells-and-whistles
aren't installed.  However, we're not sure yet which track involves less
total aggrivation for upgrading.

Have I mis-stated any major points of the two camps?

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

Date: Sat, 18 Mar 2000 10:58:48 -0500
To: Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

Just catching myself on an overstatement.

At 10:32 AM 3/18/00 -0500, I wrote:
>I don't think text/xml and application/xml are going to have much of a life
>except as a holding tank for XML formats that are either in development,
>and thus not ready for a MIME content identifier, or which aren't meant for
>any kind of large scale interchange.

I meant this within a framework of XML processing that goes beyond generic
document+style sheet->presentation.  There are many document-oriented
applications out there where application/xml or text/xml is perfectly
appropriate and does what their users need them to do.

Some of these may eventually develop the need for more specific MIME types,
of course, but lots of them will likely stay in application/xml or
text/xml.  Having the -xml suffix would also ease the integration of these
new MIME types with other XML documents.

The main argument continues to hold for XML formats that receive more
specific automated processing.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

Date: Sat, 18 Mar 2000 10:38:18 -0500
To: Tim Bray <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

At 05:29 PM 3/17/00 -0800, Tim Bray wrote:
>I repeat: whether the inventors of the media type, today, design it
>for dispatch to generic XML processing machinery (and most won't) is
>irrelevant to the point here.  The core notion is that the knowledge
>that some media type happens to use XML syntax opens the door to 
>unanticipated kinds of processing beyond those envisioned by its 
>inventors, and on this basis identifying such encodings is a good
>and useful thing.

Exactly.  These 'unanticipated kinds of processing' suggest that general
guidelines for how to label XML documents are a better idea than leaving it
up to groups of developers tightly focused on a particular type of
processing that only meets current needs.

>Up till a year ago, I might have agreed.  As of now, there is a lot of
>stuff floating around the net that claims to be XML.  For a lot of it,
>I don't have the appropriate receiving software on hand; in these cases,
>I've found it tremendously useful to throw it into IE5, which first of 
>all, tells me quickly whether it really is XML or not, and secondly, allows
>me to look at it in not-too-unreadable form.  I would *love* it if I 
>could configure my user-agent to, whenever it sees a media type it
>doesn't grok but happens to look like foo/bar-xml, to turn it over to the 
>generic XML-capable browser.  [Or even better, based on some other mime-level
>mechanism more elegant than the "-xml" suffix.]

I've been dreaming about that for a while.  Connect it to an editor, and I
know a lot of people who'd love to buy the product.  Even if I didn't have
an SVG editor handy, or some kind of generic image tool, I could tell the
browser to pass it to my preferred XML editor - Notepad, XMLSpy, XMetaL,
whatever - on grounds that the suffix suggests its possible.

I wonder what it would take to build that into Mozilla?  Hmmmm....

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

Date: Sat, 18 Mar 2000 10:32:26 -0500
To: Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

At 04:22 PM 3/17/00 -0800, Paul Hoffman / IMC wrote:
>Nope, we agree that there are very many. Where we disagree is in how they 
>will labelled when they are moved in MIME-based systems.
>
>Your assumption appears to be that they will all follow the lead of IOTP 
>and have their own sub-type tags. A different assumption is that they will 
>mostly use text/xml and application/xml. Doing so makes them quite friendly 
>to the random MIME parsers you envision. Each will have a unique DTD 
>identifier, so there is no need to have their own subtype.

I don't think text/xml and application/xml are going to have much of a life
except as a holding tank for XML formats that are either in development,
and thus not ready for a MIME content identifier, or which aren't meant for
any kind of large scale interchange.

If I'm going to the trouble of organizing a group of developers to create a
format we all agree on, I'm definitely going to take the tiny extra step of
creating a label for it that we can agree to use to simplify interchange.
If I have a million documents arriving at a gateway every minute, for three
different sets of purposes involving different DTDs, I'm not going to want
to sniff every document to find out what it contains.  I'd much rather look
at a content-type label and THEN pass it to a processor that can combine
the sniffing/validation with parsing that actually brings the information
into my application structures.

XML's ability to ride commodity HTTP infrastructures makes this possible,
cheap, and very likely.  I don't think the creators of most XML formats are
going to go to the length of creating their own transport protocols, but
they will want to be able to take maximum advantage of existing protocols.
The scenario described above takes maximum advantage of an HTTP server
(most likely) and can perform extensive and efficient processing without
having to resort to sniffing.

Sniffing XML can be fairly ugly - DOCTYPE declarations aren't required, and
they can appear fairly deep into a document under certain unpreventable
circumstances. (The XML declaration, comments, and processing instructions
can occupy space before the DOCTYPE declaration.)  Even sniffing the
DOCTYPE isn't completely reliable, thanks to a variety of issues involving
default values for namespaces within external DTDs and overrides inside the
internal DTD...

Sniffing is not an acceptable solution in a large-scale environment, in any
case, and the widespread availability of commodity components will lead
developers to find the easiest way to connect those components.  Sniffing's
a mess.

While I can always slap the wrong MIME content type identifier on a
document and cause problems that resemble a failed sniff, that's a risk
with any MIME identifier and so far as I know the Internet is still running.

>For the record, I don't know why the authors of IOTP chose to use a 
>different sub-tag; they may have a very good reason. But my guess is that 
>most XML-based applications that want to be found by generic XML parsers 
>SHOULD use text/xml and application/xml.

'want to be found' is making assumptions that don't hold very well with
XML.  Suppose that the gateway described above is also making copies of all
messages for regulatory reasons, passing them to different data
repositories based on their content.  Everything except the XML gets passed
to a traditional file storage system, while the XML gets fed into a
hierarchical store that provides random access to the information.

Having an -xml suffix on the information would make it extremely easy to
sort out the XML from the non-XML without relying on fallible and
inefficient sniffing techniques.  If messages started arriving in XML
without the -xml (say in an x- type), they couldn't be analyzed with the
same set of tools.  Human intervention might be worthwhile at that point,
but the overall costs are a lot lower.

>Like Ned, I have nothing against -xml as a concept. I'm just convinced that 
>the systems that use it will also reflexively resort to sniffing everything 
>anyway, so why give the false impression that all subtags that go over XML 
>should end in -xml? Let them sniff away.

I don't know where your assumptions about programmers come from - the ones
I know tend to prefer the easiest way of doing things.  And why the 'false
impression' rhetoric?  Should I talk about the 'false impression' that
image/png provides?

Put simply, sniffing isn't done with off-the-shelf parts and it doesn't
scale very well.  I think most programmers would rather read a clear label
than sniff the box to find out if it contains perfume, bills, or manure.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

Date: Fri, 17 Mar 2000 17:29:13 -0800
To: Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

At 04:22 PM 3/17/00 -0800, Paul Hoffman / IMC wrote:

>For the record, I don't know why the authors of IOTP chose to use a 
>different sub-tag; they may have a very good reason. But my guess is that 
>most XML-based applications that want to be found by generic XML parsers 
>SHOULD use text/xml and application/xml.

I repeat: whether the inventors of the media type, today, design it
for dispatch to generic XML processing machinery (and most won't) is
irrelevant to the point here.  The core notion is that the knowledge
that some media type happens to use XML syntax opens the door to 
unanticipated kinds of processing beyond those envisioned by its 
inventors, and on this basis identifying such encodings is a good
and useful thing.

>Simon St. Laurent wrote
>>I think we have another fundamental disagreement here.  Such 'specialized
>>systems' are already distributed by the millions, in the forms of IE 5 and
>>Mozilla.  Right now, they have pretty limited capabilities, but they're a
>>start.
>
>Yes, we disagree here. There is no reason to automatically dispatch 
>application/foo-xml in these XML systems. 

Up till a year ago, I might have agreed.  As of now, there is a lot of
stuff floating around the net that claims to be XML.  For a lot of it,
I don't have the appropriate receiving software on hand; in these cases,
I've found it tremendously useful to throw it into IE5, which first of 
all, tells me quickly whether it really is XML or not, and secondly, allows
me to look at it in not-too-unreadable form.  I would *love* it if I 
could configure my user-agent to, whenever it sees a media type it
doesn't grok but happens to look like foo/bar-xml, to turn it over to the 
generic XML-capable browser.  [Or even better, based on some other mime-level
mechanism more elegant than the "-xml" suffix.]

>Tim Bray gave a few far-fetched 
>but possibly valid ones, but all of them would need to be used content 
>sniffing even if we had -xml because each one really, really wanted to be 
>sure to get all XML. 

Far-fetched is a matter of opinion; but the conclusion doesn't follow; one
of the virtues of XML is that if data which purports to be isn't, you
find out quickly and with deterministic and easy-to-handle results.
This doesn't mean that it's a good idea to *always* check opaque media
types for XML-ness; XML processors are not as lightweight as they should
be (sigh, mea culpa) and I don't think you want to poking around at
the beginning of everything that's going through.  -Tim

Date: Fri, 17 Mar 2000 16:22:23 -0800
To: [email-masked], [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

At 06:48 PM 3/17/00 -0500, Simon St.Laurent wrote:
>At 03:03 PM 3/17/00 -0800, Paul Hoffman / IMC wrote:
> >"Growing" here means probably about one new type
> >every week or so. This greatly reduces the power of the word "burden".
>
>I think we have fundamental disagreements here about how many XML
>vocabularies are in development today,

Nope, we agree that there are very many. Where we disagree is in how they 
will labelled when they are moved in MIME-based systems.

Your assumption appears to be that they will all follow the lead of IOTP 
and have their own sub-type tags. A different assumption is that they will 
mostly use text/xml and application/xml. Doing so makes them quite friendly 
to the random MIME parsers you envision. Each will have a unique DTD 
identifier, so there is no need to have their own subtype.

For the record, I don't know why the authors of IOTP chose to use a 
different sub-tag; they may have a very good reason. But my guess is that 
most XML-based applications that want to be found by generic XML parsers 
SHOULD use text/xml and application/xml.

>I think we have another fundamental disagreement here.  Such 'specialized
>systems' are already distributed by the millions, in the forms of IE 5 and
>Mozilla.  Right now, they have pretty limited capabilities, but they're a
>start.

Yes, we disagree here. There is no reason to automatically dispatch 
application/foo-xml in these XML systems. It may be valuable to manually 
dispatch those documents to your browser's XML parser, but rarely or never 
automatically. We are talking about trying to help automatic processing, 
not any processing.

>Agents, that collapsed dream of a few years ago, are another likely
>returning possibility that will also have the needs of these 'specialized
>systems'.

I still await some good examples of these. Tim Bray gave a few far-fetched 
but possibly valid ones, but all of them would need to be used content 
sniffing even if we had -xml because each one really, really wanted to be 
sure to get all XML. The problem with the -xml system is that it has to be 
used 100% of the time in order to be useful in the given examples. 
Unfortunately, we're 100% sure that some content creators are going to end 
up sticking XML in text/plain and application/octet-stream bodies.

>Add to that a number of folks out there implementing general architectures
>for XML interchange and processing, some of them with plans for every
>desktop a processor, and I think there are more than a few search engines
>in the room.

If the search engine is XML-only, and only wanted to recognized things it 
had been told were XML (either by full type/subtype or subtypes that end in 
-xml), then, yes, you have a point. What's the chance of that? I think it's 
much more likely that a search engine is going to read every damn text 
object it sees and, if it looks like XML, do some smarter indexing in it.

Like Ned, I have nothing against -xml as a concept. I'm just convinced that 
the systems that use it will also reflexively resort to sniffing everything 
anyway, so why give the false impression that all subtags that go over XML 
should end in -xml? Let them sniff away.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
Date: Fri, 17 Mar 2000 16:10:10 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > > If this growing and distributed burden is more attractive than a 4-byte
> > > naming convention that doesn't interfere with existing processing, then I
> > > suppose we should drop the suffix, and find out how popular this
> > > non-approach proves to be in a couple of years.  At that point, it will be
> > > very difficult to fix things.  I continue to argue that the suffix is a
> > > remarkably low-cost solution with significant benefits.

> >Well, you've just convinced me. I hereby retract my assertion that
> >content sniffing is a "mostly harmless" but partial solution to this
> >problem. In light of this it doesn't look like a solution at all.

> Ned, I remain unconvinced. "Growing" here means probably about one new type
> every week or so.

Speaking as the media type reviewer, the run rate has proved to be quite
a bit higher than this. And I expect it to grow a lot in the future.

> This greatly reduces the power of the word "burden".
> Remember, this is only of interest to specialized systems, that is, the
> ones who want to pass random (that is, unknown format) XML to a generic XML
> parser. Yes, that's "distributed"... over a very small number of systems
> that wan to do this. Even if it is many systems, the cost of sniffing one
> new document type a week is incredibly low, and is only incurred in systems
> where there is not a human who updates the type-to-translation table.

But the corresponding costs of the naming convention are incredibly low.
So, even if the utility is limited (and I'm growing convinced that it isn't
as limited as I first thought), the cost-benefit conclusion seems clear.

				Ned

Date: Fri, 17 Mar 2000 18:48:15 -0500
To: Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

At 03:03 PM 3/17/00 -0800, Paul Hoffman / IMC wrote:
>"Growing" here means probably about one new type 
>every week or so. This greatly reduces the power of the word "burden".

I think we have fundamental disagreements here about how many XML
vocabularies are in development today, and how many will be in development
in the future.  Maybe I should do a survey on Robin Cover's site for
vocabulary emergence frequency, keeping in mind that this incredibly
comprehensive site represents a subset.

(http://www.oasis-open.org/cover/ - BizTalk's probably worth exploring as
well, and there are more..)
 
>Remember, this is only of interest to specialized systems, that is, the 
>ones who want to pass random (that is, unknown format) XML to a generic XML 
>parser. 

I think we have another fundamental disagreement here.  Such 'specialized
systems' are already distributed by the millions, in the forms of IE 5 and
Mozilla.  Right now, they have pretty limited capabilities, but they're a
start.

Agents, that collapsed dream of a few years ago, are another likely
returning possibility that will also have the needs of these 'specialized
systems'.

Add to that a number of folks out there implementing general architectures
for XML interchange and processing, some of them with plans for every
desktop a processor, and I think there are more than a few search engines
in the room.

>Yes, that's "distributed"... over a very small number of systems 
>that wan to do this. Even if it is many systems, the cost of sniffing one 
>new document type a week is incredibly low, and is only incurred in systems 
>where there is not a human who updates the type-to-translation table.

I think we're at odds on the fundamentals, but I think the cost your vision
is imposing on my vision is rather dramatically greater than the cost my
vision imposes upon your vision.

Should be a fun weekend of discussion!

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

Date: Fri, 17 Mar 2000 15:03:33 -0800
To: [email-masked], [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

At 06:40 AM 3/17/00 -0800, [email-masked] wrote:
> > If this growing and distributed burden is more attractive than a 4-byte
> > naming convention that doesn't interfere with existing processing, then I
> > suppose we should drop the suffix, and find out how popular this
> > non-approach proves to be in a couple of years.  At that point, it will be
> > very difficult to fix things.  I continue to argue that the suffix is a
> > remarkably low-cost solution with significant benefits.
>
>Well, you've just convinced me. I hereby retract my assertion that
>content sniffing is a "mostly harmless" but partial solution to this
>problem. In light of this it doesn't look like a solution at all.

Ned, I remain unconvinced. "Growing" here means probably about one new type 
every week or so. This greatly reduces the power of the word "burden". 
Remember, this is only of interest to specialized systems, that is, the 
ones who want to pass random (that is, unknown format) XML to a generic XML 
parser. Yes, that's "distributed"... over a very small number of systems 
that wan to do this. Even if it is many systems, the cost of sniffing one 
new document type a week is incredibly low, and is only incurred in systems 
where there is not a human who updates the type-to-translation table.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
Date: Fri, 17 Mar 2000 06:40:04 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: "Simon St.Laurent" <[email-masked]>
Cc: Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> If this growing and distributed burden is more attractive than a 4-byte
> naming convention that doesn't interfere with existing processing, then I
> suppose we should drop the suffix, and find out how popular this
> non-approach proves to be in a couple of years.  At that point, it will be
> very difficult to fix things.  I continue to argue that the suffix is a
> remarkably low-cost solution with significant benefits.

Well, you've just convinced me. I hereby retract my assertion that 
content sniffing is a "mostly harmless" but partial solution to this 
problem. In light of this it doesn't look like a solution at all.

> Past performance is no guarantee of future returns.

Well, actually, I didn't think about the lesson to be learned from past
attempts to use "magic number" approaches. These have proved to work
spectacularly badly sometimes. Again, PostScript provides one of the better
examples of how things can go wrong: I routinely see problem reports whose
underlying cause is either a false positive or a false negative  "PostScript"
result from a content sniffer.

				Ned

Date: Fri, 17 Mar 2000 09:29:09 -0500
To: Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

At 08:29 PM 3/16/00 -0800, Paul Hoffman / IMC wrote:
>The original problem is: how do I have my MIME handler automatically know 
>that it should hand a body part that has an unknown tag on it to the 
>generic XML processor?

You seem to be assuming in this case that the handler already has the
document, and that the only use of MIME types is for convenience in
processing documents you've already retrieved and know something about.

Also, 'unknown tag'?  Do you mean 'unknown content-type' here?  I don't
think we're talking about using MIME to dispatch handling of document
fragments.  (At least I hope not!)

>We have explored many, many alternatives in detail. They all have 
>drawbacks, some of them severe. However, there is a simple solution that 
>involves no changes to any protocol *and* will stop this discussion so we 
>can move on with more interesting aspects of XML.

This non-solution makes many of the more interesting aspects of XML
difficult to use.  No changes to any protocol in return for a hobbled
infrastructure is not a solution I will accept happily.

>Proposed solution: every time the MIME handler comes across an unknown 
>media type, it looks in the body part and sees if it is XML. If it is XML, 
>add this media type to the "hand to the generic XML processor" list. If it 
>is not XML, add this media type to the "don't hand to the generic XML 
>processor" list. If you are really paranoid about missing something, clear 
>the latter list every so often.

This is the fallback case which applications are going to have to use in
the event that the -xml suffix is rejected, but I strongly doubt that it
either the best way to do it or the way that has the lowest cost.

If we assume that there will only be a relatively small number of XML media
types created, the costs of trying document types to find out if they
contain XML, in order to have some idea whether to try them again, is
minimal.  You load a document here and there and figure out that it's
useless junk or potentially valuable, and you keep track of the name.

As the number of document types grows, however, this processing and the
associated list become an ever growing burden.  In situations where human
users are managing MIME types across more than one program, keeping track
of this list (which of these are XML?) will grow more difficult quite
rapidly.  Programs and networks will both have to spend significant
resources, especially in cases (like search engines) where a generic XML
processor is exploring millions of documents.  Retrieving documents to test
if they're in a usable format becomes a very bad idea as the number of
document types grows.

Also, there are lots of cases where both application-specific and
XML-generic may be appropriate.  Crazy people like me who hand-code their
documents may want to be able to choose SVG viewing in a browser and
editing in an XML-based environment rather than an SVG drawing program.
It'll be much easier to set up those mappings if the description of the
documents - typically the MIME content-type - describes both possibilities.

If this growing and distributed burden is more attractive than a 4-byte
naming convention that doesn't interfere with existing processing, then I
suppose we should drop the suffix, and find out how popular this
non-approach proves to be in a couple of years.  At that point, it will be
very difficult to fix things.  I continue to argue that the suffix is a
remarkably low-cost solution with significant benefits.

>Done. No changes to the naming schemes needed, no hoping that if the naming 
>scheme changes that all future media types follow it, no worrying about 
>'x-' names getting it wrong. Making these lists won't be that hard; there 
>are only 330 types in the IANA registry now, and that includes all of the 
>'vnd.' names.

There's never been a syntax for creating your own document types (apart
from SGML, which never caught fire) without going through a complex
process, whether it was a standards- or vendor- based process. I suspect
there are at least 330 XML vocabularies out there right now, in various
stages of development, each of which could probably benefit from a
registered MIME type.  As for the x- names, I think they might take the
hint as registered names go out and the convention becomes part of XML best
practices.

Past performance is no guarantee of future returns.  

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

To: [email-masked], [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Fri, 17 Mar 2000 08:43:51 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]

If standardized, should be "alternate-types" and be a comma separated list
in priority order.

Donald

From:  Dan Crevier <[email-masked]>
Date:  Thu, 16 Mar 2000 21:16:31 -0800
Message-ID:  <[email-masked]>
In-Reply-To:  <[email-masked]>

>On 3/16/2000 8:29 PM, Paul Hoffman / IMC wrote:
>
>> ...
>> 
>> Proposed solution: every time the MIME handler comes across an unknown
>> media type, it looks in the body part and sees if it is XML. If it is XML,
>> add this media type to the "hand to the generic XML processor" list. If it
>> is not XML, add this media type to the "don't hand to the generic XML
>> processor" list. If you are really paranoid about missing something, clear
>> the latter list every so often.
>> 
>> ...
>
>This sounds like a good solution.  Another solution to the general problem
>of "How do I specify that a given MIME type can be handled as another
>alternate MIME type?" might be to do something like:
>
>Content-Type: application/iotp; alternate-type=text/xml
>
>If the client doesn't have something that can handle application/iotp, it
>starts going through the alternate types to see if there's another way to
>handle the data.  Current clients would just ignore the alternate-type.
>This seems like a really general solution that would solve this particular
>problem.
>
>Dan

Date: Fri, 17 Mar 2000 11:24:37 +0100
To: Tim Bray <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

At 21:39 16.03.00 -0800, Tim Bray wrote:
>I'm pretty sure the answer to #1 is "no".  However, my intuition is that
>the answer to #2 is "yes".  I don't have an opinion on #3.  The code isn't
>that hard to write.  But should a MIME hander have to care?
one nice thing about this solution is that it *requires no standard action*.
Anyone can implement this any time they want to, or not, as they choose.
If they don't do it, they are no worse off than before; if they do it, it's 
their headache.

(btw, the failure mode most likely is a document that says

<XML i-am-a-document-metadata-dtd>
lots of gory header-like stuff
</XML>
real content goes here)

              Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

Date: Thu, 16 Mar 2000 21:39:32 -0800
To: Paul Hoffman / IMC <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

At 08:29 PM 3/16/00 -0800, Paul Hoffman / IMC wrote:
>Proposed solution: every time the MIME handler comes across an unknown 
>media type, it looks in the body part and sees if it is XML. If it is XML, 

This would indeed finesse the problem.  Hmm, three questions on the notion
of detecting whether content is XML:

1. is it possible in principle in the general case?
2. if not, is it possible often enough to be useful?
3. is it an appropriate kind of thing to require a general-purpose
   MIME handler to do?

I'm pretty sure the answer to #1 is "no".  However, my intuition is that
the answer to #2 is "yes".  I don't have an opinion on #3.  The code isn't
that hard to write.  But should a MIME hander have to care?

I'm getting backed into a corner where, like it or not, the -xml convention
is looking substantially less bad than all the alternatives.  As for
charset, if the people who are asserting that we have to support fallback to
text/plain are right, then it's gotta be compulsory.  -Tim

Date: Thu, 16 Mar 2000 21:16:31 -0800
Subject: Re: Finishing the XML-tagging discussion
From: Dan Crevier <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 3/16/2000 8:29 PM, Paul Hoffman / IMC wrote:

> Folks, this discussion has gotten so far away from its origin that we've
> lost track of why we are having it.
> 
> The original problem is: how do I have my MIME handler automatically know
> that it should hand a body part that has an unknown tag on it to the
> generic XML processor?
> 
> We have explored many, many alternatives in detail. They all have
> drawbacks, some of them severe. However, there is a simple solution that
> involves no changes to any protocol *and* will stop this discussion so we
> can move on with more interesting aspects of XML.
> 
> Proposed solution: every time the MIME handler comes across an unknown
> media type, it looks in the body part and sees if it is XML. If it is XML,
> add this media type to the "hand to the generic XML processor" list. If it
> is not XML, add this media type to the "don't hand to the generic XML
> processor" list. If you are really paranoid about missing something, clear
> the latter list every so often.
> 
> Done. No changes to the naming schemes needed, no hoping that if the naming
> scheme changes that all future media types follow it, no worrying about
> 'x-' names getting it wrong. Making these lists won't be that hard; there
> are only 330 types in the IANA registry now, and that includes all of the
> 'vnd.' names.
> 
> Look inside and see if this media type seems to carry XML. This is what
> automated systems are good at. As for us humans, we seem to be pretty good
> at finding rat holes to go down...

This sounds like a good solution.  Another solution to the general problem
of "How do I specify that a given MIME type can be handled as another
alternate MIME type?" might be to do something like:

Content-Type: application/iotp; alternate-type=text/xml

If the client doesn't have something that can handle application/iotp, it
starts going through the alternate types to see if there's another way to
handle the data.  Current clients would just ignore the alternate-type.
This seems like a really general solution that would solve this particular
problem.

Dan

Date: Thu, 16 Mar 2000 20:29:24 -0800
To: [email-masked], [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Finishing the XML-tagging discussion
Sender: [email-masked]

Folks, this discussion has gotten so far away from its origin that we've 
lost track of why we are having it.

The original problem is: how do I have my MIME handler automatically know 
that it should hand a body part that has an unknown tag on it to the 
generic XML processor?

We have explored many, many alternatives in detail. They all have 
drawbacks, some of them severe. However, there is a simple solution that 
involves no changes to any protocol *and* will stop this discussion so we 
can move on with more interesting aspects of XML.

Proposed solution: every time the MIME handler comes across an unknown 
media type, it looks in the body part and sees if it is XML. If it is XML, 
add this media type to the "hand to the generic XML processor" list. If it 
is not XML, add this media type to the "don't hand to the generic XML 
processor" list. If you are really paranoid about missing something, clear 
the latter list every so often.

Done. No changes to the naming schemes needed, no hoping that if the naming 
scheme changes that all future media types follow it, no worrying about 
'x-' names getting it wrong. Making these lists won't be that hard; there 
are only 330 types in the IANA registry now, and that includes all of the 
'vnd.' names.

Look inside and see if this media type seems to carry XML. This is what 
automated systems are good at. As for us humans, we seem to be pretty good 
at finding rat holes to go down...

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
Date: Thu, 16 Mar 2000 17:10:30 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> > Unfortunately, the majority of MIME dispatchers fall into this category. So
> > much so that they cannot be ignored. You can complain about their brokenness
> > all you want but it isn't accomplishing anything.

> Then if someone wants to dispatch iotp, and have it recognised as
> something better than just xml, he will upgrade to a better dispatcher.
> But he is only 1 in 1,000,000 of the worldwide users of email, and so the
> rest of them can carry on using the old dispatchers for many years without
> problem.

> That illustrates a general principle with regard to user agents. If there
> is some new functionality on offer, the marketplace will surely provide
> products to support it. Those that require the new functionality will
> happily buy the new products. Those who don't need it won't bother.

Again, this is entirely at odds with reality. For one thing, upgrade decisions
are vastly more complex than this. So what happens is that someone who tags
their materal with a generic XML tag and a parameter identifying the specific
variant effectively loses the ability to dispatch to their handler on a
majority of platforms. This leaves them with two choices: Use a specific tag
and get immediate gratification or wait for an upgrade that might possibly be
real for some small subset of their customers, someday, maybe, hopefully. The
answer is, of course, obvious.

We've seen numerous cases of this play out in MIME already, as well as in
numerous other areas of standardization.

> You can afford to take decisions that require people to use the proper
> user agents.

Sorry, but there is overwhelming evidence that this is simply not correct.

> What you can't do, OTOH, is to take decisions that break the
> underlying transport mechanisms - those indeed takes many years to filter
> through.

Nobody is proposing any such thing.

				Ned

Date: Thu, 16 Mar 2000 14:21:30 +0100
To: [email-masked] (Charles Lindsey), [email-masked]
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Sender: [email-masked]

At 11:22 16.03.00 +0000, Charles Lindsey wrote:
>That illustrates a general principle with regard to user agents. If there
>is some new functionality on offer, the marketplace will surely provide
>products to support it. Those that require the new functionality will
>happily buy the new products. Those who don't need it won't bother.
Counterexample: delivery and receipt reports.

X.400 proved that people will buy product that support it.
The experience since the SMTP equivalents got standardized is that the MTAs 
will send them, but the UAs will not process them.

We have proved?

                 Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

To: [email-masked]
Xref: clerew local.mime:303
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Date: Thu, 16 Mar 2000 11:22:54 GMT
Lines: 39
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>> Then in that case the proper method is to say
>> 	Content-Type: application/xml; xml-type=iotp

>> And if there exist engines that do not underatand parameters, then they
>> are broken (but at least they will default to treating it as generic xml).

>Unfortunately, the majority of MIME dispatchers fall into this category. So
>much so that they cannot be ignored. You can complain about their brokenness
>all you want but it isn't accomplishing anything.

Then if someone wants to dispatch iotp, and have it recognised as
something better than just xml, he will upgrade to a better dispatcher.
But he is only 1 in 1,000,000 of the worldwide users of email, and so the
rest of them can carry on using the old dispatchers for many years without
problem.

That illustrates a general principle with regard to user agents. If there
is some new functionality on offer, the marketplace will surely provide
products to support it. Those that require the new functionality will
happily buy the new products. Those who don't need it won't bother.

You can afford to take decisions that require people to use the proper
user agents. What you can't do, OTOH, is to take decisions that break the
underlying transport mechanisms - those indeed takes many years to filter
through.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

From: [email-masked]
Date: Wed, 15 Mar 2000 07:28:53 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> Then in that case the proper method is to say
> 	Content-Type: application/xml; xml-type=iotp

As I've said repeatedly, this is fine in academic theory but fails miserably in
the real world.

> And if there exist engines that do not underatand parameters, then they
> are broken (but at least they will default to treating it as generic xml).

Unfortunately, the majority of MIME dispatchers fall into this category. So
much so that they cannot be ignored. You can complain about their brokenness
all you want but it isn't accomplishing anything.

And given the choice between having the ability to dispatch to specific
XML handlers without the ability to fall back on generic XML handling and
having only generic XML handling without the ability to dispatch to a
specific handler, the former is obviously better.

> But the whole idea of a "token", as used in MIME up till now, is that it
> is an atomic object - software is never required to do more than match it
> against its list of recognised tokens.

Actually, a fair number of implementations already allow wildcards in MIME
types. So in practice this already works in some cases.

				Ned

From: Keith Moore <[email-masked]>
To: "Rick Troth" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, [email-masked]
Subject: Re: another potential content-type suffix convention 
Date: Wed, 15 Mar 2000 09:53:09 -0500
Sender: [email-masked]

>  But!  sending audio or binary app data
> and not encoding it in something save like B64 is foolish.

the voice mail people are the folks who pushed for binary SMTP.

Keith

From: "Rick Troth" <[email-masked]>
To: "Keith Moore" <[email-masked]>, <[email-masked]>
Subject: RE: another potential content-type suffix convention
Date: Wed, 15 Mar 2000 08:40:20 -0600
Importance: Normal
Sender: [email-masked]

	Trying to do this in MIME
would close the door to newer  "text"  formats.

> you can safely convert the text/* objects, because (IIRC) the definition
> of text/* specifies that bare LF should not appear.  but what
> about application/*, audio/*, etc objects that just happen to
> use text as an underlying format?  can you convert these or not?

	I maintain  (wearing my QA hat and forcing the issue)
that  "plain text"  must survive the mangling.   Depends on
what your definition  "plain text"  is,  and we don't want
to go there.   But!  sending audio or binary app data
and not encoding it in something save like B64 is foolish.

> if you do convert, you will corrupt some objects that are not text.
> if you don't convert, the recipient will get some objects that
> are not in the right format for his platform.

	Sender should have encoded.

> the problem is that even though MIME specifies canonical format,
> in practice, some content types use different canonical formats depending
> on the transmission medium.  you can gloss over these differences
> unless you're using binary MIME.

	Avoid assumptions about binary.

Date: Wed, 15 Mar 2000 10:38:22 +0000
To: [email-masked] (Charles Lindsey)
From: Graham Klyne <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Cc: [email-masked]
Sender: [email-masked]

At 10:59 AM 3/14/00 +0000, Charles Lindsey wrote:
> >(1) It effectively defines a content-type parameter that spans multiple
> >    top-level content types. This is against the rules.
>
>But what if that is the way the real world operates? You can't say that,
>just because MIME has such a rule, then the real world is constrained to
>stick with data types that fit within that rule. The real world ain't
>like that. So maybe the time has come to review the rule.

That's like saying:  I have a hammer;  in the real world there are nails 
and there are screws, so when I see a screw, I must try and use my hammer 
to drive in that screw, rather that finding (or designing) a screwdriver.

#g

------------
Graham Klyne
([email-masked])

To: [email-masked]
Xref: clerew local.mime:297
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Date: Wed, 15 Mar 2000 10:44:35 GMT
Lines: 42
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>> >(2) It encodes information in a parameter that is immutable -- that is,
>> >    every instance of application/iotp is XML. Such information is supposed
>> >    to be part of the name; it is not what parameter are intended for.

>> Well is it immutable (I don't know)? Is every IOTP object also an XML
>> object?

>I believe so.

>> Or do the classes IOTP-but-not-XML and XML-but-not-iotp exist?

>As far as I know they do not.

>> And
>> is it the case that all the other object types that might have XML
>> representations *always* have those representations?

>In the case of something whose type ends in -xml as in this proposal, the
>answer is yes.

Then in that case the proper method is to say
	Content-Type: application/xml; xml-type=iotp

And if there exist engines that do not underatand parameters, then they
are broken (but at least they will default to treating it as generic xml).

But the whole idea of a "token", as used in MIME up till now, is that it
is an atomic object - software is never required to do more than match it
against its list of recognised tokens.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

From: [email-masked]
Date: Tue, 14 Mar 2000 21:03:34 -0800 (PST)
Subject: Re: another potential content-type suffix convention
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> for what it's worth (which might not be much)

> just as a strawman example of another possible content-type suffix:
> (I thought of this a few years ago, but it's taken awhile to remember it
> in the context of recent dicsussion.)

> some binary-transparent mail transports are LF-native, others are CRLF-native.

And some are neutral and support multiple formats (not limited to these)
natively.

> ...

> now if you have a MIME message with some of its contents labeleled
> with content-transfer-encoding: binary, and it traverses the boundary
> between an LF-native and CRLF-native transport, some of the
> "binary" objects may need to be converted from LF to CRLF or
> vice versa.

> you can safely convert the text/* objects, because (IIRC) the definition
> of text/* specifies that bare LF should not appear.  but what
> about application/*, audio/*, etc objects that just happen to
> use text as an underlying format?  can you convert these or not?

> if you do convert, you will corrupt some objects that are not text.
> if you don't convert, the recipient will get some objects that
> are not in the right format for his platform.

> the problem is that even though MIME specifies canonical format,
> in practice, some content types use different canonical formats depending
> on the transmission medium.  you can gloss over these differences
> unless you're using binary MIME.

> one idea to solve this problem (not necessarily a good one)
> was to define a content-type suffix (say -text) to denote
> content-types that used text as their underlying format.

This was raised during the original design of MIME. But it didn't fly then,
for a variety of reasons.

For one thing, the answer to the "can I convert" question isn't necessarily
"yes" or "no". There may be specific conversions that are allowed and others
that aren't. This is especially true once you look at entire list of
formats, which includes LF, CR, CRLF, counted (with byte, word, longword,
big-endian, little-endian, and pading variations), fixed padded, and
some others I won't bother to describe. And what the answer can be depends
on the content-type and platform and a bunch of other stuff. So having
this information in the tag doesn't provide you with enough information
to actually *do* much of anything. Whereas the argument with the -xml tag
is that it *does* provide enough information to act.

But another, even more serious, problem is that the media types that you can
supposedly convert willy-nilly from one of these formats to another often
aren't so flexible once you get down to the details. The standard example of
this is PostScript -- sometimes conversions are OK, but other times there are
counted structures that break if you convert. So now this information turns out
to be instance-dependent rather than type-dependent. 

Bottom line: I didn't see this as worth labelling back when we discussed
it circa 1991, and if anything experience with HTTP transport without
conversions has convinced me we were, if anything, worrying a nonissue.

				Ned

To: [email-masked]
Subject: another potential content-type suffix convention
cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Tue, 14 Mar 2000 23:02:53 -0500
Sender: [email-masked]

for what it's worth (which might not be much)

just as a strawman example of another possible content-type suffix:
(I thought of this a few years ago, but it's taken awhile to remember it
in the context of recent dicsussion.)

some binary-transparent mail transports are LF-native, others are CRLF-native.

by binary-transparent I mean that all the bits will go from source to
destination undisturbed.

by LF-native I mean that when using this transport, unencoded
text objects use LF as a line terminator.  UUCP and UNIX mailbox
files fall in this category.  

by CRLF-native I mean that when using this transport, unencoded
text objects use CRLF as a line terminator.  BINARY SMTP falls
in this category.

now if you have a MIME message with some of its contents labeleled
with content-transfer-encoding: binary, and it traverses the boundary
between an LF-native and CRLF-native transport, some of the 
"binary" objects may need to be converted from LF to CRLF or
vice versa. 

you can safely convert the text/* objects, because (IIRC) the definition
of text/* specifies that bare LF should not appear.  but what
about application/*, audio/*, etc objects that just happen to
use text as an underlying format?  can you convert these or not?

if you do convert, you will corrupt some objects that are not text.
if you don't convert, the recipient will get some objects that
are not in the right format for his platform.

the problem is that even though MIME specifies canonical format,
in practice, some content types use different canonical formats depending 
on the transmission medium.  you can gloss over these differences
unless you're using binary MIME.

one idea to solve this problem (not necessarily a good one)
was to define a content-type suffix (say -text) to denote
content-types that used text as their underlying format.

that way, the gateway between CRLF-native and LF-native
would know to convert line endings for text/* and */*-text
but would not convert line endings for other content types.

now if we also had -xml then the gateway might need to know
about -xml (with slightly different conversion rules)
in addition to -text.  or should XML objects be -xml-text? 

Keith

p.s. IIRC the rule we eventually agreed on (not sure whether
it's documented anywhere) was "don't send binary MIME over
LF-native transports".   much simpler and vastly preferable.
another good rule would be "nobody but the recipient 
can convert things into binary"

From: [email-masked]
Date: Tue, 14 Mar 2000 19:47:50 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> On Mon, 13 Mar 2000 08:02:11 PST, [email-masked] said:
> > Specifically, in order for this to work sending agents have to generate a field
> > saying "this thing is XML". In order to do tis they have to have a list of all
> > XML-based types. And this is exactly the list we're trying to avoid having.

> Huh?

> If I have a sending agent that knows how to generate a foobar type, and
> a foobar-using-xml type, then *whatever* scheme we use to flag xml, I
> have enough information to flag that THIS type is xml.

No, as I said before, all you have is an (application)->MIME type mapping.
Unless the fact that the type is XML is implicit in the MIME type
name you don't necessarily know it is XML.

> I don't need to
> know whether a frobozz-using-xml type exists, or is registered, or is
> being used via private agreement with x-frobozz types.

You either need to know that it is XML or else you'd have to examine
the data. And we try and avoid the latter...

> > Compare this with embedding this information in the content-type. There's
> > already a list of (some file characteristic)->content-type mappings in most
> > MIME applications. So no new list is needed. The information simply gets
> > embedded in the existing list.

> There's only one snag here - semi-legacy software.  If we decide that
> we should just use application/xml and tehn a Content-Feature: or
> whatever tag to flag specific ideosyncracies/schemas for the object,
> then once deployed, a receipient will be able to get at *least* the
> base application/xml level of support no matter WHAT future updates of
> his software he makes.

Not if the legacy software doesn't know to generate the content-feature
field. And this is going to take a fairly serious redesign to generate
in a lot of places.

> I thought the whole point of XML was that the
> reciepient will be able to do basic operations (such as "hmm.. forward
> all THIS stuff tagged with finance schema to Fred, and all the
> stuff that looks like shop-floor-machining stuff to Larry") without
> knowing what the heck the data IS.

I fail to see what this has to do with anything.

> If you start using application/iotp-xml, and application/foo-xml,
> and application/frobozz-xml, until the recipient updates his table,
> he gets punted ALL the way back to application/octet-stream.

Not if he has an application that looks for the suffix. And adding support for
this to legacy applications is far easier than adding support at the front end
to generate a new field *and* adding support at the back end to examine this
new field and act on it.

> That's a phone call to our help desk to figure out how to open
> this unidentified file.  Then another to find out how to install
> the table update for foobar-xml.  Then another to find out how
> to install the application to get rid of the "application not found"
> box.... You get the idea. ;)

OK, now consider the case where we use a content-feature field. You still
have to do all of this *and* you need to update the dispatcher with a
major new release *and* you need to convince the person sending the
message to update their software as well.

> /Valdis (who left user services mostly because he hated those kinds
> of phone calls ;)

Well, I myself haven't left, and believe me, I don't want to deal with the
upgrade nightmare a content-feature field implies.

				Ned

From: [email-masked]
Date: Tue, 14 Mar 2000 16:22:17 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME media type APPLICATION/IOTP)
To: Pete Resnick <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> On 3/13/00 at 2:13 PM -0800, [email-masked] wrote:

> >(3) It tends to discourage proper content-type labelling -- why
> >bother when the XML flag is all you need?

> If this were actually true, then why not have the defined
> Content-Type be "application/xml" with a parameter of
> "xml-content=iotp"?

I'd actually have no problem with this if the majority of applications
could dispatch this way. Unfortunately they cannot. In fact it is even
worse: We now have places where MIME types appear that don't allow
for *any* parameters. Yes, it is broken, but it is reality. (We're just
lucky that plain text, multiparts, or any of the various other MIME
content types where parameters are vital aren't used in these places.)

> If the XML is all you need to know,
> "application/xml" would let you know that you can act on this part;
> if you want to dispatch to a particular XML program (like an IOTP
> application), then the parameter will be enough for you to do that.

The fallacy here is that there are supposedly two groups of applications being
talked about and you are mixing them up. Specifically, there are ones that need
to know that something is XML, and ones that need to know the more specific
label. And neither of them are likely to be able to dispatch on a parameter
value.

> My guess is that the IOTP people will say, "No, we need to know from
> the Content-Type that it's IOTP so we can dispatch to IOTP
> applications easily with existing code." If their argument is
> correct, then proper Content-Type labelling will be forced to
> continue.

For IOTP perhaps. But likely not for other XML-derived types.

Basically my objection here can be rephrased to say that you are adding
gratuitous silly states to the protocol. And I'm opposed to silly states
because experience says that if you allow them they will happen. You now have a
parameter which had better appear on *every* object of this type or else some
things will break.

> Argument #3, BTW, perfectly well applies to "application/iotp-xml":
> If it really is true that "the XML flag is all you need", then we can
> expect to see "application/octet-stream-xml" for everything that even
> remotely smells like XML before long.

No, because we already have it: We call it application/xml.

> I think this argument against labeling outside of type/subtype (be it
> a parameter, a Content-Disposition, or some other Content-* field)
> just doesn't hold water.

I disagree. I think this sort of labelling will wreak all sorts of
havoc, whereas a proper subtype naming will not.

> The idea of parsing subtype names makes me
> think of parsing Subject fields for content; it's the wrong place to
> embed real information.

The two cases could not be more different; about the only thing they have in
common is that they both can appear in email.

				Ned

From: [email-masked]
Date: Tue, 14 Mar 2000 18:39:56 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> In <[email-masked]> [email-masked] writes:

> >Surely not! This has a bunch of problems:

> >(1) It effectively defines a content-type parameter that spans multiple
> >    top-level content types. This is against the rules.

> But what if that is the way the real world operates? You can't say that,
> just because MIME has such a rule, then the real world is constrained to
> stick with data types that fit within that rule. The real world ain't
> like that. So maybe the time has come to review the rule.

But it isn't the way the real world operates. The rule is there for a reason
and a lot of stuff depends on it. Indeed, it is precisely _because_ top
level types are used in the real world that the rule is important.

> >(2) It encodes information in a parameter that is immutable -- that is,
> >    every instance of application/iotp is XML. Such information is supposed
> >    to be part of the name; it is not what parameter are intended for.

> Well is it immutable (I don't know)? Is every IOTP object also an XML
> object?

I believe so.

> Or do the classes IOTP-but-not-XML and XML-but-not-iotp exist?

As far as I know they do not.

> And
> is it the case that all the other object types that might have XML
> representations *always* have those representations?

In the case of something whose type ends in -xml as in this proposal, the
answer is yes.

In short, this is a specious argument.

> >(3) It tends to discourage proper content-type labelling -- why bother when
> >    the XML flag is all you need?

> Indeed. If it is the case that all these things you are talking about are
> always best and most conveniently regarded as subtypes of XML, then fine.
> But people seem to be saying that this is not so.

Again, there are two classes of applications here that we're trying
to satisfy. The -xml suffix seems to satisfy both and every other proposal
satisfies one at most.

				Ned

Date: Tue, 14 Mar 2000 10:32:27 -0600 (CST)
From: Rick Troth <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: reason for application/iotp-xml 
Sender: [email-masked]

	I agree with Valdis' summary of the situation. 
 
> If you start using application/iotp-xml, and application/foo-xml,
> and application/frobozz-xml, until the recipient updates his table,
> he gets punted ALL the way back to application/octet-stream.
> 
> That's a phone call to our help desk   ... 
 
	So if IOTP needs its own  "application/"  type,  so be it. 
If it can be properly routed with  "application/xml",  better! 
But please DON'T clutter the space with  foo-xml  or  xml-foo. 
 
-- 
Rick Troth at La Casita, Houston, Texas, USA 

Date: Tue, 14 Mar 2000 10:29:32 -0500
To: [email-masked], [email-masked], [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Compromises on XML Media Types  (was Re: reason for application/iotp-xml)
Cc: Keith Moore <[email-masked]>, "Dan Kohn" <[email-masked]>, "MURATA Makoto" <[email-masked]>, [email-masked]
Sender: [email-masked]

First, apologies for spreading this message across multiple discussion
groups.  The headers for this round of discussion seem to keep growing, so
it would appear that there is interest in multiple circles.

The current draft of XML Media Types
(http://www.ietf.org/internet-drafts/draft-murata-xml-02.txt) includes a
section (6, with some examples in 7) representing a compromise position
arrived at through discussion on the ietf-xml-mime list.  I'll attempt to
summarize that discussion with reference to particular posts, and describe
at the end why I think the compromise is worth supporting.  Having
participated actively in the discussion, my viewpoint is biased, however,
so readers may wish to return to the archives themselves.
(http://www.imc.org/ietf-xml-mime/mail-archive/)

RFC 2376 provided the foundation for continuing work on XML Media Types,
describing the text/xml and application/xml types.  RFC 2376 served a
critical need at the time, providing a basic set of rules for transferring
XML over MIME-aware systems.  As XML development has spread to a wider
group, however, many developers began finding that they needed more
specific identifiers for particular XML vocabularies. In the process of
updating RFC 2376, we discussed how to handle these emerging vocabularies
as well as other critical issues, like identifying documents which are used
by XML without being XML per se, and encoding.

I arrived a bit late in the discussion, turning back claims
(http://www.imc.org/ietf-xml-mime/mail-archive/msg00060.html, #3) that
generic XML processing is not in fact useful as a fallback position.  I
think at this point there is significant if not complete consensus on
ietf-xml-mime that generic XML processing can be useful in a wide variety
of situtations, not all of which can be predicted at design-time by the
creators of a particular specification.

Given that generic processing can be useful, and becomes far easier if
content is explicitly labeled as XML - I'll be happy to defend that
position in greater detail if necessary - the question becomes how best to
enable such processing within the MIME framework.  (See
http://www.imc.org/ietf-xml-mime/mail-archive/msg00105.html for one
viewpoint opposing the provision of additional information within MIME
identifiers.)

I pushed hard at one point for a top-level xml/.  In many ways, this would
let the two-part MIME identifiers continue with the least modification,
would take advantage of the hierarchical structure already present.  This
did not prove acceptable, however, for a number of reasons that go well
beyond sheer reluctances to add another top-level types.  Most notably, XML
can be used to represent content in any of the top-level areas described by
content-types.  It is entirely plausible and in fact likely that a generic
tool for playing multimedia content (like the RealPlayer) would support
XML-based formats like SMIL or SVG.

As a result of this, discussion turned to other options for identifying XML
content.  The use of additional parameters (beyond content-type) had been
discussed earlier, the creation of an XML registration tree was also
proposed by Rick Jelliffe.  

I made a 'modest proposal'
(http://www.imc.org/ietf-xml-mime/mail-archive/msg00149.html, more formally
at http://www.imc.org/ietf-xml-mime/mail-archive/msg00149.html) for the
suffix, hoping to strike a balance between the existing structures and
newer needs.  The thread that followed
(http://www.imc.org/ietf-xml-mime/mail-archive/threads.html#00200) was not
exactly a love-fest, but seemed to be acceptable.

Most discussion on the subject since the initial proposals has had to do
with the particulars of the Internet Drafts that subsequently included the
proposals, not a general attack on the principle behind the suffix.  In my
other endeavors, outside of the IETF process, I haven't yet found
resistance to the suffix, though admittedly that's only about five cases,
all of which are in their early stages.

Yes, it's a compromise, and yes, it does mean additional work (suffix
examination) for applications that want to work with XML generically, but
it makes the task of generic XML tools much easier while imposing minimal
costs on the rest of the MIME infrastructure.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

To: [email-masked]
Xref: clerew local.mime:289
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Date: Tue, 14 Mar 2000 10:59:47 GMT
Lines: 38
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>Surely not! This has a bunch of problems:

>(1) It effectively defines a content-type parameter that spans multiple
>    top-level content types. This is against the rules.

But what if that is the way the real world operates? You can't say that,
just because MIME has such a rule, then the real world is constrained to
stick with data types that fit within that rule. The real world ain't
like that. So maybe the time has come to review the rule.

>(2) It encodes information in a parameter that is immutable -- that is,
>    every instance of application/iotp is XML. Such information is supposed
>    to be part of the name; it is not what parameter are intended for.

Well is it immutable (I don't know)? Is every IOTP object also an XML
object? Or do the classes IOTP-but-not-XML and XML-but-not-iotp exist? And
is it the case that all the other object types that might have XML
representations *always* have those representations?

>(3) It tends to discourage proper content-type labelling -- why bother when
>    the XML flag is all you need? 

Indeed. If it is the case that all these things you are talking about are
always best and most conveniently regarded as subtypes of XML, then fine.
But people seem to be saying that this is not so.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP) 
Date: Tue, 14 Mar 2000 04:43:30 -0500
Sender: [email-masked]

On Mon, 13 Mar 2000 08:02:11 PST, [email-masked] said:
> Specifically, in order for this to work sending agents have to generate a field
> saying "this thing is XML". In order to do tis they have to have a list of all
> XML-based types. And this is exactly the list we're trying to avoid having.

Huh?

If I have a sending agent that knows how to generate a foobar type, and
a foobar-using-xml type, then *whatever* scheme we use to flag xml, I
have enough information to flag that THIS type is xml.  I don't need to
know whether a frobozz-using-xml type exists, or is registered, or is
being used via private agreement with x-frobozz types.

> Compare this with embedding this information in the content-type. There's
> already a list of (some file characteristic)->content-type mappings in most
> MIME applications. So no new list is needed. The information simply gets
> embedded in the existing list.

There's only one snag here - semi-legacy software.  If we decide that
we should just use application/xml and tehn a Content-Feature: or
whatever tag to flag specific ideosyncracies/schemas for the object,
then once deployed, a receipient will be able to get at *least* the
base application/xml level of support no matter WHAT future updates of
his software he makes.  I thought the whole point of XML was that the
reciepient will be able to do basic operations (such as "hmm.. forward
all THIS stuff tagged with finance schema to Fred, and all the
stuff that looks like shop-floor-machining stuff to Larry") without
knowing what the heck the data IS.

If you start using application/iotp-xml, and application/foo-xml,
and application/frobozz-xml, until the recipient updates his table,
he gets punted ALL the way back to application/octet-stream.

That's a phone call to our help desk to figure out how to open
this unidentified file.  Then another to find out how to install
the table update for foobar-xml.  Then another to find out how
to install the application to get rid of the "application not found"
box.... You get the idea. ;)

/Valdis (who left user services mostly because he hated those kinds
of phone calls ;)

To: [email-masked], [email-masked]
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP) 
Date: Mon, 13 Mar 2000 22:10:49 -0500
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]

Definitely true.  The whole SGML derived concept of a rigid document
type with a DTD is giving way to a much more fluid concpet where it
will be the common case that most anything can get stuck inside
anything else of any significant complexity all identified by
namespaces and each having their own schema.

Donald

From:  Graham Klyne <[email-masked]>
Message-Id:  <[email-masked]>
X-Sender:  [email-masked]
Date:  Mon, 13 Mar 2000 18:20:50 +0000
To:  [email-masked]
Cc:  Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>,
            Dan Kohn <[email-masked]>, [email-masked],
            "Martin J. Duerst" <[email-masked]>,
            MURATA Makoto <[email-masked]>,
            "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
In-Reply-To:  <[email-masked]>
References:  <"Your message dated Mon, 13 Mar 2000 10:43:55 +0000" <4.2.2.20000313101
[email-masked]>
	     <[email-masked]>
	     <[email-masked]>
	     <[email-masked]>

>At 08:02 AM 3/13/00 -0800, [email-masked] wrote:
>
>>>      Content-features:  (Schema="<URI>")
>
>[...]
>
>
>>Well, I would have hoped that the schema would be derivable from the content
>>without the need for a conneg tag. That is, given the labelling in the
>>content it should be possible to construct a URN automatically that tells
>>you where to look for the schema definition.
>>
>>And again, unless you're dealing with application/xml, this seems like
>>an immutable property of the type.
>
> From my reading, this is not true of the W3C vision of where XML in 
>general, and RDF in particular, may be going.
>
>I understand that the idea of using multiple schema in a single document is 
>very much part of the long-term vision.  So, for example, an invoice may be 
>described in the language of business, but the items to which it refers may 
>be described in a language described by some completely different 
>schema.  A business application may need to understand the invoice-schema 
>parts of the invoice, but a manufacturing control application might need to 
>understand a different set of information expressed in different terms.
>
>#g
>
>------------
>Graham Klyne
>([email-masked])
>

Date: Mon, 13 Mar 2000 20:49:32 -0600
To: Dan Kohn <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: RE: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Cc: [email-masked], Keith Moore <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto	 <[email-masked]>, "Donald E. Eastlake 3rd"	 <[email-masked]>, [email-masked], "[email-masked]'"	 <[email-masked]>
Sender: [email-masked]

Just to answer an old one:

On 3/11/00 at 12:34 PM -0800, Dan Kohn wrote:

>I appreciate Pete's concern here, and agree that in an ideal world, 
>this could be handled under Content-Disposition or some new sort of 
>Content-Structure header.   But my (perhaps mistaken) belief is that 
>most dispatching tools out there work off of MIME type, and do not 
>necessarily have access to arbitrary Content- headers.

This is true for legacy dispatching tools which don't look at other 
MIME headers, but in those cases, they have an easy solution:

1. Map application/iotp to an IOTP application.
2. Map application/iotp to an XML application.

If you are going to *modify* a dispatching tool to parse subtypes, I 
don't see why you can't modify it to grab a different Content-* field 
or a parameter on the Content-Type line.

>The point is that "-xml" has demonstratable benefit to a significant subset
>of the community, while Pete and Keith have complained about the lack of
>elegance of the solution.

It's not just elegance; I believe both Keith and I are worried about 
mucking up the works down the road.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Mon, 13 Mar 2000 20:49:30 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME media type APPLICATION/IOTP)
Sender: [email-masked]

On the other two points:

On 3/13/00 at 2:13 PM -0800, [email-masked] wrote:

>(1) It effectively defines a content-type parameter that spans 
>multiple top-level content types.

How? It seems to only apply to "application" as far as I can see now. 
But, even if this is true, we are introducing exactly the same kind 
of thing with "-xml" (a cross-"Content-Type" parameter, albeit 
encoded in the subtype name). Perhaps we should just say that this is 
a good place to start violating that rule?

>(2) It encodes information in a parameter that is immutable -- that 
>is, every instance of application/iotp is XML.

But this might not be true for other subtypes.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Mon, 13 Mar 2000 20:37:26 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME media type APPLICATION/IOTP)
Sender: [email-masked]

On 3/13/00 at 2:13 PM -0800, [email-masked] wrote:

>(3) It tends to discourage proper content-type labelling -- why 
>bother when the XML flag is all you need?

If this were actually true, then why not have the defined 
Content-Type be "application/xml" with a parameter of 
"xml-content=iotp"? If the XML is all you need to know, 
"application/xml" would let you know that you can act on this part; 
if you want to dispatch to a particular XML program (like an IOTP 
application), then the parameter will be enough for you to do that. 
My guess is that the IOTP people will say, "No, we need to know from 
the Content-Type that it's IOTP so we can dispatch to IOTP 
applications easily with existing code." If their argument is 
correct, then proper Content-Type labelling will be forced to 
continue.

Argument #3, BTW, perfectly well applies to "application/iotp-xml": 
If it really is true that "the XML flag is all you need", then we can 
expect to see "application/octet-stream-xml" for everything that even 
remotely smells like XML before long.

I think this argument against labeling outside of type/subtype (be it 
a parameter, a Content-Disposition, or some other Content-* field) 
just doesn't hold water. The idea of parsing subtype names makes me 
think of parsing Subject fields for content; it's the wrong place to 
embed real information.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

From: [email-masked]
Date: Mon, 13 Mar 2000 14:13:08 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> In <[email-masked]> Paul Hoffman / IMC <[email-masked]> writes:

> >I propose to leave the type application/iotp and to drop this discussion
> >until there is a request for a real-world application where thre would be
> >some advantage to the end user for application/foo-xml to be handed to an
> >XML viewer directly instead of being written to disk.

> Just stumbled on this discussion. I know zilch about iotp, and no more
> than epsilon about xml. So let me recap and see if I understand the
> problem.

> Something arrives described as application/iotp (or is it text/iotp - who
> cares).

> If you were expecting such things, and are in the business of handling
> iotp objects (whatever they are), you presumably possess an iotp engine,
> and have configured your mailer to use it when it sees application/iotp.

> So far so good. But if you are not expecting such messages, you might like
> to try to understand it to find out what is going on. If the best your
> mailer can do is put it in a file and tell you it as recevied an
> application/octet-stream, that leaves you on your own to figure it out.

> But (so I gather) help is at hand. Iotp can also be understood by an XML
> engine, which, even if it doesn't understand iotp fully, can at least
> print out the structure of the document, so you know where to start
> looking in order to figure it out.

> So, what the message needs to say is "if you have an iotp engine, then
> that should be the first choice for interpreting this document; but if
> not, give it to your XML engine, which will at least have an intelligent
> try". Is that correct?

> If so, then surely the correct MIME way to do it is something like:

> Content-Type: application/iotp; alternative-format=xml

Surely not! This has a bunch of problems:

(1) It effectively defines a content-type parameter that spans multiple
    top-level content types. This is against the rules.
(2) It encodes information in a parameter that is immutable -- that is,
    every instance of application/iotp is XML. Such information is supposed
    to be part of the name; it is not what parameter are intended for.
(3) It tends to discourage proper content-type labelling -- why bother when
    the XML flag is all you need? 

FYI, Keith already proposed approximately this, but as a content-disposition
parameter, which avoids (1) and (2) but makes (3) even more of a problem.

				Ned

Date: Mon, 13 Mar 2000 18:20:50 +0000
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 08:02 AM 3/13/00 -0800, [email-masked] wrote:

>>      Content-features:  (Schema="<URI>")

[...]

>Well, I would have hoped that the schema would be derivable from the content
>without the need for a conneg tag. That is, given the labelling in the
>content it should be possible to construct a URN automatically that tells
>you where to look for the schema definition.
>
>And again, unless you're dealing with application/xml, this seems like
>an immutable property of the type.

 From my reading, this is not true of the W3C vision of where XML in 
general, and RDF in particular, may be going.

I understand that the idea of using multiple schema in a single document is 
very much part of the long-term vision.  So, for example, an invoice may be 
described in the language of business, but the items to which it refers may 
be described in a language described by some completely different 
schema.  A business application may need to understand the invoice-schema 
parts of the invoice, but a manufacturing control application might need to 
understand a different set of information expressed in different terms.

#g

------------
Graham Klyne
([email-masked])

From: [email-masked]
Date: Mon, 13 Mar 2000 08:02:11 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: Graham Klyne <[email-masked]>
Cc: [email-masked], Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Sender: [email-masked]

> > All of these approaches were explored in depth already on the XML-MIME list.
> > All of them have major disadvantages over the tagging scheme presently
> > proposed. I ended up in strong opposition to all of them, whereas I could find
> > no good reason to oppose this approach.

> Was the 'Content-features' + CONNEG proposal one of those that you strongly
> opposed for this purpose?  If so, I'd like to know why.

I believe this one was discussed. And I agree that it's the best of a bad lot.

However, I still oppose it. The problem with this proposal is that all it
does is push the problem around; it doesn't solve it.

Specifically, in order for this to work sending agents have to generate a field
saying "this thing is XML". In order to do tis they have to have a list of all
XML-based types. And this is exactly the list we're trying to avoid having.

Compare this with embedding this information in the content-type. There's
already a list of (some file characteristic)->content-type mappings in most
MIME applications. So no new list is needed. The information simply gets
embedded in the existing list.

Now, I know that the conneg folks have high hopes of being able to pass conneg
information from applications generating media types to the applications that
move them around. However, existing infrastructure rarely supports this sort of
thing at present. And if you believe that knowing something is XML is useful,
waiting for this infrastructure to appear just isn't reasonable.

I am also less that fully comfortable using conneg fields to carry around
information that is an immutable property of a given media type. My feeling
is that conneg is for the stuff that's associated with a given instance
of a media type.

> I've briefly reviewed the XML-MIME discussion, but haven't been able to
> spot anything that argues against this approach, except that there was an
> expressed requirement for a very "simple" way to detect XML content.

Its basically the same as the argument against putting a "this is XML" tag in 
the content-disposition field. It's a much better semantic fit than
content-disposition, but that's all.

> The Murata proposal goes some way toward this and, like you, I see it as
> "mostly harmless", even though it may be messy at times.  But I don't think
> it can ever be a complete solution:  I cannot see that it will be
> reasonable to enforce that all processors will reliably recognize XML in
> this way.  But a simple mechanism --like Murata-- that can work much of the
> time may still be useful on occasion.  I refer in particular to your
> comment quoted at the end of this message.

> Where this leads me is:  what is an appropriate mechanism for describing
> for precisely the XML use of some content?  I offer something along the
> lines of:

>      Content-features:  (Schema="<URI>")

> (Where <URI> can refer to a DTD, XML-schema, RDF-schema or other
> XML-related document schema.)  The CONNEG framework can allow this to be
> extended to deal with compound documents that are part-XML, or to compound
> XML documents that use different schema in different parts.  I also believe
> this can be designed to interwork cleanly with some ideas being considered
> for W3C CC/PP.

Well, I would have hoped that the schema would be derivable from the content
without the need for a conneg tag. That is, given the labelling in the
content it should be possible to construct a URN automatically that tells
you where to look for the schema definition.

And again, unless you're dealing with application/xml, this seems like
an immutable property of the type.

				Ned

From: Keith Moore <[email-masked]>
To: Graham Klyne <[email-masked]>
cc: "Scott Lawrence" <[email-masked]>, "Dan Kohn" <[email-masked]>, "'Keith Moore'" <[email-masked]>, [email-masked], [email-masked], [email-masked], "Martin J. Duerst" <[email-masked]>, "MURATA Makoto" <[email-masked]>, [email-masked], "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP) 
Date: Mon, 13 Mar 2000 09:59:40 -0500
Sender: [email-masked]

> I could be wrong, but my take is that the top-level MIME type relates to 
> the media presentation/handling capabilities of the receiving system

it's actually both this and default handling.  we went through a lot
of this when agonizing over whether to accept model/ as a new top-level.

but IMHO media presentation takes precedence over default handling.
so it's more important for an xml-based audio type to be audio/foo
than xml/foo.

To: [email-masked]
Xref: clerew local.mime:278
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Date: Mon, 13 Mar 2000 11:05:22 GMT
Lines: 47
Sender: [email-masked]

In <[email-masked]> Paul Hoffman / IMC <[email-masked]> writes:

>I propose to leave the type application/iotp and to drop this discussion 
>until there is a request for a real-world application where thre would be 
>some advantage to the end user for application/foo-xml to be handed to an 
>XML viewer directly instead of being written to disk.

Just stumbled on this discussion. I know zilch about iotp, and no more
than epsilon about xml. So let me recap and see if I understand the
problem.

Something arrives described as application/iotp (or is it text/iotp - who
cares).

If you were expecting such things, and are in the business of handling
iotp objects (whatever they are), you presumably possess an iotp engine,
and have configured your mailer to use it when it sees application/iotp.

So far so good. But if you are not expecting such messages, you might like
to try to understand it to find out what is going on. If the best your
mailer can do is put it in a file and tell you it as recevied an
application/octet-stream, that leaves you on your own to figure it out.

But (so I gather) help is at hand. Iotp can also be understood by an XML
engine, which, even if it doesn't understand iotp fully, can at least
print out the structure of the document, so you know where to start
looking in order to figure it out.

So, what the message needs to say is "if you have an iotp engine, then
that should be the first choice for interpreting this document; but if
not, give it to your XML engine, which will at least have an intelligent
try". Is that correct?

If so, then surely the correct MIME way to do it is something like:

Content-Type: application/iotp; alternative-format=xml

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

Date: Mon, 13 Mar 2000 11:07:17 +0000
To: "Scott Lawrence" <[email-masked]>
From: Graham Klyne <[email-masked]>
Subject: RE: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP) 
Cc: "Dan Kohn" <[email-masked]>, "'Keith Moore'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Martin J. Duerst" <[email-masked]>, "MURATA Makoto" <[email-masked]>, <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]

At 12:24 PM 3/12/00 -0500, Scott Lawrence wrote:
> > >why?  is there really much value in a default treatment
> > of text/* xml
> > >documents as plain text?  (the default doesn't seem to
> > work well in
> > >practice for text/html) or is xml really likely to be used for
> > >image/*, audio/*, video/*, or model/* content?
>
>I think that this actually argues in favor of 'xml/' as a top level.

I disagree.

I could be wrong, but my take is that the top-level MIME type relates to 
the media presentation/handling capabilities of the receiving system, and 
the sub-type relates to the content encoding/decoding details of a 
particular message.  I think XML falls into the second category for most 
purposes.

#g

------------
Graham Klyne
([email-masked])

Date: Mon, 13 Mar 2000 10:43:55 +0000
To: [email-masked]
From: Graham Klyne <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Cc: Pete Resnick <[email-masked]>, Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Sender: [email-masked]

Ned,

When you say:
>All of these approaches were explored in depth already on the XML-MIME list.
>All of them have major disadvantages over the tagging scheme presently
>proposed. I ended up in strong opposition to all of them, whereas I could find
>no good reason to oppose this approach.

Was the 'Content-features' + CONNEG proposal one of those that you strongly 
opposed for this purpose?  If so, I'd like to know why.

I've briefly reviewed the XML-MIME discussion, but haven't been able to 
spot anything that argues against this approach, except that there was an 
expressed requirement for a very "simple" way to detect XML content.

The Murata proposal goes some way toward this and, like you, I see it as 
"mostly harmless", even though it may be messy at times.  But I don't think 
it can ever be a complete solution:  I cannot see that it will be 
reasonable to enforce that all processors will reliably recognize XML in 
this way.  But a simple mechanism --like Murata-- that can work much of the 
time may still be useful on occasion.  I refer in particular to your 
comment quoted at the end of this message.

Where this leads me is:  what is an appropriate mechanism for describing 
for precisely the XML use of some content?  I offer something along the 
lines of:

     Content-features:  (Schema="<URI>")

(Where <URI> can refer to a DTD, XML-schema, RDF-schema or other 
XML-related document schema.)  The CONNEG framework can allow this to be 
extended to deal with compound documents that are part-XML, or to compound 
XML documents that use different schema in different parts.  I also believe 
this can be designed to interwork cleanly with some ideas being considered 
for W3C CC/PP.

Finally, I note that one of the objections raised on the XML-MIME list was 
a desire to avoid using content negotiation protocols in order to discover 
that a document contains XML.  I agree.  I observe that neither the CONNEG 
framework, nor the 'Content-features:' proposal, is a negotiation protocol 
per se.  They are mechanisms for describing content features and handling 
capabilities, which may be used as part of a negotiation framework, but 
studiously avoid defining any negotiation protocol.

#g
--

At 01:00 PM 3/11/00 -0800, [email-masked] wrote:
>>I've really got to agree with Keith here; this is a mess and I oppose
>>the direction it is taking. If XML-ishness needs to be called out as
>>a property of a body part, it should be separated out as a parameter
>>of some sort, or made a new field, not embedded as part of the name
>>of a content-type. I know where in our code I can dispatch off of a
>>parameter or a new field; that's easy. Dispatching off part of a name
>>would be grotesque.
>
>All of these approaches were explored in depth already on the XML-MIME list.
>All of them have major disadvantages over the tagging scheme presently
>proposed. I ended up in strong opposition to all of them, whereas I could find
>no good reason to oppose this approach.
>
>>There are mechanisms in MIME to call out properties like this. Why
>>are we trying to embed this particular one in the name instead of
>>using the mechanisms that MIME provides?
>
>Because upon examination none of them seem even remotely correct for the task
>at hand. My conclusion is that if you want to do this, this is right way.

Also, Ned said, long ago in May 1999, in the XML-MIME list:
>The long and short of it is that I don't see either extreme position on this
>issue as tenable. The notion of "all XML goes under the application/xml media
>type and a different mechanism is used to distinguish different instances of
>XML usage" is a nonstarter, and so is "every little twiddle to something done
>in XML gets a new media type". I also don't think that XML is even close to
>mature enough for us to attempt to establish definitive rules for when a media
>type is needed and when it isn't.

------------
Graham Klyne
([email-masked])

From: Keith Moore <[email-masked]>
To: "D. J. Bernstein" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: reason for application/iotp-xml 
Date: Sun, 12 Mar 2000 20:43:50 -0500
Sender: [email-masked]

> When you have a universal video tool, and a universal XML browser, what
> do you do with video/blah-xml? (Or should that be xml/blah-video?)

good question.  offhand, I'd say video/ takes precedence for presentation 
purposes.  it's difficult to imagine any kind of generic XML tool
doing a good job at presentation for anything other than text objects...
and after all one reason that universal video, audio, and image presentation
tools exist is that it's nice to have the same user interface regardless
of subtype.

OTOH, an indexer for a search engine might give more precedence to the -xml 
suffix.

Keith

Date: 13 Mar 2000 00:08:50 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: reason for application/iotp-xml
Sender: [email-masked]

Keith Moore writes:
> yes, but it does seem fairly common to have a "universal video tool" that
> understands most video formats

When you have a universal video tool, and a universal XML browser, what
do you do with video/blah-xml? (Or should that be xml/blah-video?)

---Dan

From: [email-masked]
Date: Sun, 12 Mar 2000 15:14:36 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: Keith Moore <[email-masked]>
Cc: Scott Lawrence <[email-masked]>, Dan Kohn <[email-masked]>, "'Keith Moore'" <[email-masked]>, [email-masked], [email-masked], [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, [email-masked], "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]

> > the notion of something useful being possible with an arbitrary
> > 'video/foo' type that my application doesn't understand just doesn't
> > fly.

> yes, but it does seem fairly common to have a "universal video tool" that
> understands most video formats - perhaps even formats that the MIME
> reader doesn't know about.  having such a tool as the default handler
> for video/* allows your MIME reader to play video clips even when the
> specific video/ type isn't registered with it.  similarly for audio/*.

Exactly right. I'd also add "image" to the list.

				Ned

From: [email-masked]
Date: Sun, 12 Mar 2000 15:11:20 -0800 (PST)
Subject: RE: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: Scott Lawrence <[email-masked]>
Cc: Dan Kohn <[email-masked]>, "'Keith Moore'" <[email-masked]>, [email-masked], [email-masked], [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, [email-masked], "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]

> > >why?  is there really much value in a default treatment
> > of text/* xml
> > >documents as plain text?  (the default doesn't seem to
> > work well in
> > >practice for text/html) or is xml really likely to be used for
> > >image/*, audio/*, video/*, or model/* content?

> I think that this actually argues in favor of 'xml/' as a top level.
> It is certainly true that at least some level of processing can be
> done on any XML document by generic XML processors whether or not
> they understand anything at all about the rest of the type - that's
> one of the primary design goals of XML.  The 'text/' top level type
> is probably the _only_ other MIME type for which that is true - the
> notion of something useful being possible with an arbitrary
> 'video/foo' type that my application doesn't understand just doesn't
> fly.

Flies fine for me on a regular basis. I tend to use MIME stuff on two
systems, one which supports default top-level handling and the other
does not. In the case of the latter system, scarcely a month goes by
where I don't have to go through a tedious process of adding entries. In the
case of the former, it has been literally *years* since I've touched my
MIME settings.

				Ned

From: Keith Moore <[email-masked]>
To: "Scott Lawrence" <[email-masked]>
cc: "Dan Kohn" <[email-masked]>, "'Keith Moore'" <[email-masked]>, [email-masked], [email-masked], [email-masked], "Martin J. Duerst" <[email-masked]>, "MURATA Makoto" <[email-masked]>, [email-masked], "Donald E. Eastlake 3rd" <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP) 
Date: Sun, 12 Mar 2000 12:16:38 -0500
Sender: [email-masked]

> the notion of something useful being possible with an arbitrary
> 'video/foo' type that my application doesn't understand just doesn't
> fly.

yes, but it does seem fairly common to have a "universal video tool" that
understands most video formats - perhaps even formats that the MIME
reader doesn't know about.  having such a tool as the default handler
for video/* allows your MIME reader to play video clips even when the
specific video/ type isn't registered with it.  similarly for audio/*.

presumably such tools would work with XML-based video and audio formats 
also, if such ever became popular.

From: "Scott Lawrence" <[email-masked]>
To: "Dan Kohn" <[email-masked]>, "'Keith Moore'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Martin J. Duerst" <[email-masked]>, "MURATA Makoto" <[email-masked]>, <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>
Subject: RE: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP) 
Date: Sun, 12 Mar 2000 12:24:08 -0500
Importance: Normal
Sender: [email-masked]

> >why?  is there really much value in a default treatment
> of text/* xml
> >documents as plain text?  (the default doesn't seem to
> work well in
> >practice for text/html) or is xml really likely to be used for
> >image/*, audio/*, video/*, or model/* content?

I think that this actually argues in favor of 'xml/' as a top level.
It is certainly true that at least some level of processing can be
done on any XML document by generic XML processors whether or not
they understand anything at all about the rest of the type - that's
one of the primary design goals of XML.  The 'text/' top level type
is probably the _only_ other MIME type for which that is true - the
notion of something useful being possible with an arbitrary
'video/foo' type that my application doesn't understand just doesn't
fly.

I don't like the idea of the '-xml' - it introduces a new piece of
structure that we don't need.  The top level type is there for
exactly this purpose, and XML fits it better than most other top
level types.

--
Scott Lawrence      Director of R & D        <[email-masked]>
Agranat Systems   Embedded Web Technology
http:/most/www.agranat.com/

Date: Sun, 12 Mar 2000 18:39:31 +0900
To: [email-masked], [email-masked], [email-masked]
Subject: Re: reason for application/iotp-xml (was RE: Registration of  MIME med ia type APPLICATION/IOTP)
From: MURATA Makoto <[email-masked]>
Sender: [email-masked]

In message "Re: reason for application/iotp-xml (was RE: Registration of 
  MIME med ia type APPLICATION/IOTP)",
Tim Bray wrote...
 >There's also an argument from principle.  One of the core ideas of XML is to 
 >move past the notion that data should be encoded in a format proprietary 
 >to a product or application.  The idea is that the door should always be 
 >left open for future processing of data in ways that are unpredictable at 
 >the time of creation.  The generalized -xml convention certainly is 
 >consistent with that spirit.

Agreed.

XML is a meta language: XML-based formats can be defined by providing a 
tag-and-attribute inventory on top of XML.  XML is a self-descriptive 
language: any data in any XML-based format can be parsed and further 
processed without any knowledge of a particular tag-and-attribute inventory.
  
The whole point of XML is to make XML-generic processing possible and 
powerful so that development of each XML-based format is easy.  A large 
number of XML software tools (e.g., XML editors or browsers) are designed 
so that they can be used for any tag-and-attribute inventory.  Other than 
IE 5.0, we have XMLSpy, XML Notepad, and so forth.  Generic XML 
processing is the whole point of XML!

In message "Re: reason for application/iotp-xml (was RE: Registration of 
  MIME med ia type APPLICATION/IOTP)",
Paul Hoffman / IMC wrote...

 >And, just to get back to specifics, the author of the IOTP draft said the 
 >other day:
 >
 >>I'm polling the TRADE WG but it is my impression that there is enough
 >>implementation that people would prefer not to change.
 >
 >Not only can we wait for "the next one" on this topic, we have another 
 >example of a group that doesn't feel much inclined towards the utility of 
 >the application/foo-xml solution for their protocol.

Since this issue requires balance of so many things, I do not think that 
we have a thoroughly thougtout example yet.

In message "Re: reason for application/iotp-xml (was RE: Registration of 
  MIME med ia type APPLICATION/IOTP)",
Tim Bray wrote...
 >Having said that, I still have the feeling that if we do all agree that
 >this is a good effect to achieve, there has to be a better way than
 >this -xml convention.  Media types have been working well in a 2-part
 >structure for a long time, going to a 2-and-a-half parts smells funny.
 >But I haven't thought of anything better. -Tim

Nobody really likes the -xml convention.  But we have already investigated 
other proposals and none of them appear have been accepted.

Cheers,

----
MURATA Makoto  [email-masked]

Date: Sat, 11 Mar 2000 21:07:30 -0800
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of   MIME med ia type APPLICATION/IOTP)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 05:40 PM 3/11/00 -0800, Paul Hoffman / IMC wrote:
>>1. A web crawler building a full-text index
>>2. An XLink processor building a topological map a la Google
>>3. A rules-driven firewall filter deciding whether to let something
>>    through
>>4. A schema-driven datatype-checker
>
>Of these four, only (3) makes sense for IOTP. 

Well, I'm claiming the thesis behind XML is that you can't prejudge what
might or might not make sense tomorrow for the data objects you create
today.  Having said that, I'm prepared to believe that you're right
as regards IOTP.

>(3) is pretty psychedelic. Firewalls that look at MIME types but not the 
>content are so horribly insecure as to not need further discussion.

That's not it; one can envision a firewall that checks those data
objects known to be XML-encoded, whatever their primary media types,
for certain patterns of XML markup that are regarded as blessed or
unblessed.  In particular, given that there is likely to be XML
markup that has cross-application inclusion semantics, one can
envision firewalls disallowing such inclusions whatever the application.

>Not only can we wait for "the next one" on this topic, we have another 
>example of a group that doesn't feel much inclined towards the utility of 
>the application/foo-xml solution for their protocol.

I'm not trying to be difficult, but once again, one of the central
theses in the use of XML is explicitly to minimize the damage due to
the fact that very few groups, in designing a data format, bother to take 
the trouble to ensure that it might be reusable for unforeseen 
purposes at a later date.  Thus, the fact that this particular group
says they don't need this particular flag for their particular application
is not very relevant to the argument as to whether the -xml suffix is
a good idea.  -Tim

Date: Sat, 11 Mar 2000 17:40:02 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of  MIME med ia type APPLICATION/IOTP)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 03:37 PM 3/11/00 -0800, Tim Bray wrote:
>1. A web crawler building a full-text index
>2. An XLink processor building a topological map a la Google
>3. A rules-driven firewall filter deciding whether to let something
>    through
>4. A schema-driven datatype-checker

Of these four, only (3) makes sense for IOTP. And, even then, a sender or 
receiver of a IOTP object behind a firewall would have already talked to 
the net admin for the firewall to allow application/iotp through. Also, see 
below.

But, to stretch into the theoretical again, let's also look at calendar 
objects in XML. In the case of (1) and (2) and (4), the process doing the 
XML crawling and/or indexing *should* know about application/iotp. Even if 
it doesn't, and it is making the assumption that "there's XML out there 
that I don't know the MIME type of but I want to find it", it will likely 
pull down or look at all objects with MIME types that it doesn't know about 
(thereby skipping all the image/gif files) and then look in the file to see 
"is this XML"? The first time that the process comes across application/foo 
and discovers that it has XML in it, you can bet that the process would 
start to specifically look for application/foo.

(3) is pretty psychedelic. Firewalls that look at MIME types but not the 
content are so horribly insecure as to not need further discussion.

And, just to get back to specifics, the author of the IOTP draft said the 
other day:

>I'm polling the TRADE WG but it is my impression that there is enough
>implementation that people would prefer not to change.

Not only can we wait for "the next one" on this topic, we have another 
example of a group that doesn't feel much inclined towards the utility of 
the application/foo-xml solution for their protocol.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 11 Mar 2000 15:37:26 -0800
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of  MIME med ia type APPLICATION/IOTP)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 01:55 PM 3/11/00 -0800, Paul Hoffman / IMC wrote:
>IOTP is a trading protocol. It involves talking about money and 
...
>To date, we have not seen anything formatted in XML that would be useful to 
>automatically hand to an XML parser.

I also am troubled by the ad-hoc-ness of the -xml suffix; but unlike Paul,
I do see a potential benefit.  First of all, is there an existence proof
of an application that does generic XML processing (whatever that means)
of an XML vocabulary it doesn't understand, the example here being IOTP?
I have some:

1. A web crawler building a full-text index
2. An XLink processor building a topological map a la Google
3. A rules-driven firewall filter deciding whether to let something
   through
4. A schema-driven datatype-checker

There's also an argument from principle.  One of the core ideas of XML is to 
move past the notion that data should be encoded in a format proprietary 
to a product or application.  The idea is that the door should always be 
left open for future processing of data in ways that are unpredictable at 
the time of creation.  The generalized -xml convention certainly is 
consistent with that spirit.

Having said that, I still have the feeling that if we do all agree that
this is a good effect to achieve, there has to be a better way than
this -xml convention.  Media types have been working well in a 2-part
structure for a long time, going to a 2-and-a-half parts smells funny.
But I haven't thought of anything better. -Tim

Date: 11 Mar 2000 22:47:23 -0000
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: reason for application/iotp-xml
Sender: [email-masked]

Dan Kohn writes:
> These subtypes need to be under
> existing top-level types in order to be dispatched correctly.

You're saying that application/iotp-xml can be dispatched correctly
while xml/iotp can't? Please explain.

---Dan

Date: Sat, 11 Mar 2000 13:55:39 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

(It's a bad sign when it takes more than 15 seconds to trim off the Cc: 
list...)

At 01:00 PM 3/11/00 -0800, [email-masked] wrote:
>>There are mechanisms in MIME to call out properties like this. Why
>>are we trying to embed this particular one in the name instead of
>>using the mechanisms that MIME provides?
>
>Because upon examination none of them seem even remotely correct for the task
>at hand. My conclusion is that if you want to do this, this is right way.

That's a big "if", particularly if you look at this application. Thank 
goodness we are finally talking about a real example of something that is 
formatted with XML, and are no longer postulating about "potential" 
applications.

IOTP is a trading protocol. It involves talking about money and 
descriptions and roles and promises. What possible value would there be to 
a recipient using a non-IOTP-aware program to have that program 
automatically hand the IOTP package to an XML parser? It's not like that 
automatic handoff will magically cause trade to happen when it wouldn't 
have before.

In the specific case of IOTP, the right thing for the receiving agent to do 
when it doesn't recognize application/iotp is to write the object out to 
disk and say "there is an object whose file name is <foo> waiting for you". 
The sender might even give a filename hint of "foo.xml". The recipient can 
then open that object up in whatever generic file opener they have.

To date, we have not seen anything formatted in XML that would be useful to 
automatically hand to an XML parser. If the parser knows about the type, it 
would have snagged it on receipt. All of these things would be just as 
useful being handed to a text viewer where the user can see "oh, this is 
XML and I have a tool that will format this nicely". (I imagine the same 
thing could be done for binary blobs to make a guess if you want to pass 
them through an ASN.1 dumper...)

I propose to leave the type application/iotp and to drop this discussion 
until there is a request for a real-world application where thre would be 
some advantage to the end user for application/foo-xml to be handed to an 
XML viewer directly instead of being written to disk.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 11 Mar 2000 22:53:49 +0100
To: [email-masked], Keith Moore <[email-masked]>
From: Harald Tveit Alvestrand <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Cc: [email-masked], Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 11:40 11.03.00 -0800, [email-masked] wrote:

>And the answer is that we need to define a rule, probably as part of the
>current proposal. It can be any of:
>
>(1) Any additional things of this sort are always added after the -xml, and
>     there's a clear ordering to them.
>
>(2) Any additional things of this sort are always added before the -xml, and
>     there's a clear ordering to them.
>
>(3) Any additional things of this sort can be added before or after the -xml,
>     but for any given type there is one and only one valid ordering.
>
>I don't much care which of these we pick. In fact we actually don't even need
>to have a rule now, but if we ever added another of these in the future 
>we'd be forced to use rule (2) at that point, since anything else would not be
>backwards compatible.

Seems to me that we could formulate this thing in the negative, rather than 
positive; forbid things that could cause confusion, rather than say that 
things should be a certain way:

"It is NOT allowed to register content-types that end in -XML when that
content-type is not parseable according to the XML standard, version
<insert appropriate number>".

This is enough to ascertain that if you hand *-XML to an XML parser, that 
parser will either grok it or be right in signalling an error, without 
saying that (for instance) application/iotp has to be application/iotp-XML, 
if the people defining it want it that way.

To allow us to postpone the choice between Ned's three rules above, we 
could outlaw anything that matches '-XML-' too, for any purpose until 
further notice.

Then we can cross the next bridge when we come to it - and hope it's 
another 10 years until we need it. (Has it really been that long? how time 
flies....)

                 Harald A

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

From: [email-masked]
Date: Sat, 11 Mar 2000 13:00:23 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: Pete Resnick <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked], Dan Kohn <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Sender: [email-masked]

> On 3/10/00 at 7:57 PM -0500, Keith Moore wrote:

> >  > Again, I'm not especially supportive of the frob as I fail to see very much
> >>  utility in it. But I also don't oppose it. I see it as "mostly harmless".
> >
> >here's the question: say someone else wants to define another frob,
> >and it's orthogonal to xml.  does a type that uses both the new
> >frob and the xml frob then become application/foo-xml-newfrob
> >or application/foo-newfrob-xml?

> Oy. The mind reels at what the MIME parsing code for this looks like.

Really. Funny, I see it as two lines of code, tops. All you have to do
is search for whatever tag you're interested in followed by a dash or
EOS. I have a route to do this sort of thing readily available. I suspect
most others do as well.

> I've really got to agree with Keith here; this is a mess and I oppose
> the direction it is taking. If XML-ishness needs to be called out as
> a property of a body part, it should be separated out as a parameter
> of some sort, or made a new field, not embedded as part of the name
> of a content-type. I know where in our code I can dispatch off of a
> parameter or a new field; that's easy. Dispatching off part of a name
> would be grotesque.

All of these approaches were explored in depth already on the XML-MIME list.
All of them have major disadvantages over the tagging scheme presently
proposed. I ended up in strong opposition to all of them, whereas I could find
no good reason to oppose this approach.

> There are mechanisms in MIME to call out properties like this. Why
> are we trying to embed this particular one in the name instead of
> using the mechanisms that MIME provides?

Because upon examination none of them seem even remotely correct for the task
at hand. My conclusion is that if you want to do this, this is right way.

				Ned

From: Dan Kohn <[email-masked]>
To: "'Pete Resnick'" <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Date: Sat, 11 Mar 2000 12:34:03 -0800
Sender: [email-masked]

I appreciate Pete's concern here, and agree that in an ideal world, this
could be handled under Content-Disposition or some new sort of
Content-Structure header.   But my (perhaps mistaken) belief is that most
dispatching tools out there work off of MIME type, and do not necessarily
have access to arbitrary Content- headers.

To take just one example of the utility of putting the information in the
content type, think of web crawlers associated with search engines.  Most
web crawlers look only for "text/*" documents for archiving.  With the
"-xml" suffix rule, all existing web crawlers can be easily modified to
search for "*/*-xml" as well, opening up to search a huge quantity of data
that would otherwise be unavailable.  (Obvious caveats apply, that if you
don't want your data searchable, use robot tags.
<http://www.fast.no/fast.php3?d=support_faqs&c=crawler&h=3>)  These crawlers
would require significant changes to parse the rest of the HTTP headers as
well, and more important, most web authors have no way of adding arbitrary
MIME headers to their sites.

The point is that "-xml" has demonstratable benefit to a significant subset
of the community, while Pete and Keith have complained about the lack of
elegance of the solution.

Ned Freed has shown that a simple rule of "-xml" comes last will allow
extensibility.  However, we haven't needed any extensibility of the last 10
years and the popularity and extensibility of XML itself will hopefully mean
that we won't need to have this debate again for a long time.

In lieu of a proposal for a more elegant solution that also provides
complete backward (and easy upward) compatibility, I think we should move
forward with Murata-san's draft.

		- dan
--
Daniel Kohn <mailto:[email-masked]>
tel:+1-425-602-6222  fax:+1-425-602-6223
http://www.dankohn.com 

-----Original Message-----
From: Pete Resnick [mailto:[email-masked]]
Sent: Saturday, 2000-03-11 12:01
To: Keith Moore
Cc: [email-masked]; Keith Moore; Dan Kohn; [email-masked];
Martin J. Duerst; MURATA Makoto; Donald E. Eastlake 3rd;
[email-masked]
Subject: Re: reason for application/iotp-xml (was RE: Registration of
MIME med ia type APPLICATION/IOTP)

On 3/10/00 at 7:57 PM -0500, Keith Moore wrote:

>  > Again, I'm not especially supportive of the frob as I fail to see very
much
>>  utility in it. But I also don't oppose it. I see it as "mostly
harmless".
>
>here's the question: say someone else wants to define another frob,
>and it's orthogonal to xml.  does a type that uses both the new
>frob and the xml frob then become application/foo-xml-newfrob
>or application/foo-newfrob-xml?

Oy. The mind reels at what the MIME parsing code for this looks like.

I've really got to agree with Keith here; this is a mess and I oppose 
the direction it is taking. If XML-ishness needs to be called out as 
a property of a body part, it should be separated out as a parameter 
of some sort, or made a new field, not embedded as part of the name 
of a content-type. I know where in our code I can dispatch off of a 
parameter or a new field; that's easy. Dispatching off part of a name 
would be grotesque.

There are mechanisms in MIME to call out properties like this. Why 
are we trying to embed this particular one in the name instead of 
using the mechanisms that MIME provides?

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Sat, 11 Mar 2000 14:01:22 -0600
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
Cc: [email-masked], Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Sender: [email-masked]

On 3/10/00 at 7:57 PM -0500, Keith Moore wrote:

>  > Again, I'm not especially supportive of the frob as I fail to see very much
>>  utility in it. But I also don't oppose it. I see it as "mostly harmless".
>
>here's the question: say someone else wants to define another frob,
>and it's orthogonal to xml.  does a type that uses both the new
>frob and the xml frob then become application/foo-xml-newfrob
>or application/foo-newfrob-xml?

Oy. The mind reels at what the MIME parsing code for this looks like.

I've really got to agree with Keith here; this is a mess and I oppose 
the direction it is taking. If XML-ishness needs to be called out as 
a property of a body part, it should be separated out as a parameter 
of some sort, or made a new field, not embedded as part of the name 
of a content-type. I know where in our code I can dispatch off of a 
parameter or a new field; that's easy. Dispatching off part of a name 
would be grotesque.

There are mechanisms in MIME to call out properties like this. Why 
are we trying to embed this particular one in the name instead of 
using the mechanisms that MIME provides?

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

From: [email-masked]
Date: Sat, 11 Mar 2000 11:40:26 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Sender: [email-masked]

> > Again, I'm not especially supportive of the frob as I fail to see very much
> > utility in it. But I also don't oppose it. I see it as "mostly harmless".

> here's the question: say someone else wants to define another frob,
> and it's orthogonal to xml.  does a type that uses both the new
> frob and the xml frob then become application/foo-xml-newfrob
> or application/foo-newfrob-xml?

And the answer is that we need to define a rule, probably as part of the
current proposal. It can be any of:

(1) Any additional things of this sort are always added after the -xml, and
    there's a clear ordering to them.

(2) Any additional things of this sort are always added before the -xml, and
    there's a clear ordering to them.

(3) Any additional things of this sort can be added before or after the -xml,
    but for any given type there is one and only one valid ordering.

I don't much care which of these we pick. In fact we actually don't even need
to have a rule now, but if we ever added another of these in the future we'd be
forced to use rule (2) at that point, since anything else would not be
backwards compatible.

> or do MIME readers have to recognize both forms?

Absolutely not. This would be a fundamental change to the namespace where names
would no longer be unique strings, and there's no need for it in any case.

> what happens when there are three frobs?

One of the rules applies.

> can they appear in any order?

No.

> if we're going to add frobs to content-types, then it seems like we
> should do this in a way that allows for extensibility.

Extensibiity can actually be deferred if we want to. See above.

				Ned

Date: Sat, 11 Mar 2000 01:34:02 -0500
From: Steve Waterbury <[email-masked]>
Organization: NASA/GSFC
To: [email-masked]
CC: [email-masked]
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia  type APPLICATION/IOTP)
Sender: [email-masked]

Keith Moore wrote:

> here's the question: say someone else wants to define another frob,
> and it's orthogonal to xml.  does a type that uses both the new
> frob and the xml frob then become application/foo-xml-newfrob
> or application/foo-newfrob-xml?
> or do MIME readers have to recognize both forms?

I vote for the latter.

> what happens when there are three frobs?
> can they appear in any order?

I think so ... the implementation would be somewhat similar to 
having a command recognize it's switches when they can occur in 
any order ... not so difficult, really.  

Cheers,
-- Steve.

                                           oo _\o
                                            \/\ \
                                              /
____________________________________________ oo _________________
"Sometimes you're the windshield; sometimes you're the bug."
- Knopfler

Stephen C. Waterbury                       Component Technologies
Code 562, NASA/GSFC                  and Radiation Effects Branch
Greenbelt, MD 20771           Engineering Web/Database Specialist
Phone/FAX: 301-286-7557/1695        
email:                              [email-masked]
WWW:          http://misspiggy.gsfc.nasa.gov/people/waterbug.html
_________________________________________________________________

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP) 
Date: Fri, 10 Mar 2000 19:57:31 -0500
Sender: [email-masked]

> Again, I'm not especially supportive of the frob as I fail to see very much
> utility in it. But I also don't oppose it. I see it as "mostly harmless".

here's the question: say someone else wants to define another frob,
and it's orthogonal to xml.  does a type that uses both the new
frob and the xml frob then become application/foo-xml-newfrob 
or application/foo-newfrob-xml?  
or do MIME readers have to recognize both forms?
what happens when there are three frobs?
can they appear in any order?

if we're going to add frobs to content-types, then it seems like we
should do this in a way that allows for extensibility.

Keith

From: [email-masked]
Date: Fri, 10 Mar 2000 16:43:38 -0800 (PST)
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Sender: [email-masked]

> Ned writes:

> > I expect to see heavy use of XML under model and image at least. I suspect
> > there will be some use even under audio, video, and message.

> > This is why I'm strongly opposed to an top-level content-type. Like it or
> > not, we chose the outermost facet of our typing space in such a way that
> > XML has mutiple overlaps. It isn't even close to the orthogonality that's
> > needed. And it is way too late to change our typing space choice.

> > This leaves us with suffixes as tne only option IMO. And while I'm not
> > enthusiastic about the suffix, I don't agree that it does the harm that
> > you seem to think it does.

> the problem with adding this frob to the content-type is that it
> (a) encourages other folks to add other frobs, and
> (b) removes the "right side of a content-type" as a place where
> anything else which is orthogonal to presentation encoding can be added.
> and thus it limits the future extensibility of the content-type scheme.

But on the other hand, I don't see much value in labelling something with a
name that has a -xml suffix when te content isn't XML. Seems more than a bit
misleading, doesn't it?

> maybe we need a frob to indicate that the content is
> gzip-compressed?

No, because that's an encoding issue. If we want gzip to be labelled we
need to do a CTE for it. This is a red herring in this context.

> surely that would be generally useful?

It isn't a content-type.

> (so you could have application/foo and application/foo-gzip)?
> maybe we need a frob to indicate that the content is (in somebody's view)
> obscene?

No, because that's othogonal to most if not all content types. It calls for
a separate field.

> how about a frob to indicate that the content is asn.1/ber?

No, because in general knowing that something is ASN.1 is pointless unless you
know the data definition. (For example, try decoding an X.400 P1 object to get
the bodypart content out without knowing ASN.1 structure. Can't be done, even
if you assume BER.)

> I don't think that -xml is the last frob that people will want to
> add to MIME typing.

Perhaps not, but its the first real one to come along in almost 10 years.
One of these every 10 years isn't a bad run rate.

> and there are other places where this frob could be added and
> do less harm.  maybe as a content-disposition parameter? e.g.

> content-disposition: attachment; filename="foo.bar";
> 	default_interpretation="application/xml"

This would work, but I see it as far more dangerous, actually. Adding
information that is very much a part of the type definition elsewhere
encourages improper content-type labelling.

Again, I'm not especially supportive of the frob as I fail to see very much
utility in it. But I also don't oppose it. I see it as "mostly harmless".

				Ned

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, "Donald E. Eastlake 3rd" <[email-masked]>, [email-masked]
Subject: Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP) 
Date: Fri, 10 Mar 2000 18:26:45 -0500
Sender: [email-masked]

[ for ietf-822 readers: there has been a request on the ietf-types list
[ to define a new content-type called application/iotp.  IOTP happens
[ to be layered on top of XML.  some XML proponents have suggested that
[ it should instead be called application/iotp-xml and that all XML-based
[ content for which default handling would be useful should be named
[ with content-types ending in -xml.    I see this as a MIME-architecture
[ issue which needs to be carefully condsidered before such a convention
[ would be adopted.  

Ned writes:
> I expect to see heavy use of XML under model and image at least. I suspect
> there will be some use even under audio, video, and message.
> 
> This is why I'm strongly opposed to an top-level content-type. Like it or
> not, we chose the outermost facet of our typing space in such a way that
> XML has mutiple overlaps. It isn't even close to the orthogonality that's
> needed. And it is way too late to change our typing space choice.
> 
> This leaves us with suffixes as tne only option IMO. And while I'm not
> enthusiastic about the suffix, I don't agree that it does the harm that
> you seem to think it does.

the problem with adding this frob to the content-type is that it 
(a) encourages other folks to add other frobs, and 
(b) removes the "right side of a content-type" as a place where
anything else which is orthogonal to presentation encoding can be added.
and thus it limits the future extensibility of the content-type scheme.

maybe we need a frob to indicate that the content is
gzip-compressed?  surely that would be generally useful?
(so you could have application/foo and application/foo-gzip)?
maybe we need a frob to indicate that the content is (in somebody's view)
obscene?  how about a frob to indicate that the content is asn.1/ber?

I don't think that -xml is the last frob that people will want to 
add to MIME typing.

and there are other places where this frob could be added and
do less harm.  maybe as a content-disposition parameter? e.g.

content-disposition: attachment; filename="foo.bar"; 
	default_interpretation="application/xml" 

Keith

From: Dan Kohn <[email-masked]>
To: "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked], "Martin J. Duerst" <[email-masked]>, MURATA Makoto <[email-masked]>, [email-masked], "Donald E. Eastlake 3rd" <[email-masked]>
Subject: RE: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP) 
Date: Fri, 10 Mar 2000 14:08:57 -0800
Sender: [email-masked]

I am cross-posting to [email-masked] because Keith correctly points out
that <http://www.normos.org/ietf/draft/draft-murata-xml-02.txt> raises
fundamental architectural questions regarding the right way to integrate XML
and MIME.  Those issues have been discussed on [email-masked] and I
believe a rough consensus was achieved, but the purpose of this thread is to
try to confirm that. 

>why?  is there really much value in a default treatment of text/* xml 
>documents as plain text?  (the default doesn't seem to work well in
>practice for text/html) or is xml really likely to be used for
>image/*, audio/*, video/*, or model/* content?

>how do you figure that?  such categorization is the primary purpose of 
>top-level types.  and while I grant that XML could be used to represent
>images, audio, or video...it does not seem well-suited as a presentation
>layer for these.

Keith, I think this may be the crux of the disagreement.  For the "-xml"
suffix to make sense, I think it must be likely that XML structure data will
show up in multiple MIME top-level types AND that that data could be
generically processed in a useful way.  Those two constraints would imply
that XML is acting fundamentally as the presentation layer in the network
stack (apologies for obligatory OSI network stack reference), and that that
presentation information should be available to dispatchers that can make
use if it.

The fact that almost all subtypes based on XML can be generically processed
is addressed in the I-D and excerpted in my message, which I attach below.

As to whether subtypes based on XML belong in different top-level type, I
believe the following examples demonstrate that XML-based data types will
most likely be registered in ALL top-level categories:

Application/*:
IOTP
<http://www.normos.org/ietf/draft/draft-ietf-trade-iotp-v1.0-protocol-07.txt
>
RDF <http://www.w3.org/RDF/>
MathML <http://www.w3.org/Math/>

Audio/*:
Nothing yet, but don't rule out VXML <http://www.vxml.org/> or a derivative
SMIL is also a possibility <http://www.w3.org/AudioVideo/>.  Also, note that
XML modularization <http://www.w3.org/TR/xhtml-modularization/> makes it
quite likely that new XML subtypes will be created that serve specific
needs, and encoding binary audio information is completely feasible.

Video/*:
SMIL and/or a derivative could be registered here or in Application/*
<http://www.w3.org/AudioVideo>

Model/*:
UML <http://www.omg.org/uml/> (may be under Application/*)
If VRML were being started from scratch today it would likely be built in
XML.  See <http://www.vrml.org/WorkingGroups/dbwork/vrmlxml.html> for some
integration discussion.

Image/*:
SVG <http://www.w3.org/Graphics/SVG/>

Text/*:
XHTML <http://www.w3.org/TR/xhtml1/>, though this is better under
Application/*

		- dan
--
Daniel Kohn <mailto:[email-masked]>
tel:+1-425-602-6222  fax:+1-425-602-6223
http://www.dankohn.com 

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Friday, 2000-03-10 11:38
To: Dan Kohn
Cc: Keith Moore; [email-masked]; Martin J. Duerst; MURATA Makoto;
[email-masked]; Donald E. Eastlake 3rd
Subject: Re: reason for application/iotp-xml (was RE: Registration of
MIME med ia type APPLICATION/IOTP) 

> >okay - more generally, I don't think we should make a special case in 
> >the MIME content-type syntax (not even using an ad hoc mechanism)
> >for content-types that happen to be based on XML.  MIME already has
> >a mechanism to define default handling of certain classes of objects,
> >in the top-level content-type.  If there's really enough utility in
> >doing this for XML, we should create an xml/ top-level type.
> >We shouldn't create another separate syntactical convention to do this.
> 
> Keith, take two potential types, image/svg-xml and application/mathml-xml.
> In both cases, for dispatchers that don't understand or care about XML,
the
> "-xml" suffix is completely opaque.  

it may be opaque, but it still does harm if it constrains evolution of
the MIME content-type space.

> These subtypes need to be under
> existing top-level types in order to be dispatched correctly.  

why?  is there really much value in a default treatment of text/* xml 
documents as plain text?  (the default doesn't seem to work well in
practice for text/html) or is xml really likely to be used for
image/*, audio/*, video/*, or model/* content?

> A new XML
> top-level type doesn't provide any information of categorization, because
> XML-based MIME types can fall in any of the top level categories.

how do you figure that?  such categorication is the primary purpose of 
top-level types.  and while I grant that XML could be used to represent
images, audio, or video...it does not seem well-suited as a presentation
layer for these.

but this again begs the question about how much encoding information 
you want to make explicit in the content-type name.  and my main point
is that the answer is not obvious - embedding -xml in the name comes
at a cost.  we need to think carefully before either (a) establishing
yet another syntactic convention for content-type names, or (b) 
making XML explicit in a content-type name.  and this is is a MIME
architectural issue - it isn't something that should be done just because
XML proponents think it is a good idea.

if there is going to be such a convention, it needs to be carefully
considered both for its impact on the MIME architecture and whether
it's actually desirable to do this for XML.  (the latter is easier to
justify than the former)

> In summary, there is no downside to using the "-xml" suffix

disagree. see above.

Keith

-----Original Message-----
From: Dan Kohn 
Sent: Friday, 2000-03-10 11:19
To: Keith Moore
Cc: [email-masked]; Martin J. Duerst; MURATA Makoto;
[email-masked]; Donald E. Eastlake 3rd
Subject: reason for application/iotp-xml (was RE: Registration of MIME
media type APPLICATION/IOTP)

Keith Moore said:

>okay - more generally, I don't think we should make a special case in 
>the MIME content-type syntax (not even using an ad hoc mechanism)
>for content-types that happen to be based on XML.  MIME already has
>a mechanism to define default handling of certain classes of objects,
>in the top-level content-type.  If there's really enough utility in
>doing this for XML, we should create an xml/ top-level type.
>We shouldn't create another separate syntactical convention to do this.

Keith, take two potential types, image/svg-xml and application/mathml-xml.
In both cases, for dispatchers that don't understand or care about XML, the
"-xml" suffix is completely opaque.  These subtypes need to be under
existing top-level types in order to be dispatched correctly.  A new XML
top-level type doesn't provide any information of categorization, because
XML-based MIME types can fall in any of the top level categories.

However, for dispatchers that do understand XML, and especially for those
that haven't seen a specific type before (such as application/iotp-xml), the
"-xml" suffix provides additional information that the content could instead
be dispatched to an XML browser or processed generically in various ways.
In the IOTP example, this could be very useful in allowing someone not
configured to deal with the subtype to at least have the information
displayed in an accessible way.  Of course, if the dispatcher is configured
to deal with IOTP, then the "-xml" remains opaque.

In summary, there is no downside to using the "-xml" suffix, but significant
potential functionality can be gained.

To quote <http://www.normos.org/ietf/draft/draft-murata-xml-02.txt>:

   While the benefits of specific MIME types for particular types of
   XML documents are significant, all XML documents share common
   structures and syntax that make possible common processing.

   Some areas where 'generic' processing is useful include:

   o  Browsing - An XML browser can display any XML document with a
      provided CSS[12] or XSLT[19] style sheet, whatever the vocabulary
      of that document.

   o  Editing - Any XML editor can read, modify, and save any XML
      document.

   o  Fragment identification - XPointers[16] can work with any XML
      document, whatever vocabulary it uses and whether or not it uses
      XPointer for its own fragment identification. [Editor's note: the
      use of non-XPointer fragment identifiers by XML vocabularies like
      SVG and SMIL requires further discussion.]

   o  Hypertext Linking - XLink[17] hypertext linking is designed to
      connect any XML documents, regardless of vocabulary.

   o  Searching - Search engines, agents, and XML-oriented query tools
      should be able to read XML documents and extract the content and
      names of elements and attributes even if they are ignorant of the
      particular vocabulary used for elements and attributes.

   o  Storage - XML-oriented storage systems, which keep XML documents
      internally in a parsed form, should similarly be able to process,
      store, and recreate any XML document.

Also, note that Murata-san's draft has specific "opt-out" language if your
XML-based MIME type is not suitable for generic processing:

   XML-generic processing is not always appropriate for XML-based media
   types.  For example, some such media types may require fragment
   identifiers different from XPointer.  By *not* following the naming
   convention */*-xml, such media types can avoid XML-generic
   processing.

However, I would suggest that application/iotp-xml is a perfect illustration
of the utility of suffix-based naming.

		- dan

P.S.  Please use [email-masked], which is the permanent address for
this list, rather than [email-masked].

--
Daniel Kohn <mailto:[email-masked]>
tel:+1-425-602-6222  fax:+1-425-602-6223
http://www.dankohn.com