Subject: Re: Media types, fragment identifiers, and XPointer
From: MURATA Makoto <[email-masked]>
To: <[email-masked]>
Date: Tue, 01 Jun 1999 15:52:29 +0900

I was expecting more response, but only Larry responded ;-)
#Thanks.  > Larry

Larry Masinter wrote:
> 
> It would be good if we could extend the MIME registry of media
> types to include, where possibly, a description of how
> "fragment identifiers" apply to that media type.
> 
> Currently this information is not in the media type registry,
> and fragment identifiers are, in practice, only used for HTML.

RFC2396 ("Uniform Resource Identifiers (URI): Generic Syntax"), which 
you co-authored, says:

   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.  Therefore, the format and interpretation of
   fragment identifiers is dependent on the media type [RFC2046] of the
   retrieval result.  The character restrictions described in Section 2
   for URI also apply to the fragment in a URI-reference.  Individual
   media types may define additional restrictions or structure within
   the fragment for specifying different types of "partial views" that
   can be identified within that media type.

   A fragment identifier is only meaningful when a URI reference is
   intended for retrieval and the result of that retrieval is a document
   for which the identified fragment is consistently defined.

text/html is defined by RFC1866 (HTML 2.0).  HTML 2.0 and its subsequent 
versions define the interpretation of fragment identifiers.  

There appear to be no information in the media type registry, which is:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/

> To make this useful might mean some extensions to current
> platform definitions of MIME dispatch (to pass along the
> fragment identifier to the media type rendering agent), but

RFC 2045 says:

   The purpose of the Content-Type field is to describe the data
   contained in the body fully enough that the receiving user agent can
   pick an appropriate agent or mechanism to present the data to the
   user, or otherwise deal with the data in an appropriate manner. The
   value in this field is called a media type.

Fragment identifiers are not mentioned by RFC 2045 or RFC 2046.

Are there any documents about generalization of fragment identifiers?  
I suppose that there is no such.

> it was desirable to have named or identified components for
> other types. If there's a general definition of how this
> works for XML types that aren't otherwise specified, that's
> great, too. 

Here are some questions about requirements.

Q1.  Do we need XPointers for every XML instance?  

I personally think that this is too much.  For example, I do not think we have 
use XPointers for RDF, which is in the XML syntax.

Q2.  Do we need XPointers only for human-readable documents that are rendered 
     by some browsers?

I am not sure if the answer is Yes.  How do XLL experts in this ML feel?

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: "Larry Masinter" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: RE: Media types, fragment identifiers, and XPointer
Date: Fri, 28 May 1999 15:08:47 PDT
Importance: Normal
Sender: [email-masked]

It would be good if we could extend the MIME registry of media
types to include, where possibly, a description of how
"fragment identifiers" apply to that media type.

Currently this information is not in the media type registry,
and fragment identifiers are, in practice, only used for HTML.

To make this useful might mean some extensions to current
platform definitions of MIME dispatch (to pass along the
fragment identifier to the media type rendering agent), but
it was desirable to have named or identified components for
other types. If there's a general definition of how this
works for XML types that aren't otherwise specified, that's
great, too. 

Larry
-- 
http://www.parc.xerox.com/masinter

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of MURATA Makoto
> Sent: Thursday, May 27, 1999 6:57 PM
> To: [email-masked]
> Subject: Media types, fragment identifiers, and XPointer
> 
> 
> It appears that media types, fragment identifiers, and XPointer are 
> actually related.
> 
> In my understanding, URIs can have fragment identifiers such as "#foo".  
> How to interpret fragment identifiers depends on the media type.   (Could 
> somebody provide pointers to relevant RFCs?)
> 
> On the other hand, the XML community is developing a mechanism called 
> XPointer. 
> (http://www.w3.org/TR/WD-xptr)
> 
> 	"XPointers operate on the tree defined by the elements and other 
> 	markup constructs of an XML document.
> 
> 	An XPointer consists of a series of location terms, each of which 
> 	specifies a location, usually relative to the location specified by 
> 	the prior location term. Each location term has a keyword (such as id, 
> 	child, ancestor, and so on) and can have arguments such as an instance 
> 	number, element type, or attribute. For example, the location term 
> 	child(2,CHAP) refers to the second child element whose type is CHAP."
> 
> XPointer is intended to be used as a fragment identifier.
> 
> 	"The locator for a resource is typically provided by means of a 
> 	Uniform Resource Identifier, or URI. XPointers can be used as fragment 
> 	identifiers in conjunction with the URI structure to specify a 
> more precise 
> 	sub-resource."
> 
> I personally have expected that XPointer is usable for every XML document 
> no matter what the media type is.  But I am apparently wrong.  Do we need 
> a top-level media type "xml" or some convention such as "image/xml.vml" 
> so that XPointer can be used for any XML document?  Or, are "text/xml" and 
> "application/xml" enough?
> 
> Cheers,
> 
> Makoto
>  
> Fuji Xerox Information Systems
>  
> Tel: +81-44-812-7230   Fax: +81-44-812-7231
> E-mail: [email-masked]
> 

From: MURATA Makoto <[email-masked]>
Date: Fri, 28 May 1999 10:57:04 +0900
To: [email-masked]
Subject: Media types, fragment identifiers, and XPointer
Sender: [email-masked]

It appears that media types, fragment identifiers, and XPointer are 
actually related.

In my understanding, URIs can have fragment identifiers such as "#foo".  
How to interpret fragment identifiers depends on the media type.   (Could 
somebody provide pointers to relevant RFCs?)

On the other hand, the XML community is developing a mechanism called XPointer. 
(http://www.w3.org/TR/WD-xptr)

	"XPointers operate on the tree defined by the elements and other 
	markup constructs of an XML document.

	An XPointer consists of a series of location terms, each of which 
	specifies a location, usually relative to the location specified by 
	the prior location term. Each location term has a keyword (such as id, 
	child, ancestor, and so on) and can have arguments such as an instance 
	number, element type, or attribute. For example, the location term 
	child(2,CHAP) refers to the second child element whose type is CHAP."

XPointer is intended to be used as a fragment identifier.

	"The locator for a resource is typically provided by means of a 
	Uniform Resource Identifier, or URI. XPointers can be used as fragment 
	identifiers in conjunction with the URI structure to specify a more precise 
	sub-resource."

I personally have expected that XPointer is usable for every XML document 
no matter what the media type is.  But I am apparently wrong.  Do we need 
a top-level media type "xml" or some convention such as "image/xml.vml" 
so that XPointer can be used for any XML document?  Or, are "text/xml" and 
"application/xml" enough?

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Tue, 18 May 1999 22:36:23 +0200
From: Chris Lilley <[email-masked]>
To: Murray Altheim <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Using CONNEG instead of MIME types for compound types & references
Sender: [email-masked]

Murray Altheim wrote:

> > The second problem is as Larry points out is the file with
> > embedded xml from different namespaces. [...]
> > It would be nice from the browsers
> > point of view if it had prior knowledge of the namespaces before
> > downloading the document, because then it could either
> 
> This is one of the (pardon my French) stupidities of embedding what
> is essentially prolog information deep within an instance. 

I believe that the intention was to allow scoping.

> In
> traditional SGML systems the benefit of having a prolog is that the
> engine can learn all about the document instance *before* it begins
> processing. This is simply poor design on the part of XML Namespaces,

No, because the WG originally came up with an unscoped design with
everything in a prolog; but feedback was that this design was
insufficient.

> probably brought about by design constrains or 'market pressure'.

It was indeed brought about by design constraints; specifically, the
need to be useful. You might not like the specific choices that were
made, but it is misrepresentation to call it "stupid" and "poor design". 

> > Others such as Murray (I hope I am not mis-interpreting him!)
> > have pointed out that they would like a more general solution,
> > because they feel that an XHTML mime type will keep XHTML off
> > in it's own landscape and not encourage it to join the more
> > general XML solution.
> 
> Well, yes. And since there is a strong requirement that a solution be
> found for XML, if a stop-gap solution is arrived at for XHTML it will
> probably be *different* than XML, which would further push XHTML off
> into its own unique landscape. I doubt vendors would want to do both.

Actually, if the choices are to label it as text/html or text/xml, the
worry is that text/html will be chosen which, indeed, keeps HTML of in
its own landscape; it means that processors have no way to distinguish
between well-formed xml in the xhtml namespace, and  totally unspecified
"real world"html with all its myriad undocumented parsing tricks for
alleged backwards compatibility.

So, being able to say "this uses HTML semantics, but is well formed xml"
is very valuable. A specific MIME type is the obvious way to achieve
that.

> As Rick has pointed out, XHTML is 'application-specific', but no
> more so than MathML or any other XML application that requires
> specialized processing not provided in a stylesheet. It also happens
> to be potentially the most widely used XML markup language, and a
> framework for creation of many others. So we all need to work together
> to create a solution that works for both XHTML and XML in general.

If an instance is well formed xml, and uses just the xhtml namespace,
and thus can be validated, label it as text/xhtml.

If an instance is well formed xml, and uses multiple namespaces (and
thus, until schemas arive, cannot be validated) call it text/xml if you
don't have a better and more precise name.

If an instance is, well, stuff (not well formed, could be anything, like
real-world html) then call it text/html. The battle to have text/html
bear any resemblance to its defining spec was lost long ago. Processors
that accept text/html have to be prepared to process just about
anything; if it happens to be well formed xml, well, such processors

a) will not even notice
b) will not parse it according to the xml spec in any case

As a result, anything labelled as text/html is a dead loss in terms of
consistent parse trees between implementations; with expected results on
CSS, XSL, the DOM, and anything else that depends on a clean parse tree.

--
Chris

--
Chris

Date: Thu, 13 May 1999 14:27:41 -0400
From: John Cowan <[email-masked]>
Organization: Lojban Peripheral
To: [email-masked], [email-masked]
Subject: Re: Modest Proposal
Sender: [email-masked]

Tim Bray wrote:
 
> But that syntax is rather ugly.  Since I'm not an expert in this
> field, a question for those who are: is there a precedent for this
> kind of syntax design?  I.e. loading extra values into the 2nd
> half of the media type and introducing the '-' separator to do so?

The media subtype already has:

	the "x-" prefix for experimental/private subtypes
	the prefixes "vnd." and "prs." for vendor-defined and
		personally-defined-but-publicly-usable subtypes

So adding "-xml" to the end is not really a big deal: "-" is already
legal in the syntax.

> Because if there is not, I would have to suggest that there must be
> a better way, e.g. a syntax="xml" parameter or some such?  -Tim

The trouble is that media-type parameters are meant to be for things
that vary, like charset.  There is no equivalent of #FIXED parameters
in media types.

-- 
John Cowan	http://www.ccil.org/~cowan		[email-masked]
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

Date: Wed, 12 May 1999 22:40:35 -0400
To: Tim Bray <[email-masked]>, [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Modest Proposal
Sender: [email-masked]

At 06:04 PM 5/12/99 -0700, Tim Bray wrote:
>At 04:32 PM 5/11/99 -0400, Simon St.Laurent wrote:
>>This provides for things like:
>>graphics/svg-xml
>>application/xpdl-xml
>>application/ice-xml
>>model/x3d-xml
>[...good news...]
>But that syntax is rather ugly.  Since I'm not an expert in this
>field, a question for those who are: is there a precedent for this
>kind of syntax design?  I.e. loading extra values into the 2nd
>half of the media type and introducing the '-' separator to do so?

I'd be interested.  I can't say I've seen it.  I suggested a suffix to
avoid the "who's the registrar of this here tree" issues.

>Because if there is not, I would have to suggest that there must be
>a better way, e.g. a syntax="xml" parameter or some such?  -Tim

I'm concerned that while this is prettier, it's something that application
developers and users wouldn't see and wouldn't use.  I'm not sure all ASP
and servlet developers are going to consistently set extra pieces in the
content-type header, unless they have to deal with parameters anyway, for
things like character set.  Is current software (Apache, for instance) set
up to support parameters in MIME types for static files, or is it going to
take a rewrite?  Have to admit, I haven't tried it, but I'll look in the
morning when I'm awake again.

Basically, can we make certain people actually use parameters?  Otherwise,
making this work reliably seems to require XML someplace in the name.  I'll
take reliability over aesthetics any day.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Wed, 12 May 1999 18:04:00 -0700
To: "Simon St.Laurent" <[email-masked]>, [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: Modest Proposal
Sender: [email-masked]

At 04:32 PM 5/11/99 -0400, Simon St.Laurent wrote:
>This provides for things like:
>graphics/svg-xml
>application/xpdl-xml
>application/ice-xml
>model/x3d-xml

I'm starting to buy into the concept that in the general case it's useful
to know when something's using XML syntax, no matter what its "essential"
type, such as SVG or X3D or whatever.  The examples that sway me are the
existence proof of IE5, Simon's point about doing full-text indexing.

But that syntax is rather ugly.  Since I'm not an expert in this
field, a question for those who are: is there a precedent for this
kind of syntax design?  I.e. loading extra values into the 2nd
half of the media type and introducing the '-' separator to do so?

Because if there is not, I would have to suggest that there must be
a better way, e.g. a syntax="xml" parameter or some such?  -Tim

Date: Wed, 12 May 1999 17:14:29 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Modest Proposal
To: "Simon St.Laurent" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Rather than continuing to kick landmines, however much I may dislike their
> presence, I'm putting forward something that may settle the political
> waters while still providing as much information as seems practical within
> the scope of a MIME type.

> All XML documents can continue to use application/xml if their designers
> choose.  Software will be expected to figure out what exactly is contained
> in that XML on its own.  (I'll leave the fate of text/xml to the rest of you.)

> If the developers of a particular XML document type want to register a
> specific MIME type for it, they go through the normal IETF registration
> process using the top-level headers that already exist.  The only
> difference is that all document types that use XML as their base format
> will be suffixed '-xml'.

> This provides for things like:
> graphics/svg-xml
> application/xpdl-xml
> application/ice-xml
> model/x3d-xml

> This way, applications can know which overall category the information
> belongs to (graphics and model are, of course, more meaningful than
> application, but that's the breaks), tools like editors, browsers, agents,
> and search engines don't have to suffer too mightily guessing which content
> they can open and which should be left alone, and we can assign meaningful
> (well, sort of) names to XML formats, identifying them more precisely than
> plain old vanilla XML.

> In cases where content negotiation is required, other protocols can provide
> that support.  Applications can at least get a broad feeling for the type
> of information being transferred from the MIME type, avoiding unnecessary
> negotiations for 'simple' cases.

> Does this seem possible?  Or does it still raise flags?

It seems fine to me -- I would certainly have no problem enforcing it as
reviewer.

				Ned

Date: Wed, 12 May 1999 20:13:27 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Modest Proposal
Sender: [email-masked]

At 04:42 PM 5/12/99 -0500, Shane P. McCarron wrote:
>[Tim Bray]
>> > I'm dubious about the modest proposal, but both image/svg or
image/svg-xml
>> > seem much more useful than image/xml.  -Tim
>
>[Chris Lilley] 
>> Yes, I agree. And I don't see the value of image/svg-xml, since there is
>> not likely to be a different, non-xml, svg.
>
>I think that the benefit is to user agents that don't already know what
>SVG is.  When presented with a resource of type image/svg they need to
>punt.  If the resource was image/svg-xml it would be clear at least that
>it could be parsed as XML, even if rendition would be somewhat useless.
>
>I don't think this is useful, but I think that was the intent of the
>original proposal.

Well, actually, since SVG has text elements[1], there's plenty of
potentially useful information in those that an XML-aware search engine
could use to identify the file as relevant to a particular topic.
image/svg-xml would have the benefit of making it obvious to such programs
that there is some chance that they can read and meaningfully process that
information.  It would also make it clear that the information in an SVG
file could be edited in a generic XML editor.  If you don't have a
custom-to-SVG editor around, that capability could be important.

I'd call it very useful.  Talk about a revolution!  Graphics with text you
can reliably index, and using generic tools at that!

[1] - http://www.w3.org/TR/1999/WD-SVG-19990412/text.html

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Wed, 12 May 1999 16:51:59 -0500
From: Chris Lilley <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Rick Jelliffe <[email-masked]>, [email-masked]
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
Sender: [email-masked]

Ned Freed wrote:

> And insofar as the W3C is concerned, my understanding is that they don't
> want to act as a registration authority for XML types. 

This is correct.

> I haven't heard any
> other organizations suggested that would be appropriate for this job.

Oasis has been suggested.

> 
> And if you assume that the W3C wanted its own tree where its own rules
> would apply, it would be silly to restrict it to XML. As such, you'd likely
> end up with a "w3c." facet.

Yes. That might make sense; for example, where the defining document was
a W3C Recommendation rather than an IETF RFC.

--
Chris

Date: Wed, 12 May 1999 16:42:34 -0500
From: "Shane P. McCarron" <[email-masked]>
Reply-To: [email-masked]
Organization: MACS, Inc.
To: Chris Lilley <[email-masked]>
CC: Tim Bray <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked]
Subject: Re: Modest Proposal
Sender: [email-masked]

> > I'm dubious about the modest proposal, but both image/svg or image/svg-xml
> > seem much more useful than image/xml.  -Tim
> 
> Yes, I agree. And I don't see the value of image/svg-xml, since there is
> not likely to be a different, non-xml, svg.

I think that the benefit is to user agents that don't already know what
SVG is.  When presented with a resource of type image/svg they need to
punt.  If the resource was image/svg-xml it would be clear at least that
it could be parsed as XML, even if rendition would be somewhat useless.

I don't think this is useful, but I think that was the intent of the
original proposal.

--
Shane P. McCarron                              phone: +1 612 434-4431
Testing Research Manager                         fax: +1 612 434-4318
                                              mobile: +1 612 799-6942
                                              e-mail: [email-masked]

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.

Date: Wed, 12 May 1999 16:14:11 -0500
From: Chris Lilley <[email-masked]>
To: [email-masked]
CC: "'Tim Bray'" <[email-masked]>, "'Simon St.Laurent'" <[email-masked]>, [email-masked]
Subject: Re: Modest Proposal
Sender: [email-masked]

Gavin Thomas Nicol wrote:
> 
> > I'm dubious about the modest proposal, but both image/svg or
> > image/svg-xml seem much more useful than image/xml.
> 
> Chris almost surely meant image/svg...

Yes, I did. 

--
Chris

Date: Wed, 12 May 1999 16:13:14 -0500
From: Chris Lilley <[email-masked]>
To: Tim Bray <[email-masked]>
CC: "Simon St.Laurent" <[email-masked]>, [email-masked]
Subject: Re: Modest Proposal
Sender: [email-masked]

Tim Bray wrote:
> 
> At 11:04 AM 5/12/99 -0500, Chris Lilley wrote:
> 
> >We expect the MIME type for the SVG image format (which is, indeed,
> >written in xml) to be image/xml.

Duh. Sorry to everyone for being confusing.

I meant to type "image/svg" but obviously was thinking of too many
things at once.

> >This is because it is an image format, and we need to do content
> >negotiation. For stand-alone files, the fact that it happens to be
> >written in xml is less important than the fact that it is an image.
> 
> I would have thought that the fact that it's in SVG is also more
> important for dispatching purposes than the fact that SVG happens
> to use XML syntax. 

;-) yes.

> I'm dubious about the modest proposal, but both image/svg or image/svg-xml
> seem much more useful than image/xml.  -Tim

Yes, I agree. And I don't see the value of image/svg-xml, since there is
not likely to be a different, non-xml, svg.

--
Chris

Date: Wed, 12 May 1999 15:18:00 -0500
From: "Shane P. McCarron" <[email-masked]>
Reply-To: [email-masked]
Organization: MACS, Inc.
To: Rick Jelliffe <[email-masked]>
CC: [email-masked]
Subject: Re: XHTML notation structures
Sender: [email-masked]

Rick Jelliffe wrote:
> 
> Thinking about what people are saying about XHTML, and, recasting it in
> XML/SGML terminology, it sounds like people want to be able to list the
> the notations used in a document, and to have this information available
> somewhere in the MIME header to figure out whether a document is
> acceptable. (I.e. after content negotiation)

Ummm... There might be some people that want to do that.  That's not our
current strategy. Our current strategy is to declare a "profile" somehow
(e.g. in an attribute on the root element, as a parameter to a media
type, a header in an HTTP GET request from a client, ...)  We expect
that documents will want to announce their requirements as you have
described, and also that clients will be required to announce their
capabilities. The purpose of this is to enable smarter servers/proxy
servers, content translation and transcoding, etc.  

The profile name, likely a URI, can be viewed opaquely or retrieved and
examined. Well known profiles will most likely be viewed opaquely, and
less well known profiles will need to be (automatically and
mechanically) examined to help ascertain the capabilities of the client
or the requirements of a resource.

> If it weren't for XHTML, I think this kind of thing would be better kept
> out of MIME and made part of the W3C fragments or packaging work.

Well, I cannot speak for the XHTML working group, but I also think this
level of detail should be kept out of the media type. We just want to
present this information in an ancillary way so that
clients/servers/proxies that are instrumented to take advantage of it
can do so.

--
Shane P. McCarron                              phone: +1 612 434-4431
Testing Research Manager                         fax: +1 612 434-4318
                                              mobile: +1 612 799-6942
                                              e-mail: [email-masked]

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.

Reply-To: <[email-masked]>
From: "Gavin Thomas Nicol" <[email-masked]>
To: "'Tim Bray'" <[email-masked]>, "'Chris Lilley'" <[email-masked]>, "'Simon St.Laurent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Modest Proposal
Date: Wed, 12 May 1999 13:44:22 -0400
Importance: Normal
Sender: [email-masked]

> I'm dubious about the modest proposal, but both image/svg or 
> image/svg-xml seem much more useful than image/xml. 

Chris almost surely meant image/svg... 

Date: Wed, 12 May 1999 13:14:19 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Modest Proposal
Sender: [email-masked]

At 09:20 AM 5/12/99 -0700, Tim Bray wrote:
>At 11:04 AM 5/12/99 -0500, Chris Lilley wrote:
>
>>We expect the MIME type for the SVG image format (which is, indeed,
>>written in xml) to be image/xml.
>>
>>This is because it is an image format, and we need to do content
>>negotiation. For stand-alone files, the fact that it happens to be
>>written in xml is less important than the fact that it is an image.
>
>I would have thought that the fact that it's in SVG is also more
>important for dispatching purposes than the fact that SVG happens
>to use XML syntax.  Also... is this going to be the only xml-encoded
>image format anyone ever creates?

I definitely have to agree here.  I'll be very surprised if svg is the only
image format ever created with XML.  

(And yes, it's image, not graphics.  Never try to give up coffee.  You get
headaches and end up stupid. I'm brewing some now in what's probably a vain
attempt to get my head working again.)

>I'm dubious about the modest proposal, but both image/svg or image/svg-xml 
>seem much more useful than image/xml.  

At least it's a response, dubious or not. What would you (or anyone) like
to change?

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Wed, 12 May 1999 09:20:06 -0700
To: Chris Lilley <[email-masked]>, "Simon St.Laurent" <[email-masked]>
From: Tim Bray <[email-masked]>
Subject: Re: Modest Proposal
Cc: [email-masked]
Sender: [email-masked]

At 11:04 AM 5/12/99 -0500, Chris Lilley wrote:

>We expect the MIME type for the SVG image format (which is, indeed,
>written in xml) to be image/xml.
>
>This is because it is an image format, and we need to do content
>negotiation. For stand-alone files, the fact that it happens to be
>written in xml is less important than the fact that it is an image.

I would have thought that the fact that it's in SVG is also more
important for dispatching purposes than the fact that SVG happens
to use XML syntax.  Also... is this going to be the only xml-encoded
image format anyone ever creates?

I'm dubious about the modest proposal, but both image/svg or image/svg-xml 
seem much more useful than image/xml.  -Tim

Date: Wed, 12 May 1999 11:04:00 -0500
From: Chris Lilley <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
CC: [email-masked]
Subject: Re: Modest Proposal
Sender: [email-masked]

"Simon St.Laurent" wrote:

> If the developers of a particular XML document type want to register a
> specific MIME type for it, they go through the normal IETF registration
> process using the top-level headers that already exist.  The only
> difference is that all document types that use XML as their base format
> will be suffixed '-xml'.
> 
> This provides for things like:
> graphics/svg-xml

There isn't a "graphics" top-level type.

We expect the MIME type for the SVG image format (which is, indeed,
written in xml) to be image/xml.

This is because it is an image format, and we need to do content
negotiation. For stand-alone files, the fact that it happens to be
written in xml is less important than the fact that it is an image.

--
Chris

From: "Rick Jelliffe" <[email-masked]>
To: <[email-masked]>
Subject: FYI: XML Notation Schemas
Date: Wed, 12 May 1999 18:29:50 +0800
Sender: [email-masked]

For anyone interested, the discussion yesterday on XHTML prompted me to
finish a counter-proposal to the XML Schema draft.

My proposal "XML Notation Schemas" is at
http://www.ascc.net/~ricko/notation.htm

The relevance of the proposal to this group is that, by concentrating on
notations and not on content models or namespace names, a MIME media-type
signature like the one I gave yesterday could be automatcally extracted from
the schema.

This might help some of the XHTML issues.

Rick Jelliffe
Computing Centre
Academia Sinica
Taipei, Taiwan

Date: Tue, 11 May 1999 16:32:14 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Modest Proposal
Sender: [email-masked]

Rather than continuing to kick landmines, however much I may dislike their
presence, I'm putting forward something that may settle the political
waters while still providing as much information as seems practical within
the scope of a MIME type.

All XML documents can continue to use application/xml if their designers
choose.  Software will be expected to figure out what exactly is contained
in that XML on its own.  (I'll leave the fate of text/xml to the rest of you.)

If the developers of a particular XML document type want to register a
specific MIME type for it, they go through the normal IETF registration
process using the top-level headers that already exist.  The only
difference is that all document types that use XML as their base format
will be suffixed '-xml'.

This provides for things like:
graphics/svg-xml
application/xpdl-xml
application/ice-xml
model/x3d-xml

This way, applications can know which overall category the information
belongs to (graphics and model are, of course, more meaningful than
application, but that's the breaks), tools like editors, browsers, agents,
and search engines don't have to suffer too mightily guessing which content
they can open and which should be left alone, and we can assign meaningful
(well, sort of) names to XML formats, identifying them more precisely than
plain old vanilla XML.

In cases where content negotiation is required, other protocols can provide
that support.  Applications can at least get a broad feeling for the type
of information being transferred from the MIME type, avoiding unnecessary
negotiations for 'simple' cases.

Does this seem possible?  Or does it still raise flags?

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Wed, 12 May 1999 04:18:16 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: [email-masked]
Subject: XHTML notation structures
Sender: [email-masked]

Thinking about what people are saying about XHTML, and, recasting it in 
XML/SGML terminology, it sounds like people want to be able to list the 
the notations used in a document, and to have this information available 
somewhere in the MIME header to figure out whether a document is 
acceptable. (I.e. after content negotiation)

Lets invent a language for representing notation dependencies: 

	() to group alternatives or derived type
	| for alternatives versions of the same resource, 
		where the LHS is preferred 
		and more specific to the RHS
        , for alternative notations useable for the same resource, 
		where LHS is preferred to 
		and a subclass of the RHS
	+ for additional types, 
		where the first one is the framework
		notation (e.g., text/xhtml or application/rdf )
        -> for additional types, pointed to from the document, 
		which may be overriden by content negotiation

Using this, the notation structure for an XHTML document with lots 
of things embedded might be:

	(text/xhtml , text/html , text/xml , text/plain )
	+ ( application/mathml , text/xml )
        + ( application/ms.vml , text/xml )
        + ( application/x-dublincore , application/rdf , text/xml )
     	-> ( text/xhtml )
	-> ( image/gif )
	-> ( image/jpg | image/gif )
	-> ( application/pdf | text/xhtml )

(Note that I do not repeat the "," alternatives)

So then the issue becomes, can we derive a useful signature from these, 
to be used in a media type name? 

If not, then is some language like this appropriate, presumably to be 
used as a parameter?

If it weren't for XHTML, I think this kind of thing would be better kept 
out of MIME and made part of the W3C fragments or packaging work.  

Rick Jelliffe

Date: Tue, 11 May 1999 09:26:03 -0700 (PDT)
From: Murray Altheim <[email-masked]>
Reply-To: Murray Altheim <[email-masked]>
Subject: Re: Using CONNEG instead of MIME types for compound types & references
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Content-MD5: HW/D6dPqAJNdG+BqIClAUw==
Sender: [email-masked]

Frank Boumphrey <[email-masked]> writes:
[...] 
> Basically if I send an XHTML file as text/html, then a browser
> will send that file off to its HTML engine, and parse it as an HTML file.
> 
> If I send the file as text/xml, then the browser will send it
> of to its XML parser, and just create a parse tree.

It seems to me a mistaken assumption that as the XML processor begins
to parse the incoming file that it couldn't *actually read* what is
happening and act accordingly. If the processor is aware of XHTML's
numerous 'cookies', it could process the file correctly. There is no
enforced 'XML blindness' operating here. 

[...]
> The second problem is as Larry points out is the file with
> embedded xml from different namespaces. A browser may be quite
> happy to accept an XHTML file and will 'know' how to display basic
> XHTML1.0, but will not know how to display mathXML or MusicXML.
> Because the Namespaces can be scoped in the document, and don't
> have to be in the head of the document, the browser may be well
> into rendering the document before it realises that it can't
> display the relevant code. It would be nice from the browsers
> point of view if it had prior knowledge of the namespaces before
> downloading the document, because then it could either

This is one of the (pardon my French) stupidities of embedding what
is essentially prolog information deep within an instance. In 
traditional SGML systems the benefit of having a prolog is that the
engine can learn all about the document instance *before* it begins 
processing. This is simply poor design on the part of XML Namespaces,
probably brought about by design constrains or 'market pressure'. 

I maintain that this is something that should be fixed in the 
Namespace spec, not hacked in XML. But of course that would be 
asking for the moon, since that spec has somehow become a 
Recommendation, inviolate and immutable.

[...] 
> Others such as Murray (I hope I am not mis-interpreting him!)
> have pointed out that they would like a more general solution,
> because they feel that an XHTML mime type will keep XHTML off
> in it's own landscape and not encourage it to join the more
> general XML solution.

Well, yes. And since there is a strong requirement that a solution be
found for XML, if a stop-gap solution is arrived at for XHTML it will
probably be *different* than XML, which would further push XHTML off
into its own unique landscape. I doubt vendors would want to do both.

What we need instead is a solution that *integrates* XHTML into the
XML environment, both as a 'family' of valid document types and also
as document types and modules mixed into instances via 'namespaces' 
(whatever that really means). While the latter is an enormously more
complicated problem than the former, it's obvious we can't all push 
it off into the future very far since the world has already gone off
and created many (IMO) broken solutions. 

As Rick has pointed out, XHTML is 'application-specific', but no 
more so than MathML or any other XML application that requires 
specialized processing not provided in a stylesheet. It also happens
to be potentially the most widely used XML markup language, and a 
framework for creation of many others. So we all need to work together
to create a solution that works for both XHTML and XML in general.

Murray

...........................................................................
Murray Altheim, SGML Grease Monkey         <mailto:altheim&#64;eng.sun.com>
Member of Technical Staff, Tools Development & Support
Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900

              An SGML declaration does not an i18n make.

Date: Tue, 11 May 1999 07:58:00 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
To: "Simon St.Laurent" <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

> > It has been reported that there is deployed software that has to be changed
> > to deal with new top-level types (a big design botch in my opinion). This
> > came up when the model top-level type was added.

> > There's also the cost of writing it up and getting it standardized. It is
> > likely that there would be strong objection to defining such a type (I
> > certainly would object because I don't see this as being properly orthogonal to
> > several of the existing top-level types).

> So the practical costs are caused by 'reports' of poorly written software,
> while the political costs are caused by a group of dug-in individuals on
> philosophical grounds.  It doesn't sound promising, but it also sounds like
> the real costs are political, not caused by implementations.  (We would
> hope that those folks fixed their software correctly after the experience
> of model, but can't count on it, of course.)

Well, if comments on this list are any indicator, there appears to be close to
a consensus that this isn't the way to go. The reasons people give for this
fall all over the map, but people don't have to agree on why something is bad
to block it. And given the feedback here coming from the subset of the
community that is likely to be the most amenable to this idea, the chances of
this getting approved in a wider context look bad.

> > > I'm afraid that I'm unconvinced that the costs of 1 are greater than the
> > > costs of 2.  Are there genuine compatibility issues, or is this just
> > > philosophical opposition?

> > The former, according to reports we've gotten in the past.

> I'd like to hear more detail on these 'reports'.

As I said before, this came up in conjunction with the discussion that led
up to the creation of the model top-level type, and blocked the creation of
a "chemistry" top-level type. See the archives for the ietf-types list for
May-June 1995 for the full story.

> It's hard to base a
> cost-benefit analysis on reports with no owners or details.  As I noted
> above, it sounds like philosophical opposition - politics - is the real
> roadblock.

Philosophy isn't necessarily politics. My problem with the xml top-level type
proposal is that it doesn't mesh well with how existing top-level types
have been done. XML could be application material, image material, audio
material, model material, or even message material, and by creating a top
level XML type you may break the ability people currently have to assess
the broad category of something by looking at its top-level type. This
is a philosophical point, but it has ongoing real-world consequences outside
the purely political realm.

				Ned

From: "Rick Jelliffe" <[email-masked]>
To: <[email-masked]>
Subject: Re: Using CONNEG instead of MIME types for compound types & references
Date: Tue, 11 May 1999 22:24:38 +0800
Sender: [email-masked]

 From: Frank Boumphrey <[email-masked]>

> > Let's solve the problems that caused us to start this mailing
> > list in the first place; those problems include the problems
> > of properly labelling XHTML with various kinds of embedded
> > tables, math, markup and use of features.
>
> I would like to reiterate these problems, it is the problem of
> how a user agent treats an XHTML file.

Oh I see the problem: I thought this list was for improving RFC 2376
following on from Murata-san's original list of problems. But Frank B and
Larry M are saying that the pressing problem is in fact how to make RFC 2376
handle XHTML.

That means widening the scope of discussion from the simple XML-specific
categories of

* generic documents (*/xml)
* application-specific documents (application/*)
* application-specific documents with fallback/manageability
    (application/xml[-.]*)

because XHTML does not fit in any of those categories. Instead its category
is

* application-specific framework documents with application-specific
extensions and possibly some embedded generic bits (e.g., XHTML with MathML
and "XML Data Islands")

(N.b. I am using application-specific to mean that the nominal target
application of the document has functionality hardwired to the element type
names; a generic applicaton is one in which uses stylesheets and scripts.)

I wasn't suggesting that we avoid this topic, merely that we should avoid
the multipart packaging issue. There is supposed to be a W3C working group
on packaging (according to appendix B of the Fragment Interchange spec.): I
wonder what their requirements are?

Rick Jelliffe

From: "Frank Boumphrey" <[email-masked]>
To: "Larry Masinter" <[email-masked]>, "Rick Jelliffe" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Using CONNEG instead of MIME types for compound types & references
Date: Tue, 11 May 1999 09:41:51 -0400
Sender: [email-masked]

> Let's solve the problems that caused us to start this mailing
> list in the first place; those problems include the problems
> of properly labelling XHTML with various kinds of embedded
> tables, math, markup and use of features.

I would like to reiterate these problems, it is the problem of
how a user agent treats an XHTML file.

Basically if I send an XHTML file as text/html, then a browser
will send that file off to its HTML engine, and parse it as an HTML file.

If I send the file as text/xml, then the browser will send it
of to its XML parser, and just create a parse tree.

Now there may be some devices that do not want to accept an
XML file but will be quite happy to accept an XHTML or an
HTML file. Such a device may be a traditional browser

There will also be some devices that are happy to
accept an XML or an XHTML file but not an HTML file, they have
no wish at all to deal with unclosed tags etc.

Both these devivices would like to know what kind of file they
are dealing with before down loading the whole file, hence the
need to identify a file as an XHTML file in some way.

The second problem is as Larry points out is the file with
embedded xml from different namespaces. A browser may be quite
happy to accept an XHTML file and will 'know' how to display basic
XHTML1.0, but will not know how to display mathXML or MusicXML.
Because the Namespaces can be scoped in the document, and don't
have to be in the head of the document, the browser may be well
into rendering the document before it realises that it can't
display the relevant code. It would be nice from the browsers
point of view if it had prior knowledge of the namespaces before
downloading the document, because then it could either

1. Decide to display it as a tree.
2. Send a mesage to the user asking whether it wants the document
down loaded or not.
3. Decide not to down load the document at all.

For this reason there are many who would like to see
a text/xhtml mime type. (This includes my self as I see
that this is the easiest solution to our problem, but then
I am just being selfish).

For the record I think that application/xml.html would be quite
acceptable and presumably (please correct me if I'm wrong) one
could include a whole series of these to define all the namespaces
used in an XHTML document, i.e. application/xml.html,
application/xml.mathml, application/xml.musicml etc.

Others such as Murray (I hope I am not mis-interpreting him!)
have pointed out that they would like a more general solution,
because they feel that an XHTML mime type will keep XHTML off
in it's own landscape and not encourage it to join the more
general XML solution.

Frank
----- Original Message -----
From: Larry Masinter <[email-masked]>
To: Rick Jelliffe <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 10, 1999 2:36 PM
Subject: RE: Using CONNEG instead of MIME types for compound types &
references

> > Let us solve the simple needs of transmitting a simple document
> > before attempting to get multipart documents correct!  Divide and
> > conquer.
>
> Let's solve the problems that caused us to start this mailing
> list in the first place; those problems include the problems
> of properly labelling XHTML with various kinds of embedded
> tables, math, markup and use of features.
>
> If XML could only allow you to have simple documents without
> any of the complexities of compound mixed features, we wouldn't
> have started this discussion in the first place, since it would
> be fine just to create a new MIME type for each.
>
> Larry
>
>

Date: Tue, 11 May 1999 08:40:23 -0400
To: "Larry Masinter" <[email-masked]>, <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Using CONNEG instead of MIME types for compound types & references
Sender: [email-masked]

At 10:38 AM 5/10/99 -0700, Larry Masinter wrote:
>There are a number of situations where MIME types don't solve the
>problem for "content negotiation" because the XML bodies that are
>transferred will be compound objects that contain multiple kinds
>of markup. In such situations, having a "top level" type other
>than "application/xml" doesn't do any good, since there's no useful
>way to use MIME to describe the combination of elements that are
>contained within.

So long as I can gather from the MIME type that the content I'm getting or
about to get is XML, that's a big step forward.  Multi-part XML doesn't
frighten me, and in hard cases where content negotiation is genuinely
needed, it'll be worth the effort of the many proposals you've noted.

I do not, on the other hand, want to be forced to go through content
negotiation protocols just to find out that a document uses XML syntax.
For short documents, that could be almost as bad as downloading the
document in its entirety.

The beauty of MIME types is that they present a lot of useful information
in a very tiny capsule that's easy to work with. I'd like to make sure they
contain as much useful information as possible without making that capsule
any larger.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Tue, 11 May 1999 08:35:37 -0400
To: Ned Freed <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
Cc: [email-masked]
Sender: [email-masked]

At 09:16 AM 5/10/99 -0700, Ned Freed wrote:
>> 1) What are the real 'costs' of adding a new top-level MIME type?
>
>It has been reported that there is deployed software that has to be changed
>to deal with new top-level types (a big design botch in my opinion). This
>came up when the model top-level type was added.
>
>There's also the cost of writing it up and getting it standardized. It is
>likely that there would be strong objection to defining such a type (I
>certainly would object because I don't see this as being properly
orthogonal to
>several of the existing top-level types).

So the practical costs are caused by 'reports' of poorly written software,
while the political costs are caused by a group of dug-in individuals on
philosophical grounds.  It doesn't sound promising, but it also sounds like
the real costs are political, not caused by implementations.  (We would
hope that those folks fixed their software correctly after the experience
of model, but can't count on it, of course.)

>(3) Recommand/require that the names of XML-based types have "-xml" at the
>    end of the name. This is the same as (2) in terms of effort, but might
>    be a win in that matching a suffix might be easier/cleaner to do in
>    some contexts (the beginnnings of these strings are grotted up with
>    registration tree information).

I could live with this.

>> 2) What are the real 'costs' of creating separate content-negotiation
>> protocols?
>
>The costs are that there are contexts where you're unlikely to see the
>ability to use such things in the forseeable future, and where you'd
>really like to make choices based on knowing the XML variant in use.

Here we agree completely, it seems.

>> I'm afraid that I'm unconvinced that the costs of 1 are greater than the
>> costs of 2.  Are there genuine compatibility issues, or is this just
>> philosophical opposition?
>
>The former, according to reports we've gotten in the past.

I'd like to hear more detail on these 'reports'.  It's hard to base a
cost-benefit analysis on reports with no owners or details.  As I noted
above, it sounds like philosophical opposition - politics - is the real
roadblock.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Tue, 11 May 1999 05:51:15 -0500
From: "Shane P. McCarron" <[email-masked]>
Reply-To: [email-masked]
Organization: MACS, Inc.
To: Larry Masinter <[email-masked]>
CC: Rick Jelliffe <[email-masked]>, [email-masked]
Subject: Re: Using CONNEG instead of MIME types for compound types & references
Sender: [email-masked]

Larry Masinter wrote:
> Let's solve the problems that caused us to start this mailing
> list in the first place; those problems include the problems
> of properly labelling XHTML with various kinds of embedded
> tables, math, markup and use of features.

Well...

Our strategy in the HTML Working Group has been to avoid the issue of
compound documents as well.  Instead, we are defining a mechanism
whereby popular feature sets with DTDs can be combined into single DTDs
that are in the XHTML family.  Thus, as long as the document is
announced as XHTML, a conforming user agent will need to deal with it.

Part of this relates to XHTML Profiles. While this effort is still in
its infancy, my belief is that it is likely to include a method of
specifying the various feature sets that are required by a document
and/or supported by a user agent.  This is needed for content
negotiation.  If we can leverage the CONNEG work on this, so much the
better!

--
Shane P. McCarron                              phone: +1 612 434-4431
Testing Research Manager                         fax: +1 612 434-4318
                                              mobile: +1 612 799-6942
                                              e-mail: [email-masked]

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.

Date: Tue, 11 May 1999 01:04:30 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
To: Rick Jelliffe <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked]
Sender: [email-masked]

> You are assuming a step which I am not: that all XML must be registered
> using the xml. registration tree.  It would be a service made available for
> convenience; if it were a new top-level MIME type, then one would expect
> everyone to use it.

Then I fail to see the point of adding the tree. Nearly equivalent rules would
have apply to it, the same procedures, and it doesn't serve to distinguish XML
usage.

Unless you can explain why you think the present registration procedure isn't
working for XML I fail to see the point of having a new one that isn't going to
be able to be materially different from the old.

> > So what you end up with is a registration tree designed to capture all
> > registrations of a given type that cannot possibly get all the registrations
> > it is supposed to. And that makes it fairly useless in my book.

> That says that new MIME types require an RFC (from my context it should be
> obvious that I am talking about MIME types in the default, IETF, tree,
> because my proposal is based on MIME types in other registration trees not
> requiring an RFC.)

No, it says that types in the IETF tree have to be backed up with an RFC, and
it is NOT obvious or even correct that you're talking about the IETF tree only
here. You were responding to my proposal, and my proposal was in no way limited
to the IETF tree.

> > Again, I'm not suggest a prefix that goes before the registration facet,
> > I'm suggesting one that goes after it.

> And I again I'm saying that RFC 2048 only allows, in its plain reading,
> registration of specific media-content types. I cannot see where it allows
> bulk open-ended registrations by registering a prefix.

I'm sorry, but this is nonsensical in that I'm not talking about registration
in the IETF tree.

> I agree that now that vendors are starting to use vnd. vendor tree, things
> are not grim. My point is this: it would be convenient and useful to have an
> automated procedure which circumvented the need for an RFC for each MIME
> type, which RFC 2048 requires (as quoted above).

The problem is it won't work. The rules for these things require substantive
review. You cannot avoid this review and automate the process by setting up a
new registration tree; there would be tremendous objection to attempting to
circumvent the review process.

It took years of wrangling to get the vnd. and prs. trees approved and the
rules for registration in them lightened to the point where people would use
them, and to this day there are plenty of people who don't think we did the
right thing when we did this. Every single time I approve one of these things I
think about whether or not I'm making an egregious blunder that is going to
wreck the whole process.

It is my assessment that a proposal which lifts even more of the review
requirements, especially when there doesn't solve any current problem, is going
to be a total nonstarter.

And believe me, it isn't because I love reviewing the things that I say this.

				Ned

From: "Rick Jelliffe" <[email-masked]>
To: "Ned Freed" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
Date: Tue, 11 May 1999 15:31:47 +0800
Sender: [email-masked]

 From: Ned Freed <[email-masked]>

> > On Mon, 10 May 1999, Ned Freed wrote:

> No, the point of having different registration authorities is to allow
> different rulesets to be brought to bear on different classes of media
types.

So where it the problem?...the different ruleset is the automated
registration for a definite class of documents on the provision of a DTD or
schema.

> And insofar as the W3C is concerned, my understanding is that they don't
> want to act as a registration authority for XML types. I haven't heard any
> other organizations suggested that would be appropriate for this job.

Which is why I didn't suggest that they should act: merely that they, and
IETF, agree on someone to act as registrar. I could do it (through Academia
Sinica, for example). Because the procedure is automated, the registrar is
nominal.  W3C needs to give some consent because they are the trademark
holders of XML, not because they need be principals.

> And if you assume that the W3C wanted its own tree where its own rules
> would apply, it would be silly to restrict it to XML. As such, you'd
likely
> end up with a "w3c." facet.

No, I was not assuming that W3C wanted its own tree. That is why I did not
call the facet "w3c.".

> > Also, where did this requirement for orthogonality spring from?
>
> It isn't a requirement, it is just a common sense concern. I think it is
> inevitable that the IETF will use XML for some of its future work. But
such
> types will be registered in the IETF tree, not an XML tree -- I can assure
you
> that the idea that the IETF would be forced to use an "xml." or worse
"w3c."
> tree and hence someone else would have this sort of control over the
IETF's use
> of something it created is a complete anathema to many, and hence is a
100%
> complete nonstarer.

You are assuming a step which I am not: that all XML must be registered
using the xml. registration tree.  It would be a service made available for
convenience; if it were a new top-level MIME type, then one would expect
everyone to use it.

> So what you end up with is a registration tree designed to capture all
> registrations of a given type that cannot possibly get all the
registrations
> it is supposed to. And that makes it fairly useless in my book.

If that was what I was proposing, I would agree with you.

> > All new MIME media types require writing a specification (an RFC).
>
> No they do not. Read RFC 2048 (which as it happens I wrote).

I know you wrote it: we are indebted to you, it is a great thing. But that
is not what you wrote:

"2.1.1.  IETF Tree

   The IETF tree is intended for types of general interest to the
   Internet Community. Registration in the IETF tree requires approval
   by the IESG and publication of the media type registration as some
   form of RFC."

That says that new MIME types require an RFC (from my context it should be
obvious that I am talking about MIME types in the default, IETF, tree,
because my proposal is based on MIME types in other registration trees not
requiring an RFC.)

> Again, I'm not suggest a prefix that goes before the registration facet,
I'm
> suggesting one that goes after it.

And I again I'm saying that RFC 2048 only allows, in its plain reading,
registration of specific media-content types. I cannot see where it allows
bulk open-ended registrations by registering a prefix.

> And the media types registration process has shown that it can handle one
> registration a day if need be. Moreover, such a need is unlikely to exist
since
> only a subset of all the DTDs that are announced will actually need a
media
> type.

I agree that now that vendors are starting to use vnd. vendor tree, things
are not grim. My point is this: it would be convenient and useful to have an
automated procedure which circumvented the need for an RFC for each MIME
type, which RFC 2048 requires (as quoted above).

Because, as far as I can construe RFC 2048, there is no scope to
bulk-declare prefixes, the only solution I could see is a registration tree.
However, it may well be, as you advise, that this would be more trouble than
it is worth.  Especially because the kind of information that I am
suggesting would be needed for registration (the schema) should be available
in the document itself, as a DOCTYPE or schema or namespace declaration.

Rick Jelliffe

From: "Larry Masinter" <[email-masked]>
To: "Rick Jelliffe" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Using CONNEG instead of MIME types for compound types & references
Date: Mon, 10 May 1999 11:36:39 PDT
Importance: Normal
Sender: [email-masked]

> Let us solve the simple needs of transmitting a simple document 
> before attempting to get multipart documents correct!  Divide and
> conquer.  

Let's solve the problems that caused us to start this mailing
list in the first place; those problems include the problems
of properly labelling XHTML with various kinds of embedded
tables, math, markup and use of features.

If XML could only allow you to have simple documents without
any of the complexities of compound mixed features, we wouldn't
have started this discussion in the first place, since it would
be fine just to create a new MIME type for each.

Larry

Date: Mon, 10 May 1999 11:12:48 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
To: Rick Jelliffe <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> On Mon, 10 May 1999, Ned Freed wrote:

> > > 1a) What are the costs of adding xml- as a prefix to XML-based MIME types?
> > > (Rick Jelliffe's proposal.)
> >
> > There are actually three possible proposals in this space:
> >
> > (1) Add a "xml." facet and corresponding registration tree. Again, this
> >     requires writing a specification, and it is likely to be controversial
> >     because this doesn't meet the criteria for a new registration tree and
> >     also isn't orthogonal to existing trees.

> Why doesnt it meet the criteria for new trees?  The point of a
> registration tree is to accomodate registration authorities other than
> the IETF/RFC mechanism: a program administered by a registrar accepted by
> W3C (the copyright holders) and IETF seems to meet the criteria as far as
> I read them.

No, the point of having different registration authorities is to allow
different rulesets to be brought to bear on different classes of media types.

And insofar as the W3C is concerned, my understanding is that they don't
want to act as a registration authority for XML types. I haven't heard any
other organizations suggested that would be appropriate for this job.

And if you assume that the W3C wanted its own tree where its own rules 
would apply, it would be silly to restrict it to XML. As such, you'd likely
end up with a "w3c." facet.

> Also, where did this requirement for orthogonality spring from?
 
It isn't a requirement, it is just a common sense concern. I think it is
inevitable that the IETF will use XML for some of its future work. But such
types will be registered in the IETF tree, not an XML tree -- I can assure you
that the idea that the IETF would be forced to use an "xml." or worse "w3c."
tree and hence someone else would have this sort of control over the IETF's use
of something it created is a complete anathema to many, and hence is a 100%
complete nonstarer. 

So what you end up with is a registration tree designed to capture all
registrations of a given type that cannot possibly get all the registrations
it is supposed to. And that makes it fairly useless in my book.

> > (2) Recommend/require that the names of XML-based types have "xml-" after
> >     the registration facet.

> The RFC for MIME media types does not allow for delegation of IETF
> registration tree names, which is what you seem to suggest here.

No, what said is that the prefix would appear after the registration
facet, that is, xml-, vnd.xml-, prs.vnd.xml-, and possibly w3c.xml-.

> All new MIME media types require writing a specification (an RFC).

No they do not. Read RFC 2048 (which as it happens I wrote).

> The only ways around this is either to rewrite the MIME media type spec,
> or to add a registration tree. I don't see how it can be done inside the XML
> spec, under the current procedures.  If the MIME spec is rewritten to allow
> the registration of a prefix (application/xml-*) and to allow people to use
> that prefix without creating an RFC, we increase the likelihood for
> collision: this is why we need a registration tree.

Again, I'm not suggest a prefix that goes before the registration facet, I'm
suggesting one that goes after it.

> We are easily getting a DTD a day being announced, and many more being
> created. There is no way they can all be vetted adequately; and they do
> not need to be vetted if they use XML: it already has the RFC out. They
> should be able to piggyback on top of the XML RFC, and just provide
> minimal extra information.

And the media types registration process has shown that it can handle one
registration a day if need be. Moreover, such a need is unlikely to exist since
only a subset of all the DTDs that are announced will actually need a media
type.

> This is why I think it is more than just an issue of the inconvenience of
> getting an XML registration tree up: I think other approaches will cause
> more trouble.

I can assure you that this assessment is incorrect.

				Ned

Date: Mon, 10 May 1999 11:05:31 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Using CONNEG instead of MIME types for compound types & references
Sender: [email-masked]

At 01:54 AM 5/11/99 +0800, Rick Jelliffe wrote:
>Let us solve the simple needs of transmitting a simple document
>before attempting to get multipart documents correct!  Divide and
>conquer.

I'll disagree here. Because we know they exist and believe they will 
continue to exist, it is our responsibility to try hard to make sure 
they're covered by whatever solution we come up with. It's fine for us to 
eventually say "nope, we couldn't handle it so here's a system for 
single-parts only", but we need to try. Otherwise, a MIME-creating program 
with an outgoing document won't be able to figure out how to tag it.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 11 May 1999 01:54:21 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: Larry Masinter <[email-masked]>
cc: [email-masked]
Subject: Re: Using CONNEG instead of MIME types for compound types & references
Sender: [email-masked]

On Mon, 10 May 1999, Larry Masinter wrote:

> There are a number of situations where MIME types don't solve the
> problem for "content negotiation" because the XML bodies that are
> transferred will be compound objects that contain multiple kinds
> of markup. In such situations, having a "top level" type other
> than "application/xml" doesn't do any good, since there's no useful
> way to use MIME to describe the combination of elements that are
> contained within.

Let us solve the simple needs of transmitting a simple document 
before attempting to get multipart documents correct!  Divide and
conquer.  

The multipart problems (sending a document rather than an entity) are a 
black hole from which we may never return.  

Rick Jelliffe

Date: Tue, 11 May 1999 01:48:28 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: [email-masked]
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
Sender: [email-masked]

On Mon, 10 May 1999, Ned Freed wrote:

> > 1a) What are the costs of adding xml- as a prefix to XML-based MIME types?
> > (Rick Jelliffe's proposal.)
> 
> There are actually three possible proposals in this space:
> 
> (1) Add a "xml." facet and corresponding registration tree. Again, this
>     requires writing a specification, and it is likely to be controversial
>     because this doesn't meet the criteria for a new registration tree and
>     also isn't orthogonal to existing trees.

Why doesnt it meet the criteria for new trees?  The point of a 
registration tree is to accomodate registration authorities other than 
the IETF/RFC mechanism: a program administered by a registrar accepted by 
W3C (the copyright holders) and IETF seems to meet the criteria as far as 
I read them. Also, where did this requirement for orthogonality spring from?
 
> (2) Recommend/require that the names of XML-based types have "xml-" after
>     the registration facet.

The RFC for MIME media types does not allow for delegation of IETF 
registration tree names, which is what you seem to suggest here.

All new MIME media types require writing a specification (an RFC).
The only ways around this is either to rewrite the MIME media type spec, 
or to add a registration tree. I don't see how it can be done inside the XML 
spec, under the current procedures.  If the MIME spec is rewritten to allow 
the registration of a prefix (application/xml-*) and to allow people to use 
that prefix without creating an RFC, we increase the likelihood for 
collision: this is why we need a registration tree. 

We are easily getting a DTD a day being announced, and many more being 
created. There is no way they can all be vetted adequately; and they do 
not need to be vetted if they use XML: it already has the RFC out. They 
should be able to piggyback on top of the XML RFC, and just provide 
minimal extra information.

This is why I think it is more than just an issue of the inconvenience of 
getting an XML registration tree up: I think other approaches will cause 
more trouble. 

Rick Jelliffe

From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>
Subject: Using CONNEG instead of MIME types for compound types & references
Date: Mon, 10 May 1999 10:38:16 PDT
Importance: Normal
Sender: [email-masked]

There are a number of situations where MIME types don't solve the
problem for "content negotiation" because the XML bodies that are
transferred will be compound objects that contain multiple kinds
of markup. In such situations, having a "top level" type other
than "application/xml" doesn't do any good, since there's no useful
way to use MIME to describe the combination of elements that are
contained within.

For example, if, as it seems, there will be XML body parts which
contain XHTML and, embedded within (not using multipart), contain
equations using the MathML and molecular diagrams using ChemML,
and some Dublin Core metadata using RDF, there is no useful
designation of the entire top level type that accurately describes
the content, or allows you to say that you accept XHTML,
MathML but don't accept ChemML.

For *these* kind of XML bodies where multiple applications are
intermixed, having new MIME types doesn't solve the problem.

In this situation, though adding additional MIME types doesn't solve
the problem, the media feature mechanisms *do* allow content negotiation
and are appropriate.

I want to distinguish between a "protocol" (rules of engagement)
and a "protocol element" (a string or data structure used within
one or more protocols).

CONNEG developed content negotiation *protocol elements* for
describing data, sender and recipient capabilities,
characteristics and preferences. Most of the work on different content
negotiation *protocols* has happened outside of the CONNEG working group,
since content negotiation is usually in the context of some other
communication protocol. HTTP and Internet Fax both have some kind of
"content negotiation". The Internet Fax mechanisms are, IMHO, the best
you can do for email. (Section 3 of RFC 2532 describes how a sender
may determine an email recipient's capabilities.) HTTP has both "accept"
requests, "Vary" responses, and some experimental protocols (Transparent
Content Negotiation and RVSA).

------
RFC 2506 Media Feature Tag Registration Procedure. March 1999. 
 (Also BCP0031) (Status:  BEST CURRENT PRACTICE)

How to register features. The simplest thing to do would be
to define an "XML namespace" feature and a "XML DTD" feature,
whose values are the pointer to the XML namespace and DTD
respectively.
-------
RFC 2533 A Syntax for Describing Media Feature Sets. March 1999.
    (Status: PROPOSED STANDARD)

How to combine a set of features into a feature set
--------
draft-ietf-conneg-feature-hash-01.txt: Identifying composite media features
April 1999.

How to use URLs or hashes to indentify complex sets of features
or feature profiles.

and, while you're at it (although only relevant to some XML
applications):
-------
RFC 2534 Media Features for Display, Print, and Fax. March 1999.
  (Status:  PROPOSED STANDARD)

This is as useful for HTML as it is for anything. In fact, it
was originally motivated by wanting to do better than the
"screen size" in the User Agent field.
------
RFC 2530 Indicating Supported Media Features Using Extensions to DSN and
     MDN.March 1999. (Status: PROPOSED STANDARD)

This is a way of adding content negotiation to email.
------
RFC 2531 Content Feature Schema for Internet Fax. March 1999. 
    (Status: PROPOSED STANDARD)

The color space description protocol elements here are applicable to
any calibrated-color application, even though designed originally
for "fax".
------
Two proposals for content negotiation *protocols* in HTTP:

RFC 2295 Transparent Content Negotiation in HTTP. March 1998. 
   (Status: EXPERIMENTAL)

RFC 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0. March 1998. 
   (Status: EXPERIMENTAL)

Date: Mon, 10 May 1999 09:16:43 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
To: "Simon St.Laurent" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > Again, this can be handled by using content-negotiation. It would be pretty
> > easy to add a conneg type that would describe the type of XML that you are
> > passing, without breaking the example I gave for protocols that don't do
> > negotiation.

> The need for content negotiation in certain circumstance seems real -
> maybe, just maybe, I've extracted this much of a concession.

> The question then becomes whether it is better to describe content in one
> concise description (the MIME type) or using separate protocols.

> 1) What are the real 'costs' of adding a new top-level MIME type?

It has been reported that there is deployed software that has to be changed
to deal with new top-level types (a big design botch in my opinion). This
came up when the model top-level type was added.

There's also the cost of writing it up and getting it standardized. It is
likely that there would be strong objection to defining such a type (I
certainly would object because I don't see this as being properly orthogonal to
several of the existing top-level types).

> 1a) What are the costs of adding xml- as a prefix to XML-based MIME types?
> (Rick Jelliffe's proposal.)

There are actually three possible proposals in this space:

(1) Add a "xml." facet and corresponding registration tree. Again, this
    requires writing a specification, and it is likely to be controversial
    because this doesn't meet the criteria for a new registration tree and
    also isn't orthogonal to existing trees.

(2) Recommend/require that the names of XML-based types have "xml-" after
    the registration facet. This could be done simply by adding some text
    to this effect to a revision of the XML in MIME document -- once in place
    the media types reviewer (me) will see to it that appropriate names are
    selected for new types.

(3) Recommand/require that the names of XML-based types have "-xml" at the
    end of the name. This is the same as (2) in terms of effort, but might
    be a win in that matching a suffix might be easier/cleaner to do in
    some contexts (the beginnnings of these strings are grotted up with
    registration tree information).

> 2) What are the real 'costs' of creating separate content-negotiation
> protocols?

The costs are that there are contexts where you're unlikely to see the
ability to use such things in the forseeable future, and where you'd
really like to make choices based on knowing the XML variant in use.

> I'm afraid that I'm unconvinced that the costs of 1 are greater than the
> costs of 2.  Are there genuine compatibility issues, or is this just
> philosophical opposition?

The former, according to reports we've gotten in the past.

				Ned

Date: Tue, 11 May 1999 00:08:18 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: Tim Bray <[email-masked]>
cc: [email-masked]
Subject: Re: media types and ignorance
Sender: [email-masked]

On Mon, 10 May 1999, Tim Bray wrote:

> Or maybe the whole notion that a rigid 2-level type hierarchy is a useful
> vehicle for interoperability is becoming bogus.

I think Tim's ambivalence is just a sign that that all these are useful, 
and that we should provide enough richness to cover the major cases:

* generic XML using stylesheets and fallback (text/xml & application/xml);

* application-specific XML with no need for fallback (application/*, 
model/*, etc);

* application-specific XML but which allows some measure of fallback, 
even if just to allow browser users to figure out which is the best 
handler for it (the XML registration tree: application/xml.*): we can 
expect smarter broswers to check for <?xml when they do not have a MIME 
media type registered for a specific MIME type.

Simon asked why an XML registration tree would be better than just a new 
top-level MIME type: the reason is that to introduce any new types in the 
(default) IETF registration tree you need to make a full RFC providing 
certain information (see the RFCs on MIME types, referenced in previous 
postings). It is not simply a matter of whether the strings "xml/blah" 
has more information thatn "application/xml.blah" or "application/xml; 
schema=blah". It is more importantly the administrative requirements 
needed to maintain the integrity of MIME.

The essense of my call for an XML registration tree is that it could be 
automatically registered after a minimum of information is provided.  
Otherwise we will just get spurious unregistered MIME media types: 
text/rdf, application/vml, etc etc.  The reason we don't want the MIME 
media type registration to fall over is that WWW and email browsing 
relies on registered MIME media type being fixed to a particular type.

(It is bad enough that my browser has decided that all .gz files are VRML; 
I don't want to encourage media-type detection using file extensions. So 
I believe we need to make it easy to register new XML-based types.)

Rick Jelliffe

Date: Mon, 10 May 1999 08:40:29 -0700
To: [email-masked]
From: Tim Bray <[email-masked]>
Subject: media types and ignorance
Sender: [email-masked]

At 10:22 AM 5/9/99 -0700, Ned Freed wrote:
>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.

Hard to argue with that.  This discussion has been peeving me seriously
because with each exchange, I realize I understand less than I thought 
about how the Internet is supposed to fit together.  

I honestly don't have an opinion I'm comfy with, but here are a few
data points that might be useful:

- I'm currently helping work on a language whose mime type will
  almost certainly be encoded as "model/x3d" - it will be encoded
  in XML
- Internet Explorer 5 has a facility I've found very useful - send
  it a well-formed XML document with no stylesheet and it constructs
  a nice collapsing-tree view of it in real time.  Tremendously
  helpful when you're getting some chunk of XML vocabulary for
  the first time and want to get a handle on it.  This is, in fact,
  a useful general-purpose XML processor, something I seem to 
  recall denying the existence of here not too long ago.
- There are going to be a lot of new formats that happen to be
  encoded in XML, for which the fact of the encoding syntax is 
  an irrelevant side-issue.

It's obvious that there is a real need for application/xml; among
other things, it clarifies i18n immensely.  Three days out of each week, 
I don't believe that text/xml is useful.  I know this is heresy, but 
sometimes I think that what you need is not a media type but another 
parameter akin to charset, so that you can say for some arbitrary mimetype

content-type: text/foo; charset="ISO-8859-1" syntax="xml-1.0"

which lets you know that there's a really useful fallback (ie your
XML-savvy-browser) in the case that you're not set up for text/foo.

Or maybe the top-level xml/* type has the same utility.

Or maybe the whole notion that a rigid 2-level type hierarchy is a useful
vehicle for interoperability is becoming bogus.

I just don't know, so I'm going to shut up and listen.  -Tim

Date: Mon, 10 May 1999 10:18:01 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
Sender: [email-masked]

At 09:32 AM 5/9/99 -0700, Paul Hoffman / IMC wrote:
>Correct. Not all MIME-using mechanisms have content negotiation. Internet 
>mail, for example. Content-negotiation can and should be dealt with using 
>content-negotiation protocols. See <http://www.imc.org/ietf-medfree/> for 
>details.
>
>[...]
>
>Again, this can be handled by using content-negotiation. It would be pretty 
>easy to add a conneg type that would describe the type of XML that you are 
>passing, without breaking the example I gave for protocols that don't do 
>negotiation.

The need for content negotiation in certain circumstance seems real -
maybe, just maybe, I've extracted this much of a concession.

The question then becomes whether it is better to describe content in one
concise description (the MIME type) or using separate protocols.

1) What are the real 'costs' of adding a new top-level MIME type?

1a) What are the costs of adding xml- as a prefix to XML-based MIME types?
(Rick Jelliffe's proposal.)

2) What are the real 'costs' of creating separate content-negotiation
protocols?

I'm afraid that I'm unconvinced that the costs of 1 are greater than the
costs of 2.  Are there genuine compatibility issues, or is this just
philosophical opposition?

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Sun, 09 May 1999 14:18:26 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: Top-level media type xml desirable?  (WAS: RE: Parameters for top-level XML media types?)
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > More specifically, what happens when the XML-dispatching program decides,
> > "Surprise! The original client is the agent best suited to display of this
> > particular XML object." The problem is that even in tightly integrated plug in
> > setups there's usually no way to communicate this sort of thing back to the
> > client's dispacher to the point where a truly seamless display can be
> > achieved.

> > The inevitable result is suboptimal integration, which users, myself included,
> > loathe.

> I can't agree with you here. Yes, Eudora does this badly, but I think this
> is a problem with the implementation, not the idea. If an MUA or Web
> display engine says "I can natively display a stream of XML", then the
> integration with an intermediary is not difficult at all.

Actually, in my opinion Eudora is far and away the best agent out there when it
comes to this sort of thing, which is why I held it up as a fairly unique
counterexample to what I see as the current state of affairs. Nothing else I've
seen even comes close to having Eudora's capabilities.

If you know of something else I'd like to hear about it.

> > This is another instance of a problem we first encountered with security
> > multiparts: When you dispatch handling of a security multipart to a separate
> > application, getting the enclosed data back to the original client often
> > isn't possible. And while a few clients have adopted plugin architectures
> > that address this (Eudora, for example), most have not, and worse, plugins
> > capable of working really well in such environments have been slow in coming.

> I've spoken with people who make such plugins (such as the ones I try to
> use with Eudora), and they complain about the Eudora API, not about their
> ability to hand back blobs of text to the program. In my mind, this can't
> be all that hard for data types that the original program knows how to
> handle, particularly if they are guaranteed not to get back a multipart.

Well, as it happens I'm familiar with the Eudora API -- I was asked to review
its capabilities in this area some time back, and I liked them so much that I
modelled some aspects of a similar API in our product after what Qualcomm had
done.

So while I cannot claim to have actually written code to the Eudora API, I can
claim to have developed a similar API and written code that uses it to do
similar things. And I can assure you that not only are such transformations
possible, they are easy to implement using APIs of this sort.

So I'm afraid I'm not prepared to accept the complaints you have heard as 
valid. Perhaps they were directed at an earlier version of Eudora, or something
like that.

(Please note that I don't work for Qualcomm and I only use Eudora rarely. So I
have no vested interest in their MUA.)

> To me, the problems of "original clients" displaying XML handed back to
> them from a process that decides what goes where isn't a serious issue. The
> more serious issue in my mind is that we are starting to get a significant
> number of XML formats and some viewers, and we haven't agreed to a method
> for them to link those through MIME. I think we need to say "yes, MIME is
> your linkage and here's exactly how" (which I don't think we are ready to
> do), or we must say "MIME is not your linkage and you need to come up with
> your own methods."

Again, I don't think you can say either one is right in general. I think that
for some applications separate MIME types are appropriate and necessary; for
others a single MIME type for an entire family of things is appropriate; and
for others a generic MIME label is fine.

				Ned

Date: Sun, 09 May 1999 14:13:00 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> At 10:22 AM 5/9/99 -0700, Ned Freed wrote:
> There is also an intermediate case -- IMAP. In IMAP header information for
> >a MIME message can be downloaded and examined prior to downloading the
> >actual message content. But this is restricted to the labelling in header
> >fields -- media type, media type parameters, and disposition information,
> >in other words.

> If we ever get the rescap protocol finished, however, this won't be an
> issue, because the sender could have determined that the recipient couldn't
> (or didn't want) the type of information they were sending by looking at
> the media features of the receiver.

In the case of specific sender to specific receiver perhaps. But how about
mailing lists? Mail archives?

One of the key uses of IMAP (as opposed to POP) is to provide usable and useful
archive and bulletin board services. And like it or not, rescap will never be
able to solve the issues that arise with these sorts of things (unless it
develops an ability to predict the future, which seems rather unlikely given
current technology ;-).

And this says nothing about the liklihood of rescap support appearing any time
soon, let alone becoming widespread. I hope it does appear as soon as the
specifications are done and catches on in a big way, but I'm not sure I want
to make protocol design choices in other venues based on my hopes.

				Ned

Date: Sun, 09 May 1999 13:13:47 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Top-level media type xml desirable?  (WAS: RE: Parameters for top-level XML media types?)
Sender: [email-masked]

At 10:34 AM 5/9/99 -0700, Ned Freed wrote:
>While all of these are true, you've missed the big downside to "tweak the
>dispatched-to program": Such programs lose big-time in the integration they
>can offer in the client environment.
>
>More specifically, what happens when the XML-dispatching program decides,
>"Surprise! The original client is the agent best suited to display of this
>particular XML object." The problem is that even in tightly integrated plug in
>setups there's usually no way to communicate this sort of thing back to the
>client's dispacher to the point where a truly seamless display can be 
>achieved.
>The inevitable result is suboptimal integration, which users, myself included,
>loathe.

I can't agree with you here. Yes, Eudora does this badly, but I think this 
is a problem with the implementation, not the idea. If an MUA or Web 
display engine says "I can natively display a stream of XML", then the 
integration with an intermediary is not difficult at all.

>This is another instance of a problem we first encountered with security
>multiparts: When you dispatch handling of a security multipart to a separate
>application, getting the enclosed data back to the original client often
>isn't possible. And while a few clients have adopted plugin architectures
>that address this (Eudora, for example), most have not, and worse, plugins
>capable of working really well in such environments have been slow in coming.

I've spoken with people who make such plugins (such as the ones I try to 
use with Eudora), and they complain about the Eudora API, not about their 
ability to hand back blobs of text to the program. In my mind, this can't 
be all that hard for data types that the original program knows how to 
handle, particularly if they are guaranteed not to get back a multipart.

To me, the problems of "original clients" displaying XML handed back to 
them from a process that decides what goes where isn't a serious issue. The 
more serious issue in my mind is that we are starting to get a significant 
number of XML formats and some viewers, and we haven't agreed to a method 
for them to link those through MIME. I think we need to say "yes, MIME is 
your linkage and here's exactly how" (which I don't think we are ready to 
do), or we must say "MIME is not your linkage and you need to come up with 
your own methods."

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 09 May 1999 13:01:55 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
Sender: [email-masked]

At 10:22 AM 5/9/99 -0700, Ned Freed wrote:
There is also an intermediate case -- IMAP. In IMAP header information for
>a MIME message can be downloaded and examined prior to downloading the
>actual message content. But this is restricted to the labelling in header
>fields -- media type, media type parameters, and disposition information,
>in other words.

If we ever get the rescap protocol finished, however, this won't be an 
issue, because the sender could have determined that the recipient couldn't 
(or didn't want) the type of information they were sending by looking at 
the media features of the receiver.

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

I'll certainly agree with the last parts. The XML community isn't close to 
agreeing on whether it's FPIs or namespaces or the-next-big-thing that 
should be used as the identifier for what program should be used to process 
a particular XML object.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 09 May 1999 10:34:56 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: Top-level media type xml desirable?  (WAS: RE: Parameters for top-level XML media types?)
To: Paul Hoffman / IMC <[email-masked]>
Cc: Larry Masinter <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked]
Sender: [email-masked]

> If all XML items come in with MIME types of "xml/foo", then someone needs
> to tweak the settings in your client to know about DisplayFoo. If all your
> XML items come in with the type "application/xml", then someone needs to
> tweak the settings in the dispatched-to program to know about DisplayFoo.

> I believe that "tweak the dispatched-to program" is a much better
> environment than "tweak all the MIME-receiving clients" for many reasons:
> - If you have more than one MIME-receiving client, the user tweaks fewer
> settings.
> - There is no need to register every sub-type: XMLShow can decide to launch
> based on the content of the XML, such as from the DTD or XML namespaces
> used. This speeds up adoption of new XML types.
> - If "application/xml" automatically launches XMLShow, it is XMLShow that
> can be told about the "smarter" applications like DisplayFoo, and it might
> be able to cooperate with them in many ways. For instance, DisplayFoo might
> be able to ask XMLShow to render parts of a document while DisplayFoo
> renders other parts.
> - XMLShow will be able to open a file off of disk (with no MIME
> information) and still be able to hand off the file to DisplayFoo. The
> MIME-receiving clients can never do this.
> - Given today's MIME-receiving clients, it is more likely that XMLShow will
> be more flexible about adding new DisplayFoo viewers than the
> MIME-receiving clients are.

While all of these are true, you've missed the big downside to "tweak the
dispatched-to program": Such programs lose big-time in the integration they
can offer in the client environment.

More specifically, what happens when the XML-dispatching program decides,
"Surprise! The original client is the agent best suited to display of this
particular XML object." The problem is that even in tightly integrated plug in
setups there's usually no way to communicate this sort of thing back to the
client's dispacher to the point where a truly seamless display can be achieved.
The inevitable result is suboptimal integration, which users, myself included,
loathe.

This is another instance of a problem we first encountered with security
multiparts: When you dispatch handling of a security multipart to a separate
application, getting the enclosed data back to the original client often
isn't possible. And while a few clients have adopted plugin architectures
that address this (Eudora, for example), most have not, and worse, plugins
capable of working really well in such environments have been slow in coming.

The result in the case of container objects like security multiparts has
been to force the original client to do this sort of processing. And I suspect
that similar forces will work to force a single level of dispatch for XML.
And this, I believe, argues strongly for using different media type
labels for XML in quite a few (but not all) cases.

> In summary, I believe that specialized XML viewers are better off in an
> environment where they are launched by the thing that "application/XML"
> launches, not by their own MIME sub-types.

I'm afraid I have to disagree. 

				Ned

Date: Sun, 09 May 1999 10:22:59 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > However, I'd really rather not be downloading material I can't use.  If I
> > know beforehand - from MIME types exchanges in HTTP negotiations, for
> > instance - that the information is in XML, I may be (depending on my
> > application type) more willing to take the risk.  If not, I'll be spending
> > a lot of time downloading junk, finding that it doesn't work, and trying to
> > avoiding getting that type of information the next time around.

> Again, this can be handled by using content-negotiation. It would be pretty
> easy to add a conneg type that would describe the type of XML that you are
> passing, without breaking the example I gave for protocols that don't do
> negotiation.

There is also an intermediate case -- IMAP. In IMAP header information for
a MIME message can be downloaded and examined prior to downloading the
actual message content. But this is restricted to the labelling in header
fields -- media type, media type parameters, and disposition information,
in other words.

There are also instances in HTTP where the MIME type for an external
object is already known, but going through a content negotiation
step means making an external connection -- a far more costly operation.

And there's also the issue of needing to extend existing negotiation mechanisms 
to accomodate new labelling information. This may be a no-brainer from a
protocol design standpoint, but unfortunately it is anything but when you
consider the restrictions that exist in deployed software.

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.

				Ned

Date: Sun, 09 May 1999 09:32:12 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Negotiated Content Delivery: Maxmimizing Information
Sender: [email-masked]

At 09:16 AM 5/9/99 -0400, Simon St.Laurent wrote:
>At 09:57 AM 5/8/99 -0700, Paul Hoffman / IMC wrote:
> >1) You have a MIME-receiving agent (mail agent, HTTP client, etc.). That
> >agent knows how to dispatch based on MIME information. It knows how to
> >dispatch to programs. These dipatched-to programs might display the content
> >directly, or might make a decision and launch a different display program.
> >2) You have a generic XML-display program (XMLShow) and some programs for
> >displaying particular XML types (DisplayEDI, DisplayCal, and so on).
> >3) Someone invents a new XML type (XMLFoo) and a special display program
> >(DisplayFoo).
>
>Good examples - except that in all cases, you omit the negotiations phase
>where the two ends of the connection can decide whether transmission is
>really worthwhile.

Correct. Not all MIME-using mechanisms have content negotiation. Internet 
mail, for example. Content-negotiation can and should be dealt with using 
content-negotiation protocols. See <http://www.imc.org/ietf-medfree/> for 
details.

>However, I'd really rather not be downloading material I can't use.  If I
>know beforehand - from MIME types exchanges in HTTP negotiations, for
>instance - that the information is in XML, I may be (depending on my
>application type) more willing to take the risk.  If not, I'll be spending
>a lot of time downloading junk, finding that it doesn't work, and trying to
>avoiding getting that type of information the next time around.

Again, this can be handled by using content-negotiation. It would be pretty 
easy to add a conneg type that would describe the type of XML that you are 
passing, without breaking the example I gave for protocols that don't do 
negotiation.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sun, 09 May 1999 09:16:08 -0400
To: <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Negotiated Content Delivery: Maxmimizing Information
Sender: [email-masked]

At 09:57 AM 5/8/99 -0700, Paul Hoffman / IMC wrote:
>1) You have a MIME-receiving agent (mail agent, HTTP client, etc.). That 
>agent knows how to dispatch based on MIME information. It knows how to 
>dispatch to programs. These dipatched-to programs might display the content 
>directly, or might make a decision and launch a different display program.
>2) You have a generic XML-display program (XMLShow) and some programs for 
>displaying particular XML types (DisplayEDI, DisplayCal, and so on).
>3) Someone invents a new XML type (XMLFoo) and a special display program 
>(DisplayFoo).

Good examples - except that in all cases, you omit the negotiations phase
where the two ends of the connection can decide whether transmission is
really worthwhile.  Once I've downloaded the file, sure, no problem, I can
save it as a stream and the user can poke at it manually if they want, I
can check to see if it's XML or a binary format, etc.

However, I'd really rather not be downloading material I can't use.  If I
know beforehand - from MIME types exchanges in HTTP negotiations, for
instance - that the information is in XML, I may be (depending on my
application type) more willing to take the risk.  If not, I'll be spending
a lot of time downloading junk, finding that it doesn't work, and trying to
avoiding getting that type of information the next time around.

There are two fairly obvious cases where this is important.  The first is
the automated engine case - agents and search engines, for the most part.
While both of these tools can be built such that they are limited to a
particular set of MIME types, 'generic' (oops) engines and agents also make
sense, in part because things like namespaces allow document authors to do
things like embed information of one type inside of a document that is
ostensibly of another type.  XHTML, for example, seems like a likely
container for XML islands of all kinds, and I suspect we'll see other such
container formats arriving.  Even formats that aren't 'containers' per se
may have lots of such mixed content, and agents and search engines should
at least be aware that these formats are searchable, and not compressed
binaries or other non-XML information.

The second case isn't automated, but it presents as many problems.  User
intervention in MIME types is always a pain in the neck, something most
users aren't fond of.  I'll give a new case that may be more relevant than
the usual "my browser doesn't do Shockwave".  

Suppose 'HotSync' information for a PDA - say an address book - is stored
in XML.  Not everyone's software uses an identical XML format, since people
are irritating that way and I haven't seen any move to standardize.  I'd
like to download an address book in the wrong format to my PDA, which has
an option for importing from XML. (I have to do a little manual
identification work, but that's all right.)  Normally, though, my PDA
doesn't like getting files it doesn't understand, a reasonable approach
given its limited storage capacity.  Am I going to have to go through the
'ok, download it, I know it's a weird MIME type' routine every time I want
to download an address book in a different format?  Multiply by several
million users and support costs, and the need to identify XML documents as
XML in some way becomes significant.

At 10:21 AM 5/8/99 -0700, Ned Freed wrote:
>Um, well, actually, in many cases the MIME type is very relevant and is
used to
>get the data delivered to the right place. While it may be nice to imagine a
>world where there's a separate XML-level dispatch process, such a process
>doesn't exist in any product I'm aware of and I don't see any moves
underway to
>add it.

MDSAX (see http://www.jxml.com) does provide a document router that you can
use to build such processes, but you'll definitely get exceptions if you
feed it non-XML information.  Working around that is not that difficult,
but in the general case you're right - I see no movement in that direction
yet.  This would work fine in cases where you had to figure what
application/xml meant after you got it, but doesn't do anything for the
negotiated cases described above.

At 01:12 AM 5/8/99 -0700, Larry Masinter wrote:
>I don't believe that "xml" fits into the guidelines for new
>top level types, which seem to rest, not on the argument about
>"default processing" but rather "device/gateway filtering".
>At least notionally, the distinction was between text/ image/
>audio/ video/ and (now) model/, with "application/" being the
>catch-all for everything else. I think "xml" is, for the
>most part, "application/".

Maybe it's time for some new thinking, acknowledging that MIME types are
generic type identifiers rather than clinging to their historical roots.
Using 'xml' in the mix - top level identifier or somewhere else - is a
change, but it's a change that enables a heck of a lot of tools, despite
the constant dismissals.  I realize that may be difficult to take, but I
think users will thank us in the long run for dealing with this now rather
than waiting for the traffic jam to develop.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

From: John Cowan <[email-masked]>
Subject: Re: Application-specific media types
To: [email-masked] (Larry Masinter)
Date: Sat, 8 May 1999 14:29:48 -0400 (EDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Larry Masinter scripsit:

> Wouldn't application/xhtml be more appropriate? I know we've had
> text/html in the past, but that was in a fit of fantasy that
> someone could actually _read_ HTML as if it were text.

Well, I suppose it depends on the HTML; all of mine seems perfectly
readable to me, as I handcraft it that way (not with any great
effort; I simply use a plain text editor or else XED).

-- 
John Cowan					[email-masked]
		e'osai ko sarji la lojban.

Date: Sat, 08 May 1999 10:21:04 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: Top-level media type xml desirable?  (WAS: RE: Parameters for top-level XML media types?)
To: Larry Masinter <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, [email-masked]
Sender: [email-masked]

> > It isn't clear to me whether your opposition is to the creation of new
> > top-level media types period, or just to xml/.

> I'm opposed to creating more top-level media types than are necessary,
> or to adding more parameters and other doodads than are necessary,
> where I define 'necessary' as 'having a compelling application TODAY'.

> So far, I've seen some good arguments for text/xml, application/xml,
> a few calendaring applications and (possibly, if the issues about
> subsets and compositions are elaborated), text/xhtml.

If registration activity is any indication, there are a lot more XML-derived
things out there that need their own media types than this.

However, I agree that not everything does, so our disagreement, such as it is,
seems to be more a matter of degree than anything else.

> But I don't see any reason for creating new media types otherwise,
> until they're needed. For the most part, applications can use
> text/xml, application/xml, or even application/octet-stream, since
> the MIME type is irrelevant.

Um, well, actually, in many cases the MIME type is very relevant and is used to
get the data delivered to the right place. While it may be nice to imagine a
world where there's a separate XML-level dispatch process, such a process
doesn't exist in any product I'm aware of and I don't see any moves underway to
add it.

> I don't believe that "xml" fits into the guidelines for new
> top level types, which seem to rest, not on the argument about
> "default processing" but rather "device/gateway filtering".

I've been thinking about this a lot of late, and I'm afraid that while I was
largely neutral about a new top-level type before, I have to agree with Larry
on this point.

In particular, XML seems to me to cut across existing top-level media types --
an XML object can be a document or some other form of application data, a
model, an image, a means of storing audio data, or even some sort of message or
multipart object.

Mind you, I'm not saying that XML objects will eventually end up being
registered under every existing top-level type -- registration under multipart
is certainly unlikely at a minimum -- but registration under several top level
types seems certain.

> At least notionally, the distinction was between text/ image/
> audio/ video/ and (now) model/, with "application/" being the
> catch-all for everything else. I think "xml" is, for the
> most part, "application/".

For the most part, perhaps, but not always. I see a bright future for XML
under model at a minimum, and likely under image and audio as well.

As for XML appearing as a distinguished registration tree "xml.", the current
purpose of differing registration trees is for when someone other than IANA
wants to do the registration or when the rules for registration are
significantly different from existing trees.

But neither of these seem to apply here. W2C is the logical candidate for an
alternate registration authority, but they don't seem interested in doing XML
registration (according to previous messages on this list at least). And I see
nothing about XML that calls for significantly different rules.

And remember that the IETF isn't likely to register the XML types it defines
in an "xml." tree. They'll prefer the unfaceted IETF tree. So the separate
tree would almost certainly fail to capture all XML, making it useless for
spotting all XML-based objects.

				Ned

Date: Sat, 08 May 1999 09:57:02 -0700
To: "Larry Masinter" <[email-masked]>, "Simon St.Laurent" <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Top-level media type xml desirable?  (WAS: RE: Parameters for  top-level XML media types?)
Sender: [email-masked]

At 01:12 AM 5/8/99 -0700, Larry Masinter wrote:
>I'm opposed to creating more top-level media types than are necessary,
>or to adding more parameters and other doodads than are necessary,
>where I define 'necessary' as 'having a compelling application TODAY'.

I agree with Larry here.

>I don't believe that "xml" fits into the guidelines for new
>top level types, which seem to rest, not on the argument about
>"default processing" but rather "device/gateway filtering".
>At least notionally, the distinction was between text/ image/
>audio/ video/ and (now) model/, with "application/" being the
>catch-all for everything else. I think "xml" is, for the
>most part, "application/".

It sure seems to be. It is an application that can be processed by multiple 
processors.

Let me turn around the "desirable?" question. In many ways, I think it 
would be better for the XML  world to *not* have a top-level "xml" type. 
Take a look at the situation today, which will probably be the same a year 
and five years from now:

1) You have a MIME-receiving agent (mail agent, HTTP client, etc.). That 
agent knows how to dispatch based on MIME information. It knows how to 
dispatch to programs. These dipatched-to programs might display the content 
directly, or might make a decision and launch a different display program.
2) You have a generic XML-display program (XMLShow) and some programs for 
displaying particular XML types (DisplayEDI, DisplayCal, and so on).
3) Someone invents a new XML type (XMLFoo) and a special display program 
(DisplayFoo).

At the point that step (3) happens and you receive a message with that 
content type, you want your agent in (1) to do The Right Thing, which is to 
launch DisplayFoo or, if you don't have a copy of DisplayFoo, to launch 
XLMShow.

If all XML items come in with MIME types of "xml/foo", then someone needs 
to tweak the settings in your client to know about DisplayFoo. If all your 
XML items come in with the type "application/xml", then someone needs to 
tweak the settings in the dispatched-to program to know about DisplayFoo.

I believe that "tweak the dispatched-to program" is a much better 
environment than "tweak all the MIME-receiving clients" for many reasons:
- If you have more than one MIME-receiving client, the user tweaks fewer 
settings.
- There is no need to register every sub-type: XMLShow can decide to launch 
based on the content of the XML, such as from the DTD or XML namespaces 
used. This speeds up adoption of new XML types.
- If "application/xml" automatically launches XMLShow, it is XMLShow that 
can be told about the "smarter" applications like DisplayFoo, and it might 
be able to cooperate with them in many ways. For instance, DisplayFoo might 
be able to ask XMLShow to render parts of a document while DisplayFoo 
renders other parts.
- XMLShow will be able to open a file off of disk (with no MIME 
information) and still be able to hand off the file to DisplayFoo. The 
MIME-receiving clients can never do this.
- Given today's MIME-receiving clients, it is more likely that XMLShow will 
be more flexible about adding new DisplayFoo viewers than the 
MIME-receiving clients are.

In summary, I believe that specialized XML viewers are better off in an 
environment where they are launched by the thing that "application/XML" 
launches, not by their own MIME sub-types.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Larry Masinter" <[email-masked]>
To: "Rick Jelliffe" <[email-masked]>, <[email-masked]>
Subject: RE: Application-specific media types
Date: Sat, 8 May 1999 08:49:52 PDT
Importance: Normal
Sender: [email-masked]

> This is why I think and "xml." prefix (which would probably require an 
> XML registration tree) and some simple automated registration process (so 
> that people can have instant access to a name) is the most workable 
> solution: it seems to fit into MIME specs, works with existing 
> technology, and provides a nice convention for conveying its meaning to 
> humans.  (People can still register XML media types under IETF, 
> experimetal or vendor trees, so a registration tree just adds convenience.)

I could support this, but I think that the process should
encourage the same kinds of considerations for XML types
as it does for media types in the "vnd" tree. It's very easy
for programmers and developers to forget about the simple
security considerations for receiving content that might
cause the recipient to make permanent and damaging
changes to the recipient's environment. 

"This media type will only be generated by my own application"
is the typical thoughtless reaction. But this is
the stuff that viruses are made out of. 

The problems exist with some extensions to existing media
types, too (for example, several trojan attacks were launched
using javascript extensions to html), but at least having
the considerations apply at type definition might encourage
_some_ thought.

In the privacy of your own application, you can do whatever
you want. It's only when you intend to send some data to
another recipient using a different or separate application
that you need a MIME type at all, and that's the time when
the MIME type considerations (security considerations, being
explicit about optional & required parameters) need to be
asked.

Larry
-- 
http://www.parc.xerox.com/masinter

Date: Sat, 8 May 1999 15:29:18 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: [email-masked]
Subject: Re: Application-specific media types
Sender: [email-masked]

On Fri, 7 May 1999, Shane P. McCarron wrote:

> So, my question for you all is, would anyone here object to the creation
> of an application specific media type text/xhtml, registered by the W3C,
> that would be used to announce resources that are within the XHTML
> family (as that is defined by the W3C)?

Well, without arguing on merits or needs, like I said, I think the form 
needs to be manageble: so application/xml.html (using an XML registration 
tree or an xml subtyping mechanism) would a much preferable form. 

We should create a media-type name framework in which it is easy for any 
existing format to have an XML version (e.g. application/xml.vrml), and 
for any ordinary user to be able to read the media type and figure out 
what is going on.  The trouble with application/xhtml is that is 
disguises what is going on: users may think it means experimental HTML, 
or they may miss that it is HTML att all.

When a browser does not have a handler registered for a media type, it 
asks the users. This gives moderately sophisiticated users the chance to 
try some other application: they need to be able to look at the media 
type name and make some sense of it.  So  application/xml.html is better than
application/xhtml, and application/xml.vrml is better than 
application/vrxml or application/xvrml (and I think model/xml.vrml is 
better than both those).

This is why I think and "xml." prefix (which would probably require an 
XML registration tree) and some simple automated registration process (so 
that people can have instant access to a name) is the most workable 
solution: it seems to fit into MIME specs, works with existing 
technology, and provides a nice convention for conveying its meaning to 
humans.  (People can still register XML media types under IETF, 
experimetal or vendor trees, so a registration tree just adds convenience.)

Rick Jelliffe

From: "Larry Masinter" <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>, <[email-masked]>
Subject: RE: Top-level media type xml desirable?  (WAS: RE: Parameters for  top-level XML media types?)
Date: Sat, 8 May 1999 01:12:43 PDT
Importance: Normal
Sender: [email-masked]

> It isn't clear to me whether your opposition is to the creation of new
> top-level media types period, or just to xml/.

I'm opposed to creating more top-level media types than are necessary,
or to adding more parameters and other doodads than are necessary,
where I define 'necessary' as 'having a compelling application TODAY'.

So far, I've seen some good arguments for text/xml, application/xml,
a few calendaring applications and (possibly, if the issues about
subsets and compositions are elaborated), text/xhtml.

But I don't see any reason for creating new media types otherwise,
until they're needed. For the most part, applications can use
text/xml, application/xml, or even application/octet-stream, since
the MIME type is irrelevant.

I don't believe that "xml" fits into the guidelines for new
top level types, which seem to rest, not on the argument about
"default processing" but rather "device/gateway filtering".
At least notionally, the distinction was between text/ image/
audio/ video/ and (now) model/, with "application/" being the
catch-all for everything else. I think "xml" is, for the
most part, "application/".

Larry

From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Application-specific media types
Date: Sat, 8 May 1999 00:33:46 PDT
Importance: Normal
Sender: [email-masked]

> Within the media type text/xhtml, I expect that the W3C will define
> additional parameters that can help user agents interpret the contents
> of the resource more readily from the envelope. However, as with
> text/html, that is the W3C's problem to deal with. 

The optional and required parameters need to be specified when
the media type is registered.

Wouldn't application/xhtml be more appropriate? I know we've had
text/html in the past, but that was in a fit of fantasy that
someone could actually _read_ HTML as if it were text.

Larry

From: "Scott Lawrence" <[email-masked]>
To: <[email-masked]>
Subject: RE: Top-level media type xml desirable?  (WAS: RE: Parameters for top-level XML media types?)
Date: Fri, 7 May 1999 15:24:12 -0400
Importance: Normal
Sender: [email-masked]

> From: Langer, Paul

> We will destroy the portability of XML, if media types like
> xml/my-application are allowed; as soon as something can be labeled as
> e.g. xml/hugo the owner of application hugo will feel free to add
> hugo-specific features to XML.

I find this statement a bit puzzling; the X in XML is from 'eXtensible'.
The _goal_ of XML is to be the 'mother tongue' from which new
application-specific languages evolve.

I think that this is really at the heart of the question of whether or not
xml/ is an appropriate media type, and think that it is not a particularly
useful one.  The interesting and useful attribute of an XML-derived language
is not that it is derived from XML; it's in whatever application domain it
serves.  The MIME registration of any application type that employs XML as
its expression/definition mechanism will say so - I don't see any particular
value in making that a part of the hierarchy of its name.  ASN.1 is used for
a great many different things (too many :-), but we don't expect them all to
interoperate or even to be interested in interoperating.

--
Scott Lawrence           Director of R & D        <[email-masked]>
Agranat Systems, Inc.  Embedded Web Technology   http://www.agranat.com/

Date: Fri, 7 May 1999 12:26:10 -0700 (PDT)
From: Murray Altheim <[email-masked]>
Reply-To: Murray Altheim <[email-masked]>
Subject: Re: Application-specific media types
To: [email-masked], [email-masked]
Content-MD5: snfel3+W/zQCkBD2bujylQ==
Sender: [email-masked]

Shane P. McCarron <[email-masked]> writes:
> 
> [In this message I am trying a new tactic here to speed up
> deliberations. -spm]
[...]
> Instead of having that philosophical discussion, maybe we could short
> this to ground. Some members of the HTML Working Group would like to
> define a new media type text/xhtml rather than relying upon text/xml or
> text/html.  The basic reasons for this are:
[...]

For the record, there are also members of the HTML WG who have expressed
a strong protest to creation of a new media type text/xhtml. Sun 
Microsystems has repeatedly been among these members, with the reasons
previously explained in detail within the WG archives.

> So, my question for you all is, would anyone here object to the creation
> of an application specific media type text/xhtml, registered by the W3C,
> that would be used to announce resources that are within the XHTML
> family (as that is defined by the W3C)?

I unfortunately today cannot spend much time on this reply as I must
soon leave the office. The biggest problem I see is that while XHTML 
may be a special class of application, there needs to be some means
of content or 'feature' negotiation that provides specific information
about the document type. If this solution is successful, there will
be no need for a new media type, and such a single-use solution will
keep XHTML off in its own landscape rather than integrated into a more
general XML solution. Perhaps that is what some vendors want, especially
those that benefit from HTML continuing within its proprietary universe.
I think it a big mistake.

If the HTML WG is successful in defining 'document type profiles', there
will be little need for a new media type.

Murray

...........................................................................
Murray Altheim, SGML Grease Monkey         <mailto:altheim&#64;eng.sun.com>
Member of Technical Staff, Tools Development & Support
Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900

              An SGML declaration does not an i18n make.

Date: Fri, 07 May 1999 14:15:58 -0500
From: "Shane P. McCarron" <[email-masked]>
Reply-To: [email-masked]
Organization: MACS, Inc.
To: [email-masked]
Subject: Application-specific media types
Sender: [email-masked]

[In this message I am trying a new tactic here to speed up
deliberations. -spm]

I have previously advocated the use of application specific media types
for certain classes of applications.  To restate my bias for the record:
I believe that HTML is a special class of application now and into the
foreseeable future, and as such needs to be handled specially by user
agents.

Now, how does that fit into the world in which there is an xml/ class of
media?  Well, it can readily.  I don't personally care whether there is
a class of xml/*, text/xml.*, or any other variation you might think
of.  I don't think that is worth debating that this point. Rather, I
think that the issue is whether specific applications can control their
own namespace within the media type set, or whether they need to work
within a single family of media types that is centrally regulated.

Instead of having that philosophical discussion, maybe we could short
this to ground. Some members of the HTML Working Group would like to
define a new media type text/xhtml rather than relying upon text/xml or
text/html.  The basic reasons for this are:

Ease of identifying content by user agents.
Special semantics of markup that cannot be expressed in any schema.
Historical precedent.
Management and evolution of the media type namespace by the responsible
body.

Within the media type text/xhtml, I expect that the W3C will define
additional parameters that can help user agents interpret the contents
of the resource more readily from the envelope. However, as with
text/html, that is the W3C's problem to deal with. 

Also, with regard to text/html, and before anyone asks - the reason we
cannot use that easily is because there is too much baggage associated
with it, and too many broken documents out there.  We need a new,
distinct media type to make a clean break with the past.  XHTML(tm) is a
new XML application that is similar to HTML, but that is extensible, and
whose documents are guaranteed to be well formed and valid.  User agents
can operate much more sensible in the presence of such documents than
they can in the presence of the mess that is HTML today.

The reason I am here talking with you all is that the W3C has determined
that, as this is a bigger problem than the general XHTML case, we should
all work together to develop a generic solution.

I have no problem with that in theory, but I also don't have years to
wait for us to define the perfect philosophical answer.

So, my question for you all is, would anyone here object to the creation
of an application specific media type text/xhtml, registered by the W3C,
that would be used to announce resources that are within the XHTML
family (as that is defined by the W3C)?

And, assuming there are objections, what are they specifically?

Maybe if we work from this concrete case we will make more rapid
progress toward consensus.
--
Shane P. McCarron                              phone: +1 612 434-4431
Testing Research Manager                         fax: +1 612 434-4318
                                              mobile: +1 612 799-6942
                                              e-mail: [email-masked]

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.

Date: Fri, 07 May 1999 14:48:37 -0400
To: <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: RE: Top-level media type xml desirable?  (WAS: RE: Parameters for  top-level XML media types?)
Sender: [email-masked]

At 11:27 AM 5/7/99 -0700, Larry Masinter wrote:
>Different applications will need different categorizations of information,
>and attempts to put too many application-specific parameters into the
>MIME type will result in granularities of descriptions that may support
>some applications and interfere with others.

I'd appreciate an explanation of why a top-level xml type would interfere
with applications.  Perhaps some were built with no fallback capabilities
for unknown types at all - is that your concern?  Or is it that
applications might not recognize that application/x-myml and xml/x-myxml
could be the same thing?

It isn't clear to me whether your opposition is to the creation of new
top-level media types period, or just to xml/.

>"... In that Empire, the craft of Cartography attained such Perfection
that the
>Map of a Single province covered the space of an entire City, and the Map
of the
>Empire itself an entire Province. In the course of Time, these Extensive maps
>were found somehow wanting, and so the College of Cartographers evolved a
Map of
>the Empire that was of the same Scale as the Empire and that coincided
with it
>point for point."

"When it was proclaimed that the Library contained all books, the first
impression was one of extravagant happiness.  All men felt themselves to be
the masters of an intact and secret treasure.  There was no personal or
world problem whose eloquent solution did not exist in some hexagon... but
the searchers did not remember that the possibility of a man's finding his
Vindication, or some treacherous variation thereof, can be computed as
zero."[1]

Cataloging and description is important. Borges was a librarian - I suspect
he'd agree.

[1] - From "The Library of Babel", in _Labyrinths_.  (James E. Irby,
translator.) Originally from _Ficciones_, 1956.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

From: "Larry Masinter" <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>, <[email-masked]>
Subject: RE: Top-level media type xml desirable?  (WAS: RE: Parameters for  top-level XML media types?)
Date: Fri, 7 May 1999 11:27:44 PDT
Importance: Normal
Sender: [email-masked]

> Larry Masinter wrote:
> >> "Provide the minimum information necessary for a recipient to be able
> >> to decide on an appropriate processor for an incoming message"
>
> Why does this bar the door to an XML top-level type?  What is so scary
> about this that you aren't interested in doing the job as well as possible
> rather than just saying "we've provided you with the least possible amount
> of information so that you still have to guess what this pile of junk is"?

Different applications will need different categorizations of information,
and attempts to put too many application-specific parameters into the
MIME type will result in granularities of descriptions that may support
some applications and interfere with others.

> If you're going to describe something, describing it halfway seems like a
> waste of time.

"... In that Empire, the craft of Cartography attained such Perfection that the
Map of a Single province covered the space of an entire City, and the Map of the
Empire itself an entire Province. In the course of Time, these Extensive maps
were found somehow wanting, and so the College of Cartographers evolved a Map of
the Empire that was of the same Scale as the Empire and that coincided with it
point for point."

---- From Travels of Praiseworthy Men (1658) by J.A. Suarez Miranda in Jorge
Luis Borges' 'Of Exactitude in Science' A Universal History of Infamy (1972)

Date: Fri, 07 May 1999 11:54:03 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Top-level media type xml desirable?  (WAS: RE: Parameters for  top-level XML media types?)
Sender: [email-masked]

At 10:16 AM 5/7/99 -0500, Shane P. McCarron wrote:
Within an agent, once the basic container has been
>determined, the agent will examine the contents further to figure out
>how to process the content.  Part of this is parsing the XML data
>stream. While an agent might have a single XML parser, it might not. 
>And it doesn't matter.  Agents need to know a lot more than we could or
>should put in a mime type in order to faithfully reflect the intent of
>the content author.  

But why is it such a problem to provide the agent with as much information
as possible?  If the agent knows that the basic content type is XML, it
knows that it's safe to poke at it with an XML processor.  If the agent
knows what kind of XML it's looking at, it can pick and choose which files
it wants on that basis if that behavior is appropriate.  At least we'd be
giving the agent as much information as possible within the constraints of
MIME rather than punting and requiring it to search through _everything_ to
find what it wants.

I don't see this as a case where 'less is more'.  I still like Rick's
proposal.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Fri, 07 May 1999 11:50:06 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Top-level media type xml desirable?  (WAS: RE: Parameters for  top-level XML media types?)
Sender: [email-masked]

Larry Masinter wrote:
>> "Provide the minimum information necessary for a recipient to be able
>> to decide on an appropriate processor for an incoming message"

Why does this bar the door to an XML top-level type?  What is so scary
about this that you aren't interested in doing the job as well as possible
rather than just saying "we've provided you with the least possible amount
of information so that you still have to guess what this pile of junk is"?

If you're going to describe something, describing it halfway seems like a
waste of time.  If this is really the approach that MIME is required to
take, it may well be time to move on to something more robust.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Fri, 07 May 1999 10:16:26 -0500
From: "Shane P. McCarron" <[email-masked]>
Reply-To: [email-masked]
Organization: MACS, Inc.
To: Larry Masinter <[email-masked]>
CC: "Langer, Paul" <[email-masked]>, "'Simon St.Laurent'" <[email-masked]>, [email-masked]
Subject: Re: Top-level media type xml desirable?  (WAS: RE: Parameters for  top-level XML media types?)
Sender: [email-masked]

Larry Masinter wrote:
> 
> > > [snip]
> > > I think maybe we should go back to a very simple question:
> > > what are MIME types for?
> > > I thought at one point that they were to describe file types.
> > > If that is indeed the case, it might be a good idea to describe file types
> > as
> > > accurately and completely as possible.
> > > [snip]
> >
> > Agreed. But I think "describe file types as accurately and completely as
> > possible" should refer ONLY to the format of the content of the "file",
> > NOT to possible usages of that content.
> 
> Disagree. "as accurately and completely as possible" is not a goal.
> "Provide the minimum information necessary for a recipient to be able
> to decide on an appropriate processor for an incoming message". Web
> browsing was close enough to mail reading to use the same typing mechanism.
> 
> Different applications may require more specific information to
> decide on how to process other kinds of data, but that information
> should not be added to, or required to be supplied as part of, the
> MIME type.

I agree with this.  Within an agent, once the basic container has been
determined, the agent will examine the contents further to figure out
how to process the content.  Part of this is parsing the XML data
stream. While an agent might have a single XML parser, it might not. 
And it doesn't matter.  Agents need to know a lot more than we could or
should put in a mime type in order to faithfully reflect the intent of
the content author.  The HTML Working Group and the IETF Conneg groups
are both working on ways to reveal this additional information.  Let's
provide them with the basic tools to let them do their jobs.
--
Shane P. McCarron                              phone: +1 612 434-4431
Testing Research Manager                         fax: +1 612 434-4318
                                              mobile: +1 612 799-6942
                                              e-mail: [email-masked]

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.

From: "Larry Masinter" <[email-masked]>
To: "Langer, Paul" <[email-masked]>, "'Simon St.Laurent'" <[email-masked]>, <[email-masked]>
Subject: RE: Top-level media type xml desirable?  (WAS: RE: Parameters for top-level XML media types?)
Date: Fri, 7 May 1999 07:30:04 PDT
Importance: Normal
Sender: [email-masked]

> > [snip]
> > I think maybe we should go back to a very simple question: 
> > what are MIME types for? 
> > I thought at one point that they were to describe file types. 
> > If that is indeed the case, it might be a good idea to describe file types
> as
> > accurately and completely as possible.
> > [snip]
> 
> Agreed. But I think "describe file types as accurately and completely as
> possible" should refer ONLY to the format of the content of the "file",
> NOT to possible usages of that content.

Disagree. "as accurately and completely as possible" is not a goal.
"Provide the minimum information necessary for a recipient to be able
to decide on an appropriate processor for an incoming message". Web
browsing was close enough to mail reading to use the same typing mechanism.

Different applications may require more specific information to
decide on how to process other kinds of data, but that information
should not be added to, or required to be supplied as part of, the
MIME type.

Date: Fri, 07 May 1999 10:24:53 -0400
To: <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Perhaps we need an XML registration tree (was Re: Parameters for top-level XML media types?)
Sender: [email-masked]

At 06:03 PM 5/7/99 +0800, Rick Jelliffe wrote:
>To make matters more concrete, here is a draft RFC.

Rick's concrete proposal appears to satisfy all my concerns and then some.
I have no objection to multilayered MIME types - I've always wondered why
MIME was built with only two layers of description, though I suppose it
made sense at the time.  His proposal seems to have all the benefits of an
XML layer without the disruption of xml/x-*.

At 02:51 PM 5/7/99 +0900, MURATA Makoto wrote:
>However, there should be a procedure for reopening previous agreements.  
>If a *new* argument is raised and many people agree to reopen this 
>issue, I think we should reopen it.  You might want to read the 
>ENTIRE archive of this ML, write a proposal to reopen this issue, and ask 
>people whether they support your proposal or not.

Sounds good.  We'll see how Rick's proposal goes over.  If I suspect the
discussion is headed down the path to ruin, I'll take my previous arguments
and supplement them with new material in a more formal presentation and
request that these issues be reconsidered.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

From: "Rick Jelliffe" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: Re: Perhaps we need an XML registration tree (was Re: Parameters for top-level XML media types?)
Date: Fri, 7 May 1999 18:03:43 +0800
Sender: [email-masked]

To make matters more concrete, here is a draft RFC.

Actually, I have found it a little hard to work out from the RFCs whether
the "xml." goes on the content type (left) or the subtype (right). I am
assuming that it goes on the right.

If registration trees go on the left, then my fallback suggestion is that
the XML RFC also allow subtyping of  application/xml under some
registration authority. This accomplishes exactly the same thing, with
the same syntax.

Rick

-----<snip>

Network Working Group
Rick Jelliffe
Request for Comments: nnnn                 Academia Sinica Computing Centre
Obsoletes:
May 1999
Category: Internet Best Current Practices

                      MIME Registration Tree for XML

Status of this Memo

   This draft provides information on a MIME registration tree for XML.
   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Abstract

RFC 2048 [1] provides for the registration of Additional Registration
Tree (s2.1.5). This RFC specifies procedures and scope for a registration
tree for XML [3] documents to augment  RFC nnn [4]
The proposed mechanism is an automated registration system for
XML-based MIME media types under an "xml." registration tree.

Table of Contents

 ...

1.  Introduction

        XML [] is a subset of SGML [] optimized for distributing
        certain kinds of documents over the WWW. RFC nnn [] gives
        the MIME Media Types which can be used for generic, browsable
        XML documents: text/xml and application/xml.

        A generic, browsable XML document contains enough markup inside
        it for a generic XML browser to use that document: in particular
        this means stylesheet information.

        However, XML will also be used to create large numbers of
        application-specific document types. Documents of these
        types are XML, but they require specific MIME media types.

        Because of the large numbers of these document types,
        it is feared that they either will swamp the IETF registration
        process or, more likely, that their creators will simply
        not follow Best Internet Practise and create media types for
        these types, willy nilly.

        Furthermore, because RFC nnn [] exists, the registration of
        an application-specific document type under the IETF tree will
        not provide much, if any, additional information. It is
        onerous to the registrees, time-wasting for IANA, and uninformative
        for readers.

2. Registration Tree

The registration tree has the prefix "xml".

For example, the MIME media type for the "Question and
Answer Markup Language", QAML, would be  text/xml.qaml
and application/xml.qaml.

All document types registered under the XML tree have both
text/xml.* adn application/xml.* media types. Any parameters defined in RFCs
for generic XML MIME media types [] also may be used.

If the document type describes some kind of literature,
for example from a word processor, the recommended
content type is text/xml.*

Otherwise the media type should be application/xml.*
In accordence with RFC 2046[] (s1), image/xml.*
and the other top-level content types should not be used.

2. Automated Registration

The XML registration tree is an automated process.

People or organizations seeking to register an application-specific
XML document under this tree submit, using an online form, a subset of the
information required by IANA for IETF-tree registration [1]: including
- registree name and contact details,
- the requested MIME content-type identifier,
- URL of the DTD or schema giving the document's structures and purpose,
- URI of the document's namespace,
- URL for user documentation of that document type.

The automated process checks if the media type has been registered. If
it is available, the media type is registered, and the requester notified
by email. If it is already allocated, the requester is instead notified
of the contact address of the person of organization who has already
registered that content-type; the requestor can then negotiate directly
with them.

3. Management

   XML is a trademark of the World Wide Web Consortium (W3C).

   Management of the XML registration tree is to be performed by
   a person or organization (the "registrar") to be agreed by
   IETF and W3C.

   The registrar will make available lists of registered
   types in the XML registration tree over Internet and to
   IANA, W3C and ISO SC34.

   There is no provision for handling different versions of
   application-specific document types at the MIME level.
   Versions must be signified inside the XML document, signified
   by markup or by fixed attributes in the DTD; applications
   should be designed to handle version variants gracefully.

4.  Security Considerations

   This RFC raises no security issues beyond those given in [],
   as far as document types registered under the "xml." tree.

   For security of the automation process, automatic registrations
   should be periodically checked at the discretion of the
   registrar. Bogus registrations should be removed, and the
   registree notified. A bogus registration includes the registration
   of a MIME type for document type which does not exist, or which
   has not been adequately described by a DTD or other schema, or
   which has been registered by some body for the purposes of hijacking
   an established or new technology.

5.  References

   [1] Freed, N., Klensin, J., Postel, J.,
   "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration
Procedures"
   RFC 2048, November 1996

   [1] Freed, N., Borenstein, N.
   "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"
   RFC 2046, November 1996

   [2] Bray, et al "XML 1.0 Specification",...

   [3] Whitehead, J., and Mutata, M., "MIME Media Types for XML",
   RFC nnn, xxx, October 1998.

   [4] IS 8879:1986 (ammended 1998) "Information Technology --
   Standard Generalized Markup Language", ISO SC34

6.  Author's Address

   Rick Jelliffe
   Computing Centre, Academia Sinica
   P.O. Box 1-8, Nankang
   Taipei 11529,
   Taiwan, ROC

   Phone: +8862-2-2789-9380
   Fax:   +8862-2-2783-6444
   EMail: [email-masked]

From: MURATA Makoto <[email-masked]>
Date: Fri, 07 May 1999 16:58:18 +0900
To: <[email-masked]>
Subject: Re: Perhaps we need an XML registration tree (was Re: Parameters for top-level XML media types?)
Sender: [email-masked]

Rick Jelliffe wrote:
> 
> I thought participants have agreed that

Thank you for nice summary and clarifying my intention.  I appreciate it.

Rick Jelliffe wrote:
> Perhaps what is needed is an XML MIME registration tree, rather than a new
> type.

This is a new and interesting idea.  I look forward to comments from MIME 
experts on this mailing list.

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: "Rick Jelliffe" <[email-masked]>
To: <[email-masked]>
Subject: Perhaps we need an XML registration tree (was Re: Parameters for top-level XML media types?)
Date: Fri, 7 May 1999 15:29:43 +0800
Sender: [email-masked]

 From: MURATA Makoto <[email-masked]>

> There *is* an agreement that generic XML processors cannot do anything
useful.
> I would like to make sure that we go forward (not backward).  I also would
> like to make sure that people's time and effort are well spent.  Thus, I
do
> not want to reopen this issue.

I think Murata-san means "(fallback to) generic processors (on
application-specific
documents) cannot do anything useful", rather than that text/xml and
application/xml are useless, which is what Simon seems to think he means.

I thought participants have agreed that

* there are generic XML documents which contain enough information in them
to be useful (e.g. with a stylesheet), and that these can use text/xml or
application/xml;

* there are application-specific XML documents which need their own MIME
type: e.g., application/*;

* fallback from application-specific XML to generic XML and from generic XML
to text has not been proved to be particularly useful, except for debugging;

* MIME parameters are not particularly useful at the current state of
technology (they may be useful for negotiation during requests, but the
current and new generation of browsers don't use them for dispatching
received documents);

* people are seem open to change there minds if there are convincing cases
shown and if technology changes.

Finally, I cannot see why people are scared of having a million new XML MIME
types under application/* or audio/*; or the other places.

Perhaps what is needed is an XML MIME registration tree, rather than a new
type.

Perhaps it could even be an automated system: you send the desired MIME
content-type and a minimal RFC to describe it (e.g., the DTD), and the
system allocates and confirms MIME content-type, under the XML registration
tree. That would be better than x- (no name collisions) and easier than
getting a content-type registered under the IETF registration tree (because
using XML answers some of the mandated questions about encodings, and
because the types would be allocated on demand; a subsequent administrative
review would disallow bogus requests).

I don't think that new XML-based media types whould require the same
scrutiny or comment as text/xml and application/xml; they are just
subclasses of them. IETF has a good role to play for text/xml and
application/xml comments, for the XML class of documents. But having
established that text/xml and application/xml are OK, I think creators of
XML document types shouldn't have to duplicate the effort involved in
getting an IETF MIME type registered (that effort is small and efficient,
but as Murata-san has found out, is not nothing).

This would give, for example,   application/xml.ddml  , which is useable by
existing browsers, and allows a program to fall back to generic XML (if it
knows that all application/xml.* documents are also application/xml).
(Refer  http://www.freenic.net/rfcs/rfc2000/rfc2048.txt)

Rick Jelliffe

To: "'Simon St.Laurent'" <[email-masked]>, [email-masked]
Subject: Top-level media type xml desirable?  (WAS: RE: Parameters for top -level XML media types?)
Date: Fri, 7 May 1999 09:14:48 +0200 
From: "Langer, Paul" <[email-masked]>
Sender: [email-masked]

at Friday, May 07, 1999 4:35 AM Simon St.Laurent wrote:

> [snip]
> I think maybe we should go back to a very simple question: 
> what are MIME types for? 
> I thought at one point that they were to describe file types. 
> If that is indeed the case, it might be a good idea to describe file types
as
> accurately and completely as possible.
> [snip]

Agreed. But I think "describe file types as accurately and completely as
possible" should refer ONLY to the format of the content of the "file",
NOT to possible usages of that content.

We will destroy the portability of XML, if media types like
xml/my-application are allowed; as soon as something can be labeled as
e.g. xml/hugo the owner of application hugo will feel free to add
hugo-specific
features to XML.

I still think that a top-level media type "xml" with application-specific
subtypes is an attempt to solve the open schema issues at a wrong place.

All the best,
Paul

-----------------------------------------------------------
Paul Langer                           [email-masked]
Software AG                           Tel. +49-6151-92-1912
Uhlandstr. 12                         Fax  +49-6151-92-1613
D-64297 Darmstadt 

From: MURATA Makoto <[email-masked]>
Date: Fri, 07 May 1999 14:51:27 +0900
To: <[email-masked]>
Subject: Re: Parameters for top-level XML media types?
Sender: [email-masked]

Simon St.Laurent wrote:
> 
> I'll wait for the official response on "generic XML applications" are
> useful before throwing out any more 'realistic' examples, or arguing this
> particular point any further.

There *is* an agreement that generic XML processors cannot do anything useful.  
I would like to make sure that we go forward (not backward).  I also would 
like to make sure that people's time and effort are well spent.  Thus, I do 
not want to reopen this issue.

However, there should be a procedure for reopening previous agreements.  
If a *new* argument is raised and many people agree to reopen this 
issue, I think we should reopen it.  You might want to read the 
ENTIRE archive of this ML, write a proposal to reopen this issue, and ask 
people whether they support your proposal or not.

I apologize if I sound like a chair (I am merely a co-author of RFC2376).  
I am just suggesting the above procedure to participants of this mailing list,
hoping that it facilitates discussion and progress.

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Fri, 07 May 1999 00:47:12 -0400
To: <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Parameters for top-level XML media types?
Sender: [email-masked]

At 12:16 PM 5/7/99 +0900, MURATA Makoto wrote:
>Simon St.Laurent wrote:
>> Generic XML search engines are indeed a possibiliy.  Generic XML browsers
>> already exist.  Generic XML editors are arriving as well.  If they aren't
>> useful, that's really quite unfortunate.
>
>Are you talking about generic XML as documents as opposed to 
>generic XML as data?  I do not think generic XML editors are useful for 
>XML data for RPC.

It depends on what kind of approach you take.  If you use a single
vocabulary for RPC (like XML-RPC, or something built on IBM's BeanML)
you're generally correct.  If you take a much more general approach
(something like JXML's MDSAX package for program composition from XML
documents) then many of the same possibilities for processing generic XML
data open up that already existed for documents.

I'd be willing to discuss the more general approach in much greater detail
if it seems appropriate.  For a _very_ rough picture, you can see the later
slides in the presentation I've posted at:
     http://www.simonstl.com/articles/nycod/index.htm

>We have agreed on another thing.  You are arguing top-level media type for 
>document-like XML documents.  Right?
>
>MURATA Makoto wrote:
>> 
>> 	4. Document-like XML documents can be handled by general-purpose 
>> 	   XML viewers

I'm arguing top-level media type for document-like XML documents and also
for XML documents in general.  There is no separation between XML for
documents and XML for data - both are possible, both can be mixed, both
approaches can indeed appear within a single 'document'.  Describing the
two as different things is useful in some contexts but not always accurate.  

I remain willing to support your 'agreement' number 4 but opposed to #3.
After searching the archives, I find that I joined the list 4/13, while the
agreements were posted on 4/11.  Makes life difficult, I suppose.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

From: MURATA Makoto <[email-masked]>
Date: Fri, 07 May 1999 12:16:02 +0900
To: <[email-masked]>
Subject: Re: Parameters for top-level XML media types?
Sender: [email-masked]

Simon St.Laurent wrote:
> Generic XML search engines are indeed a possibiliy.  Generic XML browsers
> already exist.  Generic XML editors are arriving as well.  If they aren't
> useful, that's really quite unfortunate.

Are you talking about generic XML as documents as opposed to 
generic XML as data?  I do not think generic XML editors are useful for 
XML data for RPC.

We have agreed on another thing.  You are arguing top-level media type for 
document-like XML documents.  Right?

MURATA Makoto wrote:
> 
> 	4. Document-like XML documents can be handled by general-purpose 
> 	   XML viewers

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Thu, 06 May 1999 22:34:30 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: RE: Parameters for top-level XML media types?
Sender: [email-masked]

At 06:48 PM 5/6/99 -0700, Paul Hoffman / IMC wrote:
>There are other ways of doing this without an XML top-level type. The 
>process in your MUA or other viewer that dispatches a document of a 
>particular type/subtype pair can be told to launch an XML viewer even if 
>neither the type or the subtype says "xml". In the case of 
>"text/x-xmlnews", if you don't have an "xmlnews" viewer, you can still tell 
>the MIME dispatcher to dispatch "text/x-xmlnews" to the XML parser.

Are these ways as efficient?  As intuitive?  As generally useful across
multiple cases?  I don't think so.  It's extra work that accomplishes very
little.  Using the xml top level type would accomplish all this and
accomodate multiple types of systems at the same time.

>Having a top-level "xml" type allows you to default all subtypes for which 
>there is not a known specialized viewer to the generic XML viewer, just 
>like the top-level "text" type can default to the text viewer. It has 
>generally been found in the text case not to be very useful for most 
>unrecognized text subtypes. In order for us to want to create an "xml" main 
>type, we'd have to be very sure that dispatching to a generic XML viewer is 
>useful, and is more useful than writing the object out to disk.

I think maybe we should go back to a very simple question: what are MIME
types for?

I thought at one point that they were to describe file types.  If that is
indeed the case, it might be a good idea to describe file types as
accurately and completely as possible.

I'll wait for the official response on "generic XML applications" are
useful before throwing out any more 'realistic' examples, or arguing this
particular point any further.  If I'm not allowed to suggest that generic
XML applications are useful, there isn't much point to this case at all,
and we may as well stick with a broken and underutilized system.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Thu, 06 May 1999 22:29:33 -0400
To: <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Parameters for top-level XML media types?
Sender: [email-masked]

At 11:05 AM 5/7/99 +0900, MURATA Makoto wrote:
>We have agreed that generic XML processors cannot do anything useful.
>
>In my mail "What we have agreed on" , I wrote:
>> 
>> 	3. Fallback to general-purpose XML applications is not useful.
>> 
>snip
>
>> If these are agreed on, we can eliminate some options and concentrate on 
>> the rest.
>> 
>> If you disagree with these four points, please speak up now.

Fine, then.  If you'd like to end the argument with "you should have spoken
up earlier", you're welcome to continue.

Unfortunately, 'Generic XML processors cannot do anything useful' is not true.

Generic XML search engines are indeed a possibiliy.  Generic XML browsers
already exist.  Generic XML editors are arriving as well.  If they aren't
useful, that's really quite unfortunate.

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

From: MURATA Makoto <[email-masked]>
Date: Fri, 07 May 1999 11:05:43 +0900
To: <[email-masked]>
Subject: Re: Parameters for top-level XML media types?
Sender: [email-masked]

Simon St.Laurent wrote:
>  XML documents have a double identity - they can be
> processed by generic XML processors and stored in generic repositories -
> and they also have specific content that may require a particular
> processor.  

We have agreed that generic XML processors cannot do anything useful.

In my mail "What we have agreed on" , I wrote:
> 
> 	3. Fallback to general-purpose XML applications is not useful.
> 
snip

> If these are agreed on, we can eliminate some options and concentrate on 
> the rest.
> 
> If you disagree with these four points, please speak up now.
> 
> Cheers,
> 
> Makoto
> 
> ----------------------------------------------------------
snip
> 3. Fallback to general-purpose XML applications is not useful.
> 
> "What's the XML parser going to do with this block of data? Display it? Not 
> terribly valuable. Get some namespace information from the inside and then 
> dispatch based on the namespace? Possibly valuable, but this begs the 
> question of why wasn't that information out in the MIME headers." (Paul)
> 
> "what experience has shown is that fallback
> strategies of *any* sort tend to be overrated. In almost every case something
> has messed it up. Either we got the granularity wrong (and I see a very good
> chance of this happening here given the emergence of alternative forms of XML),
> or it didn't prove to offer useful functionality, or it simply didn't deploy in
> the manner in which we envisioned. About the only success story we have,
> actually, are the image/audio/video top-level types, and while these have
> worked out tolerably well, their actual value to end users isn't that great." (Ned)
> 
> "Not even possible, in some cases. XML is being used for all sorts of
> things from serialising Java Beans to Web server configuration files to
> interprocess communication - a lot of these uses are not especially
> "displayable". In some cases, the fact that they are written in XML is
> the least important thing about them. These are likely to need
> specialised registrations, too.  Further, if the specification for any
> such case is not controlled by a single vendor, then registration in the
> vendor tree does not seem appropriate. This would be the case for
> situations ranging from a small vendor group (such as the Flashpix
> group) through groups such as W3C to bodies such as ISO, ITU, IEE and so
> on."  (Chris)
> 

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Thu, 06 May 1999 18:48:24 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Parameters for top-level XML media types?
Sender: [email-masked]

Simon St.Laurent makes the same argument in a few places, but I'll select 
the one near the end of his message.

>Creating a first-level xml space tells generic XML processors that they can
>do _something_ to the material contained in the file. Then the second level
>can provide a more specific description useful for processors that don't
>want to waste their time with the wrong XML information.

There are other ways of doing this without an XML top-level type. The 
process in your MUA or other viewer that dispatches a document of a 
particular type/subtype pair can be told to launch an XML viewer even if 
neither the type or the subtype says "xml". In the case of 
"text/x-xmlnews", if you don't have an "xmlnews" viewer, you can still tell 
the MIME dispatcher to dispatch "text/x-xmlnews" to the XML parser.

Having a top-level "xml" type allows you to default all subtypes for which 
there is not a known specialized viewer to the generic XML viewer, just 
like the top-level "text" type can default to the text viewer. It has 
generally been found in the text case not to be very useful for most 
unrecognized text subtypes. In order for us to want to create an "xml" main 
type, we'd have to be very sure that dispatching to a generic XML viewer is 
useful, and is more useful than writing the object out to disk.

Going back to Larry's challenge for real-world examples, I'd like to see a 
bunch of examples where launching the generic XML viewer is really useful. 
What value would I get out of that for many XML types?

--Paul Hoffman, Director
--Internet Mail Consortium

From: MURATA Makoto <[email-masked]>
Date: Fri, 07 May 1999 10:20:46 +0900
To: <[email-masked]>
Subject: Re: Parameters for top-level XML media types?
Sender: [email-masked]

Simon St.Laurent wrote:
> 
> No, we definitely haven't.  While I didn't support the case you made
> earlier for parameters, I still think a top-level media type of 'xml' would
> be extremely useful.  

Remember that another option is available.  I think that you are advocating 
the use of specialized media types but not arguing for the top-level media 
type "xml".

> 
> Solution 1. Specialized media types (possibly with some parameters)
> 

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: MURATA Makoto <[email-masked]>
Date: Fri, 07 May 1999 10:13:58 +0900
To: <[email-masked]>
Subject: Re: Parameters for top-level XML media types?
Sender: [email-masked]

Larry Masinter wrote:
> 
> 
> Makoto wrote:
> 
> > If the charset parameter is not present, we cannot use negotiation 
> > of HTTP 1.1, which is already available.
> 
> This is not true. The scope of "Accept-Charset" is unclear
> (whether it applies to more than text/plain and text/html),
> but it does not depend on there being a "charset" parameter 
> on the results.

Oops, you are definetely right.  I should have mentioned code conversion 
by proxy servers.

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Thu, 06 May 1999 18:33:56 -0400
To: <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: RE: Parameters for top-level XML media types?
Sender: [email-masked]

At 12:31 PM 5/6/99 -0700, Larry Masinter wrote:
>Before we invest a lot of effort into solving this problem, could you
>please give a couple of _realistic_ examples where
>   a) this is really a problem and
>   b) MIME type labelling would actually help?

Sure.  Whenever I hear someone ask for '_realistic_ examples' I expect
they're planning to dislike whatever I present on philosophical grounds,
but I'll give it a shot.

>It sounds nice in principal, but for the most part, the examples given
>are very weak. For the most part, the examples I've seen are based on
>some hypothetical world in which there are thousands of different documents
>and document types in different repositories, and people are browsing
>indiscriminately among the ones that fit their application.

The principle is extremely simple.  File types should be labeled as
precisely as possible.  XML documents have a double identity - they can be
processed by generic XML processors and stored in generic repositories -
and they also have specific content that may require a particular
processor.  At present, MIME types can identify the first identity (using
text/xml or application/xml) OR the section (typically using
application/x-whatever), but not both.

As for 'some hypothetical world', I don't think we're really that far away
from the very scenario you describe.  People and software browsing
indiscriminately is here today, as are thousands of different documents in
different repositories.  We don't _yet_ have thousands of different
document types, but as XML makes plenty of provision for this, it might be
wise to be prepared.

>I've not yet seen a real example. The closest I've seen is the calendaring
>example, where someone gets lots of calendar messages along with other
>messages in their email box, and the application is trying to sort out
>which things are calendar requests from just ordinary email by filtering
>on the MIME type. But I'm suspicious of this application; for a long
>list of reasons, it seems like the wrong use of the MIME type to determine
>the intent of the message.

Lacking any strong theoretical feelings about the 'proper' use of MIME
types, I'd happily make the claim that if it works, great, and if we can
make it work better, even better.

Now for some 'real world' examples, though they'll have to be somewhat
vague given the current lack of 'real world' XML currently in circulation.

XMLNews (www.xmlnews.org) provides an XML vocabulary for marking up news
stories.  At present, I can't find them serving any 'live' XMLNews
information, so I'll make this up out of the usual conjecture and guesswork.

Suppose I subscribe to a news feed that uses XMLNews format, say one
focused on XML. (Maybe Robin Cover's site in XML form.)  The feed comes in
through my email, and hopefully I've finally built a mail program that I
like better than Eudora Pro. Because subject headers are such crummy things
to sort on, I feed the XMLNews information into a repository that works
well with XML.  There are a few ways I could set this up:

1) Filter based on sender (okay for simple case)
2) Filter based on MIME-type: all text/xml goes through another processor
and into the repository. If I'm smart, a post-processor figures out which
XML is which so I don't end up collecting business cards.
3) Filter based on MIME-type: all application/x-xmlnews is separated,
inspected to make sure it's 'really' XML and not a mere name collision and
then sent into the repository.
4) Filter based on MIME-type: all xml/x-xmlnews is separated, put in the
repository.

Number 4 seems to me the most trustworthy and requires the least
post-processing.  Seems like a good combination to me.

Similarly, suppose I have a search engine that scours the Web seeking out
XMLNews information and indexing it.  ('News beyond the Wire' or
something.)  If XMLNews is identified as text/xml or application/xml, the
signal-to-noise ratio is going to be extremely high.  I'll be loading lots
of documents and throwing them in the discard pile.  If it's
application/x-xmlnews, the signal-to-noise ratio will be much lower. On the
other hand, if I build a search engine that simply indexes XML documents,
it's going to have to load all kinds of application/x-* to figure out
what's in XML and what isn't - a problem given the likely proliferation of
application/x-* that XML makes possible.

If it's xml/x-xmlnews, then both my XMLNews-specific search engine and my
generic XML search engine are happy - both know that they can index the
material, and the odds of wasted transfers decline. (Admittedly, because
non-XML formats are likely to grow much more slowly, we could train the
generic search engine to ignore bad matches.  On the other hand, it seems a
lot easier to get the matches right the first time.)

Similar issues arise for other specific and generic processors.  Browsers
can display (either as a tree or with style sheets) any XML that's text/xml
or application/xml.  If they get an unknown MIME type, however, they're
going to have to bug the user to figure out what to do with it. Again, they
could check everything they get to find out if it's XML, but why not get it
right the first time?

Creating a first-level xml space tells generic XML processors that they can
do _something_ to the material contained in the file. Then the second level
can provide a more specific description useful for processors that don't
want to waste their time with the wrong XML information. 

We have an opportunity here to strengthen the use of MIME types by making
them more meaningful.  MIME types are an amazingly underutilized and
frequently misunderstood resource for identifying information types.
Unfortunately, if we continue down the path of text/xml, application/xml,
and application/x-*, we're not providing applications with enough
information to use MIME types meaningfully and reliably.

Simon St.Laurent
XML: A Primer
Sharing Bandwidth / Cookies
http://www.simonstl.com

From: "Frank Boumphrey" <[email-masked]>
To: <[email-masked]>, "Simon St.Laurent" <[email-masked]>
Subject: Re: Parameters for top-level XML media types?
Date: Thu, 6 May 1999 15:47:28 -0400
Sender: [email-masked]

I would like to second what Simon says.

One other point is that there is no requirement for an XML document to have
an XML declaration, so without an XML mime the document will probably get
sent to the wrong engine

Frank

Frank Boumphrey

XML and style sheet info at Http://www.hypermedic.com/style/index.htm
Author: - Professional Style Sheets for HTML and XML http://www.wrox.com
CoAuthor:  XML applications from Wrox Press, www.wrox.com
Author: Using XML on the Web (Aug)
----- Original Message -----
From: Simon St.Laurent <[email-masked]>
To: <[email-masked]>
Sent: Thursday, May 06, 1999 12:54 PM
Subject: Re: Parameters for top-level XML media types?

> At 08:12 PM 5/6/99 +0900, MURATA Makoto wrote:
> >It appears that nobody think parameters  are good enough reasons for
> >introducing a top-level media type "xml".  Thus, the only possible reason
is:
> >
> >> 4. Document-like XML documents can be handled by general-purpose
> >>    XML viewers
> >
> >I do not think this is a good reason either.  XML browsers only have to
> >examine the stylesheet PI and then invoke appropriate formatting engines.
> >
> >Thus, I believe that there is no reason to introduce a top-level media
> type "xml".
> >Have we reached a consensus here?
>
> No, we definitely haven't.  While I didn't support the case you made
> earlier for parameters, I still think a top-level media type of 'xml'
would
> be extremely useful.  (I probably should have said this sooner, but hadn't
> read closely enough to realize that parameters were the last 'good' reason
> for a top-level xml type in the discussion.)
>
> A key part of my concern over the use of MIME types is that MIME types are
> used for more than just deciding how to process information once it has
> been received.  Applications can also use MIME types to negotiate the
> content types they will accep using mechanisms like the HTTP Accept
header.
>  It is not at all difficult for me to imagine scenarios where content
> negotiation will be important as more and more formats evolve, all riding
> along (presently) on application/xml.
>
> For instance, the recent XSL Formatting Object discussions have brought up
> a key issue - because FOs are just XML documents, information providers
now
> have another option for shipping readable but otherwise useless text to
> their customers, saving the semantic XML for those willing to pay a fee.
> In this case, being able to tell the difference between xml/xfo and
> xml/x-pfml (where x-pfml is the paid for markup language) is extremely
> significant.  Servers may have to make decisions about what form to send a
> document in based on received types.
>
> Right now, we just have a weak set of tools for guessing what a client is
> capable of based on its ID string.  MIME types haven't been powerful
enough
> (or well-enough used) to handle this work.  We have an opportunity here to
> give MIME types real work in improving server-client relations and improve
> the efficiency of XML transfers.
>
> application/xml (or text/xml) doesn't say anything about the 'real'
> expectations of the receiving application.  As a result, we may see a lot
> of wasted or terminated transactions as 'junk' arrives to client software
> that isn't capable of processing what the server sent.
>
> Another, more philosophical, point that I'd like to make is that XML isn't
> _just_ a stream of characters.  Unlike regular text documents, or even
most
> binary formats, XML documents contain internal structure that can be used
> for processing and storage.  You _can_ store XML documents as plain old
> text files in plain old file systems - but you can also store your XML
> documents in a data store that uses the internal structure of the document
> to keep it hierarchically.
>
> XML may be text, but it is certainly text+.  Having meaningful MIME types
> to describe that information would be much more useful than finagling
> namespaces and reading into multiple portions of a document to figure out
> what exactly it contains.
>
> If all this goes over like a lead balloon, I'll step out of the way and
let
> you move on to consensus.
>
> Simon St.Laurent
> XML: A Primer
> Sharing Bandwidth / Cookies
> http://www.simonstl.com
>

From: "Larry Masinter" <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>, <[email-masked]>
Subject: RE: Parameters for top-level XML media types?
Date: Thu, 6 May 1999 12:31:44 PDT
Importance: Normal
Sender: [email-masked]

>                       I shouldn't have to download an entire
> text/xml or application/xml document only to find out that the contents are
> in a form that my application isn't interested in.

Before we invest a lot of effort into solving this problem, could you
please give a couple of _realistic_ examples where
   a) this is really a problem and
   b) MIME type labelling would actually help?

It sounds nice in principal, but for the most part, the examples given
are very weak. For the most part, the examples I've seen are based on
some hypothetical world in which there are thousands of different documents
and document types in different repositories, and people are browsing
indiscriminately among the ones that fit their application.

I've not yet seen a real example. The closest I've seen is the calendaring
example, where someone gets lots of calendar messages along with other
messages in their email box, and the application is trying to sort out
which things are calendar requests from just ordinary email by filtering
on the MIME type. But I'm suspicious of this application; for a long
list of reasons, it seems like the wrong use of the MIME type to determine
the intent of the message.

Larry

From: "Larry Masinter" <[email-masked]>
To: "Langer, Paul" <[email-masked]>, <[email-masked]>
Subject: RE: Scope of Accept-Charset (WAS: RE: Parameters for top-level XML media types?)
Date: Thu, 6 May 1999 12:21:32 PDT
Importance: Normal
Sender: [email-masked]

> at Thursday, May 06, 1999 5:35 PM Larry Masinter wrote:
> 
> > [snip]
> > The scope of "Accept-Charset" is unclear
> > (whether it applies to more than text/plain and text/html),
> > [snip]
> 
> Why do you think that "Accept-Charset" may apply only to
> text/plain and text/html?

Because that's all it is used for in practice. A browser that
sends "accept-charset: utf-8" may be able to deal with
text/plain and text/html documents in utf-8, but it
is unlikely to know whether or not the RTF handler inside
application/word is also capable of dealing with utf-8.

One of the problems with "accept-charset" (that wouldn't
be there if we used RFC 2533 feature sets) is that there's
no way to link it to particular media types.

Larry

Date: Thu, 06 May 1999 14:11:24 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: RE: Parameters for top-level XML media types?
Sender: [email-masked]

At 07:51 PM 5/6/99 +0200, Langer, Paul wrote:

>We are currently developing "a data store that uses the internal structure
>of
>the document to keep it hierarchically".
>I see no chance for media types to be of any help for determining the
>structure of XML documents. Do you think of one media type for each and 
>every DTD (or whatever schema we use tomorrow)?
>XML promises to be self-describing data; if it is not possible to get all
>necessary information out of the XML document itself, something is
>broken in XML.  

I'm not arguing that all of the information about the structure of the
documents should be provided in the MIME type - one media type per DTD
makes even less sense in a world where DTDs are not required.  Nonetheless,
for many well-defined XML document types, it seems worthwhile.

Indeed, XML's promise of 'self-describing data' is important.
Unfortunately, we also need useful shorthand descriptions of that data so
that we don't waste lots of time transmitting information only to find that
it wasn't really what we wanted.  I shouldn't have to download an entire
text/xml or application/xml document only to find out that the contents are
in a form that my application isn't interested in.

Self-describing information doesn't reduce the value of a shorthand
description that conveys useful meaning.  This doesn't mean that XML is
broken - it just means that shorthand descriptions are very useful.

You may not find MIME types to be of any use within your hierarchical
structure, but I think it's easy enough to say that they would be useful
for providing shorthand descriptions of what you've got and whether or not
they should be stored in your system, not to mention whether the user
wanted them in the first place.

Simon St.Laurent
XML: A Primer
Sharing Bandwidth / Cookies
http://www.simonstl.com

To: "'Simon St.Laurent'" <[email-masked]>, [email-masked]
Subject: RE: Parameters for top-level XML media types?
Date: Thu, 6 May 1999 19:51:14 +0200 
From: "Langer, Paul" <[email-masked]>
Sender: [email-masked]

at Thursday, May 06, 1999 6:55 PM Simon St.Laurent wrote:

> [snip]
> You _can_ store XML documents as plain old
> text files in plain old file systems - but you can also store your XML
> documents in a data store that uses the internal structure of the document
> to keep it hierarchically.  
> [snip] 
> Having meaningful MIME types to describe that information would be much
> more useful than finagling namespaces and reading into multiple portions
> of a document to figure out what exactly it contains.
> [snip]

We are currently developing "a data store that uses the internal structure
of
the document to keep it hierarchically".
I see no chance for media types to be of any help for determining the
structure of XML documents. Do you think of one media type for each and 
every DTD (or whatever schema we use tomorrow)?
XML promises to be self-describing data; if it is not possible to get all
necessary information out of the XML document itself, something is
broken in XML.  

All the best,
Paul

-----------------------------------------------------------
Paul Langer                           [email-masked]
Software AG                           Tel. +49-6151-92-1912
Uhlandstr. 12                         Fax  +49-6151-92-1613
D-64297 Darmstadt 

To: "'Larry Masinter'" <[email-masked]>, [email-masked]
Subject: Scope of Accept-Charset (WAS: RE: Parameters for top-level XML me dia types?)
Date: Thu, 6 May 1999 19:02:06 +0200 
From: "Langer, Paul" <[email-masked]>
Sender: [email-masked]

at Thursday, May 06, 1999 5:35 PM Larry Masinter wrote:

> [snip]
> The scope of "Accept-Charset" is unclear
> (whether it applies to more than text/plain and text/html),
> [snip]

Why do you think that "Accept-Charset" may apply only to
text/plain and text/html?

All the best,
Paul

-----------------------------------------------------------
Paul Langer                           [email-masked]
Software AG                           Tel. +49-6151-92-1912
Uhlandstr. 12                         Fax  +49-6151-92-1613
D-64297 Darmstadt 

Date: Thu, 06 May 1999 12:54:40 -0400
To: <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Parameters for top-level XML media types?
Sender: [email-masked]

At 08:12 PM 5/6/99 +0900, MURATA Makoto wrote:
>It appears that nobody think parameters  are good enough reasons for 
>introducing a top-level media type "xml".  Thus, the only possible reason is:
>
>> 	4. Document-like XML documents can be handled by general-purpose 
>> 	   XML viewers
>
>I do not think this is a good reason either.  XML browsers only have to 
>examine the stylesheet PI and then invoke appropriate formatting engines.
>
>Thus, I believe that there is no reason to introduce a top-level media
type "xml".  
>Have we reached a consensus here?

No, we definitely haven't.  While I didn't support the case you made
earlier for parameters, I still think a top-level media type of 'xml' would
be extremely useful.  (I probably should have said this sooner, but hadn't
read closely enough to realize that parameters were the last 'good' reason
for a top-level xml type in the discussion.)

A key part of my concern over the use of MIME types is that MIME types are
used for more than just deciding how to process information once it has
been received.  Applications can also use MIME types to negotiate the
content types they will accep using mechanisms like the HTTP Accept header.
 It is not at all difficult for me to imagine scenarios where content
negotiation will be important as more and more formats evolve, all riding
along (presently) on application/xml.

For instance, the recent XSL Formatting Object discussions have brought up
a key issue - because FOs are just XML documents, information providers now
have another option for shipping readable but otherwise useless text to
their customers, saving the semantic XML for those willing to pay a fee.
In this case, being able to tell the difference between xml/xfo and
xml/x-pfml (where x-pfml is the paid for markup language) is extremely
significant.  Servers may have to make decisions about what form to send a
document in based on received types.

Right now, we just have a weak set of tools for guessing what a client is
capable of based on its ID string.  MIME types haven't been powerful enough
(or well-enough used) to handle this work.  We have an opportunity here to
give MIME types real work in improving server-client relations and improve
the efficiency of XML transfers.

application/xml (or text/xml) doesn't say anything about the 'real'
expectations of the receiving application.  As a result, we may see a lot
of wasted or terminated transactions as 'junk' arrives to client software
that isn't capable of processing what the server sent.

Another, more philosophical, point that I'd like to make is that XML isn't
_just_ a stream of characters.  Unlike regular text documents, or even most
binary formats, XML documents contain internal structure that can be used
for processing and storage.  You _can_ store XML documents as plain old
text files in plain old file systems - but you can also store your XML
documents in a data store that uses the internal structure of the document
to keep it hierarchically.  

XML may be text, but it is certainly text+.  Having meaningful MIME types
to describe that information would be much more useful than finagling
namespaces and reading into multiple portions of a document to figure out
what exactly it contains.

If all this goes over like a lead balloon, I'll step out of the way and let
you move on to consensus.

Simon St.Laurent
XML: A Primer
Sharing Bandwidth / Cookies
http://www.simonstl.com

Reply-To: <[email-masked]>
From: "Gavin Thomas Nicol" <[email-masked]>
To: "'Larry Masinter'" <[email-masked]>, "'MURATA Makoto'" <[email-masked]>, <[email-masked]>
Subject: RE: Parameters for top-level XML media types?
Date: Thu, 6 May 1999 11:58:44 -0400
Importance: Normal
Sender: [email-masked]

> > Suggestion:
> >  a) eliminate text/xml
> >  b) eliminate 'charset' parameter from application/xml
> >      The charset is self-identifying. If there is a PUA in use,
> >      then it must be declared in the head of the XML body.
> >      Having PUAs in your charset is like having a private use
> >      font.
> 
> Makoto wrote:
> 
> > If the charset parameter is not present, we cannot use negotiation 
> > of HTTP 1.1, which is already available.

Note that the encoding declaration is not mandatory for XML. An XML
document does not necessarily have to start with an XML declaration.

From: "Larry Masinter" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: RE: Parameters for top-level XML media types?
Date: Thu, 6 May 1999 08:34:53 PDT
Importance: Normal
Sender: [email-masked]

re:
> Suggestion:
>  a) eliminate text/xml
>  b) eliminate 'charset' parameter from application/xml
>      The charset is self-identifying. If there is a PUA in use,
>      then it must be declared in the head of the XML body.
>      Having PUAs in your charset is like having a private use
>      font.

Makoto wrote:

> If the charset parameter is not present, we cannot use negotiation 
> of HTTP 1.1, which is already available.

This is not true. The scope of "Accept-Charset" is unclear
(whether it applies to more than text/plain and text/html),
but it does not depend on there being a "charset" parameter 
on the results.

From: MURATA Makoto <[email-masked]>
Date: Thu, 06 May 1999 20:12:15 +0900
To: <[email-masked]>
Subject: Re: Parameters for top-level XML media types?
Sender: [email-masked]

Larry Masinter wrote:
> > Does anybody think that some of them are good enough reasons for introducing 
> > top-level XML media types?  (I am just asking.)
> 
> These are good reasons for making sure that this information is
> self-identified in the head of the XML body.

It appears that nobody think parameters  are good enough reasons for 
introducing a top-level media type "xml".  Thus, the only possible reason is:

> 	4. Document-like XML documents can be handled by general-purpose 
> 	   XML viewers

I do not think this is a good reason either.  XML browsers only have to 
examine the stylesheet PI and then invoke appropriate formatting engines.

Thus, I believe that there is no reason to introduce a top-level media type "xml".  
Have we reached a consensus here?

> Suggestion:
>  a) eliminate text/xml
>  b) eliminate 'charset' parameter from application/xml
>      The charset is self-identifying. If there is a PUA in use,
>      then it must be declared in the head of the XML body.
>      Having PUAs in your charset is like having a private use
>      font.

If the charset parameter is not present, we cannot use negotiation 
of HTTP 1.1, which is already available.

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]