Subject: Fwd: RE: Transformation + FOs makes abuse easy
From: "Simon St.Laurent" <[email-masked]>
To: [email-masked]
Date: Wed, 28 Apr 1999 14:34:48 -0400

It's a little ways out from the discussions that have dominated this list,
but I thought it might raise some interesting issues.  (text/xfo would be
for documents using the XSL Formatting Objects vocabulary.)  I'm violently
opposed to these transmissions, but the use of MIME as a supporting
infrastructure component seems likely, so I thought I'd put it on the radar
screen.

>From: Miles Sabin <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Cc: "[email-masked]'" <[email-masked]>
>Subject: RE: Transformation + FOs makes abuse easy
>Date: Wed, 28 Apr 1999 18:41:28 +0100
>
>Simon St.Laurent wrote,
>> As a result, the 'meaningful Web' project that was the 
>> driving force (at least in public) for the creation of 
>> XML is at risk.  Server-side transformation from 
>> semantically rich private vocabularies to presentation-
>> oriented public vocabularies may leave the Web exactly 
>> where it was before - interesting to read, but not very 
>> useful. 
>
>Silly question, but (modulo the invention of a few new
>mime types), wouldn't the distinction between,
>
>  Accept: text/xml, text/xsl
>
>and,
>
>  Accept: text/xfo
>
>resolve this issue? Ie. if you're happy to recieve a
>presentation-oriented server-side processed document you
>use the latter. If you want it undigested, you use the 
>former.
>
>Cheers,
>
>
>Miles
>
>-- 
>Miles Sabin                          Cromwell Media
>Internet Systems Architect           5/6 Glenthorne Mews
>+44 (0)181 410 2230                  London, W6 0LJ
>[email-masked]           England
> 

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

From: "Larry Masinter" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: RE: Parameters for top-level XML media types?
Date: Sun, 18 Apr 1999 20:16:11 PDT
Importance: Normal
Sender: [email-masked]

> - the version of XML,

Not any more than Postscript 1 and Postscript 2 having separate versions.

> - the version of Unicode,

Not for any other text type, why for XML?

> - how the Private Use Area (PUA) of Unicode is used 
> 	[Rick Jelliffe wrote: "This also could have bearing on the PUA 
> 	(private use area) character problem, and the problem of corporate 
> 	character sets (e.g. Hong Kong's GCCS)."]

Using Private Use Area in Unicode is tantamount to using a private
charset.

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.

> - which conversion table (Note: for a given CCS, more than one conversion 
>   table may exist),
> - which schema language is used (DTD or the upcoming schema language 
> from W3C),
> - which stylesheet (XSL, CSS, DSSSL, etc.) is used, and
> - other issues mentioned in my mail "List of issues".
> 
> 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.

From: "Larry Masinter" <[email-masked]>
To: "Larry Masinter" <[email-masked]>, "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: RE: Five proposed solutions
Date: Fri, 16 Apr 1999 09:13:35 PDT
Importance: Normal
Sender: [email-masked]

> So perhaps the calandaring applications have components
> that use MIME but aren't intended to be processed by a general
> MIME processor, and so separate MIME types are needed.

er:

So perhaps the calendaring applications have components
that use XML but aren't intended to be processed by a general
XML processor, so separate MIME types are needed.

Sorry,

Larry

From: "Larry Masinter" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: RE: Five proposed solutions
Date: Fri, 16 Apr 1999 09:09:40 PDT
Importance: Normal
Sender: [email-masked]

> Q1. Do you propose to revise RFC 2048 and discourage media types 
>     that are built on top of XML?

Certainly not. People can build media types "that are built
on top of XML", in the same way that XML is a media type that
is built on top of "text/plain".  XML inherits many of the
characteristics of text/plain, but it isn't text/plain, because
that's not how it is intended to be processed.

text/plain can be processed with a generic text processor,
but you can't tell the difference between my autoexec.bat
and a web page.

> Q2. Do you propose to revise RFC 2376 and discourage such
> media types?

I think that the revision of RFC 2376 (necessary anyway)
will need to give some guidelines.

For the most part, the external representations of components
of XML don't need any MIME designation at all, because in
order to process them, they have to be supplied in some context
or wrapped in some kind of packaging or container that doesn't
need to use MIME anyway. (That is, the MIME label might as well be
text/plain or application/octet-stream). 

The only cases where you need a MIME label at all is when
the body is being sent as a message body; i.e., in a context
where you might be sending almost anything at all.
MIME is _not_ the only way of labelling data in Internet
protocols.

Even in those cases, applications where the type of message
body can be distinguished by the DOCTYPE within the XML body
need not define a separate MIME type.

In some cases, where the body isn't intended to be processed
by a general XML processor, but a separately coded processor
for some subset of XML that was designed for the application,
or where the bodies don't contain sufficient declarations
internally to distinguish them from other body types,
it might be necessary to register a separate MIME type.

So perhaps the calandaring applications have components
that use MIME but aren't intended to be processed by a general
MIME processor, and so separate MIME types are needed.

It would be useful to note that the generic text/xml or
application/xml designations are only appropriate for those
bodies that contain a DOCTYPE (or whatever new typing
mechanism you're going to add.)

I.e., "XML bodies that are intended to be used in Internet
protocols should always contain a DOCTYPE." You might even
want to restrict the use so that the initial segment is easy
to parse without invoking a general XML parser.

Larry

From: MURATA Makoto <[email-masked]>
Date: Fri, 16 Apr 1999 20:04:57 +0900
To: [email-masked]
Subject: Parameters for top-level XML media types?
Sender: [email-masked]

We have agreed on two points about fallback.

> 	3. Fallback to general-purpose XML applications is not useful.
> 
> 	4. Document-like XML documents can be handled by general-purpose 
> 	   XML viewers

Other than fallback, are there any reasons for introducing top-level 
XML media types?  One possible reason is that all subtypes can 
share parameters of the top-level media types.  Possibilities for 
such parameters are as below:

- the version of XML,

- the version of Unicode,

- how the Private Use Area (PUA) of Unicode is used 
	[Rick Jelliffe wrote: "This also could have bearing on the PUA 
	(private use area) character problem, and the problem of corporate 
	character sets (e.g. Hong Kong's GCCS)."]

- which conversion table (Note: for a given CCS, more than one conversion 
  table may exist),

- which schema language is used (DTD or the upcoming schema language from W3C),

- which stylesheet (XSL, CSS, DSSSL, etc.) is used, and

- other issues mentioned in my mail "List of issues".

Does anybody think that some of them are good enough reasons for introducing 
top-level XML media types?  (I am just asking.)

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, 16 Apr 1999 18:13:53 +0900
To: <[email-masked]>
Subject: Re: Five proposed solutions
Sender: [email-masked]

Larry Masinter wrote:
> I'm afraid you've let your personal viewpoint color your summary
> of the issues. You said:
> 
> "Solution 5 has not received any support."
> 
> and then gave quotes which, for the most part, don't really support
> that summary.

I tried not to mix my personal viewpoint.  Even if I had failed to 
do so, that was never intended.  Anyway, my mail and your note 
(and probably your response to my questions below) collectively 
provide a "summary".

I have two questions for clarification.  

Larry Masinter wrote:
> I'd like to recommend
> that applications use text/xml or application/xml, unless they
> have a strong need to do something else, and note that in most
> cases, there isn't a strong need, since the actual nature of
> the data can be determined by looking inside the XML itself.

Q1. Do you propose to revise RFC 2048 and discourage media types 
    that are built on top of XML?

Q2. Do you propose to revise RFC 2376 and discourage such media types?

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: Five proposed solutions
Date: Thu, 15 Apr 1999 08:34:02 PDT
Importance: Normal
Sender: [email-masked]

I'm afraid you've let your personal viewpoint color your summary
of the issues. You said:

"Solution 5 has not received any support."

and then gave quotes which, for the most part, don't really support
that summary.

> The others disagree for basically two reasons.  The first reason is
> that we should not prevent developers from developing new media types
> only because they use XML.

"Solution 5" doesn't prevent developers from developing new
media types. "Solution 5" just asks developers to code new media types
using existing media type labels. They are free to develop new
kinds of media. "Solution 5" doesn't prevent new developments.
It just says that those new developments are labeled as "text/xml"
or "application/xml".

> 	"If the answer to this is "no, we don't want to try and
> 	control the development, direction, and use of XML" then your
> 	question is basically out of scope. People will design
> 	whatever they want and register whatever they want. The
> 	resulting mixtures and granularity will be whatever developers
> 	decide is appropriate." (Ned)

I thought Ned's position was actually agreeing with Solution 5.
I don't think that it's a matter of whether we "want" to control
these things, but whether it's practical. I'd like to recommend
that applications use text/xml or application/xml, unless they
have a strong need to do something else, and note that in most
cases, there isn't a strong need, since the actual nature of
the data can be determined by looking inside the XML itself.

> 	"Not just developers; increasingly, vertical markets. An XML
> 	namespace for real-estate listings, for example. One for
> 	dental records. So forth."  (Chris)

I don't see that Chris is arguing against using text/xml or
application/xml as the MIME label for external representations
for XML bodies that use vertical market namespaces.

> 	"This is the position of W3C; certain building blocks are made
> 	available (foundational blocks such as XML itself, XLink,
> 	XPointer, namespaces, etc; useful common things like
> 	styleshets, SVG for images, RDF for metadata which can be used
> 	or not as appropriate) but the way in which people combine
> 	these building blocks is up to them, and the element names
> 	that they use (when not using a building block that defines
> 	names for them, like XHTML and SVG do) is entirely their own
> 	affair."  (Chris)

This doesn't argue one way or another against "solution 5".

> The second reason is the burden of parsing.

The arguments from Chris and Frank are all about IMAP. But
the problem isn't a general one for "a mail protocol like IMAP",
it is "IMAP" that has the problem. An IMAP server has parsed
the MIME bodies of the messages in the mail store, in any case.
It's separated out multipart bodies, parsed the mail headers
into names and values, dealt with various encoding issues.
The only problem is that IMAP contains inconsistent access to
parsing and query facilities. But this is just a weakness of IMAP.
If you were using, say, WebDAV, to access your mailbox, then the
DTD of the XML body of your mail could as easily be a property
of the message body.

> 	"Certainly with a mail protocol like IMAP you can look through
> 	your inbox for entries based on values of the MIME header
> 	fields. The example mentioned was a "mail-enabled"
> 	application. For this application, the implementors on the
> 	IETF CALSCH WG felt very much that the MIME header field
> 	parameters were of importance."  (Frank)
>
> 	"Yes; especially in the case of IMAP where the initial
> 	selection of bodis is done on the server and likely ones are
> 	sent to the client for the calendar program to further
> 	process."  (Chris)

> 	"But it [specialized media types] sure cuts down the class of
> 	data to be further processed. Instead of searching through the
> 	entire mailbox/the entire server, just search in the
> 	text/calendar resources." (Frank)
> 
> 	"The overhead of having to open up every XML document to find
> 	out what document type it is is not practical. As in the case
> 	of email, all I should have to do is ask for a particular type
> 	of object from the store and get it." (Frank)
> 
> 	"There needs to be some balance between an infinite number of
> 	media types/subtypes for each transaction type and a smaller,
> 	managable number of media types for each logical application
> 	object type. As Ned has pointed out, this example and other
> 	show that leaving "hooks" on the outside of the object wrapper
> 	is very useful in providing a scalable, practical Internet
> 	solution using XML." (Frank)
> 
> 	"The thing to avoid, though, it to havce to parse the document
> 	once to find out what sort of thing it is, dispatch it
> 	somewhere else, and then have that "somewhere else" start
> 	parsing again from scratch. If that can be avoided by better
> 	labelling up front, that is a win." (Chris)

In general, we have to do this anyway: we parse the MIME to separate
out the multipart bodies, and then reparse the bodies when we do
the dispatch. If there's a generic XML dispatch engine in your
operating system, then perhaps it can pass on parsed-XML instead of
raw-XML, though, which would save some of the extra processing.

The dispatched XML media handlers would operate with DOM rather than
by reparsing, even if one of them was a DOM-toothbrush-interpreter
and another was a DOM-apartment-for-rent processor.

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

From: MURATA Makoto <[email-masked]>
Date: Thu, 15 Apr 1999 23:42:04 +0900
To: [email-masked]
Subject: Five proposed solutions
Sender: [email-masked]

1. Summary

My first mail to this mailing list lists four possible solutions for
dispatching (and content negotiation).

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

Solution 2: New top-level media type xml and its subtypes

Solution 3: A new parameter "externalid" for text/xml and application/xml

Solution 4: Yet another parameter "optinfo" or "ADD-PARAM" on top of solution 3

Larry added another.

Solution 5: The handler of the XML media types examines the XML MIME
entity and then dispatches to one of several possible media type
handlers.

So far, solution 1 has found some strong support.  Solution 2 has neither 
strong opposition nor strong support, but has been questioned.  Solution 3 
and 4 do not work.  Solution 5 has not received any support.

2. Solution 1

Solution 1 has found some strong support.

	"I tend to lean towards "every application gets a new media
	type." (PaulH)

	"In case it isn't obvious by now, so do I." (Ned)

	"My quick and dirty way of thinking of this is that the media
	type/subtype should to be sufficient to get you the right
	application, but the parameters then can tell that application
	what to do, or when to do it, or various other sorts of things
	that for whatever reason are best not stored in or derived
	from the actual content." (Ned)

One concern is the burden of registration, but "Registration of media 
subtypes is easy."  (Agreement 1 in "What we have agreed on").

Furthermore, a specialized media type may require parameters specific
to that media type.

	"However, in the general problem space surrounding these sorts
	of applications, I see value in using parameters." (Ned)

	"However, just having a "calendar" media type won't cut
	it. The CUA needs to be able to search the MIME entity bucket
	for particular types of "calendar" media types." (Frank)

3. Solution 2

We have not yet found good reasons fot a top-level media type for xml.

Fallback is not a good reason, since "Fallback to general-purpose XML
applications is not useful."  (Agreement 3 in "What we have agreed
on").

Here are some other weak reasons. 

	"However, if the answer [My note: the more general question of whether 
	there is to be an attempt to "design" the XML usage space, and if there 
	is, whether such an attempt has any chance of succeeding.] to this is 
	"yes", then the task at hand becomes one of coming up with an appropriate 
	set of rules that people think will actually do the job and will be 
	followed. And in such a world a top-level XML type might have some value, 
	if only as a place to attach the ruleset." (Ned)

	"The only value I would see is if the fallbacks and other behaviours of
	the text/* tree were seen to be unavoidable and made the use of XML too
	fragile there. XML element names and element content can use all sorts
	of Unicode characters." (Chris)

	"We can also lift the line termination rule of the top-level media type
	"text"." (Murata)

[Note: There are some possible reasons, which I will mention my personal mail.]

However, it might make sense to introduce a top-level media type for
document-like XML, since "Document-like XML documents can be handled
by general-purpose XML viewers" (Agreement 4 in "What we have agreed
on").

4. Solution 3 and 4

Solution 3 and 4 do not work, since "Dispatch based on parameters are
not widely supported" (Agreement 2).

	"I'm afraid you've missed the biggest problem with this
	approach -- one that makes it almost a complete nonstarter:
	The lack of ability to dispatch on parameters in most
	applications that support MIME." (Ned)

5. Solution 5

Larry advocates this solution.  He points out that MIME headers
cannot entirely solve the problem of dispatching and negotiation.  

	"In general, you cannot solve the problem of "dispatch to the
	appropriate handler" by modifying MIME, since finding the
	appropriate handler is platform and installation 
	dependent." (Larry)

	"And adding more MIME types for each kind of combination of
	XML seems like a recipe for disaster. If we have html, xhtml,
	html-netscape, html-microsoft,
	html-optimized-for-msie-on-windows-nt50, each with slightly
	different definitions, would they get separate MIME types?"
	(Larry)

	"... specialized media types should be
	introduced with caution, since a world in which every kind of
	document has its own media types is one in which there is
	little interoperability." (Larry)

	"Neither adding parameters to text/calendar nor inventing new
	MIME subtypes for text/calendar-request text/calendar-response
	etc.  will help implement the query capabilities that you
	need.  
	...  
	Since it doesn't work, stop trying. You need some other kind
	of query protocol than keying off content-type."  (Larry)

	"Someone has to parse them. Certainly if a search engine can
	parse web pages to find the words and their lexical
	equivalences, an event search engine can parse the XML
	documents and index them in the multiple ways that searching
	the calendar-event database needs to be searched." (Larry)

	"Purchase orders that are applicable to the particular
	division, purchase orders that haven't already been processed,
	purchase orders that are assigned to a particular account rep,
	etc. These are all database search problems, not type-indexing
	problems." (Larry)

	"You might also want to scan your email for "event invitations
	from my boss", and you can't solve that problem with
	specialized MIME media types. So the question is: are there
	any realistic cases where having a "text/calendar" distinction
	in the email header actually helps substantially in deciding
	which email bodies to retrieve?"  (Larry)

The others disagree for basically two reasons.  The first reason is
that we should not prevent developers from developing new media types
only because they use XML.

	"If the answer to this is "no, we don't want to try and
	control the development, direction, and use of XML" then your
	question is basically out of scope. People will design
	whatever they want and register whatever they want. The
	resulting mixtures and granularity will be whatever developers
	decide is appropriate." (Ned)

	"Not just developers; increasingly, vertical markets. An XML
	namespace for real-estate listings, for example. One for
	dental records. So forth."  (Chris)

	"This is the position of W3C; certain building blocks are made
	available (foundational blocks such as XML itself, XLink,
	XPointer, namespaces, etc; useful common things like
	styleshets, SVG for images, RDF for metadata which can be used
	or not as appropriate) but the way in which people combine
	these building blocks is up to them, and the element names
	that they use (when not using a building block that defines
	names for them, like XHTML and SVG do) is entirely their own
	affair."  (Chris)

The second reason is the burden of parsing.

	"Certainly with a mail protocol like IMAP you can look through
	your inbox for entries based on values of the MIME header
	fields. The example mentioned was a "mail-enabled"
	application. For this application, the implementors on the
	IETF CALSCH WG felt very much that the MIME header field
	parameters were of importance."  (Frank)

	"Yes; especially in the case of IMAP where the initial
	selection of bodis is done on the server and likely ones are
	sent to the client for the calendar program to further
	process."  (Chris)

	"But it [specialized media types] sure cuts down the class of
	data to be further processed. Instead of searching through the
	entire mailbox/the entire server, just search in the
	text/calendar resources." (Frank)

	"The overhead of having to open up every XML document to find
	out what document type it is is not practical. As in the case
	of email, all I should have to do is ask for a particular type
	of object from the store and get it." (Frank)

	"There needs to be some balance between an infinite number of
	media types/subtypes for each transaction type and a smaller,
	managable number of media types for each logical application
	object type. As Ned has pointed out, this example and other
	show that leaving "hooks" on the outside of the object wrapper
	is very useful in providing a scalable, practical Internet
	solution using XML." (Frank)

	"The thing to avoid, though, it to havce to parse the document
	once to find out what sort of thing it is, dispatch it
	somewhere else, and then have that "somewhere else" start
	parsing again from scratch. If that can be avoided by better
	labelling up front, that is a win." (Chris)

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: "Martin J. Duerst" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Positions on "List of issues"
Date: Wed, 14 Apr 1999 19:01:23 +0800
Sender: [email-masked]

 From: Martin J. Duerst <[email-masked]>
 >But in the general case, the idea is really that you
> say what it is, and leave the rest of the choice to the user and it's
> environment.

"What it is"  is a judgement based on the provider's expectations about how
the document will act at the recipient. I don't think many people will just
stick XML on the net without some intended application.

But people feel that text/xml does not allow them to express "what it is";
in particular, I think people want to run a Java program on the XML document
without having to load an initial HTML document first. If that is, in fact,
the major need, is it something that text/xml should address? Personally, I
don't think so.

Rick

Date: Wed, 14 Apr 1999 15:00:31 +0900
To: "Rick Jelliffe" <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: Positions on "List of issues"
Cc: <[email-masked]>
Sender: [email-masked]

At 20:02 99/04/13 +0800, Rick Jelliffe wrote:
> My 2 cents worth:
> 
> > Issue 1: Proposals for additional parameters in the past
> 
> I agree with Tim Bray that it is inappropriate to give the DTD in a
> parameter: in particular, because XML content models are basically glorified
> assert() statements. DOCTYPE declarations are fine and appropriate where
> they are.

> In particular, I think we are missing a key distinction that the MIME
> content-type is not so much the "type" of a resource, but the type of a
> particular *publication* of a resource.

Well, if it's to distinguish the PS version of a document from the pdf
version and from the HTML version, then you are certainly right. And
it should also be possible to serve something as text/plain if one
really wants. But in the general case, the idea is really that you
say what it is, and leave the rest of the choice to the user and it's
environment. Cases where this doesn't work are implementation problems,
not proofs of concept.

> Furthermore, let me bring up another problem with parameters: the parameters
> have to be sourced from somewhere: everytime we have to duplicate
> information from inside an XML document into a header, we create the chance
> for a mismatch.

Yes indeed. [I might come back to this point in another discussion :-]
The main distinction is: What do you want to be able to do without having
to look inside the resource. On many systems, having to look inside or not
is a big distinction in practical terms.

> > RFC 2376 should be revised when charsets for UTF-16 are registered.
> 
> Yes. And XML appendix F should be revised simultaneously, so that the
> specifications are kept in sync.

Good point.

> > Issue 4: Characters .vs. bytes
> 
> > An XML MIME entity is a sequence of characters as opposed to a
> > sequence of bytes.  RFC 2376 is not really clear about this.
> 
> This is the old question. When we discussed it before, didn't we say that:
> * a text/xml entity is a sequence of characters
> * an application/xml entity is a sequence of bytes?
> 
> I hope an application/* is not a sequence of characters.

Definitely not. In both cases, there are two levels, the character
level and the byte level. In both cases, XML is defined in terms of
characters, and not bytes. Therefore, in both cases, an XML document
is a sequence of characters. In both cases, when sent as a MIME entity,
it has to be sent as a sequence of bytes.

You are right that in the case of application/xml, the chance that
the bytes don't change is higher than in the case of text/xml, but
it is pretty high in both cases anyway.

> > Issue 6: Ambiguity of CCS conversion
> 
> > If this is the case, it might make sense to introduce a parameter
> > "map" to precisely specify which mapping should be used.
> 
> This also could have bearing on the PUA (private use area) character
> problem, and the problem of corporate character sets (e.g. Hong Kong's
> GCCS).

Adding parameters will just increase the mess with current charsets.
It will send the message "it's okay to change a charset slightly, just
add a parameter". This is definitely not what we need!

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

Date: Wed, 14 Apr 1999 02:32:03 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: Paul Langer <[email-masked]>
cc: [email-masked]
Subject: Re: Positions on "List of issues"
Sender: [email-masked]

On Tue, 13 Apr 1999, Paul Langer wrote:

> Rick Jelliffe wrote
> (http://www.imc.org/ietf-xml-mime/mail-archive/msg00064.html): 
> > In particular, I think we are missing a key distinction that the MIME
> > content-type is not so much the "type" of a resource, but the type of a
> > particular *publication* of a resource.
> 
> I disagree with this definiton of the semantics of "MIME content-type".

> XML is portable data; the particular use of this data should not be
> specified by the "publisher". The user should be able to detect the
> data type and then select an application that he/she likes. How can a
> "publisher" know, what applications are available at the user's site?

My point is not that a "publication" selects an application, but that it 
is metadata which is expected to select a class of handler: we expect a 
MIME content-type of application/xml will select a different class of 
handler to text/plain. Otherwise, all XML would be text/plain and we 
wouldn't need this mail list. 

If you want an example, the DTDs on my site at http://www.ascc.net/xml/ 
are typically published both as .dtd (text/xml) and .txt (text/plain). 
This is because I don't know which class of handler the user has: in the 
case of IE5, the DTD will cause a WF error, and it the user cannot View 
Source (if they know how) to view the whole DTD, because the file 
transmission is aborted.  

Providing this kind of multiple content-type doesnt require any 
additional MIME parameters, I can do it at on the file system using links.

Rick Jelliffe

Academia Sinica Computing Center
Tapei, Taiwan

Date: Tue, 13 Apr 1999 19:15:34 +0200
From: Paul Langer <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Positions on "List of issues"
Sender: [email-masked]

Rick Jelliffe wrote
(http://www.imc.org/ietf-xml-mime/mail-archive/msg00064.html): 
> In particular, I think we are missing a key distinction that the MIME
> content-type is not so much the "type" of a resource, but the type of a
> particular *publication* of a resource.

I disagree with this definiton of the semantics of "MIME content-type".

As far as I know, the MIME mechanism is the only mechanism for data typing
that is available today on the Internet. The HTTP/1.1 spec
(http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-06.txt)
says:
"3.7 Media Types
     HTTP uses Internet Media Types [17] in the Content-Type (section
     14.17) and Accept (section 14.1) header fields in order to provide
     open and extensible data typing and type negotiation."

XML is portable data; the particular use of this data should not be
specified by the "publisher". The user should be able to detect the
data type and then select an application that he/she likes. How can a
"publisher" know, what applications are available at the user's site?

All the best,
Paul   

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

Date: Tue, 13 Apr 1999 10:36:18 -0400
To: <[email-masked]>, <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Catalogs and MIME types
Sender: [email-masked]

At 11:25 PM 4/12/99 -0400, Gavin Thomas Nicol wrote:
>I should note that both Simon St. Laurent and Chris Lilley have been making
>noise about such "catalogs" recently as well.

And then later:
>> Rather than extending the MIME headers with lots of
>> parameter, perhaps just the URI of a single resource like that would allow
>greater
>> extensibility.
>
>Yes, I think this is absolutely the right way to go. The only thing I would
>add is that packaging itself has many facets: the "catalog" (drlove, XPDL,
>etc.)
>definition, packaging in MIME multipart/*, resource name aliasing, push vs.
>pull,
>mixed mode push/pull, etc. that all need to be considered.

XPDL (http://purl.oclc.org/NET/xpdl) is exactly about this packaging (and I
really should talk with Rick about his drlove project to figure out if we
have much in common.)  After a number of rounds on XML-Dev complaining
about the imprecision of the methods currently available for identifying
XML document types (including MIME), I figured it was time to go ahead and
write up a proposal for describing such types.

At this point, I think I'm leaning toward leaving the MIME type
application/xml for documents (and creating something more descriptive for
DTDs) and using a different mechanism to connect the descriptions to the
document.  (The XPDL draft currently has five possibilities, and I'm
pondering a sixth.)

Rick's point that a single XML document may be a chameleon of MIME types,
capable of being presented as text/x-myType, application/xml, possibly
text/xml and text/plain, and potentially even more, seems very striking.
We've moved beyond "one document - one type" and dealing with that will be
difficult.  

I think I'd rather let MIME identify a basic type - application/xml - and
develop another mechanism for detail beyond that.  XML documents share some
key features as far as transfer over networks, which to me at least is what
MIME is best for helping with.

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

Date: Tue, 13 Apr 1999 15:35:49 +0200
From: Chris Lilley <[email-masked]>
To: MURATA Makoto <[email-masked]>
CC: [email-masked]
Subject: Re: DTD media type?
Sender: [email-masked]

MURATA Makoto wrote:
> 
> Martin J. Duerst wrote:
> > Is there somewhere a web page where all these terms
> > are defined and explained with simple examples, or something similar?

> Here is an imprecise-but-not-totally-inappropriate analogy.
> 
> XML documents are source programs.  [...]

This is a strikingly good analogy; I wish I had read your mail before
giving my tutorial today. Lots of people are familiar with programming;
it hadn't occurred to me to 

> The BNF for XML documents and that for external DTD subsets are quite
> different.  On the other hand, some external parsed entities are
> legal XML documents, and some external parameter entities are legal
> external DTD subsets.
> 
> Viewers for XML documents and viewers for external DTD subsets are
> quite different.

This is a good summary. It shows that, for example, a generic XML parser
and router, as has been discussed on this list, would bot be able to
deal with external DTD subsets.

Since the parser is different (or rather, since the start token is
different) then using a parameter would not seem wise. Rather, a
different MIME type (for example, text/xml-xdtd ) would seem a better
choice. Or application/xml-xdtd if we decide that text/* is unusable for
XML.

We currently serve DTDs as text/plain on the W3C site; it would be
better to use a more descriptive type.

--
Chris

Reply-To: <[email-masked]>
From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: Positions on "List of issues"
Date: Tue, 13 Apr 1999 09:16:16 -0400
Importance: Normal
Sender: [email-masked]

> In particular, I think we are missing a key distinction that the MIME
> content-type is not so much the "type" of a resource, but the
> type of a particular *publication* of a resource.

This is a very good distinction, and a very succint summary. Well
done.

> Relative to the issue of bundling resources with a document,
> I recently put up a proposal for Document Resource Links, for XML. See
>     http://www.ascc.net/~ricko/drlove.htm
>
> Rather than extending the MIME headers with lots of
> parameter, perhaps just the URI of a single resource like that would allow
greater
> extensibility.

Yes, I think this is absolutely the right way to go. The only thing I would
add is that packaging itself has many facets: the "catalog" (drlove, XPDL,
etc.)
definition, packaging in MIME multipart/*, resource name aliasing, push vs.
pull,
mixed mode push/pull, etc. that all need to be considered.

When we considered this before (for MIME SGML), we concluded that MIME
*already*
provides sufficient infrastructure... you only really needed to register a
few
more MIME types for the primary objects (document instances, DTD's, SGML
declarations< etc.) and that the rest of the requirements really fall onto
the "catalog", or perhaps as you might call it, the "publication
specification".

> And the URI acts as a "publication type name".

This is a nice feature.

From: "Rick Jelliffe" <[email-masked]>
To: <[email-masked]>
Subject: Positions on "List of issues"
Date: Tue, 13 Apr 1999 20:02:05 +0800
Sender: [email-masked]

My 2 cents worth:

> Issue 1: Proposals for additional parameters in the past

I agree with Tim Bray that it is inappropriate to give the DTD in a
parameter: in particular, because XML content models are basically glorified
assert() statements. DOCTYPE declarations are fine and appropriate where
they are.

But I think we need to have some clearer idea of what the MIME headers are
supposed to do; is there a nice functional demarcation between the headers
and the resource?

In particular, I think we are missing a key distinction that the MIME
content-type is not so much the "type" of a resource, but the type of a
particular *publication* of a resource.

For example, lets take a VML file: if I want to publish it for viewing on a
VML browser, I should be able to send it out with the MIME type image/vml
(or whatever). If I want to publish it out for viewing by generic XML tools,
I send it as text/xml. If I want to publish it for viewing as text, I send
it as text/plain.  (Browsers are, of course, free to implement any
application dispatching system they like, which could circumvent my
intentions, but that is life.)

So IMHO the MIME content-types should be geared at helping information
providers publish documents in forms they think are useful. In other words,
it is not the function of the MIME header to describe the resource in
general; the MIME header should describe the document enough for the
particular uses that the information provider has in mind.

With this distinction in mind, we can judge the various parameters suggested
using the simple maxim that "when I publish a resource, I publish it with a
specific use in mind (even if you use it differently)", which means that we
dont need to be overly concerned with "graceful degradatation" or to provide
an elaborate class mechanism (not to deny that the class relations exist).

Furthermore, let me bring up another problem with parameters: the parameters
have to be sourced from somewhere: everytime we have to duplicate
information from inside an XML document into a header, we create the chance
for a mismatch.

If we need fast indexing to elements inside a document, we should invent an
index format: eg
html 23
head 32
meta 44
meta 55
meta 68
to allow (normalized) character indexing into an XML instance. That would be
far more useful in many circumstances than cluttering up the header with
lots of parameters.

> Issue 2: Type of XML mime entities

It would be useful to have a text/dtd (and therefore application/xml) MIME
type. text/xml should be used for XML entities (well-formed or not).
> Issue 3: UTF-16

> RFC 2376 should be revised when charsets for UTF-16 are registered.

Yes. And XML appendix F should be revised simultaneously, so that the
specifications are kept in sync.

> Issue 4: Characters .vs. bytes

> An XML MIME entity is a sequence of characters as opposed to a
> sequence of bytes.  RFC 2376 is not really clear about this.

This is the old question. When we discussed it before, didn't we say that:
* a text/xml entity is a sequence of characters
* an application/xml entity is a sequence of bytes?

I hope an application/* is not a sequence of characters.

> Issue 5: Packaging

> There should be a mechanism for packaging an XML document together
> with its stylesheet, catalog, and referenced resources (e.g., links,
> external entities).

Relative to the issue of bundling resources with a document, I recently put
up a proposal for Document Resource Links, for XML. See
    http://www.ascc.net/~ricko/drlove.htm

Rather than extending the MIME headers with lots of parameter, perhaps just
the URI of a single resource like that would allow greater extensibility.
And the URI acts as a "publication type name".

> Issue 6: Ambiguity of CCS conversion

> If this is the case, it might make sense to introduce a parameter
> "map" to precisely specify which mapping should be used.

This also could have bearing on the PUA (private use area) character
problem, and the problem of corporate character sets (e.g. Hong Kong's
GCCS).

> Issue 7: The default of the charset parameter

Chris Lilley's recent proposal to revised RFC2376 is as below:

> 1) Require explicit charset for overriding the internal encoding
> declaration, so if one really wants to re-label a document as US-ASCII
> one actually has to send it out as text/xml; charset="US-ASCII"

> 2) Define the absence  of an explicit charset encoding in the MIME
> header not as "US-ASCII" but as "use encoding in XML instance" in
> accordance with the XML 1.0 Recommendation.

Yes.  But...We should encourage the use of application/xml when data
integrity is at a premium, and text/xml when data accessibility is a
premium.

I wonder whether the following is actually what is required to make text/xml
work:
 * if the MIME charset and the XML encoding PI concur, the entity is
accepted with the MIME charset;
  * if the MIME charset and the XML encoding PI disagree, *and* the
content-type is application/xml, the resource should be accepted using
the XML encoding PI;
  * if the MIME charset and the XML encoding PI disagree, *and* the
content-type is text/xml, the user-agent may (at user selection):
    - accept the document using the MIME charset (default; status quo in
RFC; indicative of transcoding)
    - accept the document using the XML PI (indicative of poor server
labelling);
    - follow some policy and heuristics determined by the user-agent
(indicative that data integrity is not the highest priority);
    - reject the entity and request it again as application/xml (safest);

where "concurring" takes into account the different defaults.

This is all so complicated, maybe we should just always recommend
application/xml!

Rick Jelliffe
Academia Sinica Computing Center
Taipei, Taiwan

From: MURATA Makoto <[email-masked]>
Date: Tue, 13 Apr 1999 19:33:59 +0900
To: [email-masked]
Subject: Re: DTD media type?
Sender: [email-masked]

Martin J. Duerst wrote:
> 
> Makoto, I think the things you have mentioned in your mail are quite important.
> But my guess is that many of the participants in this discussion don't have
> the necessary background. Is there somewhere a web page where all these terms
> are defined and explained with simple examples, or something similar?

I am obsessed by XML...

Here is an imprecise-but-not-totally-inappropriate analogy.

XML documents are source programs.  External DTD subsets are 
header files that contain declarations and are referenced 
at the beginning of XML documents (note: at most one external 
DTD subset is referenced by one XML document).

External parsed entities are include files that contain source 
program fragments and are referenced in the middle of XML documents.  
External parameter entities are include files that contain declarations 
and are referenced by external DTD subsets. 

       XML document ----------------> external DTD subset 
        |                              |-->  external parameter entity
        |
        |--> external parsed entity 

The BNF for XML documents and that for external DTD subsets are quite 
different.  On the other hand, some external parsed entities are 
legal XML documents, and some external parameter entities are legal 
external DTD subsets.

Viewers for XML documents and viewers for external DTD subsets are 
quite different.

(Please forgive my white lie.  I think that this is enough for our 
 discussion. > XML experts)

If you would like to know the truth, the best document on the WWW is 
Tim's annotated XML.  Its URL is:

	http://www.xml.com/axml/testaxml.htm

DTDs, external DTD subsets, and internal DTD subsets are defined in 
2.8 of XML 1.0 (http://www.xml.com/axml/target.html#dt-doctype)

	[Definition:] The XML document type declaration contains or 
	points to markup declarations that provide a grammar for a class of 
	documents. This grammar is known as a document type definition, or 
	DTD. The document type declaration can point to an external subset (a 
	special kind of external entity) containing markup declarations, or 
	can contain the markup declarations directly in an internal subset, 
	or can do both. The DTD for a document consists of both subsets taken 
	together.

Entitites are defined in Section 4 of XML 1.0. 
(http://www.xml.com/axml/target.html#sec-physical-struct)

Parameter entity

	[Definition:] Parameter entities are parsed entities for use within the 
	DTD. These two types of entities use different forms of reference and are 
	recognized in different contexts. Furthermore, they occupy different namespaces; a 
	parameter entity and a general entity with the same name are two distinct 
	entities. 

Parsed entity

	Entities may be either parsed or unparsed. [Definition:] A parsed entity's 
	contents are referred to as its replacement text; this text is considered an 
	integral part of the document.

Hope this helps.

Cheers,

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

Date: Tue, 13 Apr 1999 18:05:43 +0900
To: MURATA Makoto <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: DTD media type?
Cc: [email-masked]
Sender: [email-masked]

At 16:58 99/04/11 +0900, MURATA Makoto wrote:
> In the xml-dev mailing list, some people requested a media type for DTD (to 
> be precise, an external DTD subset), since browsers should be able to launch 
> a DTD viewer for DTDs.  One could also argue that an additional parameter of 
> text/xml and application/xml is enough for that purpose.

[rest deleted]

Makoto, I think the things you have mentioned in your mail are quite important.
But my guess is that many of the participants in this discussion don't have
the necessary background. Is there somewhere a web page where all these terms
are defined and explained with simple examples, or something similar?

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

Reply-To: <[email-masked]>
From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Date: Mon, 12 Apr 1999 23:25:22 -0400
Importance: Normal
Sender: [email-masked]

> 1. something generic gets the XML and parses it
>  1.a the generic something displays the XML to a human using a 
>      stylesheet, possibly with help from other logic for 
> embedded chunks
>      from different namespaces.
>  1.b the generic something invokes some application.
> 
>  The 1.a example is of course Web browsers (although it seems there 
>  are some nasty architectural holes in how you dispatch control for 
>  embedded chunks of XML).  I have a hard time thinking of a 1.b
>  example.
> 
> 2. An app gets invoked to deal with a resource that happens to
>    be encoded in XML, and the app uses its built-in XML parser.
>    This case probably wants its own media type; the fact that 
>    the encoding is XML is hardly material.

I would say that 1b is roughly equivalent to 2, except for an additional
level of abstraction.

I actually prototyped, a while ago now, 1b using the standard set of
mail tools on Unix. I basically specified a compound document/application
object in a TR9401 catalog (a poxy medium it turns out, that needed a lot
of fixing, and a number of extensions). That catalog could be transmitted
to a generical application that then invoked whatever else was appropriate
(in this case, DynaText, Panorama, and Web browsers).

I think we need to clearly seperate the issue of packaging a single XML
instance/entity, and a compound document. I would argue that the former
is almost entirely devoid of any application semantics (being either
simple text/xml or application/xml), but the latter *intrinsically*
has *some* semantics associated with it.

I guess this is basically supporting the notion that application specific
uses of XML should have application defined media types, but there is a
slight difference in the *mechanism* that I am talking about. We could
have something like xml/processing-specification or something suchlike,
with an associated handler, and that handler could be reponsible for the
dispatch (not part of the MIME world at all). Again, I prototyped something
like this some time ago, and it did work well,  even on top of *existing*
(this was '95) MIME infrastructure.

I should note that both Simon St. Laurent and Chris Lilley have been making
noise about such "catalogs" recently as well.

From: MURATA Makoto <[email-masked]>
Date: Mon, 12 Apr 1999 11:48:44 +0900
To: [email-masked]
Subject: What we have agreed on
Sender: [email-masked]

Having read the disussion so far, I believe that we have agreed on 
a few things and would like to know if somebody disgarees.

	1. Registration of media subtypes is easy.

	2. Dispatch based on parameters are not widely supported.

	3. Fallback to general-purpose XML applications is not useful.

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

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

----------------------------------------------------------
1. Registration of media subtypes is easy.

"Registrations now routinely take only a few days if they don't contain 
egregious errors." (Ned)

"Registrations containing errors take longer, of course. But feedback is quick,
typically taking only a day or two, so the burden is on the person doing the
registration to turn the thing around in a timely way." (Ned)

"The registration process is the same (i.e. fast) in *any* tree that
currently exists. The slowness associated with the IETF tree has to do with
RFC review, which is an entirely separate process from type registration." (Ned)

"The standards say that RFC documentation is only required for registration 
in the IETF tree, and in practice none of the many registered XML-based types 
have been backed up with RFCs." (Ned)

"Moreover, relatively few types belong in the IETF tree." (Ned)

2. Dispatch based on parameters are not widely supported.

"The lack of ability to dispatch on parameters in most applications that 
support MIME. Not only do applications lack this ability, there are also 
quite a few contexts where MIME labelling is used that don't support 
parameters, period." (Ned)

"Many current implementations of content dispatch don't allow dispatch
based on media type parameters, in any case." (Larry)

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)

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

"1.a the generic something displays the XML to a human using a 
stylesheet, possibly with help from other logic for embedded chunks
from different namespaces." (Tim)

"Then there is a second class of uses which are essentially textual,
where the XML markup is  being used to structure headings, footnotes,
chapters and suchlike document-like things.  These things do indeed
benefit, if not recognised, from being "displayed" and may even contain
an internal link to a stylesheet which can be used to display them. I
think that dispatching this 'marked up text' class of uses to a single
parser/viewer, such as a browser, make sense (not in all cases of
course, and editing should be distinguished from viewing, but full
mailcap files can do that) and thus, a MIME labelling of text/xml would
make sense."  (Chris)

Date: Sun, 11 Apr 1999 13:27:12 -0700
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Mixed-format and Unpacking Expectations
Sender: [email-masked]

Larry wrote:
| When I asked
| | In the case where you're allowed to have a document that mixes
| | traditional HTML, MathML, Vector Graphics ML, etc., are these
| | separate "applications" or are they one "application" ("renderable
| | XML document")?
| 
| I was thinking of an XML application which allowed, in a single 
| body part, all of those namespaces. In the case where you have
| separate body parts, MHTML is probably the best you can do.

Ah.  My answer would be that the use of "XML namespaces" does not 
imply separate applications (although you could figure out how to
specify that an "XML namespace" should be mapped to an application,
as NOTATION was used to do).

| > In both cases I used the basis of the MHTML work, but tried to avoid
| > putting information about relations of parts in the MIME headers, so
| > that you could discard the MIME packaging without loss of information.
| 
| MHTML doesn't put "information about the relations of parts" in the
| MIME headers. It just puts the identity of each part in the wrapper.
| If you have body parts that are self-identifying (they contain their
| own uri/cid or whatever) then you can reassemble.

Yes, I was thinking of RFC 2387 (Multipart/related), which uses
Content-Disposition, possibly encoding structural information not
borne elsewhere.  I see now that RFC 2557 (MHTML) doesn't (and
the bibliographic reference to RFC 2183 (Content-Disposition), 
CONDISP, is apparently dangling).  But then, I was ignoring relative
URLs.

regards, Terry

Terry Allen                             Commerce One, Inc.
Business Language Designer              1600 Riviera Ave., Suite 200
Advanced Technology Group               Walnut Creek, Calif., 94596
tallen[at]sonic.net

From: "Larry Masinter" <[email-masked]>
To: "Terry Allen" <[email-masked]>, <[email-masked]>
Subject: RE: Mixed-format and Unpacking Expectations
Date: Sun, 11 Apr 1999 11:35:31 PDT
Importance: Normal
Sender: [email-masked]

When I asked

| In the case where you're allowed to have a document that mixes
| traditional HTML, MathML, Vector Graphics ML, etc., are these
| separate "applications" or are they one "application" ("renderable
| XML document")?

I was thinking of an XML application which allowed, in a single 
body part, all of those namespaces. In the case where you have
separate body parts, MHTML is probably the best you can do.

> In both cases I used the basis of the MHTML work, but tried to avoid
> putting information about relations of parts in the MIME headers, so
> that you could discard the MIME packaging without loss of information.

MHTML doesn't put "information about the relations of parts" in the
MIME headers. It just puts the identity of each part in the wrapper.
If you have body parts that are self-identifying (they contain their
own uri/cid or whatever) then you can reassemble.

Larry

From: MURATA Makoto <[email-masked]>
Date: Sun, 11 Apr 1999 16:58:24 +0900
To: [email-masked]
Subject: DTD media type?
Sender: [email-masked]

In the xml-dev mailing list, some people requested a media type for DTD (to 
be precise, an external DTD subset), since browsers should be able to launch 
a DTD viewer for DTDs.  One could also argue that an additional parameter of 
text/xml and application/xml is enough for that purpose.

Other than external DTD subsets and XML documents, there are two types of 
XML network entities.  They are external parsed entities and external parameter 
entities.

At present, RFC 2376 says that text/xml and application/xml can be 
used for all of the four types.  No mechanisms for distinguishing the 
four types are present.

Can we use XML processors to distinguish these four types?  The answer is No.

A DTD does not parse as an XML document.

An external parsed entity does not typically parse as an XML document.
(Note: it is possible to create an external parsed entity which also 
parses as an XML document.)

An external parameter entity does not parse as an XML document.  
(Note: an external parameter entity can also become an external DTD subset.)

Then, can we develop some other program to distinguish the four types?  
It is possible, but not likely.

To do such autodetection, programs have to understand the charset parameter, 
handle the specified charset, and then compare the text against the BNFs for 
the four types.  People will not implement such complicated autodetection, in 
my humble opinion.

Cheers,

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

Date: Sat, 10 Apr 1999 13:50:14 -0700
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: Mixed-format and Unpacking Expectations
Sender: [email-masked]

I'd like to add remarks on topics I haven't seen dealt with at any
length yet: mixed format compound documents and expectations for
MIME unpacking.  Here are some quotes of what has been said:

| MURATA Makoto, Paul Hoffman, Frank Dawson, Jim Whitehead
| 1. Problem statement
| 
| We would like the MIME parser to be able to dispatch different sorts
| of XML documents to different applications, such as specialized
| programs that handle just one type of XML document.  Because MIME
| parsers do not look inside the MIME parts, identifiying the sort of
| documents must be done in the MIME headers.  However, neither text/xml
| nor application/xml allow such information.
| ...
| (3) A new parameter "externalid" for text/xml and application/xml
| 
| This parameter specifies the externalID from the DOCTYPE of the XML
| document (if the DOCTYPE is present).  Examples would be:
| ...
| Note: None of the above proposals handle non-monolithic XML documents 
| very well, 
| since different islands of non-monolithic XML documents belong to different 
| namespaces and thus different schemata. 
| ===================
| Later, Murata Makoto wrote:
| Issue 5: Packaging
| 
| There should be a mechanism for packaging an XML document together
| with its stylesheet, catalog, and referenced resources (e.g., links,
| external entities).  One possibility is MHTML.
| ===================
| Larry asked:
| In the case where you're allowed to have a document that mixes
| traditional HTML, MathML, Vector Graphics ML, etc., are these
| separate "applications" or are they one "application" ("renderable
| XML document")?
| ====================

Mixed-format compound documents.

I have imagined complex documents that are not pure XML.  Such
a document would have a root entity (cover page, table of contents)
that gives access to others (which is why it's a document rather 
merely a web).  That root entity could be PDF, XML, Word, plain
text, CGM, you name it.  Other entities could be XML, Word, PDF,
etc. and on and on.  I want to be able to package up such a document
in MIME, and I think of "nonmonolithic" XML documents as a special
case of this format-generic complex document.  I'd like to solve
the general problem AND solve the XML problem together.  I've made
several proposals for doing so:  "Package or Perish", an SGML '97 
paper, and "MIME Multipart/Related for CBL", possibly accessible
s.v. "Related Documents" at 

  http://www.veosystems.com/xml/cbl/cbl-1.1/doc/index.html

In both cases I used the basis of the MHTML work, but tried to avoid
putting information about relations of parts in the MIME headers, so
that you could discard the MIME packaging without loss of information.
I don't have any attachment to the details of either of those proposals:
the week before the SGML '97 conference my colleagues and I worked up
half a dozen combinations of MIME semantics to do the job, and any 
proposal that works is fine by me.

I invented a text/x-compounddoc subtype for mixed-format compound
documents, perhaps pointlessly:  is it the opinion of this group that
the root entity's MIME type is what should be used to label the whole
(which is related to what Larry was asking)?  or maybe the MIME type
of the manifest (see next)?

Expectations for MIME unpacking.

There may be XML documents composed of very many pieces:

My-enormous-catalogue-container
	Catalogue-entry-1
	Catalogue-entry-2
	Catalogue-entry-3
	...
	Catalogue-entry-100,000

Each of these catalogue entries may have an identifier, which could
be listed in a manifest (in XML, say) that is the first body part of 
a multipart MIME message.  The recipient may know he is interested only 
in Catalogue-entry-98,256.  It seems to me that it might be more
efficient to obtain that part by extracting and parsing the manifest and 
then searching for the MIME header of the wanted body part (thus making
recursive use of the MIME packaging) rather than having the MIME unpacker 
unpack all of the MIME message first.  I'm no MIME expert, so I don't know 
if that's reasonable, but I am uneasy about assuming that unpacking should 
be done before any subsequent processing.  (Perhaps no such assumption has
been made ...)

regards, Terry

Terry Allen                             Commerce One, Inc.
Business Language Designer              1600 Riviera Ave., Suite 200
Advanced Technology Group               Walnut Creek, Calif., 94596
tallen[at]sonic.net

From: MURATA Makoto <[email-masked]>
Date: Fri, 09 Apr 1999 12:34:37 +0900
To: [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Chris Lilley wrote:
> It struck me as an entirely reasonable question, in particular since the
> RFC that defines text/xml and application/xml refers to "MIME-like
> protocols" which seems to imply that HTTP is not MIME (something I have
> heard asserted in the past).

RFC 2068(Hypertext Transfer Protocol -- HTTP/1.1) says:
----------------------------------------------------
19.4 Differences Between HTTP Entities and MIME Entities

   HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
   822) and the Multipurpose Internet Mail Extensions (MIME ) to allow
   entities to be transmitted in an open variety of representations and
   with extensible mechanisms. However, MIME [7] discusses mail, and
   HTTP has a few features that are different from those described in
   MIME.  These differences were carefully chosen to optimize
   performance over binary connections, to allow greater freedom in the
   use of new media types, to make date comparisons easier, and to
   acknowledge the practice of some early HTTP servers and clients.

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

Date: Thu, 08 Apr 1999 15:10:34 +0200
From: Chris Lilley <[email-masked]>
To: Frank Dawson <[email-masked]>
CC: Larry Masinter <[email-masked]>, [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Frank Dawson wrote:

> Actually, the current MIME content type definition for "text/calendar"
> provides for MIME header parameter that CUAs are using to scan the inbox for
> the "new invitations". 

Okay,

> This is what gave me concern when I read the content
> type definition for text/xml and application/xml. It doesn't allow an
> application to detect what kind of XML object is in the email.

If you are pointing out the utility of parameters for finer granularity
of labelling in general, then I agrree it can help.

> For our
> application area, it is disfunctional. It is imparing the use of XML for
> representing iCalendar objects (and certainly other application objects
> too).

I sense from this a worry that existing registered uses of XML would
need to re-register to use text/xml. If that is your worry, then I would
say that I do not believe that this is the intention.

--
Chris

Date: Thu, 08 Apr 1999 15:10:29 +0200
From: Chris Lilley <[email-masked]>
To: Frank Dawson <[email-masked]>
CC: Larry Masinter <[email-masked]>, [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Frank Dawson wrote:
> 
> Larry Masinter wrote, in part:
> 
> >I'm saying you definitely have a problem: you have a complex space
> >of possible objects:
> 
> NO, this is not a complex problem. This is an existing 20+ year old mail
> enabled application. This nut has already been cracked for Internet
> developers using the "text/calendar" content definition. I queried
> Kurita-san and Paul Hoffman because I was interested in utilizing XML
> representation of iCalendar. We have a DTD defined. It is an isomer of the
> iCalendar standard format,

So, the mechanics and all the semantics of text/calendar are retained
but it merely uses a different syntax?

In that case, it would seem that something like text/xcalendar would
meet your needs, and that apart from the syntactic portion, the defining
specification would see "see text/calendar" in a great many places (or
have the same text copied, whatever).

> There needs to be
> some balance between an infinite number of media types/subtypes for each
> transaction type and a smaller, managable number of media types for each
> logical application object type. 

Yes. This is the hierarchical model, as opposed to the flat model.
Parameters provide a third level of hierarchy below the content type and
content subtype levels.

> As Ned has pointed out, this example and
> other show that leaving "hooks" on the outside of the object wrapper is very
> useful in providing a scalable, practical Internet solution using XML.

The hooks are particularly useful for specialised types such as
calendaring. For a more generic "this is a textual document marked up in
XML" type, the difficulty is finding hooks of suitable generality.

--
Chris

From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Date: Thu, 8 Apr 1999 06:16:45 PDT
Importance: Normal
Sender: [email-masked]

I'm not sure about this group. Here we have a bunch of
people arguing about labelling things on the outside and
not requiring processors to go inside the body to determine
the actual content, yet everyone seems to be content
with having the entire discussion with a "Subject" line
of "RE: Starting the ietf-xml-mime mailing list".

Regards,

Larry

Date: Thu, 08 Apr 1999 14:50:04 +0200
From: Chris Lilley <[email-masked]>
To: Larry Masinter <[email-masked]>
CC: Earthlink <[email-masked]>, [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Larry Masinter wrote:
> [Frank wrote]
> > In addition, though, we also want to get at subtypes of objects. Or in the
> > case of MIME type/subtypes, this would be the "sub-sub type". For example,
> > for a calendar object (text/calendar) we want to pull to the client just the
> > "event invitations". This would be the "sub sub type" of type=text,
> > subtype=calendar.
> 
> This is a good example of a problem that specialized media types won't solve.

But it sure cuts down the class of data to be further processed. Instead
of searching through the entire mailbox/the entire server, just search
in the text/calendar resources.

> You might also want to scan your email for "event invitations from my boss",
> and you can't solve that problem with specialized MIME media types. 

You can't solve that problem in its entirety with specialised MIME media
types, but you can go a good part of the way and have a better start
than, for example, sending all calendar events as text/plain.
text/calendar;category=work;recurring=monthly (to take a suggestive but
doubtles invalid example) would help even more - the parameters could be
used to cut down on the search spoace even further.

> So the
> question is: are there any realistic cases where having a "text/calendar"
> distinction in the email header actually helps substantially in deciding
> which email bodies to retrieve?

Yes; especially in the case of IMAP where the initial selection of bodis
is done on the server and likely ones are sent to the client for the
calendar program to further process.

--
Chris

Date: Thu, 08 Apr 1999 14:43:35 +0200
From: Chris Lilley <[email-masked]>
To: Earthlink <[email-masked]>
CC: Larry Masinter <[email-masked]>, [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Earthlink wrote:
> 
> >It's not clear that specialized media types solve any problem at all,
> >in the case of XML that already contains a document declaration.
> 
> The overhead of having to open up every XML document to find out what
> document type it is is not practical. As in the case of email, all I should
> have to do is ask for a particular type of object from the store and get it.

Yes. Thanks for bringing to our attention the fact that IMAP uses
servers, as well as HTTP; since I use POP I tend to forget about what
IMAP does.

Is it possible to request the "best" of several multipart/alternate
message bodyparts over IMAP, where "best" means the preferences of MIME
type that the user has?

> In addition, though, we also want to get at subtypes of objects. Or in the
> case of MIME type/subtypes, this would be the "sub-sub type". For example,
> for a calendar object (text/calendar) we want to pull to the client just the
> "event invitations". This would be the "sub sub type" of type=text,
> subtype=calendar.

What about parameters, can these be handled?

For example the CGM registration (image/cgm) defined two mandatory
parameters; this was a problem at the time because parameters were not
well handled by current implementations. But recently, W3C made WebCGM
(a particuklar profile) a Recommendation, and were able to use those
parameters to indicate thata particular CGM used the WebCGM profile.
This was handy, no additional registration was necessary and the general
semantics of imege/cgm still apply to WebCGM, but specific semantics are
also added.

Would IMAP be able to fetch image/cgm;Version=4;ProfileId=WebCGM
bodyparts specifically?

This use of parameters for profiles of a registered type/subtype
combination sounds to me much like the possibilities with registering
text/xhtml and then declaring the various HTML profiles for mobile, TV
etc.

--
Chris

Date: Thu, 08 Apr 1999 14:34:41 +0200
From: Chris Lilley <[email-masked]>
To: Murray Altheim <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Murray Altheim wrote:
> I don't believe that
> resorting to file extensions can possibly be the way of the future.

I agree that it should not be the way of the future, but there is some
evidence that implementors are moving in this direction. Try serving up
a PNG file labelled as image/png but with a .gif extension to a popular
browser and see what happens ;-(

Similarly, try serving up an XML file with a .txt extension as
text/plain and some browsers will still complain "unable to display XML
file with stylesheet" and faiul to display it as text - they are
sniffing in the content. 

This is, apparently, because of the amount of unlabelled or mislabelled
content which already exists.

>  We all need a better alternative.

Yes. We also need one fairly quickly (all done and dusted in, lets say,
three months tops) otherwise whatever solution is proposed will merely
be a good idea, but too late.

--
Chris

Date: Thu, 08 Apr 1999 14:28:02 +0200
From: Chris Lilley <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Larry Masinter <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Ned Freed wrote:
> But this then begs the more general question of whether there is to be an
> attempt to "design" the XML usage space, and if there is, whether such an
> attempt has any chance of succeeding.
> 
> If the answer to this is "no, we don't want to try and control the development,
> direction, and use of XML" 

This is the position of W3C; certain building blocks are made available
(foundational blocks such as XML itself, XLink, XPointer, namespaces,
etc; useful common things like styleshets, SVG for images, RDF for
metadata which can be used or not as appropriate) but the way in which
people combine these building blocks is up to them, and the element
names that they use (when not using a building block that defines names
for them, like XHTML and SVG do) is entirely their own affair.

> The resulting
> mixtures and granularity will be whatever developers decide is appropriate. 

Not just developers; increasingly, vertical markets. An XML namespace
for real-estate listings, for example. One for dental records. So forth.

> And
> in such a world I see little value in having an XML top level type. (Perhaps no
> real harm, but little value.)

The only value I would see is if the fallbacks and other behaviours of
the text/* tree were seen to be unavoidable and made the use of XML too
fragile there. XML element names and element content can use all sorts
of Unicode characters. Fallbacks to text/plain are not useful in
general, and fallbacks to 7-bit US-ASCII risk manglng the data. On the
other hand, as you said in another post:

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

If it can be assumed that a program which falls back to text/plain has
already lost significant semantics anyway, and if it can be assumed that
such fallback is rarely of value and rarely happens, then the use of
text/xml is useful. If on the other hand the fallback is seen asa n
unavoidable problem, then an xml/* tree would, indeed, have value simply
by lifting such restrictions.

> And in such a world a top-level XML type might
> have some value, if only as a place to attach the ruleset.

Right, that was what I was trying to say.

> (Delegation of XML
> registration would also be something to consider.)

Perhaps, but who would own it? Oasis, perhaps?  My sense is that W3C is
not interessted in being a central repository for all possible uses of
XML, many of which are not Web related in any way.

--
Chris
> 
> I basically don't have an opinion on which way this should go. My one
> observation is that the IETF at least has typically opted to try and stay out
> of areas like this in the past.
> 
>                                 Ned

Date: Thu, 08 Apr 1999 14:14:49 +0200
From: Chris Lilley <[email-masked]>
To: Larry Masinter <[email-masked]>
CC: Ned Freed <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Larry Masinter wrote:
> 
> > > I tend to lean towards "every application gets a new media type".
> >
> > In case it isn't obvious by now, so do I.
> 
> This is a fine maxim, but it begs the question: what constitutes
> a separate, distinct application, vs a modification, profile,
> extension, or varation of an old one?

Thats a good question, but part of it comes down to monolighic versus
granular compound documents.

> In the case where you're allowed to have a document that mixes
> traditional HTML, 

(I'm assuming you mean XHTML here, ie HTML written in XML. Sop, all the
things you citer are written in XML, and constitute one large XML
instance using multiple namespaces).

> MathML, Vector Graphics ML, etc., are these
> separate "applications" or are they one "application" ("renderable
> XML document")?

If sens as separate bodyparts, which is possible, then they would all be
separate "applications". If sent as one big XML instance, then in this
case I would ay it would be text/xml.

Once XLink and XPointer get more widely deployed, we are likely (IMHO)
to see people moving away from this class of monolithic document and
instead using small skeleton documents, written in XML and using
XPointer transclusion to reference different media pieces (graphics,
math, audio, etc) some (many) orf which are writen in XML , but each
with their own label. This granularity allows finer control by mail user
agents (they can figure out which bodyparts they understand) and allows
the benefits of cacheing over HTTP as different compound documents reuse
different component pieces.

So (to get back to Larrys point) while we may see monolithic
multimnamespace documents which can only really be labelled as text/xml,
we will also alongside that see smaller more granular compound
documents, where a correspondingly finer grained labelling of each
component is more appropriate.

Since it doesn't seem to have come up yet, I will also note the concept
of content negotiation, as used by HTTP; where MIME labelling is used in
negotiations between client and server. I guess this could also apply to
email in the case of external bodyparts, but am not sure so will leave
that to someone else. 

Content negotiation can be initiated by the document author (in the case
that multiple alternatives are explicitly offered in the link to the
resource), by the client (in the case of accept headers) or by the HTTP
server (in the case of 'multiple choices' response code). Discussion of
different MIME types for things written in XML should bear these
considerations in mind, as well as the case where the content is already
sent and one is trying to dispatch it appropriately.

--
Chris
> 
> Larry

Date: Thu, 08 Apr 1999 14:00:09 +0200
From: Chris Lilley <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> Dispatching based on media types raises a few important issues that are
> somewhat unique to XML.
> 
> If we say "every application gets a new media type" then there is no clean
> way for a MIME-handling application to fall back to handing an unknown
> media type to an XML parser.

Although that is the right thing to do in some circumstances, and not in
others.

>  An unclean way for such an application to
> handle an unknown media type is to look inside the first few octets of the
> body and, if it looks like XML, hand it off to the XML parser instead of
> treating it as application/octet-stream or text/plain.

Increasingly, many programs contain an XML parser. XML is being used for
a very wide variety of different things. There is unlikely to be "a"
single XML parser - its a component of some other application program.

> If we say "stick everything XMLish under a media type that is XML-specific
> with some parameter for the kind of XML" then we assume that handing off
> unknown body types to an XML parser is useful.

Right. In some cases, it may be. The thing to avoid, though, it to havce
to parse the document once to find out what sort of thing it is,
dispatch it somewhere else, and then have that "somewhere else" start
parsing again from scratch. If that can be avoided by better labelling
up front, that is a win.

> I question this assumption.

Right.

> What's the XML parser going to do with this block of data? Display it? Not
> terribly valuable.

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.

Then there is a second class of uses which are essentially textual,
where the XML markup is  being used to structure headings, footnotes,
chapters and suchlike document-like things.  These things do indeed
benefit, if not recognised, from being "displayed" and may even contain
an internal link to a stylesheet which can be used to display them. I
think that dispatching this 'marked up text' class of uses to a single
parser/viewer, such as a browser, make sense (not in all cases of
course, and editing should be distinguished from viewing, but full
mailcap files can do that) and thus, a MIME labelling of text/xml would
make sense.

The third class of uses which are intended to be displayed but which
requitre specialised display processors. Examples of these are markup
for chemical structures, X3D for xml-ised vrml, PDB (protein database)
format, BSML (bioinformatics sequence markup language), SVG (scalable
vector graphics) and so on. These are likely to benefit from specialised
registrations, which might be in the image, application,  model, or
other top level types.

So far I havewn't seens a good case made for application/xml, sinc ehte
re isn't a single XML application; the arguments around its use have
centered around concerns for the lowest common denominator fallback to
text/plain if text/xml is not recognised (and the possibility of bit 8
mangling, if sent over email rather than http or binary ftp)

> 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.
> 
> I tend to lean towards "every application gets a new media type".

I think that is reasonable in many cases, but not all. There still seems
to be a place for text/xml, for textlike or documentlike applications.

--
Chris

From: "Peter Stark" <[email-masked]>
To: <[email-masked]>
Subject: Specialised media types (was RE: Starting the ietf-xml-mime mailing list)
Date: Thu, 8 Apr 1999 04:47:16 -0700
Importance: Normal
Sender: [email-masked]

I think that using specialized media types - one for every XML app - can be
a potential scalability problem. Even if the media type registration is
impressively fast today (one day!), I anyway doubt that it's appropriate to
have a central authoritive for this purpose.

One particular problem is the naming of media types in the Vendor tree:

	text/vnd.*

You can put whatever you like after 'vnd', and that's what people do.

I wonder why media types can't use similar naming rules as, for example,
java classes (domain names) or XML names (URIs). Wouldn't it be possible to,
in some way, join the MIME Media type tree with the domain names. For
example,

	text/xml.org.w3.html, would be XHTML
and
	text/xml.com.anyCo.myXmlApplication, would be someone's XML application.
but
	text/html, would still be HTML

That way, the browser can, even if it doesn't recognize the type, at least
see that it's an XML document (and perhaps display it). It also means that I
can create my own media types without having to contact a central naming
authority (except for getting the domain name). I can also further sub-type
my own media type.

Perhaps some sort of new URN should be used instead, I don't know. Anything
would be better than "vnd.whatever.."-names.

PS

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Ned Freed
> Sent: Wednesday, April 07, 1999 3:11 PM
> To: Larry Masinter
> Cc: Earthlink; [email-masked]
> Subject: RE: Starting the ietf-xml-mime mailing list
>
>
> > > In addition, though, we also want to get at subtypes of
> objects. Or in the
> > > case of MIME type/subtypes, this would be the "sub-sub type".
> For example,
> > > for a calendar object (text/calendar) we want to pull to the
> client just the
> > > "event invitations". This would be the "sub sub type" of type=text,
> > > subtype=calendar.
>
> > This is a good example of a problem that specialized media
> types won't solve.
>
> Agreed.
>
> My quick and dirty way of thinking of this is that the media type/subtype
> should to be sufficient to get you the right application, but the
> parameters
> then can tell that application what to do, or when to do it, or
> various other
> sorts of things that for whatever reason are best not stored in
> or derived from
> the actual content.
>
> > You might also want to scan your email for "event invitations
> from my boss",
> > and you can't solve that problem with specialized MIME media
> types. So the
> > question is: are there any realistic cases where having a
> "text/calendar"
> > distinction in the email header actually helps substantially in deciding
> > which email bodies to retrieve?
>
> Of course the general case of this problem may in fact be
> intractable, even
> with full access to message content. (Define "boss". Figure out
> how to relate
> the origin of a given event invitation to this definition of "boss". Etc.)
> However, in the general problem space surrounding these sorts of
> applications,
> I see value in using parameters. For example, I may wish to have certain
> sorts of calendar operations handled silently and automatically, whereas
> others need to be done manually.
>
> In short, I agree with Frank that parameters have their uses in
> this context.
>
> 				Ned
>
>

Date: Wed, 07 Apr 1999 00:50:30 +0200
From: Chris Lilley <[email-masked]>
To: "Donald E. Eastlake 3rd" <[email-masked]>
CC: [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

"Donald E. Eastlake 3rd" wrote:
> 
> I consider the original question to have been pretty insulting. 

OK, I accept that you consider it so; it wasn't intended to be, and Paul
Hoffman seemed to treat it like a simple request for information and
responded with that information.

> There
> is only one set of MIME types for all uses. 

That is also my understanding; I was checking that this is shared and
agreed upon context for this discussion. I have heard other opinions
voice the contrary.

> The name of the list is
> ietf-xml-mime, not email-xml-mime. 

Right, so we are clear it is about MIME; and if we read the MIME RFCs we
are clear that that MIME is about email, and not necessarily clear that
it is about any other protocol.

So it seemed better to ask at first than to risk misunderstandings
because of a lack of shared assumptions.

> If it had been hosted at the W3C,
> would non-web uses have been ignored?

Yes, unless they could be shown to follow naturally and pretty much for
free from the Web uses.

The Web is the universe of network-accessible information. So, that
includes mail, ftp, and so on.

It struck me as an entirely reasonable question, in particular since the
RFC that defines text/xml and application/xml refers to "MIME-like
protocols" which seems to imply that HTTP is not MIME (something I have
heard asserted in the past).

So, if everyone agrees that the scope is, at minimum, both email and
HTTP, then we can move on. It never hurts, I find, to state exactly what
problem is being solved before attempting to solve it.

--
Chris

Date: Thu, 08 Apr 1999 08:37:00 +0900
To: Paul Grosso <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Cc: [email-masked]
Sender: [email-masked]

At 09:53 99/04/07 -0500, Paul Grosso wrote:

> the original namespace proposal
> developed by the XML WG was to have namespace declarations only in
> the prolog (at the top) of an XML document.

> Now there is this suggestion to collect all declared namespaces at
> the top of the document again.  Isn't this going around in circles?
> Whatever the reasons for going with locally scoped declarations, aren't
> most of them also reasons against listing all such decls at the top?

As the discussion about callendars has just shown, there can be
huge differences between having things inside the document (even
at the top) and outside ("higher up than the top").

Also, requiring that all used namespaces be listed may definitely
be too much in certain scenarios. It could be only the "main"
namespace(s), only the "mandatory" namespaces, and so on. That
would then of course lead to the question of how to distinguish
these cases.

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

From: "Frank Dawson" <[email-masked]>
To: "Larry Masinter" <[email-masked]>, <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Date: Wed, 7 Apr 1999 19:14:51 -0400
Sender: [email-masked]

Larry Masinter wrote, in part:

>I'm saying you definitely have a problem: you have a complex space
>of possible objects:

NO, this is not a complex problem. This is an existing 20+ year old mail
enabled application. This nut has already been cracked for Internet
developers using the "text/calendar" content definition. I queried
Kurita-san and Paul Hoffman because I was interested in utilizing XML
representation of iCalendar. We have a DTD defined. It is an isomer of the
iCalendar standard format, but the MIME content type defintiion for text/xml
and application/xml stinks. It doesn't provide us (and soon other XML
application developers too) the right tools to do our job. Tools that are
already in place for the iCalendar content type.

This is not a problem with MIME. This is not a problem with calendaring.
This is a problem with the current definition for the XML content type. This
mailing list is to air our discussion on how to best fix this, right?

>Yes, the example is real, and shows that this problem can't be solved
>by overloading the MIME type space.

Well, I personally don't think that we have "overloaded" the calendar
content type in the iCalendar content type definition. There needs to be
some balance between an infinite number of media types/subtypes for each
transaction type and a smaller, managable number of media types for each
logical application object type. As Ned has pointed out, this example and
other show that leaving "hooks" on the outside of the object wrapper is very
useful in providing a scalable, practical Internet solution using XML.

- - Frank

From: "Frank Dawson" <[email-masked]>
To: "Larry Masinter" <[email-masked]>, <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Date: Wed, 7 Apr 1999 19:04:48 -0400
Sender: [email-masked]

Larry Masinter wrote:

>You might also want to scan your email for "event invitations from my
boss",
>and you can't solve that problem with specialized MIME media types. So the
>question is: are there any realistic cases where having a "text/calendar"
>distinction in the email header actually helps substantially in deciding
>which email bodies to retrieve?

Actually, the current MIME content type definition for "text/calendar"
provides for MIME header parameter that CUAs are using to scan the inbox for
the "new invitations". This is what gave me concern when I read the content
type definition for text/xml and application/xml. It doesn't allow an
application to detect what kind of XML object is in the email. For our
application area, it is disfunctional. It is imparing the use of XML for
representing iCalendar objects (and certainly other application objects
too).

- - Frank

From: "Larry Masinter" <[email-masked]>
To: "Earthlink" <[email-masked]>, <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Date: Wed, 7 Apr 1999 15:51:59 PDT
Importance: Normal
Sender: [email-masked]

I'm saying you definitely have a problem: you have a complex space
of possible objects:

"all possible calendaring events, with indication as to the applicable
users, the nature of the event, whether it's a request, a response,
the dates involved, urgent"

You need to query this space, find those that match a particular
set of criteria, and then retrieve the objects that match your criteria.

Neither adding parameters to text/calendar nor inventing new
MIME subtypes for text/calendar-request text/calendar-response etc.
will help implement the query capabilities that you need.

Since it doesn't work, stop trying. You need some other kind of query
protocol than keying off content-type.

> However, just having a "calendar" media type won't cut it. The CUA needs to
> be able to search the MIME entity bucket for particular types of "calendar"
> media types. 

No, I think this is a poor characterization. The CUA needs to be able
to search the MIME entity bucket for particular calendar events that
match a particular query, "all repeating events that do not occur
on Thursday". Trying to cram this into the type space is just poor
engineering.

Yes, it needs to search the MIME entity bucket. No, the search is not
characterized by "type".

> All of these scheduling messages "sub-sub types" are represented in the same
> single calendar media type.

You may want to characterize them as "sub-sub types", but it is a misuse
of the type space.

>                   Tell me again, how you are going a scalable way
> for a "calendar portal" site that has 100s of thousands of calendar users
> wanting this info each day to service requests from CUAs for "new
> invitations" or "invitation responses"? You can't expect the calendar
> service to be able to parse ALL of the thousands of XML entities that are in
> the MIME entity bucket to first find the calendar ones and then the "new
> invitations" or "invitation responses".

Someone has to parse them. Certainly if a search engine can parse web
pages to find the words and their lexical equivalences, an event search
engine can parse the XML documents and index them in the multiple ways
that searching the calendar-event database needs to be searched.

> If calendaring doesn't provide a real enough example, 

Yes, the example is real, and shows that this problem can't be solved
by overloading the MIME type space.

>                        think about electronic
> commerce and the millions of transactions a site may be handling a day. We
> can't expect an EDI client to have to parse each of the XML entities in the
> MIME bucket to find the "purchase orders".

Purchase orders that are applicable to the particular division, purchase
orders that haven't already been processed, purchase orders that are
assigned to a particular account rep, etc. These are all database search
problems, not type-indexing problems.

Larry

Date: Wed, 07 Apr 1999 15:10:31 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
To: Larry Masinter <[email-masked]>
Cc: Earthlink <[email-masked]>, [email-masked]
Sender: [email-masked]

> > In addition, though, we also want to get at subtypes of objects. Or in the
> > case of MIME type/subtypes, this would be the "sub-sub type". For example,
> > for a calendar object (text/calendar) we want to pull to the client just the
> > "event invitations". This would be the "sub sub type" of type=text,
> > subtype=calendar.

> This is a good example of a problem that specialized media types won't solve.

Agreed.

My quick and dirty way of thinking of this is that the media type/subtype
should to be sufficient to get you the right application, but the parameters
then can tell that application what to do, or when to do it, or various other
sorts of things that for whatever reason are best not stored in or derived from
the actual content.

> You might also want to scan your email for "event invitations from my boss",
> and you can't solve that problem with specialized MIME media types. So the
> question is: are there any realistic cases where having a "text/calendar"
> distinction in the email header actually helps substantially in deciding
> which email bodies to retrieve?

Of course the general case of this problem may in fact be intractable, even
with full access to message content. (Define "boss". Figure out how to relate
the origin of a given event invitation to this definition of "boss". Etc.)
However, in the general problem space surrounding these sorts of applications,
I see value in using parameters. For example, I may wish to have certain
sorts of calendar operations handled silently and automatically, whereas
others need to be done manually.

In short, I agree with Frank that parameters have their uses in this context.

				Ned

From: "Earthlink" <[email-masked]>
To: <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Date: Wed, 7 Apr 1999 18:10:11 -0400
Sender: [email-masked]

I think that this argument needs a realworld application to give it some
bite. I really don't think that there is appreciation for the problem facing
application developers who are looking at possibly using a XML
representation for their object, but are frustrated with the current MIME
definition for the XML content type.

Paul Hoffman wrote:

>I tend to lean towards "every application gets a new media type".

Paul understand the calendaring and scheduling application about as well as
any outsider to this application domain. I agree with his note that argues
that the MIME header needs to provide cues to application-specific client
agents (e.g., Calendar User Agent) that periodically peeks into the MIME
entity bucket (e.g., inbox) to look for it's application specific messages.
This is the paradigm that mail-enabled CUAs use today.

However, just having a "calendar" media type won't cut it. The CUA needs to
be able to search the MIME entity bucket for particular types of "calendar"
media types. Some of the ones that the Internet community has standardized
in RFC 2447 include:

EVENT PUBLISH (publish some arbitrary calendar data)
EVENT REQUEST (initial invitation, reschedule, delegate the invitation,
response to a counter-proposal)
EVENT REPLY (response to an invitation)
EVENT CANCEL (cancel the meeting or uninvite a single individual)
EVENT ADD (add a set of additional instances to an already scheduled event)
EVENT COUNTER (proposal an alternate time/place)
EVENT DECLINECOUNTER (decline a counter)
EVENT REFRESH (now, tell me the latest details for this meeting I am invited
to)

TODO PUBLISH (publish an arbitrary set of action items)
TODO REQUEST
TODO REPLY
TODO CANCEL
TODO ADD
TODO COUNTER
TODO DECLINE COUNTER
TODO REFRESH

JOURNAL PUBLISH
JOURNAL REQUEST
JOURNAL REPLY
JOURNAL CANCEL
JOURNAL ADD
JOURNAL REFRESH

A typical CUA action is to look into the MIME entity bucket for new
invitations.

All of these scheduling messages "sub-sub types" are represented in the same
single calendar media type. Tell me again, how you are going a scalable way
for a "calendar portal" site that has 100s of thousands of calendar users
wanting this info each day to service requests from CUAs for "new
invitations" or "invitation responses"? You can't expect the calendar
service to be able to parse ALL of the thousands of XML entities that are in
the MIME entity bucket to first find the calendar ones and then the "new
invitations" or "invitation responses".

If calendaring doesn't provide a real enough example, think about electronic
commerce and the millions of transactions a site may be handling a day. We
can't expect an EDI client to have to parse each of the XML entities in the
MIME bucket to find the "purchase orders".

- - Frank

From: "Larry Masinter" <[email-masked]>
To: "Earthlink" <[email-masked]>, <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Date: Wed, 7 Apr 1999 14:56:06 PDT
Importance: Normal
Sender: [email-masked]

> >It's not clear that specialized media types solve any problem at all,
> >in the case of XML that already contains a document declaration.
> 

Ned corrected me. There are *some* problems that might be solved by
specialized media types.

> The overhead of having to open up every XML document to find out what
> document type it is is not practical. As in the case of email, all I should
> have to do is ask for a particular type of object from the store and get it.
> 
> In addition, though, we also want to get at subtypes of objects. Or in the
> case of MIME type/subtypes, this would be the "sub-sub type". For example,
> for a calendar object (text/calendar) we want to pull to the client just the
> "event invitations". This would be the "sub sub type" of type=text,
> subtype=calendar.

This is a good example of a problem that specialized media types won't solve.

You might also want to scan your email for "event invitations from my boss",
and you can't solve that problem with specialized MIME media types. So the
question is: are there any realistic cases where having a "text/calendar"
distinction in the email header actually helps substantially in deciding
which email bodies to retrieve?

Larry

From: "Earthlink" <[email-masked]>
To: "Larry Masinter" <[email-masked]>, <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Date: Wed, 7 Apr 1999 17:43:13 -0400
Sender: [email-masked]

>It's not clear that specialized media types solve any problem at all,
>in the case of XML that already contains a document declaration.

The overhead of having to open up every XML document to find out what
document type it is is not practical. As in the case of email, all I should
have to do is ask for a particular type of object from the store and get it.

In addition, though, we also want to get at subtypes of objects. Or in the
case of MIME type/subtypes, this would be the "sub-sub type". For example,
for a calendar object (text/calendar) we want to pull to the client just the
"event invitations". This would be the "sub sub type" of type=text,
subtype=calendar.

- - Frank

Date: Wed, 07 Apr 1999 14:36:03 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
To: Murray Altheim <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > > It's not clear that specialized media types solve any problem at all,
> > > in the case of XML that already contains a document declaration.
> >
> > On the contrary, it is very clear that they do solve at least some set of
> > problems. There is no explanation for the large numbers of people happily
> > registering these things otherwise. We have ample experience to tell us that
> > people won't bother with this sort of administration unless they see some
> > possible advantage to doing it, and won't continue to do it unless those
> > advantages turn out to be real.

> On the contrary, there may be a very plausible reason why 'large numbers of
> people' are registering specialized media types: there is no suitable
> alternative that is supported by the browser vendors at large. There may
> be very real advantages in an organized content negotiation scheme, but
> they can't be realized if there is no vendor support. I don't believe that
> resorting to file extensions can possibly be the way of the future. We
> all need a better alternative.

Murray, it sounds to me like you are agreeing with me, not disagreeing. All I
ever claimed was that contrary to Larry's assertion, it is clear that a real
problem is being solved by registering various XML-derived types. I never
claimed that this is the correct solution to the problem, or that this is the
only problem around that needs a solution, or that this wasn't a solution
forced by the current characteristics of browsers.

And nowhere did I say that file extensions are being used. These
are MIME types, not file extensions.

				Ned

From: "Earthlink" <[email-masked]>
To: "Larry Masinter" <[email-masked]>, <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Date: Wed, 7 Apr 1999 17:06:47 -0400
Sender: [email-masked]

Larry Masinter wrote:

>Many current implementations of content dispatch don't allow dispatch
>based on media type parameters, in any case. E.g., you can't select
>one handler for "text/plain;charset=us-ascii" and a different one
>for "text/plain;charset=utf8", even though you might have a more
>desirable ascii-only editor and a slower or fuller Unicode-based
>editor installed. So adding more parameters doesn't really help
>for content-dispatch with current implementations.

I think you may be thinking about HTTP? Certainly with a mail protocol like
IMAP you can look through your inbox for entries based on values of the MIME
header fields. The example mentioned was a "mail-enabled" application. For
this application, the implementors on the IETF CALSCH WG felt very much that
the MIME header field parameters were of importance.

If your implementation doesn't want to make use of them, fine. But other
applications of this MIME content-type need it. That is the point.

- - Frank

From: "Earthlink" <[email-masked]>
To: "Larry Masinter" <[email-masked]>, <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Date: Wed, 7 Apr 1999 17:02:34 -0400
Sender: [email-masked]

Larry Massinter wrote, in part:

>In general, you cannot solve the problem of "dispatch to the appropriate
>handler" by modifying MIME, since finding the appropriate handler is
>platform and installation dependent.

I don't think that MIME is broken. What was poorly thought out was the
content-type definition for XML.

- - Frank

Date: Wed, 07 Apr 1999 14:55:58 -0500
From: "Shane P. McCarron" <[email-masked]>
Reply-To: [email-masked]
Organization: MACS, Inc.
To: Murray Altheim <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Murray Altheim wrote:
> 
> Shane P. McCarron <[email-masked]> writes:
> [...]
> > In case it isn't obvious, I too lean toward each application "family"
> > having their own media type.  This is the only broadly recognized
> > announcement mechanism we have, after all.
> 
> In thinking about this more, I can see the value in defining a new
> media type 'text/xhtml' for the family iff we see that all applications
> within that space using the same infrastructure and mechanisms for
> extensibility, so that any application within that space can predict
> how to read what has been extended and the implications of the
> extension. We *may* be able to solve that with document profiles.
> 
> But if it's still open season within 'text/xhtml' then we've only put
> off the problem until later, and also compounded it by meaninglessly
> fragmented the 'text/xml' space. If there is a solution for XML it
> should be the same as for XHTML, and so my sense is that either the
> HTML WG's concept of document profiles is more usable generally in
> XML or we're duplicating what must also be done for XML.

Maybe the way to look at it is that the HTML WG is working in a space
and developing a solution that MAY scale to be a general solution.
However, the HTML space needs the solution now and we are in a good
position to define the solution for the generic HTML-oriented client
space.

I realize that it would be great if we could define a generic solution
for all XML documents, but I just don't see it happening quickly.  I
think that we can get an HTML-oriented solution ready in uni time
(before the end of the year), and I think that it will be a solution
that is readily implementable by our constituents (the wireless,
television, and desktop client manufacturers).  This would be a good
thing.

--
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, 7 Apr 1999 12:37:52 -0700 (PDT)
From: Murray Altheim <[email-masked]>
Reply-To: Murray Altheim <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Content-MD5: hFcbeW7n+Sv4FmQE4dMaFw==
Sender: [email-masked]

Ned Freed <[email-masked]> writes:
> Larry Masinter <[email-masked]> writes:
> > MURATA Makoto <[email-masked]> wrote:
> > 
> > > Are you also against specialized media types?  Or, you would like
> > > to make clear that specialized media types do not solve all problems?
> 
> > It's not clear that specialized media types solve any problem at all,
> > in the case of XML that already contains a document declaration.
> 
> On the contrary, it is very clear that they do solve at least some set of
> problems. There is no explanation for the large numbers of people happily
> registering these things otherwise. We have ample experience to tell us that
> people won't bother with this sort of administration unless they see some
> possible advantage to doing it, and won't continue to do it unless those
> advantages turn out to be real.

On the contrary, there may be a very plausible reason why 'large numbers of
people' are registering specialized media types: there is no suitable
alternative that is supported by the browser vendors at large. There may
be very real advantages in an organized content negotiation scheme, but
they can't be realized if there is no vendor support. I don't believe that
resorting to file extensions can possibly be the way of the future. We 
all need a better alternative.

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: Wed, 7 Apr 1999 12:21:56 -0700 (PDT)
From: Murray Altheim <[email-masked]>
Reply-To: Murray Altheim <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
To: [email-masked]
Cc: [email-masked]
Content-MD5: qvvvvt5gfmBJt1skw6QDkA==
Sender: [email-masked]

Shane P. McCarron <[email-masked]> writes:
[...]
> In case it isn't obvious, I too lean toward each application "family"
> having their own media type.  This is the only broadly recognized
> announcement mechanism we have, after all.

In thinking about this more, I can see the value in defining a new
media type 'text/xhtml' for the family iff we see that all applications
within that space using the same infrastructure and mechanisms for 
extensibility, so that any application within that space can predict
how to read what has been extended and the implications of the
extension. We *may* be able to solve that with document profiles.

But if it's still open season within 'text/xhtml' then we've only put 
off the problem until later, and also compounded it by meaninglessly 
fragmented the 'text/xml' space. If there is a solution for XML it 
should be the same as for XHTML, and so my sense is that either the
HTML WG's concept of document profiles is more usable generally in
XML or we're duplicating what must also be done for XML.

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: Wed, 07 Apr 1999 12:07:42 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
To: Larry Masinter <[email-masked]>
Cc: MURATA Makoto <[email-masked]>, [email-masked]
Sender: [email-masked]

> > Are you also against specialized media types?  Or, you would like
> > to make clear that specialized media types do not solve all problems?

> It's not clear that specialized media types solve any problem at all,
> in the case of XML that already contains a document declaration.

On the contrary, it is very clear that they do solve at least some set of
problems. There is no explanation for the large numbers of people happily
registering these things otherwise. We have ample experience to tell us that
people won't bother with this sort of administration unless they see some
possible advantage to doing it, and won't continue to do it unless those
advantages turn out to be real.

				Ned

Date: Wed, 07 Apr 1999 11:38:51 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
To: Larry Masinter <[email-masked]>
Cc: Ned Freed <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, [email-masked]
Sender: [email-masked]

> > > I tend to lean towards "every application gets a new media type".
> >
> > In case it isn't obvious by now, so do I.

> This is a fine maxim, but it begs the question: what constitutes
> a separate, distinct application, vs a modification, profile,
> extension, or varation of an old one?

> In the case where you're allowed to have a document that mixes
> traditional HTML, MathML, Vector Graphics ML, etc., are these
> separate "applications" or are they one "application" ("renderable
> XML document")?

But this then begs the more general question of whether there is to be an
attempt to "design" the XML usage space, and if there is, whether such an
attempt has any chance of succeeding.

If the answer to this is "no, we don't want to try and control the development,
direction, and use of XML" then your question is basically out of scope. People
will design whatever they want and register whatever they want. The resulting
mixtures and granularity will be whatever developers decide is appropriate. And
in such a world I see little value in having an XML top level type. (Perhaps no
real harm, but little value.)

However, if the answer to this is "yes", then the task at hand becomes one of
coming up with an appropriate set of rules that people think will actually do
the job and will be followed. And in such a world a top-level XML type might
have some value, if only as a place to attach the ruleset. (Delegation of XML
registration would also be something to consider.)

I basically don't have an opinion on which way this should go. My one
observation is that the IETF at least has typically opted to try and stay out
of areas like this in the past. 

				Ned

Date: Wed, 07 Apr 1999 13:43:05 -0500
From: "Shane P. McCarron" <[email-masked]>
Reply-To: [email-masked]
Organization: MACS, Inc.
To: Larry Masinter <[email-masked]>
CC: Ned Freed <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Larry Masinter wrote:
> 
> > > I tend to lean towards "every application gets a new media type".
> >
> > In case it isn't obvious by now, so do I.
> 
> This is a fine maxim, but it begs the question: what constitutes
> a separate, distinct application, vs a modification, profile,
> extension, or varation of an old one?
> 
> In the case where you're allowed to have a document that mixes
> traditional HTML, MathML, Vector Graphics ML, etc., are these
> separate "applications" or are they one "application" ("renderable
> XML document")?

Well...

The issue is certainly complex.  In the XHTML world, we envision a
plethora of derivative document types based upon the defined XHTML
modules and their semantics, other standard modules and THEIR semantics,
and privately defined modules and THEIR semantics.   While we are still
actively debating the definition of "XHTML Family", it is clear to me
that this family includes a significant subset of these derivative
document types.

So, if there is a type for XHTML (text/xhtml), then that type has to be
flexible enough in definition to accommodate all documents with a type
that falls within the XHTML family. A Conforming Client would be
required to handle any XHTML family document in some sensible manner.

So, in answer to your question, I think it is up to the developer of the
Media Type to define the rules for inclusion within that type, and to do
so carefully. If they do it wrong (as we did in text/html), then they
will be forced to live with their error forever.  If they do it right,
then future documents will forever be compatible in some manner.  Viola.

Too simple?  Perhaps.  Too much magic?  Perhaps again. However, we are
not in a position to dictate what every possible application might do in
the future.  Better to tell the application developers to be
circumspect, and let the market decide who did it right in the end.  

In case it isn't obvious, I too lean toward each application "family"
having their own media type.  This is the only broadly recognized
announcement mechanism we have, after all.
--
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: "Ned Freed" <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Date: Wed, 7 Apr 1999 10:44:57 PDT
Importance: Normal
Sender: [email-masked]

> > I tend to lean towards "every application gets a new media type".
> 
> In case it isn't obvious by now, so do I.

This is a fine maxim, but it begs the question: what constitutes
a separate, distinct application, vs a modification, profile,
extension, or varation of an old one?

In the case where you're allowed to have a document that mixes
traditional HTML, MathML, Vector Graphics ML, etc., are these
separate "applications" or are they one "application" ("renderable
XML document")?

Larry

Date: Wed, 07 Apr 1999 10:27:54 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Dispatching based on media types raises a few important issues that are
> somewhat unique to XML.

> If we say "every application gets a new media type" then there is no clean
> way for a MIME-handling application to fall back to handing an unknown
> media type to an XML parser. An unclean way for such an application to
> handle an unknown media type is to look inside the first few octets of the
> body and, if it looks like XML, hand it off to the XML parser instead of
> treating it as application/octet-stream or text/plain.

> If we say "stick everything XMLish under a media type that is XML-specific
> with some parameter for the kind of XML" then we assume that handing off
> unknown body types to an XML parser is useful. I question this assumption.

And I agree. While I have no strong objection to creating a special top-level
type for XML-based things, 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.

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

It is valuable in the case of a developer who wants to fire up an XML editing
tool. But let's be real here -- such a person had better be perfectly capable
of assigning types to their editor. If they cannot they had best look for
a new line of work.

> I tend to lean towards "every application gets a new media type".

In case it isn't obvious by now, so do I.

				Ned

Date: Wed, 07 Apr 1999 09:49:44 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
To: MURATA Makoto <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > > Each application will be documented by some RFC.
> >
> > This isn't true. The standards say that RFC documentation is only required for
> > registration in the IETF tree, and in practice none of the many registered
> > XML-based types have been backed up with RFCs.

> I will revise the summary accordingly.  Registration in the IETF tree and
> that in the vendor tree are quite different.

Moreover, relatively few types belong in the IETF tree.

> > > Each specialized application will require a new subtype registration,
> > > which takes a lot of time and therefore can have long delays.
> >
> > This isn't true. Registrations now routinely take only a few days if
> > they don't contain egregious errors. And we've been known to get them done
> > in less than a day in some cases.

> Is this in the vendor tree?

The registration process is the same (i.e. fast) in *any* tree that
currently exists. The slowness associated with the IETF tree has to do with
RFC review, which is an entirely separate process from type registration.

The only case where I could imagine the registration process being slow is if
we delegate registration trees to some other organization that doesn't do it as
quickly as we do. However, thus far no such delegation has taken place, so this
is an entirely academic point.

				Ned

Date: Wed, 07 Apr 1999 09:45:16 -0700
To: Paul Hoffman / IMC <[email-masked]>, <[email-masked]>
From: Tim Bray <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

At 09:28 AM 4/7/99 -0700, Paul Hoffman / IMC wrote:
>Dispatching based on media types raises a few important issues that are 
>somewhat unique to XML.

While I still haven't thought all this through 100%, Paul has a good
point.  There are two models we're going to see in the real world.

1. something generic gets the XML and parses it
 1.a the generic something displays the XML to a human using a 
     stylesheet, possibly with help from other logic for embedded chunks
     from different namespaces.
 1.b the generic something invokes some application.

 The 1.a example is of course Web browsers (although it seems there 
 are some nasty architectural holes in how you dispatch control for 
 embedded chunks of XML).  I have a hard time thinking of a 1.b
 example.

2. An app gets invoked to deal with a resource that happens to
   be encoded in XML, and the app uses its built-in XML parser.
   This case probably wants its own media type; the fact that 
   the encoding is XML is hardly material.

Which of these will be more common?  I don't think anyone knows.
But they are both very plausible and we need to make sure there's
a good coherent story either way.  -Tim

Date: Wed, 07 Apr 1999 09:28:31 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Dispatching based on media types raises a few important issues that are 
somewhat unique to XML.

If we say "every application gets a new media type" then there is no clean 
way for a MIME-handling application to fall back to handing an unknown 
media type to an XML parser. An unclean way for such an application to 
handle an unknown media type is to look inside the first few octets of the 
body and, if it looks like XML, hand it off to the XML parser instead of 
treating it as application/octet-stream or text/plain.

If we say "stick everything XMLish under a media type that is XML-specific 
with some parameter for the kind of XML" then we assume that handing off 
unknown body types to an XML parser is useful. I question this assumption. 
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.

I tend to lean towards "every application gets a new media type".

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 7 Apr 1999 09:03:08 -0700 (PDT)
From: Murray Altheim <[email-masked]>
Reply-To: Murray Altheim <[email-masked]>
Subject: XHTML Schemas, Namespace Ids, and Profiles
To: [email-masked], [email-masked]
Content-MD5: 3XW0TK+3SzgClCJO79tTFA==
Sender: [email-masked]

[time for a new thread...]

Paul Grosso <[email-masked]> writes:
> At 14:35 1999 04 05 +0900, Martin J. Duerst wrote:
> >Define one parameter, maybe named "namespaces", that lists, comma-separated,
> >all the namespaces used in the document. The DOCTYPE, if present, counts as
> >one. The DOCTYPE, or the namespace of the root element, is listed first.
> >If other description mechanisms (schemas,...) are defined, the URIs used
> >for them can also be used.
> 
> This is extremely ironic given that the original namespace proposal
> developed by the XML WG was to have namespace declarations only in
> the prolog (at the top) of an XML document.  This would have made
> lots of things easier, but higher authorities decided that it was 
> necessary to completely revamp the namespace proposal at the last 
> minute to give locally scoped namespace declarations.

I've long argued that the truly broken part of the current namespace
proposal is that the namespace 'declaration' occurs in the instance,
and that any sort of multiple-document type schema processing must
occur in the prolog, potentially even before the schema/DTD is
encountered. For example, if I were to write an application that
colonized several DTDs before attempting validation of an instance
containing colonized names, I'd need to see the declarations *before*
the DTDs. Apparently some do not see the prolog-instance separation
as valuable.

One of the things I've also been trying to assert in the HTML WG is
the separation between the document type definition and the document
[instance's] namespace.

In documents containing a DOCTYPE the former is provided, and the
namespace 'declaration' (damn, I can never quite remove those quotes)
provides the namespace identifier. For XHTML, there is essentially 
one namespace, as regardless of which of the three DTDs (Strict, 
Transitional, or Frameset) the semantics for understanding and 
processing a specific element type are identical.

One of the HTML WG work items is 'document profiles', some sort of 
extensible metadata container for information about the document 
type or instance. This might contain MIME information, further links
to schema documentation, author contact info, interoperability data,
etc. My thinking is that it would be hierarchical and potentially
full of external links, so that applications can dig as deep as 
necessary for further information. Or simply use either the profile
identifier or some node-level sub-identifier as a cookie.

We'd for awhile discussed using the existing 'profile' attribute 
on <head>, but for some reason which I can't recall now have moved 
away from that (either some people thought that we might not require 
<head> in all XHTML 'family' doctypes, or that it was overloading 
the attribute). I do think it better as a separate element type,
as this allows containment (and therefore inlining of a profile 
within a document).

My current favorite syntax for linking a profile would borrow ideas
from existing HTML stylesheet syntax, allowing for either an inline 
profile, or a link to an external profile. I think most people would
find this intuitively obvious (given experience with stylesheets).
Simple processors could use the profile URI as a cookie, or retrieve
it to obtain further data. 

    <?xml version="1.0 ?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/1999/xhtml/xhtml1-strict.dtd" >
    <html xmlns="http://www.w3.org/TR/1999/html-in-xml">
    <head>
    <title>The Cruise of the Jasper B.</title>
    <link rel="stylesheet" type="text/css"
`        href="http://www.altheim.com/styles/marquis.css" />
    <link rel="profile" type="text/rdf"
        href="http://www.w3c.com/profiles/xhtml1-s.pfl" />
    </head>
    ...

or expanded:
    
    <?xml version="1.0 ?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/1999/xhtml/xhtml1-strict.dtd" >
    <html xmlns="http://www.w3.org/TR/1999/html-in-xml">
    <head>
    <title>The Cruise of the Jasper B.</title>
    <style type="text/css">
       body { background : white }
       h1, h2, h3, h4 { color : #800080 ;
           font-family : "SomeFontYouDontHave", sans-serif }
       ...
    </style>
    <profile type="text/rdf"
        href="http://www.altheim.com/styles/marquis.css">
    ...TBD...
    </profile>
    </head>
    ...

The second example still includes the href, to point out the need to 
create a way to maintain a named identifier for profiles, if such an 
identifier is ever to be used as a cookie. Perhaps the 'title' attribute
or some other means would be better -- just some ideas anyway.

Above we see declarations for:

   (a) the XML declaration (potentially the encoding, etc.)
   (b) the DTD's name (publicId/FPI/URN)
   (c) the DTD's location (systemId/URI)
   (d) the document namespace identifier (as URI)
   (e) the document stylesheet type and location (URI)
   (f) the document profile location (URI)    

and while obviously not all are needed all the time, I can certainly
see the ability to maintain this separation being quite valuable. 

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: Wed, 07 Apr 1999 09:53:13 -0500
To: [email-masked]
From: Paul Grosso <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

At 14:35 1999 04 05 +0900, Martin J. Duerst wrote:
>Define one parameter, maybe named "namespaces", that lists, comma-separated,
>all the namespaces used in the document. The DOCTYPE, if present, counts as
>one. The DOCTYPE, or the namespace of the root element, is listed first.
>If other description mechanisms (schemas,...) are defined, the URIs used
>for them can also be used.

This is extremely ironic given that the original namespace proposal
developed by the XML WG was to have namespace declarations only in
the prolog (at the top) of an XML document.  This would have made
lots of things easier, but higher authorities decided that it was 
necessary to completely revamp the namespace proposal at the last 
minute to give locally scoped namespace declarations.

Now there is this suggestion to collect all declared namespaces at
the top of the document again.  Isn't this going around in circles?
Whatever the reasons for going with locally scoped declarations, aren't
most of them also reasons against listing all such decls at the top?

Date: Wed, 07 Apr 1999 06:45:13 -0700
To: "Larry Masinter" <[email-masked]>, "MURATA Makoto" <[email-masked]>, <[email-masked]>
From: Tim Bray <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

At 11:58 PM 4/6/99 PDT, Larry Masinter wrote:
>It's not clear that specialized media types solve any problem at all,
>in the case of XML that already contains a document declaration.

Whereas I may well agree with Larry, I have to raise a red flag in
connection with the term "document declaration".  XML has something
called a "document type declaration" which despite its name essentially
gives no useful information about the type of the document or what
software ought to be invoked to process it.

The new namespace declarations should turn out to be more
useful in software dispatching. -Tim

From: MURATA Makoto <[email-masked]>
Date: Wed, 07 Apr 1999 21:25:24 +0900
To: [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Martin J. Duerst wrote:
> 
> > How can a MIME processor or vCard application extract a vCard fragment 
> > from the XML document?  To do so, somebody has to parse the document.  But 
> > if somebody has to parse it anyway, it should be really easy to find 
> > which namespace appears in the document.  Thus, there is not much point 
> > in having namespace information in the MIME header.
> 
> If we apply this argument fully, then the doctype is also not necessary.

Exactly.

I would like to know advantages and disadvantages of Larry's obvious 
solution (i.e., dispatch to the general-purpose XML parser which further 
dispatch to appropriate applictions).

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

Date: Wed, 07 Apr 1999 16:33:23 +0900
To: MURATA Makoto <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Cc: [email-masked]
Sender: [email-masked]

At 15:31 99/04/07 +0900, MURATA Makoto wrote:
> Martin J. Duerst wrote:

> > Define one parameter, maybe named "namespaces", that lists, comma-separated,
> > all the namespaces used in the document. The DOCTYPE, if present, counts as
> > one. The DOCTYPE, or the namespace of the root element, is listed first.
> > If other description mechanisms (schemas,...) are defined, the URIs used
> > for them can also be used.
> 
> I am wondering if it is really a good idea to put every information in 
> the MIME header.

Definitely not.

> How can a MIME processor or vCard application extract a vCard fragment 
> from the XML document?  To do so, somebody has to parse the document.  But 
> if somebody has to parse it anyway, it should be really easy to find 
> which namespace appears in the document.  Thus, there is not much point 
> in having namespace information in the MIME header.

If we apply this argument fully, then the doctype is also not necessary.

I think that, in order to decide which application(s) handle the document,
what we have to think about is things such as:

- What namespaces are included in the document.
- Which of these namespaces have to be understood completely in order
  to process the document reasonably.
- Which of these namespaces can be processed partially, or just ignored.

There may be applications that can e.g. only process pure XHTML, or
XHTML with some other namespaces, or XHTML with any additional namespaces,
and so on.

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

From: "Larry Masinter" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Date: Tue, 6 Apr 1999 23:58:49 PDT
Importance: Normal
Sender: [email-masked]

> Are you also against specialized media types?  Or, you would like 
> to make clear that specialized media types do not solve all problems?

It's not clear that specialized media types solve any problem at all,
in the case of XML that already contains a document declaration.

For other situations, specialized media types should be introduced
with caution, since a world in which every kind of document has its
own media types is one in which there is little interoperability.

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

From: MURATA Makoto <[email-masked]>
Date: Wed, 07 Apr 1999 15:41:37 +0900
To: <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Larry Masinter wrote:
> As far as I can tell, adding parameters doesn't solve the problem,
> and introduces other, possibly more severe, problems. So yes, I'm
> arguing against it.

Are you also against specialized media types?  Or, you would like 
to make clear that specialized media types do not solve all problems?

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: Wed, 07 Apr 1999 15:39:19 +0900
To: <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Larry Masinter wrote:
> 
> 
> You left out the obvious one: for some kinds of media, it is necessary
> for the handler of the MIME media type to actually dispatch to one
> of several possible media type handlers. Rather than fixing MIME,
> which does the job of labelling data adequately, why not fix the software?

Yes, the summary (which was compiled long time ago) dos not have this 
obvious one.  I will add this option.

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: Wed, 07 Apr 1999 15:37:03 +0900
To: [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Ned,

Thank you for your comments.

 Freed wrote:

> > Each application will be documented by some RFC.
> 
> This isn't true. The standards say that RFC documentation is only required for
> registration in the IETF tree, and in practice none of the many registered
> XML-based types have been backed up with RFCs.

I will revise the summary accordingly.  Registration in the IETF tree and 
that in the vendor tree are quite different.

> > Each specialized application will require a new subtype registration,
> > which takes a lot of time and therefore can have long delays.
> 
> This isn't true. Registrations now routinely take only a few days if
> they don't contain egregious errors. And we've been known to get them done
> in less than a day in some cases.

Is this in the vendor tree?

> > (3) A new parameter "externalid" for text/xml and application/xml
...
> I'm afraid you've missed the biggest problem with this approach -- one 
> that makes it almost a complete nonstarter: The lack of ability to dispatch
> on parameters in most applications that support MIME.

I will add this fact to the summary.

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: Wed, 07 Apr 1999 15:31:09 +0900
To: [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Martin J. Duerst wrote:
I wrote:
> > Note: None of the above proposals handle non-monolithic XML documents very well, 
> > since different islands of non-monolithic XML documents belong to different 
> > namespaces and thus different schemata.  For example, the MIME parser cannot 
> > invoke vCard applications if the vCard is embeded by the namespace mechanism.
> 
> I think this will become more and more important, and we should try to find
> a solution that doesn't exclude it. On first sight, it doesn't look so difficult:
> 
> Define one parameter, maybe named "namespaces", that lists, comma-separated,
> all the namespaces used in the document. The DOCTYPE, if present, counts as
> one. The DOCTYPE, or the namespace of the root element, is listed first.
> If other description mechanisms (schemas,...) are defined, the URIs used
> for them can also be used.

I am wondering if it is really a good idea to put every information in 
the MIME header.

How can a MIME processor or vCard application extract a vCard fragment 
from the XML document?  To do so, somebody has to parse the document.  But 
if somebody has to parse it anyway, it should be really easy to find 
which namespace appears in the document.  Thus, there is not much point 
in having namespace information in the MIME header.

Cheers,

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

To: [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list 
Date: Tue, 06 Apr 1999 16:50:52 -0400
From: "Donald E. Eastlake 3rd" <[email-masked]>
Sender: [email-masked]

I consider the original question to have been pretty insulting.  There
is only one set of MIME types for all uses.  The name of the list is
ietf-xml-mime, not email-xml-mime.  If it had been hosted at the W3C,
would non-web uses have been ignored?

Donald

From:  Paul Hoffman / IMC <[email-masked]>
Message-Id:  <[email-masked]>
X-Sender:  [email-masked]
Date:  Tue, 06 Apr 1999 09:47:36 -0700
To:  Chris Lilley <[email-masked]>
Cc:  [email-masked]
In-Reply-To:  <[email-masked]>
References:  <[email-masked]>
List-Archive:  <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-Unsubscribe:  <mailto:[email-masked]?body=unsubscribe>

>At 02:46 PM 4/6/99 +0200, Chris Lilley wrote:
>>Given the host of the list (Internet Mail Consortium)
>
>Hey, we host lists that have little or nothing to do with email (not that I 
>try to do that too often...)
>
>> I would like to
>>first ask for a clarification; is the topic of discussion *just* the use
>>of MIME with XML for email, or does it also include the use of MIME with
>>XML for HTTP and any other protocols.
>
>The latter.
>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Tue, 06 Apr 1999 09:47:36 -0700
To: Chris Lilley <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Cc: [email-masked]
Sender: [email-masked]

At 02:46 PM 4/6/99 +0200, Chris Lilley wrote:
>Given the host of the list (Internet Mail Consortium)

Hey, we host lists that have little or nothing to do with email (not that I 
try to do that too often...)

> I would like to
>first ask for a clarification; is the topic of discussion *just* the use
>of MIME with XML for email, or does it also include the use of MIME with
>XML for HTTP and any other protocols.

The latter.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 06 Apr 1999 14:46:03 +0200
From: Chris Lilley <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> OK, we've got about 30 people who signed up for the list. I think the first
> order of business is for someone to say what is incorrect and/or lacking in
> RFC 2376.

Given the host of the list (Internet Mail Consortium) I would like to
first ask for a clarification; is the topic of discussion *just* the use
of MIME with XML for email, or does it also include the use of MIME with
XML for HTTP and any other protocols.

--
Chris

From: MURATA Makoto <[email-masked]>
Date: Mon, 05 Apr 1999 17:30:22 +0900
To: [email-masked]
Subject: List of issues
Sender: [email-masked]

I compiled a list of issues raised in the past. Although there 
are seven issues in this list, I would like to concentrate on 
the first issue for a while.

Issue 1: Proposals for additional parameters in the past

Namespace URI:
  It specifies the URI of the top-level namespace of the XML document

Schema URI
  It specifies the URI of the top-level schema of the XML document

DTD URI:
  It specifies the URI of the DTD of the XML document

Class URI:
  It specifies the class of the XML document which will be handled 
  by the same application programs (Note: RDF metadata are XML 
  documents without DTD's, but every RDF metadata can be handled 
  by the same program.  XML documents with CSS stylesheets can be 
  displayed by WWW browsers, evenif they do not have DTDs.)

Conformance Profile URI:
  It specifies an XHTML conformance profile.

Application URI:
  It speficies the URI of application programs

Root element type: 
  This was suggested as an addition to the namespace/schema/DTD/class URI.

Issue 2: Type of XML mime entities

There are four types of XML MIME entities.  In the XML terminology,
they are called "document entities", "external DTD subsets", "external
parsed entities", and "external parameter entities".  The media types
text/xml and application/xml can be used for any of these four types.

Do we need some parameter to distinguish these four types?  (Note that
a MIME entity can be an external parsed entity AND a document entity
at the same time.  Some external DTD subsets can also be used as
external parameter entities.)

Issue 3: UTF-16

RFC 2376 should be revised when charsets for UTF-16 are registered.
Currently, there is an internet draft <draft-hoffman-utf16-02.txt> 
for UTF-16 registration.

Issue 4: Characters .vs. bytes

An XML MIME entity is a sequence of characters as opposed to a
sequence of bytes.  RFC 2376 is not really clear about this.

Issue 5: Packaging

There should be a mechanism for packaging an XML document together
with its stylesheet, catalog, and referenced resources (e.g., links,
external entities).  One possibility is MHTML.

ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-info-11.txt
ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-rev-07.txt

Issue 6: Ambiguity of CCS conversion

If an XML document is encoded in some charset whose CCS is not
Unicode, XML processors will map the CCS to Unicode.  For example, in
the case of Shift_JIS, we need a mapping from JIS X 0201 + JIS X0208
to Unicode.  Unfortunately, there are more than one mapping in the
world.  For example, the XML parser of IBM uses Javasoft mapping and
that of Javasoft uses Microsoft mapping.  I heard that many other
charsets have such ambiguities.

If this is the case, it might make sense to introduce a parameter
"map" to precisely specify which mapping should be used.

Issue 7: The default of the charset parameter

Chris Lilley's recent proposal to revised RFC2376 is as below:

> 1) Require explicit charset for overriding the internal encoding
> declaration, so if one really wants to re-label a document as US-ASCII
> one actually has to send it out as text/xml; charset="US-ASCII"
> 
> 2) Define the absence  of an explicit charset encoding in the MIME
> header not as "US-ASCII" but as "use encoding in XML instance" in
> accordance with the XML 1.0 Recommendation.

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: "Tim Bray" <[email-masked]>, "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Date: Sun, 4 Apr 1999 23:36:22 PDT
Importance: Normal
Sender: [email-masked]

> At 11:09 PM 4/4/99 PDT, Larry Masinter wrote:
> >In general, you cannot solve the problem of "dispatch to the appropriate
> >handler" by modifying MIME, since finding the appropriate handler is
> >platform and installation dependent.
> 
> Although you don't say so, I believe you are arguing against the
> desirability of an additional media type parameter.  Right? -T.

As far as I can tell, adding parameters doesn't solve the problem,
and introduces other, possibly more severe, problems. So yes, I'm
arguing against it.

Larry

Date: Sun, 04 Apr 1999 23:05:23 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
To: MURATA Makoto <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> (1) Specialized mime types

> For each specialized applications of XML, we introduce a new subtype.
> It may introduce more parameters and might even have some added
> security consideration.  This is the approach that has been assumed by
> the authors of RFC2376.

And it is what is already happening. We've registered several dozen of
these already.

> Pros:

> Each application will be documented by some RFC.

This isn't true. The standards say that RFC documentation is only required for
registration in the IETF tree, and in practice none of the many registered
XML-based types have been backed up with RFCs.

> Cons:

> When the MIME parser does not know of such a subtype, the only
> available fallback is text/plain or application/octet-stream.  That
> is, the MIME parser cannot invoke generic XML parsers/viewers, but has
> to display the document as a plain text file or save the document in a
> file.

This is a legitimate concern, although in practice what happens is that
applications let you assign a viewer to an unknown type in fairly flexible
ways. In other words, in practice this isn't all that much of a problem.

> Each specialized application will require a new subtype registration,
> which takes a lot of time and therefore can have long delays.

This isn't true. Registrations now routinely take only a few days if
they don't contain egregious errors. And we've been known to get them done
in less than a day in some cases.

Registrations containing errors take longer, of course. But feedback is quick,
typically taking only a day or two, so the burden is on the person doing the
registration to turn the thing around in a timely way.

> (2) New top-level media type xml and its subtypes

> Pros:

> Fallback to "xml/plain" allows the use of generic XML parsers/viewers.

> We can also lift the line termination rule of the top-level media type
> "text".

Most XML objects have no business being registered under text anyhow,  so this
isn't much of an advantage.

> Cons:

> It is extremely difficult to register a new top-level media type and
> therefore can have long delays (practically, who wants to do this?).
> The default behavior is probably not a good enough reason.

It isn't a question of difficulty, it is a question of legitimacy. To do
this you have to write a document that justifies the creation of such a thing.
Do so and you likely won't have much of a problem, fail to do so and
this approach isn't viable.

> Each specialized application will require a new subtype registration,
> which takes a lot of time and therefore can have long delays.

Again, this just isn't true.

> (3) A new parameter "externalid" for text/xml and application/xml

> This parameter specifies the externalID from the DOCTYPE of the XML
> document (if the DOCTYPE is present).  Examples would be:

> Content-type: text/xml;
>    externalid="http://www.foo.com/whizzy.dtd"
> or
> Content-type: application/xml; charset="utf-16be";
>    externalid="-//IETF//DTD vCard v3.0//EN"

> Pros:

> This is probably the easiest solution which also provides XML-specific
> fallback.

> Requires no registration with a central authority.

> Other parameters can be added in the future when we have new schemata
> or when we find new usage patterns for DTDs. The definitions for those
> parameters can define which sets of parameters can appear together.

> Cons:

> ...

I'm afraid you've missed the biggest problem with this approach -- one 
that makes it almost a complete nonstarter: The lack of ability to dispatch
on parameters in most applications that support MIME. Not only do applications
lack this ability, there are also quite a few contexts where MIME labelling
is used that don't support parameters, period. So in all these cases you
end up being reduced to a single dispatch path for everything that's based
on XML. As I say, its a total nonstarter.

> (4) Yet another parameter "optinfo" or "ADD-PARAM"

This has all the problems of (3).

				Ned

Date: Sun, 04 Apr 1999 23:17:02 -0700
To: "Larry Masinter" <[email-masked]>, "MURATA Makoto" <[email-masked]>, <[email-masked]>
From: Tim Bray <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

At 11:09 PM 4/4/99 PDT, Larry Masinter wrote:
>In general, you cannot solve the problem of "dispatch to the appropriate
>handler" by modifying MIME, since finding the appropriate handler is
>platform and installation dependent.

Although you don't say so, I believe you are arguing against the
desirability of an additional media type parameter.  Right? -T.

Date: Mon, 05 Apr 1999 14:35:56 +0900
To: MURATA Makoto <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Cc: [email-masked]
Sender: [email-masked]

At 12:33 99/04/05 +0900, MURATA Makoto wrote:
> Paul Hoffman / IMC wrote:
> > OK, we've got about 30 people who signed up for the list. I think the first 
> > order of business is for someone to say what is incorrect and/or lacking in 
> > RFC 2376.
> 
> Here it is.  I will also post my summary of the discussion at the xml-dev 
> mailing list very soon.

> (3) A new parameter "externalid" for text/xml and application/xml
> 
> This parameter specifies the externalID from the DOCTYPE of the XML
> document (if the DOCTYPE is present).  Examples would be:
> 
> Content-type: text/xml;
>    externalid="http://www.foo.com/whizzy.dtd"
> or
> Content-type: application/xml; charset="utf-16be";
>    externalid="-//IETF//DTD vCard v3.0//EN"

> Note: None of the above proposals handle non-monolithic XML documents very well, 
> since different islands of non-monolithic XML documents belong to different 
> namespaces and thus different schemata.  For example, the MIME parser cannot 
> invoke vCard applications if the vCard is embeded by the namespace mechanism.

I think this will become more and more important, and we should try to find
a solution that doesn't exclude it. On first sight, it doesn't look so difficult:

Define one parameter, maybe named "namespaces", that lists, comma-separated,
all the namespaces used in the document. The DOCTYPE, if present, counts as
one. The DOCTYPE, or the namespace of the root element, is listed first.
If other description mechanisms (schemas,...) are defined, the URIs used
for them can also be used.

If I'm overlooking something, please tell me.

Regards,   Martin.

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

From: "Larry Masinter" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: RE: Starting the ietf-xml-mime mailing list
Date: Sun, 4 Apr 1999 23:09:03 PDT
Importance: Normal
Sender: [email-masked]

> 1. Problem statement
> 
> We would like the MIME parser to be able to dispatch different sorts
> of XML documents to different applications, such as specialized
> programs that handle just one type of XML document.  Because MIME
> parsers do not look inside the MIME parts, identifiying the sort of
> documents must be done in the MIME headers.  However, neither text/xml
> nor application/xml allow such information.
> 
> 2. Possible solutions
> 
> Three approaches have been proposed.  They are (1) specialized media
> types such as text/calendar, (2) a top-level media type xml and its
> subtypes such as xml/calendar, and (3) a new parameter "externalid" of
> text/xml and applcation/xml.

You left out the obvious one: for some kinds of media, it is necessary
for the handler of the MIME media type to actually dispatch to one
of several possible media type handlers. Rather than fixing MIME,
which does the job of labelling data adequately, why not fix the software?

In general, you cannot solve the problem of "dispatch to the appropriate
handler" by modifying MIME, since finding the appropriate handler is
platform and installation dependent.

Some elements of this argument were taking place in a discussion with
the W3C HTML working group, which was considering registering 
"text/xhtml" as a way of representing the XMLified version of HTML.

MIME types are also used in some instances in "content negotiation"
(prospectively telling a recipient what something would be if it
were to be subsequently retrieved), as well as in "content labelling".
New media types and media parameters don't help much with either,
unfortunately.

Many current implementations of content dispatch don't allow dispatch
based on media type parameters, in any case. E.g., you can't select
one handler for "text/plain;charset=us-ascii" and a different one
for "text/plain;charset=utf8", even though you might have a more
desirable ascii-only editor and a slower or fuller Unicode-based
editor installed. So adding more parameters doesn't really help
for content-dispatch with current implementations.

And adding more MIME types for each kind of combination of XML
seems like a recipe for disaster. If we have html, xhtml,
html-netscape, html-microsoft, html-optimized-for-msie-on-windows-nt50,
each with slightly different definitions, would they get separate
MIME types?

The same arguments apply for profiles of TIFF, and probably apply
to profiles of Postscript. Postscript-2-laserwriter-fonts isn't
a separate MIME type from Postscript-1, even though in situations,
you might have the capability of displaying one but only printing
the other.

Date: Sun, 04 Apr 1999 20:38:54 -0700
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

At 08:04 PM 4/4/99 -0700, Paul Hoffman / IMC wrote:
>OK, we've got about 30 people who signed up for the list. I think the first 
>order of business is for someone to say what is incorrect and/or lacking in 
>RFC 2376.

And just to save folks a couple of keyclicks, that's at

 http://www.cis.ohio-state.edu/htbin/rfc/rfc2376.html

 -Tim

From: MURATA Makoto <[email-masked]>
Date: Mon, 05 Apr 1999 12:33:03 +0900
To: [email-masked]
Subject: Re: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> OK, we've got about 30 people who signed up for the list. I think the first 
> order of business is for someone to say what is incorrect and/or lacking in 
> RFC 2376.

Here it is.  I will also post my summary of the discussion at the xml-dev 
mailing list very soon.

Makoto
-------------------------------------------------------------
Needs more information in the MIME header! (DRAFT)

MURATA Makoto, Paul Hoffman, Frank Dawson, Jim Whitehead

1. Problem statement

We would like the MIME parser to be able to dispatch different sorts
of XML documents to different applications, such as specialized
programs that handle just one type of XML document.  Because MIME
parsers do not look inside the MIME parts, identifiying the sort of
documents must be done in the MIME headers.  However, neither text/xml
nor application/xml allow such information.

2. Possible solutions

Three approaches have been proposed.  They are (1) specialized media
types such as text/calendar, (2) a top-level media type xml and its
subtypes such as xml/calendar, and (3) a new parameter "externalid" of
text/xml and applcation/xml.

(1) Specialized mime types

For each specialized applications of XML, we introduce a new subtype.
It may introduce more parameters and might even have some added
security consideration.  This is the approach that has been assumed by
the authors of RFC2376.

Pros:

Each application will be documented by some RFC.

Cons: 

When the MIME parser does not know of such a subtype, the only
available fallback is text/plain or application/octet-stream.  That
is, the MIME parser cannot invoke generic XML parsers/viewers, but has
to display the document as a plain text file or save the document in a
file.

Each specialized application will require a new subtype registration,
which takes a lot of time and therefore can have long delays.

(2) New top-level media type xml and its subtypes

Pros:

Fallback to "xml/plain" allows the use of generic XML parsers/viewers.

We can also lift the line termination rule of the top-level media type
"text".

Cons:

It is extremely difficult to register a new top-level media type and
therefore can have long delays (practically, who wants to do this?).
The default behavior is probably not a good enough reason.

Each specialized application will require a new subtype registration,
which takes a lot of time and therefore can have long delays.

(3) A new parameter "externalid" for text/xml and application/xml

This parameter specifies the externalID from the DOCTYPE of the XML
document (if the DOCTYPE is present).  Examples would be:

Content-type: text/xml;
   externalid="http://www.foo.com/whizzy.dtd"
or
Content-type: application/xml; charset="utf-16be";
   externalid="-//IETF//DTD vCard v3.0//EN"

Pros:

This is probably the easiest solution which also provides XML-specific
fallback.

Requires no registration with a central authority.

Other parameters can be added in the future when we have new schemata
or when we find new usage patterns for DTDs. The definitions for those
parameters can define which sets of parameters can appear together.

Cons:

DTD's do not necessarily exist.  For example, RFD metadata do not have
DTD's.

The use of DTD's to choose applications might be an abuse of DTD's.
Moreover, some DTD's might be handled by many different programs on a
system, such as by a specialized processor and one or more XML
browsers.  On the other hand, some applications (such as XML browsers)
handle a variety of DTD's.

There will be new schemata that will probably overshadow DTD's, and
these schemata may not use externalIDs the same way they are used in
today's DTDs.

(4) Yet another parameter "optinfo" or "ADD-PARAM"

On top of (3), provide yet another parameter "optinfo" (list of name-value pairs) 
or "ADD-PARAM" (plain text) for additional information.

Pros:

Some applications of XML require even more appliction-specfic information so 
as to launch appropriate software tools.  For example, if iCalendar information 
is captured by an XML DTD, the text/xml or application/xml MIME header has 
to mimick "method", "component", and "optinfo" of text/icalendar.  (The 
latest internet draft for text/icalendar is available at:  
ftp://ftp.isi.edu/internet-drafts/draft-ietf-calsch-ical-12.txt)

If this parameter is not available, people will abuse the parameter "externalid" 
by providing different names for the same DTD so as to express more information.  
This parameter stops such abuse.

Cons:

The "optinfo" parameter makes it difficult for a simple MIME parser to know 
what to expect in the parameter.   The "ADD-PARAM" parameter does not have 
this problem, but does not have enough expressiveness.

Note: None of the above proposals handle non-monolithic XML documents very well, 
since different islands of non-monolithic XML documents belong to different 
namespaces and thus different schemata.  For example, the MIME parser cannot 
invoke vCard applications if the vCard is embeded by the namespace mechanism.

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

Date: Sun, 04 Apr 1999 20:04:32 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Starting the ietf-xml-mime mailing list
Sender: [email-masked]

OK, we've got about 30 people who signed up for the list. I think the first 
order of business is for someone to say what is incorrect and/or lacking in 
RFC 2376.

--Paul Hoffman, Director
--Internet Mail Consortium