Subject: RE: text/xhtml+xml vs. application/xhtml+xml
From: [email-masked]
To: Gavin Thomas Nicol <[email-masked]>
Cc: [email-masked]
Date: Tue, 31 Oct 2000 20:08:35 -0700 (PDT)
List-Id: <ietf-xml-mime.imc.org>

> > But the  analogy is gravely flawed in any case -- text/html
> > has proved to have no value whatsoever. And this goes far
> > beyond the notion of "good" and "bad" use.

> I think the millions of messages sent using text/html would
> disprove the notion that "text/html has proved to have no value
> whatsoever".

Actually, the type's use proves nothing, since as I pointed out previously, it
isn't necessary to use the type to get the right effect.

> It seems to me that you are projecting a subjective
> analysis. It's fair to say that text/html is not being used as
> intended. That is not the same as saying it is of no use.

And you are arguing a strawman here. I never said that sending HTML
was of no use, only that the labelling of it as text/html was and
is unnecessary.

> Anyway, the genie *is* out of the bag.

For HTML it is. Doesn't mean it is out of the bag for other types. We should
learn from our mistakes.

> > > because again, of (supposed) interoperability, and because they
> > > didn't have any escape route.
> >
> > Sure they did. Application/html combined with a content-disposition
> > label of "inline" offers all the benefits and has none of the
> > problems.

> If that is the case then why didn't the MUA's adopt this?

Because it isn't what we told them to do. We told them to use text/html, so
that's what they did. But we also said that the HTML had to be legible. That
didn't happen.

Again, I'm not blaming anybody for this. It happened, it was a mistake, or
an expectation mismatch, or whatever else you want to call it. The point
is now we know better, so we should not let it happen again.

> > > With HTML, the genie is already out of the bottle, but with XML
> > > there is a chance to get MUA's working as they should: when
> > > sending textual data, use text/xml, but when sending application
> > > specific data, send application/foo+xml, etc.
> >
> > In case it isn't obvious, I am strongly opposed to this policy.

> It's obvious, but that doesn't discount it.

I believe my argument discounts it quite effectively. In addition, I haven't
noticed a lot of support for other quarters for your approach.

				Ned

Date: Tue, 31 Oct 2000 13:45:34 -0500
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Fwd: Protocol Action: XML Media Types to Proposed Standard
Sender: [email-masked]

This list wasn't CC'd, but I thought you all might want to know.

>To: IETF-Announce: ;
>Cc: RFC Editor <[email-masked]>, IANA <[email-masked]>
>Cc: Internet Architecture Board <[email-masked]>
>From: The IESG <[email-masked]>
>Subject: Protocol Action: XML Media Types to Proposed Standard
>Date: Tue, 31 Oct 2000 07:38:26 -0500
>
>
>
>The IESG has approved the Internet-Draft 'XML Media Types'
><draft-murata-xml-09.txt> as a Proposed Standard.  This has been
>reviewed in the IETF but is not the product of an IETF Working Group.
>The IESG contact persons are Patrik Faltstrom and Ned Freed.
>
>
>Technical Summary
> 
>This document is an update of RFC 2376. It standardizes five media
>types -- text/xml, application/xml, text/xml-external-parsed-entity,
>application/xml-external-parsed-entity, and application/xml-dtd --
>for use in exchanging network entities that are related to the
>Extensible Markup Language (XML). This document also standardizes a
>convention (using the suffix '+xml') for naming media types outside
>of these five types when those media types represent XML entities.
>
>Major differences from RFC 2376 are (1) the addition of
>text/xml-external-parsed-entity,
>application/xml-external-parsed-entity, and application/xml-dtd, (2)
>the '+xml' suffix convention (which also updates the RFC 2048
>registration process), and (3) the discussion of "utf-16le" and
>"utf-16be".
>
>Working Group Summary
>
>Discussions about this memo has occurred on a number of mailing
>lists, including [email-masked] and [email-masked].
>There appears to be consensus for this update of RFC 2376.
>
>Protocol Quality
>
>Ned Freed has reviewed the specification for the IESG.
> 
Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books

Date: Tue, 31 Oct 2000 13:39:36 -0500
From: John Cowan <[email-masked]>
Organization: Reuters Health Information
To: Gavin Thomas Nicol <[email-masked]>
CC: [email-masked]
Subject: Re: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

Gavin Thomas Nicol wrote:
> 
> > In effect, application/xml is a proxy for x-whatever1/whatever2+xml,
> > which by the rules for "x-" (don't interpret it unless you know
> > what you are doing) can't be treated as XML by ignorant processors.
> 
> Right, hence my preference for text/xml and application/foo+xml.

My point was that if whatever1/whatever2+xml has not yet been registered
by IANA, or should not be registered for whatever reason (only used in
private interchange, e.g.), then "application/xml" serves as a proxy
for it.  Therefore, the existence of "application/xml" has its uses.

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

Date: Tue, 31 Oct 2000 13:38:15 -0500
From: John Cowan <[email-masked]>
Organization: Reuters Health Information
To: Gavin Thomas Nicol <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

Gavin Thomas Nicol wrote:

> If that is the case then why didn't the MUA's adopt this?

Why, for the same reason that DECnet implementations used to set
the Ethernet address to match the DECnet network/node number,
instead of using ARP like IP does...

And the same reason that Dr. Johnson's dictionary defined "pastern"
as "the knee of a horse"...

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

From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Tue, 31 Oct 2000 12:01:26 -0500
Importance: Normal
Sender: [email-masked]

> In effect, application/xml is a proxy for x-whatever1/whatever2+xml,
> which by the rules for "x-" (don't interpret it unless you know
> what you are doing) can't be treated as XML by ignorant processors.

Right, hence my preference for text/xml and application/foo+xml.

From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Tue, 31 Oct 2000 12:01:24 -0500
Importance: Normal
Sender: [email-masked]

> But the  analogy is gravely flawed in any case -- text/html 
> has proved to have no value whatsoever. And this goes far 
> beyond the notion of "good" and "bad" use.

I think the millions of messages sent using text/html would 
disprove the notion that "text/html has proved to have no value
whatsoever". It seems to me that you are projecting a subjective 
analysis. It's fair to say that text/html is not being used as
intended. That is not the same as saying it is of no use.

Anyway, the genie *is* out of the bag.

> > because again, of (supposed) interoperability, and because they
> > didn't have any escape route.
> 
> Sure they did. Application/html combined with a content-disposition 
> label of "inline" offers all the benefits and has none of the 
> problems.

If that is the case then why didn't the MUA's adopt this?

> > With HTML, the genie is already out of the bottle, but with XML
> > there is a chance to get MUA's working as they should: when
> > sending textual data, use text/xml, but when sending application
> > specific data, send application/foo+xml, etc.
> 
> In case it isn't obvious, I am strongly opposed to this policy.

It's obvious, but that doesn't discount it.

Date: Mon, 30 Oct 2000 12:31:33 -0500
From: John Cowan <[email-masked]>
Organization: Reuters Health Information
To: Gavin Thomas Nicol <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

Gavin Thomas Nicol wrote:

> Bottom line: text/xml, application/foo+xml and (to a lesser degree)
> application/xml are all useful. We should provide them all and give
> people clear guidelines on their use so that we can avoid the abuse
> we see with text/html.

In effect, application/xml is a proxy for x-whatever1/whatever2+xml,
which by the rules for "x-" (don't interpret it unless you know
what you are doing) can't be treated as XML by ignorant processors.

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

From: [email-masked]
Date: Mon, 30 Oct 2000 09:02:39 -0700 (PDT)
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
To: Gavin Thomas Nicol <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > It isn't a question of blame, it is a question of whether or not
> > agents have been generally able to construct HTML objects that
> > are legible without any formatting. In hindsight, the answer to
> > this question has proved to be "no". And since text/html's
> > utility was predicated on the answer being
> > "yes", it was a mistake to have defined it.

> I disagree with the logic here: it's like saying that the creation
> of weapons is predicated on their being put to good use, but having
> seen them kill people, the creation is a mistake.

Actually, a fair number of people make precisely this sort of argument in
regards to weapons and consider it entirely valid. But the analogy is gravely
flawed in any case -- text/html has proved to have no value
whatsoever. And this goes far beyond the notion of "good" and "bad" use.

> At the end of the
> day, it is the responsibility of the agents to label the content
> correctly... you can't hold the tools creators responsible for
> their misuse.

Again, you're focusing on blame. Blame isn't relevant.

> If the agents consistently abuse the protocols and standards, then
> there is an argument that the agents needs aren't being met.

Perhaps, but in such cases the right answer is to propose new mechanisms that
do meet the agent's needs, not to repeat mistakes we've made in the past.

> HTML
> is abused because people needed the equivalent of RTF, but wanted
> to piggyback on the (supposed) interoperability/business benefits
> of WWW standards.

> Likewise, agents consistently send data as text/html when in
> reality, the content is application/x-whatever. The main reason is
> because again, of (supposed) interoperability, and because they
> didn't have any escape route.

Sure they did. Application/html combined with a content-disposition label of
"inline" offers all the benefits and has none of the problems.

> With HTML, the genie is already out of the bottle, but with XML
> there is a chance to get MUA's working as they should: when
> sending textual data, use text/xml, but when sending application
> specific data, send application/foo+xml, etc.

In case it isn't obvious, I am strongly opposed to this policy.

				Ned

From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Mon, 30 Oct 2000 11:34:23 -0500
Importance: Normal
Sender: [email-masked]

> You can construct HTML that can be read without an HTML 
> processor of any sort. But few if any agents that emit 
> text/html actually do this. 

Right, and you need to ask yourself why that is.

> > To get back to ground zero, one must ask why one is exchanging 
> > XML in the first place. If is as a structured peice of text, 
> > then text/* is fine.
> 
> No it isn't, because that's not what the top-level text type is 
> for. The intent of the text type is to label material that can 
> sensible be presented to people without any processing.

I think there is a lot of XML content that meets those criteria.
There is obviously also a *lot* that doesn't (SOAP messages etc.)

> You seem to think that the top-level text type label is intended to label
> structured text, but that's just not what it is for.

No. I understand quite well what the intent of text/* is. I
should note that *all* text is somewhat structured (even this
message which will be sent text/plain). Many XML documents doi
little more than make the inherent structure explicit, and for
such documents, text/xml is fine.

> The +xml suffix is intended to make XML detectable even when 
> the specific type isn't known. 

Right, which just gives one more level of default behaviour. At the
end of the day, people are going to use XML as they see fit, and
there will be *many* application specific uses of XML. Most of those
applications can, and should use application/foo or application/foo+xml.
In the latter case, the main benefit is that if the processor doesn't
know about application/foo, it can do *something*.

Bottom line: text/xml, application/foo+xml and (to a lesser degree)
application/xml are all useful. We should provide them all and give
people clear guidelines on their use so that we can avoid the abuse
we see with text/html.

From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Mon, 30 Oct 2000 11:34:19 -0500
Importance: Normal
Sender: [email-masked]

> It isn't a question of blame, it is a question of whether or not 
> agents have been generally able to construct HTML objects that 
> are legible without any formatting. In hindsight, the answer to
> this question has proved to be "no". And since text/html's 
> utility was predicated on the answer being
> "yes", it was a mistake to have defined it.

I disagree with the logic here: it's like saying that the creation
of weapons is predicated on their being put to good use, but having
seen them kill people, the creation is a mistake. At the end of the 
day, it is the responsibility of the agents to label the content 
correctly... you can't hold the tools creators responsible for
their misuse. 

If the agents consistently abuse the protocols and standards, then
there is an argument that the agents needs aren't being met. HTML
is abused because people needed the equivalent of RTF, but wanted
to piggyback on the (supposed) interoperability/business benefits 
of WWW standards. 

Likewise, agents consistently send data as text/html when in 
reality, the content is application/x-whatever. The main reason is
because again, of (supposed) interoperability, and because they 
didn't have any escape route.

With HTML, the genie is already out of the bottle, but with XML
there is a chance to get MUA's working as they should: when
sending textual data, use text/xml, but when sending application
specific data, send application/foo+xml, etc. 

From: [email-masked]
Date: Sun, 29 Oct 2000 21:51:48 -0700 (PDT)
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
To: Gavin Thomas Nicol <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > This is a subtle issue that very few document creators will
> > understand

> True, but then the argument against text/html is also rooted in
> such subtlety?

The subtlety doesn't lie in the intent, but in the difficulty of achieving it.
You can construct HTML that can be read without an HTML processor of any sort.
But few if any agents that emit text/html actually do this. Instead they emit
junk that is quite difficult to read even if you're familiar with HTML, and
nearly impossible if you aren't.

> > It's much better to pick one MIME type for each media type then to try to
> > pass on the decision to folks who won't understand or won't care about the
> > subtlety.  That one type, IMHO, should almost always be application/foo+xml
> > not text/foo+xml.

> In that case it would seem much better to define application/foo rather
> than application/foo+xml

No. There's a specific purpose to the +xml suffix and it should be used
when it is appropriate.

> XML is a complex object type (as is text in general), the question is where
> that complexity best resides, and where one desires interoperability. I
> would argue that text/xml (as in my example) is useful, but not sufficient
> because it doesn't capture everything needed to process the content. This
> is one of the problems that XML brings to the fore because it can represent
> so many things, and be interpreted in so many ways (MIME is built around
> the assumption that the media type canonically defines how it should be
> processed).

This isn't necessarily true in light of the definition of the +xml suffix. In
addition, there is more to it than this. Top level types in particular are
intended to tell you generally how something is or can be processed. This can
assist an agent in handling material even when a specific definition isn't
available.

> To get back to ground zero, one must ask why one is exchanging XML in the
> first place. If is as a structured peice of text, then text/* is fine.

No it isn't, because that's not what the top-level text type is for. The intent
of the text type is to label material that can sensible be presented to people
without any processing.

You seem to think that the top-level text type label is intended to label
structured text, but that's just not what it is for.

> More
> often than not, this will *not* be the case, and so there is a good argument
> for application/*. In cases where XML content is being served with additional
> defined processing, the message type will probably be a multipart message,
> with one part being labelled as text/xml (another might be application/xsl
> or text/css).

> Bottom line: XML in well-defined cases should use XML, otherwise it will
> probably use a multipart message.

The +xml suffix is intended to make XML detectable even when the specific
type isn't known. This eliminates the need to use application/xml to
insure such processing is possible.

				Ned

From: [email-masked]
Date: Sun, 29 Oct 2000 21:47:37 -0700 (PDT)
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
To: Gavin Thomas Nicol <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > I completely agree with Keith. Text/html was a mistake.

> That's like saying richtext was a mistake.

If you are referring to text/richtext, then there is in fact a broad
consensus that it *was* a mistake. That's why text/enriched was devised,
after all.

> The fact is that the MUA's are blindingly violating the
> HTML specification and making it an application-specific
> format. You can hardly blame text/html for that.

It isn't a question of blame, it is a question of whether or not agents have
been generally able to construct HTML objects that are legible without any
formatting. In hindsight, the answer to this question has proved to be
"no". And since text/html's utility was predicated on the answer being
"yes", it was a mistake to have defined it.

				Ned

From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml 
Date: Tue, 24 Oct 2000 22:22:27 -0700
Importance: Normal
Sender: [email-masked]

> This is a subtle issue that very few document creators will
> understand

True, but then the argument against text/html is also rooted in
such subtlety?

> It's much better to pick one MIME type for each media type then to try to
> pass on the decision to folks who won't understand or won't care about the
> subtlety.  That one type, IMHO, should almost always be
application/foo+xml
> not text/foo+xml.

In that case it would seem much better to define application/foo rather
than application/foo+xml

XML is a complex object type (as is text in general), the question is where
that complexity best resides, and where one desires interoperability. I
would argue that text/xml (as in my example) is useful, but not sufficient
because it doesn't capture everything needed to process the content. This
is one of the problems that XML brings to the fore because it can represent
so many things, and be interpreted in so many ways (MIME is built around
the assumption that the media type canonically defines how it should be
processed).

To get back to ground zero, one must ask why one is exchanging XML in the
first place. If is as a structured peice of text, then text/* is fine. More
often than not, this will *not* be the case, and so there is a good argument
for application/*. In cases where XML content is being served with
additional
defined processing, the message type will probably be a multipart message,
with one part being labelled as text/xml (another might be application/xsl
or text/css).

Bottom line: XML in well-defined cases should use XML, otherwise it will
probably use a multipart message.

From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Tue, 24 Oct 2000 20:25:22 -0700
Importance: Normal
Sender: [email-masked]

> I completely agree with Keith. Text/html was a mistake.

That's like saying richtext was a mistake.

The fact is that the MUA's are blindingly violating the
HTML specification and making it an application-specific
format. You can hardly blame text/html for that.

From: Dan Kohn <[email-masked]>
To: Gavin Thomas Nicol <[email-masked]>, [email-masked]
Subject: RE: text/xhtml+xml vs. application/xhtml+xml 
Date: Tue, 24 Oct 2000 18:07:22 -0700
Sender: [email-masked]

This is a subtle issue that very few document creators will understand.  The
vast majority of XML (including, I would argue, the example below) is
considered unreadable by most users.  For more evidence, think of the years
of complaints about "quotable-unreadable" MIME encoding, which just has a
few hex substitutions and = signs.

It's much better to pick one MIME type for each media type then to try to
pass on the decision to folks who won't understand or won't care about the
subtlety.  That one type, IMHO, should almost always be application/foo+xml
not text/foo+xml.

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

-----Original Message-----
From: Gavin Thomas Nicol [mailto:[email-masked]]
Sent: Tuesday, 2000-10-24 17:02
To: [email-masked]
Subject: RE: text/xhtml+xml vs. application/xhtml+xml 

> I think the general consensus of the MIME community is that making HTML
> a subtype of "text/" was a mistake.  While it is possible to write HTML 
> which is readable "to some extent" as plain text, the HTML that is 
> generated by a typical MUA or HTML editor is so full of useless cruft
> that it doesn't qualify.  Perhaps a determined human being can read the 
> text "to some extent" but the typical human gives up.

Well, these tools would be far better off using application/html in my
mind (for many, even application/html is too kind).

> So IMHO we should learn from this experience and make XHTML and other
> XML-ish things subtypes of application/.

I disagree. We should have both application/ and text/ depending on 
the intent. For example, I believe the following would correctly be
text/xml while and SVG image would be better application/svg+xml.

---------------------------------------------------------------------
<?xml version="1.0"?>
<?xml-stylesheet type="text/xml" href="/stylesheets/article.xsl"?>
<article>
<title>Patently Ridiculous Patents</title>
<sideline>
  <img src="/images/dogbert.gif" alt="Dogbert at the patent office">
    <caption>Dogbert at the patent office</caption>
  </img>
</sideline> 
<body>
<p>Patently Ridiculous Patents - There has been a literal explosion of
internet related patent recently. Many of these patents are trivial,
but still the cost of defineding against them will have an impact on
companies worldwide.</p>
<p>Some examples: 
<ul>
  <li>Information Architects now has a patent on dynamic composition for
      syndication.</li>
  <li>Sunil Paul got a patent (6,052,709) for email spam filtering.</li>
  <li>Shmuel Shaffer, William Beyda and Paul Bonomo, received patent
      6,092,114 for filtering attachments to make the easily viewable
      on the target system.</li>
  <li>Dan Kikinis, of Saratoga, Calif., won a patent (6,085,232) for
      the DataLink Systems Corporation in San Diego for a paging
      system embedded in a computer keyboard.</li>
  <li>Sanjay Agraharam, Lee Begeja, Carroll Creswell, Ram Ramamurthy
      and Sandeep Sibal received patent 6,085,231 for a combined voice
      and e-mail system that allows subscribers to get both just by
      looking in their e-mail box. The system converts voice mail into
      e-mail. The system then converts the voice message into text or
      a .wav file, formats either one as an e-mail and sends it to the
      recipient.</li>
</ul></p>
<p>Makes one wonder where it's all going to stop...</p>
</body>
</article>

From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: text/xhtml+xml vs. application/xhtml+xml 
Date: Tue, 24 Oct 2000 17:02:27 -0700
Importance: Normal
Sender: [email-masked]

> I think the general consensus of the MIME community is that making HTML
> a subtype of "text/" was a mistake.  While it is possible to write HTML 
> which is readable "to some extent" as plain text, the HTML that is 
> generated by a typical MUA or HTML editor is so full of useless cruft
> that it doesn't qualify.  Perhaps a determined human being can read the 
> text "to some extent" but the typical human gives up.

Well, these tools would be far better off using application/html in my
mind (for many, even application/html is too kind).

> So IMHO we should learn from this experience and make XHTML and other
> XML-ish things subtypes of application/.

I disagree. We should have both application/ and text/ depending on 
the intent. For example, I believe the following would correctly be
text/xml while and SVG image would be better application/svg+xml.

---------------------------------------------------------------------
<?xml version="1.0"?>
<?xml-stylesheet type="text/xml" href="/stylesheets/article.xsl"?>
<article>
<title>Patently Ridiculous Patents</title>
<sideline>
  <img src="/images/dogbert.gif" alt="Dogbert at the patent office">
    <caption>Dogbert at the patent office</caption>
  </img>
</sideline> 
<body>
<p>Patently Ridiculous Patents - There has been a literal explosion of
internet related patent recently. Many of these patents are trivial,
but still the cost of defineding against them will have an impact on
companies worldwide.</p>
<p>Some examples: 
<ul>
  <li>Information Architects now has a patent on dynamic composition for
      syndication.</li>
  <li>Sunil Paul got a patent (6,052,709) for email spam filtering.</li>
  <li>Shmuel Shaffer, William Beyda and Paul Bonomo, received patent
      6,092,114 for filtering attachments to make the easily viewable
      on the target system.</li>
  <li>Dan Kikinis, of Saratoga, Calif., won a patent (6,085,232) for
      the DataLink Systems Corporation in San Diego for a paging
      system embedded in a computer keyboard.</li>
  <li>Sanjay Agraharam, Lee Begeja, Carroll Creswell, Ram Ramamurthy
      and Sandeep Sibal received patent 6,085,231 for a combined voice
      and e-mail system that allows subscribers to get both just by
      looking in their e-mail box. The system converts voice mail into
      e-mail. The system then converts the voice message into text or
      a .wav file, formats either one as an e-mail and sends it to the
      recipient.</li>
</ul></p>
<p>Makes one wonder where it's all going to stop...</p>
</body>
</article>

From: Dan Kohn <[email-masked]>
To: Marshall Rose <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [BXXPwg] application/beep+xml
Date: Tue, 24 Oct 2000 10:38:01 -0700
Sender: [email-masked]

I'm not quite sure it's correct that these issues don't arise with XML 1.0
(although I agree life will be easier if it is true).

Issues regarding the BOM are rife with XML 1.0 because UTF-16 is a
recommended charset, and beep supports its use.

RFC 2396 defines that the semantics of a fragment identifier are a property
of the data resulting from the retrieval action, so arguably RFC 2048 should
be updated to have MIME registrations explicitly define those semantics.
You can leave them undefined, but there is some value from supporting
XPointer.

XML Base is an optional enhancement for XML 1.0 that can change the
interpretation of relative URLs.  You can support it, explicitly not support
it (by outlawing relative URL), or leave it undefined.

So, again, feel free to ignore; I just wanted to make sure the issues are
clear.

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

-----Original Message-----
From: Marshall Rose [mailto:[email-masked]]
Sent: Tuesday, 2000-10-24 10:13
To: Dan Kohn
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [BXXPwg] application/beep+xml

> Marshall, my only question is whether some of the Security Considerations
of
> <http://www.imc.org/draft-murata-xml> additionally apply.  Since you are
> prohibiting the use of external entities, you avoid most of the risks,
> however there is still the possibility of someone parsing the data with a
> standard XML processor.  Also, you might explicitly want to mention
whether
> this type follows RFC 2376bis's advice on use of the BOM (section 4),
> XPointer syntax (section 5), and Base URI (section 6).  Or, you could just
> leave these things undefined. 

hi. i think you're missing the point. the particular subset listed there
excludes all of the things you are mentioning. they aren't in the 1.0
specification. hence the addition text you request is redundant. that's
sort of the whole point.
    
/mtr

Date: Tue, 24 Oct 2000 10:13:11 -0700
From: Marshall Rose <[email-masked]>
To: Dan Kohn <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [BXXPwg] application/beep+xml
Sender: [email-masked]

> Marshall, my only question is whether some of the Security Considerations of
> <http://www.imc.org/draft-murata-xml> additionally apply.  Since you are
> prohibiting the use of external entities, you avoid most of the risks,
> however there is still the possibility of someone parsing the data with a
> standard XML processor.  Also, you might explicitly want to mention whether
> this type follows RFC 2376bis's advice on use of the BOM (section 4),
> XPointer syntax (section 5), and Base URI (section 6).  Or, you could just
> leave these things undefined. 

hi. i think you're missing the point. the particular subset listed there
excludes all of the things you are mentioning. they aren't in the 1.0
specification. hence the addition text you request is redundant. that's
sort of the whole point.
    
/mtr

From: Dan Kohn <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: [BXXPwg] application/beep+xml
Date: Tue, 24 Oct 2000 09:58:54 -0700
Sender: [email-masked]

Marshall, my only question is whether some of the Security Considerations of
<http://www.imc.org/draft-murata-xml> additionally apply.  Since you are
prohibiting the use of external entities, you avoid most of the risks,
however there is still the possibility of someone parsing the data with a
standard XML processor.  Also, you might explicitly want to mention whether
this type follows RFC 2376bis's advice on use of the BOM (section 4),
XPointer syntax (section 5), and Base URI (section 6).  Or, you could just
leave these things undefined. 

Thanks.

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

-----Original Message-----
From: Marshall Rose [mailto:[email-masked]]
Sent: Tuesday, 2000-10-24 08:21
To: [email-masked]
Cc: [email-masked]
Subject: [BXXPwg] application/beep+xml

hi. after review, it looks like application/beep+xml is probably the
better choice. unless folks believe otherwise, here is what i propose to
add to the draft. please comment.
    
thanks,
    
/mtr

ps: naturally, the examples will all change to use this media type
instead of text/xml
    
    				  #######
    
6.4 Registration: application/beep+xml

   MIME media type name: application

   MIME subtype name: beep+xml

   Required parameters: none

   Optional parameters: charset (defaults to "UTF-8"[RFC 2279])

   Encoding considerations: always use binary

   Security considerations: none, per se; however, any BEEP profile
      which uses this media type must describe its relevant security
      considerations

   Interoperability considerations: n/a

   Published specification: This media type is a proper subset of the
      the XML 1.0 specification[2]. Two restrictions are made. 

      First, no entity references other than the five predefined
      general entities references ("&amp;", "&lt;", "&gt;", "&apos;",
      and "&quot;") and numeric entity references may be present. 

      Second, neither the "XML" declaration (e.g., <?xml version="1.0"
      ?>) nor the "DOCTYPE" declaration (e.g., <!DOCTYPE ...>) may be
      present. (Accordingly, if another character set other than UTF-8
      is desired, then the "charset" parameter must be present.) 

      All other XML 1.0 instructions (e.g., CDATA blocks, processing
      instructions, and so on) are allowed.

   Applications which use this media type: any BEEP profile wishing to
      make use of this XML 1.0 subset

   Additional Information: none

   Contact for further information: c.f., the "Author's Address"
      section of this memo

   Intended usage: limited use

   Author/Change controller: the IESG

_______________________________________________
BXXPwg mailing list
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt
Date: Tue, 24 Oct 2000 01:17:12 +0900 (JST)
Lines: 19
Sender: [email-masked]

> Given what you write below, it looks like this has changed recently.
> Do you have a pointer to the decision record ? Do you know the RFC
> number ? Do you know when it will be published ?

The IESG has approved publication of the I-D as a Proposed Standard.
Here is the pointer to the decision.

	http://www.ietf.org/iesg/iesg.2K-10-05

> 2. The IESG approved publication of XML Media Types
>    <draft-murata-xml-09.txt> as a Proposed Standard. Steve to send 
>    announcement.

Cheers,

IBM Tokyo Research Lab &
International University of Japan, Research Institute

MURATA Makoto

From: Dan Kohn <[email-masked]>
To: Philipp Hoschka <[email-masked]>
Cc: [email-masked]
Subject: RE: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt
Date: Mon, 23 Oct 2000 09:09:17 -0700
Sender: [email-masked]

The basic processes of IETF standardization would not allow a
non-backward-compatible change to RFC2376bis, so I think there is little
risk and some potential gain in referencing 2376bis.  The fact that it has
been "in the making for some while now" is exactly why I would prefer for
any insights it contains not to go to waste.  It is your choice, however.

As to approval (which should be announced soon), see the minutes available
at:

http://www.ietf.org/iesg/iesg.2K-10-05
> 2. The IESG approved publication of XML Media Types
>    <draft-murata-xml-09.txt> as a Proposed Standard. Steve to send 
>    announcement.

My understanding of the RFC Editor queue is that you could reference 2376bis
in your I-D with a request for them to fill in the correct RFC number, and
that this should not delay your draft (which I believe also needs to go
through Last Call first).

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

-----Original Message-----
From: Philipp Hoschka [mailto:[email-masked]]
Sent: Monday, 2000-10-23 08:53
To: Dan Kohn
Cc: [email-masked]
Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt

Dan Kohn a écrit :
> 
> I would strongly suggest an include by reference, as implementation
> experience will likely cause further updates to 2376bis at some point.  As
> an example, you are actually quoting text from RFC 2376, not 2376bis 

Citing RFC2376 seems correct, given that RFC 2376 is a stable spec,
wheras 
the current internet draft (which you refer to as 2376bis) is not, and
has 
been in the making for quite a while now.

Given what you write below, it looks like this has changed recently.
Do you have a pointer to the decision record ? Do you know the RFC
number ? Do you know when it will be published ?

As I said, I am will consider removing the "reference by copy", once
I found out if anybody actually requested reference by copy, and why.

However, I disagree with your argument that an advantage of citing
by reference is that it allows easier updates - the reference will
be to a stable document, and if that document is replaced by 
a new document, that doesn't mean that the registration for
application/smil changes as well. Propagating the changes would 
require an update of the application/smil document.

...

> If people are not willing to look up a referenced RFC, than they probably
> won't bother reading the MIME registration RFC in the first place.

As I said, I think there is practical evidence to the contrary.
 
> Also, as specified in Section 7.1 of
<http://www.imc.org/draft-murata-xml>,
> we would recommend referring to 2376bis for "specifying magic numbers,
> fragment identifiers, base URIs, and use of the BOM".  If you decide not
to
> do so (e.g., because of non-XPointer fragment semantics), 

The fragment semantics of application/smil are compatible with XPointer,
as far as I can tell.

>it would be worth
> specifying that explicitly in your registration.

Date: Mon, 23 Oct 2000 17:52:53 +0200
From: Philipp Hoschka <[email-masked]>
To: Dan Kohn <[email-masked]>
CC: [email-masked]
Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt
Sender: [email-masked]

Dan Kohn a écrit :
> 
> I would strongly suggest an include by reference, as implementation
> experience will likely cause further updates to 2376bis at some point.  As
> an example, you are actually quoting text from RFC 2376, not 2376bis 

Citing RFC2376 seems correct, given that RFC 2376 is a stable spec,
wheras 
the current internet draft (which you refer to as 2376bis) is not, and
has 
been in the making for quite a while now.

Given what you write below, it looks like this has changed recently.
Do you have a pointer to the decision record ? Do you know the RFC
number ? Do you know when it will be published ?

As I said, I am will consider removing the "reference by copy", once
I found out if anybody actually requested reference by copy, and why.

However, I disagree with your argument that an advantage of citing
by reference is that it allows easier updates - the reference will
be to a stable document, and if that document is replaced by 
a new document, that doesn't mean that the registration for
application/smil changes as well. Propagating the changes would 
require an update of the application/smil document.

...

> If people are not willing to look up a referenced RFC, than they probably
> won't bother reading the MIME registration RFC in the first place.

As I said, I think there is practical evidence to the contrary.
 
> Also, as specified in Section 7.1 of <http://www.imc.org/draft-murata-xml>,
> we would recommend referring to 2376bis for "specifying magic numbers,
> fragment identifiers, base URIs, and use of the BOM".  If you decide not to
> do so (e.g., because of non-XPointer fragment semantics), 

The fragment semantics of application/smil are compatible with XPointer,
as far as I can tell.

>it would be worth
> specifying that explicitly in your registration.

From: Dan Kohn <[email-masked]>
To: Philipp Hoschka <[email-masked]>
Cc: [email-masked]
Subject: RE: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt
Date: Mon, 23 Oct 2000 07:59:32 -0700
Sender: [email-masked]

I would strongly suggest an include by reference, as implementation
experience will likely cause further updates to 2376bis at some point.  As
an example, you are actually quoting text from RFC 2376, not 2376bis (which
was just approved by the IESG this week!), and that text has significantly
less detail and justification.

If people are not willing to look up a referenced RFC, than they probably
won't bother reading the MIME registration RFC in the first place.

Also, as specified in Section 7.1 of <http://www.imc.org/draft-murata-xml>,
we would recommend referring to 2376bis for "specifying magic numbers,
fragment identifiers, base URIs, and use of the BOM".  If you decide not to
do so (e.g., because of non-XPointer fragment semantics), it would be worth
specifying that explicitly in your registration.

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

-----Original Message-----
From: Philipp Hoschka [mailto:[email-masked]]
Sent: Sunday, 2000-10-22 11:26
To: Dan Kohn
Cc: [email-masked]
Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt

Dan,

thanks for the review. See replies below

Dan Kohn a écrit :
> 
> Philipp, could I suggest that you review
> <http://www.imc.org/draft-murata-xml>, which is expected to shortly
replace
> RFC 2376.  Specifically, I would strongly recommend changing your
> application to application/smil+xml, and quoting the appropriate sections
of
> RFC 2376bis by reference rather than by repeating the text.

For smil+xml, see Murata's recount of history. I added a paragraph
explaining why we chose not to use the postfix for this one.

As for the sections quoted by repeating the text: The sections were 
included by reference in earlier versions of the draft. I seem to
remember
that I decided to repeat the text either because somebody explicitly 
suggested doing this, or because somebody got it wrong when implementing
from an earlier draft. In any case, the intention is to make sure that
people actually follow these rather involved rules when implementing
application/smil.

If this doesn't convince you, I can consider taking them out again.
Before doing so, however, I would need to do some research on whether 
this wasn't something that was explicitly requested by somebody else.

> Thanks for considering this.
> 
>                 - dan
> --
> Dan Kohn <mailto:[email-masked]>
> <http://www.dankohn.com>  <tel:+1-650-327-2600>
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, 2000-10-17 03:47
> Subject: I-D ACTION:draft-hoschka-smil-media-type-05.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
>         Title           : The application/smil Media Type
>         Author(s)       : P. Hoschka
>         Filename        : draft-hoschka-smil-media-type-05.txt
>         Pages           : 4
>         Date            : 16-Oct-00
> 
> This document specifies the Media Type for version 1 of the
> Synchronized Multimedia Integration Language (SMIL 1.0). SMIL allows
> integrating a set of independent multimedia objects into a
> synchronized multimedia presentation.
> 
> A RL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-05.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-hoschka-smil-media-type-05.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-hoschka-smil-media-type-05.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

Date: Sun, 22 Oct 2000 20:26:26 +0200
From: Philipp Hoschka <[email-masked]>
To: Dan Kohn <[email-masked]>
CC: [email-masked]
Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt
Sender: [email-masked]

Dan,

thanks for the review. See replies below

Dan Kohn a écrit :
> 
> Philipp, could I suggest that you review
> <http://www.imc.org/draft-murata-xml>, which is expected to shortly replace
> RFC 2376.  Specifically, I would strongly recommend changing your
> application to application/smil+xml, and quoting the appropriate sections of
> RFC 2376bis by reference rather than by repeating the text.

For smil+xml, see Murata's recount of history. I added a paragraph
explaining why we chose not to use the postfix for this one.

As for the sections quoted by repeating the text: The sections were 
included by reference in earlier versions of the draft. I seem to
remember
that I decided to repeat the text either because somebody explicitly 
suggested doing this, or because somebody got it wrong when implementing
from an earlier draft. In any case, the intention is to make sure that
people actually follow these rather involved rules when implementing
application/smil.

If this doesn't convince you, I can consider taking them out again.
Before doing so, however, I would need to do some research on whether 
this wasn't something that was explicitly requested by somebody else.

> Thanks for considering this.
> 
>                 - dan
> --
> Dan Kohn <mailto:[email-masked]>
> <http://www.dankohn.com>  <tel:+1-650-327-2600>
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, 2000-10-17 03:47
> Subject: I-D ACTION:draft-hoschka-smil-media-type-05.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
>         Title           : The application/smil Media Type
>         Author(s)       : P. Hoschka
>         Filename        : draft-hoschka-smil-media-type-05.txt
>         Pages           : 4
>         Date            : 16-Oct-00
> 
> This document specifies the Media Type for version 1 of the
> Synchronized Multimedia Integration Language (SMIL 1.0). SMIL allows
> integrating a set of independent multimedia objects into a
> synchronized multimedia presentation.
> 
> A RL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-05.txt
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-hoschka-smil-media-type-05.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-hoschka-smil-media-type-05.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

Date: Sun, 22 Oct 2000 03:17:01 +0200
From: Philipp Hoschka <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt
Sender: [email-masked]

[email-masked] a écrit :
...
> Phillip, could you revise the I-D as you promised?

Thanks for retracing history so well !
I just sent an updated draft, which should appear soon.

-Philipp

From: Dan Kohn <[email-masked]>
To: James Aylett <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [BXXPwg] Re: application/beep+xml
Date: Fri, 20 Oct 2000 14:28:37 -0700
Sender: [email-masked]

Actually, I would argue that the suggestion for application/beep+xml is
remarkably similar to the existing MIME type message/http, defined in
Section 19.1 of RFC 2616.  <http://www.normos.org/ietf/rfc/rfc2616.txt>

I thought of suggesting message/beep+xml, but section 5.2.4 of RFC 2046 says
that:

   Future subtypes of "message" intended for use with email should be
   restricted to "7bit" encoding. A type other than "message" should be
   used if restriction to "7bit" is not possible.

It isn't actually clear that the second sentence's prohibition of message
types for binary content is intended to apply outside of email, but
application/beep+xml seems the more conservative approach.

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

-----Original Message-----
From: James Aylett [mailto:[email-masked]]
Sent: Friday, 2000-10-20 10:16
To: [email-masked]
Subject: Re: [BXXPwg] Re: application/beep+xml

On Fri, Oct 20, 2000 at 07:52:37AM -0700, Marshall Rose wrote:

> 1. text/xml isn't the right tag to use for xml-based profiles
> what should we use instead?
> 
> the things being moved around in the xml-based profiles described in beep
> are protocol exchanges, not documents. when a channel is started, a
> negotiation process is used to determine which profile is bound to the
> channel. the registration for this profile defines what the exchanges look
> like.
> 
> so, having each profile register its own mime type is at best redundant.
> worse, since the whole point of using URIs to identify profiles was to get
> away from a centralized registry, a mime type per profile negates this
> property.
> 
> this leaves application/xml, which is as good a choice as any, i guess...

I'm probably being stupid, but the way I see it, the protocol
exchanges that BEEP uses are actually reaching the limit of what MIME
types can sensibly be used to classify.

I think that Marshall's "these aren't documents" can be rephrased as
"these aren't MIME entities". They certainly don't have the same
function as MIME entities in anything else I can think of (although
they can often act as transport for a contained entity).

So, as far as we need some sort of MIME type indication, the opaque
application/xml is probably the best solution.

(I hesitate, but think it perhaps worth pointing to:
draft-eastlake-cturi-00.txt gives a mapping between content types and
URIs. I don't think it's even vaguely sensible to use the content type 
obtained by mapping the URI of the profile register here, but I
thought I'd point it out in case anyone disagreed.)

Cheers,
James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                           www.zap.uk.eu.org
  [email-masked]                                    www.footlights.org

_______________________________________________
BXXPwg mailing list
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

Date: Fri, 20 Oct 2000 13:13:39 -0700
To: "Marshall Rose" <[email-masked]>, "Dan Kohn" <[email-masked]>, <[email-masked]>
From: Tim Bray <[email-masked]>
Subject: Re: application/beep+xml
Cc: <[email-masked]>, "Marshall Rose" <[email-masked]>
Sender: [email-masked]

At 07:52 AM 20/10/00 -0700, Marshall Rose wrote:
>this leaves application/xml, which is as good a choice as any, i guess...

Also has the effect of discouraging transcoding, which sees desirable for 
protocol negotiations in a multilingual world (enough things can go 
wrong already...) -Tim

From: Dan Kohn <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: application/beep+xml
Date: Fri, 20 Oct 2000 12:23:18 -0700
Sender: [email-masked]

Given that all beep protocol exchanges are either channel setup or beep
profile exchanges, it seems like application/beep+xml could still be a good
choice.  Just say in the registration that the DTD used is either the one in
the beep framework document or a specific beep profile as specified by the
profile entity URL.

I definitely agree, though, that each beep profile should not need it's own
MIME type.

In general, the MIME concept of taxonomy has seemed to work quite well (I
realize I'm preaching to the choir here), and the subset of documents that
are beep or beep profiles seems much, much smaller than the set of all XML
documents.

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

-----Original Message-----
From: Marshall Rose [mailto:[email-masked]]
Sent: Friday, 2000-10-20 07:53
To: Dan Kohn; [email-masked]
Cc: [email-masked]; Marshall Rose
Subject: Re: application/beep+xml

hi. i think you raise three issues:

1. text/xml isn't the right tag to use for xml-based profiles

2. rfc1982 on sequence number arithmetic should be referenced, e.g.,

   Consult Sections 2 through 5 of [8] for a discussion of the arithmetic
   properties of sequence numbers.

3. the "URL:" in things like "<URL:http://iana.org/>" should be removed

2 & 3 are editorial, and probably not all that controversial. if anyone
objects to making these changes, speak up.

the first issue requires more discussion.

i'll agree that text/xml isn't optimal for the reasons you suggest (e.g.,
not intended for display to humans).

so, if text/xml is out, what should we use instead?

the things being moved around in the xml-based profiles described in beep
are protocol exchanges, not documents. when a channel is started, a
negotiation process is used to determine which profile is bound to the
channel. the registration for this profile defines what the exchanges look
like.

so, having each profile register its own mime type is at best redundant.
worse, since the whole point of using URIs to identify profiles was to get
away from a centralized registry, a mime type per profile negates this
property.

this leaves application/xml, which is as good a choice as any, i guess...

/mtr

From: "Marshall Rose" <[email-masked]>
To: "Dan Kohn" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Marshall Rose" <[email-masked]>
Subject: Re: application/beep+xml
Date: Fri, 20 Oct 2000 07:52:37 -0700
Sender: [email-masked]

hi. i think you raise three issues:

1. text/xml isn't the right tag to use for xml-based profiles

2. rfc1982 on sequence number arithmetic should be referenced, e.g.,

   Consult Sections 2 through 5 of [8] for a discussion of the arithmetic
   properties of sequence numbers.

3. the "URL:" in things like "<URL:http://iana.org/>" should be removed

2 & 3 are editorial, and probably not all that controversial. if anyone
objects to making these changes, speak up.

the first issue requires more discussion.

i'll agree that text/xml isn't optimal for the reasons you suggest (e.g.,
not intended for display to humans).

so, if text/xml is out, what should we use instead?

the things being moved around in the xml-based profiles described in beep
are protocol exchanges, not documents. when a channel is started, a
negotiation process is used to determine which profile is bound to the
channel. the registration for this profile defines what the exchanges look
like.

so, having each profile register its own mime type is at best redundant.
worse, since the whole point of using URIs to identify profiles was to get
away from a centralized registry, a mime type per profile negates this
property.

this leaves application/xml, which is as good a choice as any, i guess...

/mtr

From: Dan Kohn <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: application/beep+xml
Date: Fri, 20 Oct 2000 00:54:38 -0700
Sender: [email-masked]

I finally took the time to review
<http://www.ietf.org/internet-drafts/draft-ietf-beep-framework-05.txt> and
<http://www.bxxp.org>, and I would like to suggest that text/xml is probably
not the best MIME type to use for your BEEP channel management and profile
configuration.

Among other things:

+ In Section 2.2.2.2, you constrain what is acceptable beyond well-formed
and valid XML (e.g., internal entity declarations are not allowed).

+ It is hard to imagine any scenario where the BEEP channel management
should be presented to users, since it is explicitly designed for process to
process communications.

+ You don't have line-ending conversion issues to deal with, since CRLF is
mandated.

+ The fact that you recommend against a DOCTYPE declaration in Section
2.2.2.2 (even though DTDs are defined in section 7) means that if BEEP XML
gets out in the wild, it will be more difficult to identify.  The custom
MIME type would provide that identification.

I would suggest that you review <http://www.imc.org/draft-murata-xml> (which
has finished last call and will hopefully soon be approved by the IESG).  I
don't know if something like application/beep+xml would meet your needs, but
I am at least fairly certain that application/xml would be a better choice
than text/xml.  

Given sections 3.1.2 and 4.1.2 of the BEEP framework, it seems that you
might also want to consider registering application/tls+xml and
application/sasl+xml.  Or alternatively, you could have the SASL and TLS
DTDs referenced as external entities to the core BEEP DTD, and get by with
just application/beep+xml.  (Note that there is no explicit one-to-one
mapping between DTDs and MIME types, although such a mapping would be
especially useful when DOCTYPE declarations are discouraged.)

Separately, I would suggest that in Section 2.2.1.2, you should normatively
reference serial number arithmetic as defined in RFC 1982.  Finally,
Appendix E of RFC 2396 deprecates the use of "URL:" as in
<URL:http://www.iana.org/>.

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

Date: Thu, 19 Oct 2000 11:26:07 -0400
From: Mark Baker <[email-masked]>
Organization: Sun Microsystems Inc.
To: Dan Kohn <[email-masked]>
CC: Larry Masinter <[email-masked]>, [email-masked]
Subject: Re: XHTML vs HTML media types
Sender: [email-masked]

Dan Kohn wrote:
> 
> Well, I hardly see this as life-or-death, but the intro paragraph of
> <http://www.w3.org/TR/xhtml1/> says:
> 
> "XHTML is a family of current and future document types and modules that
> reproduce, subset, and extend HTML 4 [HTML]. XHTML family document types are
> XML based, and ultimately are designed to work in conjunction with XML-based
> user agents."
> 
> XHTML, especially 1.1+, is more than just HTML reformulated in XML.  The
> modularization is a fundamentally new thing (as you of course know, Larry).
> Based on this, XHTML seems to describe what XHTML is better than HTML does.
> The +xml in the name is first and foremost a syntactic convention to
> indicate support of the XML syntax (the fact that it's also a semantic
> convention as well is an extra benefit).  So, I'm still for
> application/xhtml+xml.

Right.  I think my previous email expressed the same concern.

> Separately, I agree a reference to RFC 2854 is critical.  And further, I
> think the registration should have a detailed discussion on file extensions.
> On my laptop, .html files open in IE and .xhtml in XMLSpy.  It's not
> immediately obvious to me that if I upload a .xhtml file to a web server,
> what is the best default MIME type mapping for that file?

There's not exactly a "detailed" discussion on file extensions, but it
ties in closely with the discussion on recognizing XHTML documents, and
the dangers of assuming that the processor will further dispatch on a
namespace (my 2c contribution to draft-murata-xml).

Anyhow, there's no point getting into that much further now until the WG
is ready to publish it.  When the draft is announced, I'll be sure to
forward it here (or however that process works - I have to recheck the
order of operations).

MB

Date: Thu, 19 Oct 2000 10:33:41 -0400
From: Mark Baker <[email-masked]>
Organization: Sun Microsystems Inc.
To: [email-masked]
CC: Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked]
Subject: Re: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

Thanks Ned and Keith, for your comments.  I wasn't aware of this
perception.

I'll take this back to the WG ASAP.

MB

[email-masked] wrote:
> 
> > > While this doesn't go into as much depth as draft-murata-xml does, the
> > > HTML WG believes, despite the DOCTYPE/xmlns/HTML-header preamble, that
> > > the bulk (i.e. body) of most XHTML documents will useful, to "some
> > > extent" (per above), to casual users.
> 
> > I think the general consensus of the MIME community is that making HTML
> > a subtype of "text/" was a mistake.  While it is possible to write HTML
> > which is readable "to some extent" as plain text, the HTML that is
> > generated by a typical MUA or HTML editor is so full of useless cruft
> > that it doesn't qualify.  Perhaps a determined human being can read the
> > text "to some extent" but the typical human gives up.
> 
> > So IMHO we should learn from this experience and make XHTML and other
> > XML-ish things subtypes of application/.
> 
> I completely agree with Keith. Text/html was a mistake.
> 
>                                 Ned

Date: Thu, 19 Oct 2000 10:36:40 -0400
From: Mark Baker <[email-masked]>
Organization: Sun Microsystems Inc.
To: Larry Masinter <[email-masked]>
CC: [email-masked]
Subject: Re: XHTML vs HTML media types
Sender: [email-masked]

Hi Larry,

Larry Masinter wrote:
> 
> RFC 2854 describes the applicability of 'text/html'; I would like to
> ask that any document that talks about the any other MIME type that
> might be used at least refer to it.

Just to be clear, this new type would not be used for any existing
content (unless by some freak accident, somebody authored a conformant
XHTML document).

So in what context are you recommending that I reference 2854?

> I actually think that the double 'x' in 'xhtml+xml' is redundant,
> and that 'application/html+xml' might be more appropriate.

"XHTML" is a brand we're trying to build, so we felt it important that
it be included in the subtype string.  Also, "html+xml" might lead one
to believe that the described content is semantically equivalent to
HTML.  That isn't the case (e.g. the name attribute doesn't have id
semantics in XHTML, as mentioned in my previous email).

We did have this discussion, and reached concensus on "xhtml+xml".

Thanks for your comments.

MB

Date: Thu, 19 Oct 2000 09:49:04 +0900
To: Keith Moore <[email-masked]>, Mark Baker <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: text/xhtml+xml vs. application/xhtml+xml 
Cc: Dan Kohn <[email-masked]>, [email-masked]
Sender: [email-masked]

At 00/10/18 17:26 -0400, Keith Moore wrote:
>So IMHO we should learn from this experience and make XHTML and other
>XML-ish things subtypes of application/.

Or of course image/ for things such as SVG.

Regards,   Martin.

From: [email-masked]
Date: Wed, 18 Oct 2000 16:25:24 -0700 (PDT)
Subject: RE: XHTML vs HTML media types
To: Larry Masinter <[email-masked]>
Cc: Mark Baker <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked]
Sender: [email-masked]

> RFC 2854 describes the applicability of 'text/html'; I would like to
> ask that any document that talks about the any other MIME type that
> might be used at least refer to it.

> I actually think that the double 'x' in 'xhtml+xml' is redundant,
> and that 'application/html+xml' might be more appropriate.

Interesting notion. On the one hand, you're right that it is redundant,
on the other, html+xml doesn't embed the XHTML "name" in the media type.

On the whole I think I agree with you, although I do see the case for
having xhtml+xml.

				Ned

From: [email-masked]
Date: Wed, 18 Oct 2000 16:23:25 -0700 (PDT)
Subject: Re: text/xhtml+xml vs. application/xhtml+xml
To: Keith Moore <[email-masked]>
Cc: Mark Baker <[email-masked]>, Dan Kohn <[email-masked]>, [email-masked]
Sender: [email-masked]

> > While this doesn't go into as much depth as draft-murata-xml does, the
> > HTML WG believes, despite the DOCTYPE/xmlns/HTML-header preamble, that
> > the bulk (i.e. body) of most XHTML documents will useful, to "some
> > extent" (per above), to casual users.

> I think the general consensus of the MIME community is that making HTML
> a subtype of "text/" was a mistake.  While it is possible to write HTML
> which is readable "to some extent" as plain text, the HTML that is
> generated by a typical MUA or HTML editor is so full of useless cruft
> that it doesn't qualify.  Perhaps a determined human being can read the
> text "to some extent" but the typical human gives up.

> So IMHO we should learn from this experience and make XHTML and other
> XML-ish things subtypes of application/.

I completely agree with Keith. Text/html was a mistake.

				Ned

From: Dan Kohn <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked], Mark Baker <[email-masked]>
Subject: RE: XHTML vs HTML media types
Date: Wed, 18 Oct 2000 15:26:38 -0700
Sender: [email-masked]

Well, I hardly see this as life-or-death, but the intro paragraph of
<http://www.w3.org/TR/xhtml1/> says:

"XHTML is a family of current and future document types and modules that
reproduce, subset, and extend HTML 4 [HTML]. XHTML family document types are
XML based, and ultimately are designed to work in conjunction with XML-based
user agents."

XHTML, especially 1.1+, is more than just HTML reformulated in XML.  The
modularization is a fundamentally new thing (as you of course know, Larry).
Based on this, XHTML seems to describe what XHTML is better than HTML does.
The +xml in the name is first and foremost a syntactic convention to
indicate support of the XML syntax (the fact that it's also a semantic
convention as well is an extra benefit).  So, I'm still for
application/xhtml+xml.

Separately, I agree a reference to RFC 2854 is critical.  And further, I
think the registration should have a detailed discussion on file extensions.
On my laptop, .html files open in IE and .xhtml in XMLSpy.  It's not
immediately obvious to me that if I upload a .xhtml file to a web server,
what is the best default MIME type mapping for that file?

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

-----Original Message-----
From: Larry Masinter [mailto:[email-masked]]
Sent: Wednesday, 2000-10-18 14:06
To: Mark Baker; Dan Kohn
Cc: [email-masked]
Subject: RE: XHTML vs HTML media types

RFC 2854 describes the applicability of 'text/html'; I would like to
ask that any document that talks about the any other MIME type that
might be used at least refer to it.

I actually think that the double 'x' in 'xhtml+xml' is redundant,
and that 'application/html+xml' might be more appropriate.

From: Keith Moore <[email-masked]>
To: Mark Baker <[email-masked]>
cc: Dan Kohn <[email-masked]>, [email-masked]
Subject: Re: text/xhtml+xml vs. application/xhtml+xml 
Date: Wed, 18 Oct 2000 17:26:51 -0400
Sender: [email-masked]

> While this doesn't go into as much depth as draft-murata-xml does, the
> HTML WG believes, despite the DOCTYPE/xmlns/HTML-header preamble, that
> the bulk (i.e. body) of most XHTML documents will useful, to "some
> extent" (per above), to casual users.

I think the general consensus of the MIME community is that making HTML
a subtype of "text/" was a mistake.  While it is possible to write HTML 
which is readable "to some extent" as plain text, the HTML that is 
generated by a typical MUA or HTML editor is so full of useless cruft
that it doesn't qualify.  Perhaps a determined human being can read the 
text "to some extent" but the typical human gives up.

So IMHO we should learn from this experience and make XHTML and other
XML-ish things subtypes of application/.

Keith

From: "Larry Masinter" <[email-masked]>
To: "Mark Baker" <[email-masked]>, "Dan Kohn" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: XHTML vs HTML media types
Date: Wed, 18 Oct 2000 14:05:33 -0700
Importance: Normal
Sender: [email-masked]

RFC 2854 describes the applicability of 'text/html'; I would like to
ask that any document that talks about the any other MIME type that
might be used at least refer to it.

I actually think that the double 'x' in 'xhtml+xml' is redundant,
and that 'application/html+xml' might be more appropriate.

From: Dan Kohn <[email-masked]>
To: Mark Baker <[email-masked]>, "Ned Freed (E-mail)" <[email-masked]>
Cc: [email-masked]
Subject: RE: text/xhtml+xml vs. application/xhtml+xml
Date: Wed, 18 Oct 2000 12:16:52 -0700
Sender: [email-masked]

Rather than trying to channel what the authors of RFC 2046 were thinking, it
seems like we should just ask them.  Specifically, Ned Freed and has been
instrumental in framing the issues we discuss in
<http://www.imc.org/draft-murata-xml>, is (I believe) the IESG member
presenting the draft, and also co-authored RFC 2046.

Ned, my understanding is that text/html is seen in retrospect as problematic
and has led to some of the user unhappiness with MIME, by presenting
information to users that they are unlikely to be able to deal with.  The
referenced paragraph in the draft was meant to capture some of the
discussion on the [email-masked] list, though I am on too slow a
modem to find the references.  I suspect that the distinction of application
versus text comes down to whether you expect most users to be like us (who
can heuristically recognize HTML, save to a file with the right file
extension, and then open in a browser) versus my mother, who just gets
annoyed with all of the cruft and gives up.

At the end of the day, I would evaluate based on failure scenarios.  I think
people would rather see an attachment than the source text, and are more
likely to be able to recover from the former.

In principal, your suggestion of registering both text/xhtml+xml and
application/xhtml+xml could enable the document author to decide based on
the fallback behavior desired.  However, this is unlikely to work as
expected due to the widespread practice of mapping MIME types to file
extensions, which provides insufficient granularity.  Also, if we are having
trouble evaluating the tradeoffs, it seems unlikely that most document
authors would understand the subtlety.  Finally, I also subscribe to section
3.2 of RFC 1958 on Architectural Principles of the Internet, which says, "If
there are several ways of doing the same thing, choose one."

		- dan

P.S.  Mark, I presume you will keep the HTML WG in the loop on this
discussion.

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

-----Original Message-----
From: Mark Baker [mailto:[email-masked]]
Sent: Wednesday, 2000-10-18 11:41
To: Dan Kohn
Cc: [email-masked]
Subject: Re: text/xhtml+xml vs. application/xhtml+xml

(HTML WG BCCd - the new w3.org spam filter makes it impractical to CC
them)

Hi Dan,

Dan Kohn wrote:
> 
> Mark, I would appreciate if the HTML WG could provide a little more
context
> on their thinking, perhaps by adding to discussion to the eventual XHTML
> MIME registration.
> 
> First, I'm not convinced that text/ is the correct top-level type.
Section
> 3 of <http://www.imc.org/draft-murata-xml> says:
> 
>    If an XML document -- that is, the unprocessed, source XML document
>    -- is readable by casual users, text/xml is preferable to
>    application/xml. MIME user agents (and web user agents) that do not
>    have explicit support for text/xml will treat it as text/plain, for
>    example, by displaying the XML entity as plain text. Application/xml
>    is preferable when the XML MIME entity is unreadable by casual
>    users. Similarly, text/xml-external-parsed-entity is preferable when
>    an external parsed entity is readable by casual users, but
>    application/xml-external-parsed-entity is preferable when a plain
>    text display is inappropriate.
> 
>       NOTE: Users are in general not used to text containing tags such
>       as <price>, and often find such tags quite disorienting or
>       annoying. If one is not sure, the conservative principle would
>       suggest using application/* instead of text/* so as not to put
>       information in front of users that they will quite likely not
>       understand.

That's interesting.  I guess I hadn't read that section.  Are you
attempting to update RFC 2046 on this subject?

>From RFC 2046, Sec 4.1;

"Beyond plain text, there are many formats for representing what might
be known as "rich text". An interesting characteristic of many such
representations is that they are to some extent readable even without
the software that interprets them. It is useful, then, to distinguish
them, at the highest level, from such unreadable data as images, audio,
or text represented in an unreadable form. In the absence of appropriate
interpretation software, it is reasonable to show subtypes of "text" to
the user, while it is not reasonable to do so with most nontextual data.
Such formatted textual data should be represented using subtypes of
"text"."

While this doesn't go into as much depth as draft-murata-xml does, the
HTML WG believes, despite the DOCTYPE/xmlns/HTML-header preamble, that
the bulk (i.e. body) of most XHTML documents will useful, to "some
extent" (per above), to casual users.

> It seems like application/* is thus the safer bet.  Moreover, section 2.11
> of <http://www.w3.org/TR/REC-xml> already standardizes end-of-line
handling,
> so the canonicalization of line endings that text/* supports does not seem
> necessary.

True.  That's a small point against text/* handling.  But we feel that
the text/plain fallback is more valuable.

Something we did consider, that we didn't really come to concensus on
(AFAIK) at this morning's call was the possibility of registering both
application/xhtml+xml and text/xhtml+xml, and letting server admins
decide which one wins (or if both are useful).  Any thoughts about that?

> Also, I would like to see some detailed discussion of when to use
> application/xhtml+xml and when to use text/html.  This seems like an
upward
> compatibility challenge of exceeding subtlety, and may deserve more
> attention than it received in your IRC conversation.

I'll follow that up in a separate message, hopefully soon.

> Thanks in advance for any insight you can provide into your and the WG's
> thinking.

No problem.

MB

Date: Wed, 18 Oct 2000 15:15:13 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

At 02:53 PM 10/18/00 -0400, Mark Baker wrote:
>Something we did consider, that we didn't really come to concensus on
>(AFAIK) at this morning's call was the possibility of registering both
>application/xhtml+xml and text/xhtml+xml, and letting server admins
>decide which one wins (or if both are useful).  Any thoughts about that?

I'd prefer to see JUST 'application/xhtml+xml', but could settle for having
both.

Transitions are never easy, it seems.

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

Date: Wed, 18 Oct 2000 15:04:32 -0400
From: Mark Baker <[email-masked]>
Organization: Sun Microsystems Inc.
To: Dan Kohn <[email-masked]>
CC: [email-masked]
Subject: XHTML vs HTML media types
Sender: [email-masked]

Hi Dan,

> Also, I would like to see some detailed discussion of when to use
> application/xhtml+xml and when to use text/html.  This seems like an upward
> compatibility challenge of exceeding subtlety, and may deserve more
> attention than it received in your IRC conversation.

Yes, that IRC conversation was not the first or only conversation we've
had on the matter.

In a nutshell, you'd use the HTML type when you wanted your XHTML to be
processed by a legacy processor.  If you wanted your XHTML processed as
XML (well-formedness expected, etc..), you'd send it with the XHTML
type.

There's some cross-over concerns here, such as the use of "name" vs.
"id" attributes ("name" isn't special in XHTML, but has id semantics in
HTML).  But those are being addressed.

Did you have any specific concerns you'd like to raise now?

Thanks.

MB

Date: Wed, 18 Oct 2000 14:53:44 -0400
From: Mark Baker <[email-masked]>
Organization: Sun Microsystems Inc.
To: Dan Kohn <[email-masked]>
CC: [email-masked]
Subject: Re: text/xhtml+xml vs. application/xhtml+xml
Sender: [email-masked]

(HTML WG BCCd - the new w3.org spam filter makes it impractical to CC
them.  Also, redirected to [email-masked], as you had sent it
to [email-masked])

Hi Dan,

Dan Kohn wrote:
> 
> Mark, I would appreciate if the HTML WG could provide a little more context
> on their thinking, perhaps by adding to discussion to the eventual XHTML
> MIME registration.
> 
> First, I'm not convinced that text/ is the correct top-level type.  Section
> 3 of <http://www.imc.org/draft-murata-xml> says:
> 
>    If an XML document -- that is, the unprocessed, source XML document
>    -- is readable by casual users, text/xml is preferable to
>    application/xml. MIME user agents (and web user agents) that do not
>    have explicit support for text/xml will treat it as text/plain, for
>    example, by displaying the XML entity as plain text. Application/xml
>    is preferable when the XML MIME entity is unreadable by casual
>    users. Similarly, text/xml-external-parsed-entity is preferable when
>    an external parsed entity is readable by casual users, but
>    application/xml-external-parsed-entity is preferable when a plain
>    text display is inappropriate.
> 
>       NOTE: Users are in general not used to text containing tags such
>       as <price>, and often find such tags quite disorienting or
>       annoying. If one is not sure, the conservative principle would
>       suggest using application/* instead of text/* so as not to put
>       information in front of users that they will quite likely not
>       understand.

That's interesting.  I guess I hadn't read that section.  Are you
attempting to update RFC 2046 on this subject?

>From RFC 2046, Sec 4.1;

"Beyond plain text, there are many formats for representing what might
be known as "rich text". An interesting characteristic of many such
representations is that they are to some extent readable even without
the software that interprets them. It is useful, then, to distinguish
them, at the highest level, from such unreadable data as images, audio,
or text represented in an unreadable form. In the absence of appropriate
interpretation software, it is reasonable to show subtypes of "text" to
the user, while it is not reasonable to do so with most nontextual data.
Such formatted textual data should be represented using subtypes of
"text"."

While this doesn't go into as much depth as draft-murata-xml does, the
HTML WG believes, despite the DOCTYPE/xmlns/HTML-header preamble, that
the bulk (i.e. body) of most XHTML documents will useful, to "some
extent" (per above), to casual users.

> It seems like application/* is thus the safer bet.  Moreover, section 2.11
> of <http://www.w3.org/TR/REC-xml> already standardizes end-of-line handling,
> so the canonicalization of line endings that text/* supports does not seem
> necessary.

True.  That's a small point against text/* handling.  But we feel that
the text/plain fallback is more valuable.

Something we did consider, that we didn't really come to concensus on
(AFAIK) at this morning's call was the possibility of registering both
application/xhtml+xml and text/xhtml+xml, and letting server admins
decide which one wins (or if both are useful).  Any thoughts about that?

> Also, I would like to see some detailed discussion of when to use
> application/xhtml+xml and when to use text/html.  This seems like an upward
> compatibility challenge of exceeding subtlety, and may deserve more
> attention than it received in your IRC conversation.

I'll follow that up in a separate message, hopefully soon.

> Thanks in advance for any insight you can provide into your and the WG's
> thinking.

No problem.

MB

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt
Date: Wed, 18 Oct 2000 22:37:39 +0900 (JST)
Lines: 43
Sender: [email-masked]

Dan and Philipp,

> Philipp, could I suggest that you review
> <http://www.imc.org/draft-murata-xml>, which is expected to shortly replace
> RFC 2376.  Specifically, I would strongly recommend changing your
> application to application/smil+xml, and quoting the appropriate sections of
> RFC 2376bis by reference rather than by repeating the text.
> 
> Thanks for considering this.
> 
> 		- dan

I raised this issue in January.
-- http://www.imc.org/ietf-xml-mime/mail-archive/msg00315.html

Philipp replied. 
--http://www.imc.org/ietf-xml-mime/mail-archive/msg00319.html

>However, the use of "application/smil" predates the proposal of 
>appending "-xml" to XML-based MIME types by more than a year - I think
>the first Internet draft dates from April '98. The proposal has
>already been succesfully reviewed in the past on ietf-types,
>but somebody dropped the ball bringing it to the IESG. Given
>this history, and that there is an installed base, it seems reasonable 
>to stick with the current practice of using "application/smil".

I requested addition of this historical reason in the I-D.
-- http://www.imc.org/ietf-xml-mime/mail-archive/msg00320.html

>However, in order not to make an antecedent, I would like the I-D to mention 
>this name convention and reasons not to follow it.

Phillip oked.
-- http://www.imc.org/ietf-xml-mime/mail-archive/msg00321.html

Phillip, could you revise the I-D as you promised?

Cheers,

IBM Tokyo Research Lab &
International University of Japan, Research Institute

MURATA Makoto

From: Dan Kohn <[email-masked]>
To: Graham Klyne <[email-masked]>
Cc: [email-masked]
Subject: RE: XML MIME types draft
Date: Tue, 17 Oct 2000 18:19:53 -0700
Sender: [email-masked]

Fair point, but we published the draft (and it should have now finished last
call) well before the publication of RFC 2913 (regarding which, congrats).
So, presuming that the IESG decides we have passed Last Call, we will need
to fix in the nest iteration of the standard.

Given that we have 35 references, and there are multi-month latencies built
into the last call and the RFC Editor process, I'm pretty certain we could
never publish without having one of our references grow out of date during
the process.

I expect we will be reissuing the draft before too long anyway, though,
specifically when XBase and XPointer go to W3 Recommendation.  We'll be sure
to fix the conneg references at that time.

Thanks.

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

-----Original Message-----
From: Graham Klyne [mailto:[email-masked]]
Sent: Tuesday, 2000-10-17 15:15
To: Dan Kohn
Cc: [email-masked]
Subject: XML MIME types draft

At 09:17 AM 10/17/00 -0700, you wrote:
>.... Specifically, I would strongly recommend changing your
>application to application/smil+xml, and quoting the appropriate sections
of
>RFC 2376bis by reference rather than by repeating the text.

I noticed this and realized I hadn't checked this draft for some time... 
not since '|xml' was the preferred suffix....

In browsing through, I noticed this:

>A.10 How about using a conneg tag instead (e.g., accept-features:
>      (syntax=xml))?
>
>    When the conneg protocol is fully defined, this may potentially be a
>    reasonable thing to do. But given the limited current state of
>    conneg[RFC2703] development, it is not a credible replacement for a
>    MIME-based solution.
>
>    Also, note that adding a content-type parameter doesn't work with
>    conneg either, since conneg only deals with media types, not their
>    parameters. This is another illustration of the limits of parameters
>    for MIME dispatchers.

While I agree that feature expressions are probably inappropriate for the 
kind of thing you want to do, I disagree with the reasons.

The conneg spec is complete:  RFC2506, RFC 2533, RFC 2912 define the key 
elements here.  All that is missing is a feature tag for expressing XML 
content, and it might be argued that (type='application/xml') could achieve 
that -- see RFC 2913.

I would suggest text something like:

>A.10 How about using a conneg tag instead (e.g., accept-features:
>      (syntax=xml))?
>
>    The conneg framework is designed for use as a protocol element in
>    content negotiation over a broad range of media features.  It's use
>    for simply designating XML formatted data would place an unnecessary
>    processing burden on systems that merely want to
>    invoke generic XML processing where possible.
>
>    For full content negotiation, as opposed to opportunistic XML handling,
>    the +xml convention SHOULD NOT be exploited.  Rather, a mechanism using
>    full content feature description should be employed, such as provided
by
>    RFC 2506, RFC2533, RFC 2912, etc.

#g

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

From: Dan Kohn <[email-masked]>
To: [email-masked], [email-masked]
Subject: text/xhtml+xml vs. application/xhtml+xml
Date: Tue, 17 Oct 2000 10:49:13 -0700
Sender: [email-masked]

Mark, I would appreciate if the HTML WG could provide a little more context
on their thinking, perhaps by adding to discussion to the eventual XHTML
MIME registration.

First, I'm not convinced that text/ is the correct top-level type.  Section
3 of <http://www.imc.org/draft-murata-xml> says:

   If an XML document -- that is, the unprocessed, source XML document
   -- is readable by casual users, text/xml is preferable to
   application/xml. MIME user agents (and web user agents) that do not
   have explicit support for text/xml will treat it as text/plain, for
   example, by displaying the XML entity as plain text. Application/xml
   is preferable when the XML MIME entity is unreadable by casual
   users. Similarly, text/xml-external-parsed-entity is preferable when
   an external parsed entity is readable by casual users, but
   application/xml-external-parsed-entity is preferable when a plain
   text display is inappropriate.

      NOTE: Users are in general not used to text containing tags such
      as <price>, and often find such tags quite disorienting or
      annoying. If one is not sure, the conservative principle would
      suggest using application/* instead of text/* so as not to put
      information in front of users that they will quite likely not
      understand.

Using the canonical mother example, I know that my mother, who does not mind
looking at <http://www.dankohn.com/>, would be upset if her mailer revealed
the ugly innards:

   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   <html
    xmlns="http://www.w3.org/1999/xhtml"
    xml:lang="en">
     <head>
       <meta
        name="generator"
        content="HTML Tidy, see www.w3.org" />
       <meta
        http-equiv="Content-Type"
        content="text/html; charset=utf-8" />
       <title>
         Dan Kohn's Home Page
       </title>
       ...

It seems like application/* is thus the safer bet.  Moreover, section 2.11
of <http://www.w3.org/TR/REC-xml> already standardizes end-of-line handling,
so the canonicalization of line endings that text/* supports does not seem
necessary.

Also, I would like to see some detailed discussion of when to use
application/xhtml+xml and when to use text/html.  This seems like an upward
compatibility challenge of exceeding subtlety, and may deserve more
attention than it received in your IRC conversation.

Thanks in advance for any insight you can provide into your and the WG's
thinking.

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

From: Dan Kohn <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: FW: I-D ACTION:draft-hoschka-smil-media-type-05.txt
Date: Tue, 17 Oct 2000 09:17:39 -0700
Sender: [email-masked]

Philipp, could I suggest that you review
<http://www.imc.org/draft-murata-xml>, which is expected to shortly replace
RFC 2376.  Specifically, I would strongly recommend changing your
application to application/smil+xml, and quoting the appropriate sections of
RFC 2376bis by reference rather than by repeating the text.

Thanks for considering this.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, 2000-10-17 03:47
Subject: I-D ACTION:draft-hoschka-smil-media-type-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: The application/smil Media Type
	Author(s)	: P. Hoschka
	Filename	: draft-hoschka-smil-media-type-05.txt
	Pages		: 4
	Date		: 16-Oct-00
	
This document specifies the Media Type for version 1 of the
Synchronized Multimedia Integration Language (SMIL 1.0). SMIL allows
integrating a set of independent multimedia objects into a
synchronized multimedia presentation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hoschka-smil-media-type-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hoschka-smil-media-type-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Sun, 15 Oct 2000 15:05:23 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: [email-masked]
Subject: Re: Requiring charset parameter on +xml types?
Sender: [email-masked]

On Sun, 15 Oct 2000 [email-masked] wrote:

> Martin,
> 
> > - For text/html+xml (and that would work for all types, actually),
> >    beef up the servers so that they can use the information in the
> >    file to set the charset parameter correctly.
> 
> Matt Sergeant has already implemented a Perl module "Apache::MimeXML".  
> Let's encourage such implementation efforts!

But not by making it a requirement.  Get the implementations universally
deployed first.  Otherwise clients will be written expecting something
that that cannot be provided: don't create interoperability problems!

Rick Jelliffe

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: Re: Requiring charset parameter on +xml types?
Date: Sun, 15 Oct 2000 00:35:22 +0900 (JST)
Lines: 37
Sender: [email-masked]

Martin,

> - For text/html+xml (and that would work for all types, actually),
>    beef up the servers so that they can use the information in the
>    file to set the charset parameter correctly.

Matt Sergeant has already implemented a Perl module "Apache::MimeXML".  
Let's encourage such implementation efforts!

http://www.cpan.org/modules/by-module/Apache/Apache-MimeXML-0.08.readme

> NAME
>     Apache::MimeXML - mod_perl mime encoding sniffer for XML files
> 
> SYNOPSIS
>     Simply add this line to srm.conf or httpd.conf:
> 
>       PerlTypeHandler +Apache::MimeXML
> 
>     Alternatively add it only for certain files or directories using
>     the standard Apache methods. There is about a 30% slowdown for
>     files using this module, so you probably want to restrict it to
>     certain XML locations only.
> 
> DESCRIPTION
>     An XML Content-Type sniffer. This module reads the encoding
>     attribute in the xml declaration and returns an appropriate
>     content-type heading. If no encoding declaration is found it
>     returns utf-8 or utf-16 depending on the specific encoding.

Cheers,

IBM Tokyo Research Lab &
International University of Japan, Research Institute

MURATA Makoto

Date: Sat, 14 Oct 2000 10:11:29 +0900
To: Mark Baker <[email-masked]>, [email-masked]
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: Requiring charset parameter on +xml types?
Sender: [email-masked]

Hello Mark,

As far as I understand, for text/...+xml, the charset parameter
is very close to being required (by using the general MIME default
of us-ascii, which overrides any internal information).
For application/...+xml (or others such as image/...+xml), the
internal information is relevant if there is no charset parameter.

To solve the problems, the following things should help:

- Help to make system administrators, webmasters, and so on,
   aware of the fact that they have to allow settings and have
   to make them.
- Maybe to define a type application/html+xml for use by those
   people who want to just ship files around.
- For text/html+xml (and that would work for all types, actually),
   beef up the servers so that they can use the information in the
   file to set the charset parameter correctly.
   [Sorry to be a bit lengthy here, but I just almost got excited
    about this idea.]
   This would work about as follows:
   - Server detects that content type of outgoing stuff is +xml.
   - Server verifies that there is no setting for the charset
     parameter in the configuration.
   - Server peeks into the data to check for a BOM and/or for an
     encoding declaration.
   - Server sets charset parameter.

   Please note the following:
   - If this feature is introduced into a server without any
     configuration options, the only potentially undesirable
     effect is to label files that were intended to go out
     as defaulted to us-ascii as utf-8 explicitly. But this
     is in no way a problem, because every us-ascii file is
     a utf-8 file (this means no wrong labels), and because
     the chance that a receiving XML processor understands
     utf-8 are higher than for us-ascii (utf-8 is required,
     us-ascii is not).
   - Such a feature has been the idea behind <meta http-equiv,
     but it turned out that the lookahead length and processing
     effort for that is much too high. For the xml encoding
     declaration, things look much better.

Regards,   Martin.

At 00/10/13 13:52 -0400, Mark Baker wrote:
>Greetings,
>
>At the HTML WG f2f yesterday, it was proposed that we should require the
>use of the charset parameter on the XHTML media type.  This came up in
>the discussion over whether the media type should use application/ or
>text/.
>
>Would requiring this parameter help solve the problem of those broken
>web servers that I've heard about that mislabel non-US-ASCII encoded
>text/* content as US-ASCII?
>
>Are the any other issues/pros/cons we should be aware of for requiring
>this parameter?
>
>Thanks.
>
>BTW, for W3C members that are interested (i.e. it's not required reading
>to grok this message - mustUnderstand = 0 :-), the IRC log of the
>conversation is available at;
>
>http://lists.w3.org/Archives/Member/w3c-html-wg/2000OctDec/0104.html
>
>MB

Date: Sat, 14 Oct 2000 02:08:49 +0800 (CST)
From: Rick Jelliffe <[email-masked]>
To: Mark Baker <[email-masked]>
cc: [email-masked]
Subject: Re: Requiring charset parameter on +xml types?
Sender: [email-masked]

On Fri, 13 Oct 2000, Mark Baker wrote:

> Would requiring this parameter help solve the problem of those broken
> web servers that I've heard about that mislabel non-US-ASCII encoded
> text/* content as US-ASCII?

No.  Servers would just be setup to provide some default and system
administrators would not change it, or just use something convenient.

It can only work if there is also a mechanism transfering encoding
information from the generator of the entity to the HTTP system. This is
nice for program-generated data, but for data that has to sit on a file
system or be edoted by hand it is unworkable.
 
Rick Jelliffe
Academia Sinica Computing Center

Date: Fri, 13 Oct 2000 13:52:40 -0400
From: Mark Baker <[email-masked]>
Organization: Sun Microsystems Inc.
To: [email-masked]
Subject: Requiring charset parameter on +xml types?
Sender: [email-masked]

Greetings,

At the HTML WG f2f yesterday, it was proposed that we should require the
use of the charset parameter on the XHTML media type.  This came up in
the discussion over whether the media type should use application/ or
text/.

Would requiring this parameter help solve the problem of those broken
web servers that I've heard about that mislabel non-US-ASCII encoded
text/* content as US-ASCII?

Are the any other issues/pros/cons we should be aware of for requiring
this parameter?

Thanks.

BTW, for W3C members that are interested (i.e. it's not required reading
to grok this message - mustUnderstand = 0 :-), the IRC log of the
conversation is available at;

http://lists.w3.org/Archives/Member/w3c-html-wg/2000OctDec/0104.html

MB

Date: Mon, 02 Oct 2000 15:52:42 -0400
To: Philipp Hoschka <[email-masked]>
From: "Eve L. Maler" <[email-masked]>
Subject: Re: MIME-XML technology?
Cc: "Simon St.Laurent" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 08:22 PM 10/2/00 +0200, Philipp Hoschka wrote:
>They're referring to multipart-MIME - that's what ebXML is using to
>assemble different documents (of any format) into one message.
>
>The ebXML TRP spec is online, btw - check out the ebXML website
>(locatable via google search).
>
>This discussion is probably more appropriate for the xml-dist-app
>list.

Just to round things off, the relevant spec is at:

   http://www.ebxml.org/specdrafts/ebXML_Messaging_Service_Specification_v0-21.pdf

         Eve
--
Eve Maler                                          +1 781 442 3190
Sun Microsystems XML Technology Center    eve.maler @ east.sun.com

Date: Mon, 02 Oct 2000 14:31:10 -0400
To: Philipp Hoschka <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: MIME-XML technology?
Cc: [email-masked]
Sender: [email-masked]

At 08:22 PM 10/2/00 +0200, Philipp Hoschka wrote:
>They're referring to multipart-MIME - that's what ebXML is using to
>assemble different documents (of any format) into one message.
>
>The ebXML TRP spec is online, btw - check out the ebXML website
>(locatable via google search).
>
>This discussion is probably more appropriate for the xml-dist-app
>list.

Agreed - I was just irritated by the naming convention used in the article,
which suggests that something more is going on between MIME and XML.

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

Date: Mon, 02 Oct 2000 20:22:50 +0200
From: Philipp Hoschka <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
CC: [email-masked]
Subject: Re: MIME-XML technology?
Sender: [email-masked]

They're referring to multipart-MIME - that's what ebXML is using to
assemble different documents (of any format) into one message.

The ebXML TRP spec is online, btw - check out the ebXML website
(locatable via google search).

This discussion is probably more appropriate for the xml-dist-app
list.

"Simon St.Laurent" a écrit :
> 
> Does anyone know what the "MIME-XML technology to wrap and send the
> message" this article discusses might be?
> 
> http://www.sdtimes.com/news/015/story1.htm
> 
> It sounds at the end like there's some Sun messaging spec (JAXN) involved,
> but I'm pretty irritated to find 'MIME-XML technology' set up in some kind
> of weird contrast to SOAP.
> 
> I don't love SOAP, and I doubt the journalist was given great information
> about this 'MIME-XML' critter, but I'm really scratching my head.
> 
> Simon St.Laurent
> XML Elements of Style / XML: A Primer, 2nd Ed.
> XHTML: Migrating Toward XML
> http://www.simonstl.com - XML essays and books

Date: Mon, 02 Oct 2000 14:21:17 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: MIME-XML technology?
Sender: [email-masked]

Does anyone know what the "MIME-XML technology to wrap and send the
message" this article discusses might be?

http://www.sdtimes.com/news/015/story1.htm

It sounds at the end like there's some Sun messaging spec (JAXN) involved,
but I'm pretty irritated to find 'MIME-XML technology' set up in some kind
of weird contrast to SOAP.

I don't love SOAP, and I doubt the journalist was given great information
about this 'MIME-XML' critter, but I'm really scratching my head.

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

Date: Mon, 02 Oct 2000 11:36:51 -0400
To: Paul Grosso <[email-masked]>
From: "Eve L. Maler" <[email-masked]>
Subject: Re: 
Cc: Chris Lilley <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 10:15 AM 10/2/00 -0500, Paul Grosso wrote:
>I found a mention of fragment identifier and the # separator in
>RFC 2396 [1], but I'm still looking for the discussion of the ?
>and | separator (especially, whether they require/allow the entire
>resource to be downloaded first or not and exactly where/by whom
>the bit after the | or ? should get processed).  Can someone give
>pointers to the specs that answer these questions?  (I've already
>looked at RFC 1738, 1808, and 2396.)  Thanks.
>
>[1] ftp://ftp.ietf.org/rfc/rfc2396.txt

The "query component" (starting with a ?) is discussed in RFC 2396, but I'm 
surprised, on reading this now, that it doesn't say more about the 
server/user agent distinction.  It does say "The query component is a 
string of information to be interpreted by the resource", and perhaps 
that's 2396-speak meaning that it's information to be interpreted by the 
system that serves the resource.

The | separator was invented out of whole cloth in an early version of 
XLL/XLink; when we (the W3C XML Linking WG) broke out the XPointer stuff 
into its own spec, the | went away because we had been inappropriately 
messing with basic URI functionality.  Once we got on the track of defining 
a fragment identifier language for a particular set of media types, the 
scope became somewhat simpler and clearer.

         Eve
--
Eve Maler                                          +1 781 442 3190
Sun Microsystems XML Technology Center    eve.maler @ east.sun.com

Date: Mon, 02 Oct 2000 11:24:32 -0400
To: Lloyd Rutledge <[email-masked]>, Chris Lilley <[email-masked]>, [email-masked], [email-masked], Philipp Hoschka <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Conformance value of "+xml"? (was empty, or "[symm]")
Sender: [email-masked]

At 02:07 PM 10/2/00 +0200, Lloyd Rutledge wrote:
>Having W3C require implementors of one standard be required to
>implement several others from day one, if that correctly paraphrases
>you, Simon, may have its merits -- and with the luxury of not being an
>implementor myself, I'm inclined to see these merits.  However,
>(speaking as advocate-in-proxy) implementors are typically very hard
>pressed to implement even the one standard for the first release,
>especially is that release date is targeted to coincide with the
>release of the format itself.  This is complicated further if the
>related standard itself is not yet released as a recommendation, as is
>the case with XPointer.  If every potentially related standard had to
>also be implemented, it would be a long time before we see SMIL 2.0,
>and other formats, first emerge in any practical sense.  It may be
>wise to slow release cycles as part of deliberate full step-by-step
>inter-format integration, but it would put a hard-to-ignore strain on
>implementors.

I agree that it puts strain on implementors, but I think it points to an
architectural implementation change that XML is driving: moving toward
reusable code at various levels of a program.

At some point I'd like to dream that this will be an integration problem
rather than a development problem, but right now I can see where that's not
too promising.  Getting generic modules out into the world and used is
pretty difficult, it seems.

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

Date: Mon, 02 Oct 2000 10:15:45 -0500
To: Chris Lilley <[email-masked]>
From: Paul Grosso <[email-masked]>
Subject: Re: 
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 02:59 2000 09 30 +0200, Chris Lilley wrote:
>"Simon St.Laurent" wrote:
>> At 01:33 AM 9/30/00 +0200, Chris Lilley wrote:
>> >> Used in a query string, XPointers could be processed by the server,
>> >
>> >they could be, but then they wouldn't be fragment identifiers. besides,
>> >thats what the XML Query WG is cooking up, right?
>> 
>> I'm not sure why you feel they wouldn't be fragment identifiers.
>
>I am using the term fragment identifiers in the sense it is used in the
>UROI specifications. 

I found a mention of fragment identifier and the # separator in
RFC 2396 [1], but I'm still looking for the discussion of the ?
and | separator (especially, whether they require/allow the entire
resource to be downloaded first or not and exactly where/by whom 
the bit after the | or ? should get processed).  Can someone give
pointers to the specs that answer these questions?  (I've already
looked at RFC 1738, 1808, and 2396.)  Thanks.

[1] ftp://ftp.ietf.org/rfc/rfc2396.txt

>> I strongly hope that the XML Query WG doesn't feel compelled to reinvent
>> this particular wheel or worse, create a syntax that bars the reuse of
>> XPointers for this work. 
>
>My understanding is that their work builds on XPointer.

You should read the following public documents if you want to know more:

XML Query Requirements -- W3C Working Draft 15 August 2000
http://www.w3.org/TR/xmlquery-req

XML Query Data Model -- W3C Working Draft 11 May 2000
http://www.w3.org/TR/query-datamodel/

Quoting from the Intro of the latter document:

 Several XML data models have been developed in the W3C
 Activities. The XML Information Set
 (http://www.w3.org/TR/xml-infoset) provides a description
 of the information available in a well-formed XML document.
 The XPath Recommendation ( http://www.w3.org/TR/xpath), which is
 used by both XSLT ( http://www.w3.org/TR/xslt) and XPointer 
 ( http://www.w3.org/TR/xptr), contains a data model and a
 mapping that relates the XPath data model to the XML Information
 Set (hence ``Infoset''). The Document Object Model
 ( http://www.w3.org/TR/DOM-Level-2/) is an API for HTML
 and XML documents, but it does imply an underlying abstract
 data model. The XML Schema Working Group is defining features,
 such as structures (http://www.w3.org/TR/xmlschema-1) and
 datatypes (http://www.w3.org/TR/xmlschema-2), that extend
 an instance of the XML Information Set
 with more precise type information. 

 The XML Query Data Model defines formally the information
 contained in the input to an XML Query processor; in other
 words, an XML Query processor evaluates a query on an instance of the
 XML Query Data Model. Our model is based on the XML Information
 Set, but it requires the following new features to meet the
 XML Query Working Group's requirements: . . .

You should draw your own conclusions about the relationship
between XPointer and XML Query, but it is not obvious that
XML Query will end up with either a model or a syntax that
is a subset of XPointer.  (And I'm not saying that they should
or shouldn't, but it sounded a bit like Simon might have an
opinion on that question.)

paul

Date: Mon, 02 Oct 2000 16:58:30 +0200
From: Chris Lilley <[email-masked]>
Organization: W3C
To: Lloyd Rutledge <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], Philipp Hoschka <[email-masked]>
Subject: Re: Conformance value of "+xml"? (was empty, or "[symm]")
Sender: [email-masked]

Lloyd Rutledge wrote:
> 
> On Sat, Sep 30 2000 Chris Lilley wrote:
> > OK. Your understanding is not correct. Servers do not process the fragment
> > identifiers, because therse are not sent to the server (queries, following
> > a ? character, *are* sent to the server and perhaps that is what you are
> > thinking of?)

> Thanks, Chris -- I stand corrected.  Other main points from my
> previous post still stand, though.

Yes, of course. I was not disagreeing with your entire post - just the
particular part about fragment identifiers appended to URIs.

>  Many SMIL constructs have values
> that are XPointer subsets, rather than being SMIL-only.  This
> minimizes format re-learning and facilitates future further
> incorporation of XPointer.  Full XPointer is not required in SMIL, but
> is explicitly enabled.

That seems to be wise at this point; a future direction is clearly shown,
and what is there is compatible (proper subset) so a general purpose
XPointer inmplementation can be used.

-- 
Chris

To: Chris Lilley <[email-masked]>, [email-masked], [email-masked], [email-masked], Philipp Hoschka <[email-masked]>
Subject: Re: Conformance value of "+xml"? (was empty, or "[symm]")
Date: Mon, 02 Oct 2000 14:07:31 +0200
From: Lloyd Rutledge <[email-masked]>
Sender: [email-masked]

On Sat, Sep 30 2000 Chris Lilley wrote:

> Lloyd Rutledge wrote:
> > The reason that the SMIL 2.0 spec does not require that
> > browsers process XPointer is that browsers don't and can't process
> > XPointer -- servers do.  Please correct me if my understanding of the
> > general architecture is too primitive,
> 
> OK. Your understanding is not correct. Servers do not process the fragment
> identifiers, because therse are not sent to the server (queries, following
> a ? character, *are* sent to the server and perhaps that is what you are
> thinking of?)
> 
> > but servers process XPointer,
> > not clients -- right?. 
> 
> No.
> 
> > Clients send URI's to the given server,
> 
> yes. The fragment is not part of the URI and is not sent
> 
> >  the
> > server processes it and returns the located data to the client.
> 
> Yes, and then the client locates the relevant part of this resource using
> the fragment identifier.

Thanks, Chris -- I stand corrected.  Other main points from my
previous post still stand, though.  Many SMIL constructs have values
that are XPointer subsets, rather than being SMIL-only.  This
minimizes format re-learning and facilitates future further
incorporation of XPointer.  Full XPointer is not required in SMIL, but
is explicitly enabled.

Having W3C require implementors of one standard be required to
implement several others from day one, if that correctly paraphrases
you, Simon, may have its merits -- and with the luxury of not being an
implementor myself, I'm inclined to see these merits.  However,
(speaking as advocate-in-proxy) implementors are typically very hard
pressed to implement even the one standard for the first release,
especially is that release date is targeted to coincide with the
release of the format itself.  This is complicated further if the
related standard itself is not yet released as a recommendation, as is
the case with XPointer.  If every potentially related standard had to
also be implemented, it would be a long time before we see SMIL 2.0,
and other formats, first emerge in any practical sense.  It may be
wise to slow release cycles as part of deliberate full step-by-step
inter-format integration, but it would put a hard-to-ignore strain on
implementors.

But regardless of the merits of either side, SMIL 2.0 is in last call,
and so it is unlikely such a large new requirement can be introduced.
In the end, with XPointer enabled in SMIL, it is the free market that
will decide to what degree XPointer is implemented and used in SMIL.
This is as true with XPointer as it is with the media formats
themselves that SMIL integrates.  The implementors will listen to
their customer base.  What sweetens the pot for implementors is the
availability of other XPointer implementations -- especially those in
open source, of course.  The fact that the W3C XPointer page has an
XPointer implementation list that is empty is not encouraging [1], but
over time this will surely change.  As customers and implementors step
forward and make themselves known, XPointer use will grow in SMIL,
XHTML and other formats.

-Lloyd

[1] http://www.w3.org/XML/Linking

--
Lloyd Rutledge  vox: +31 20 592 41 27       fax: +31 20 592 41 99
CWI             net: [email-masked]  Web: http://www.cwi.nl/~lloyd
Post:   PO Box 94079   |  NL-1090 GB Amsterdam  |  The Netherlands
Street: Kruislaan 413  |  NL-1098 SJ Amsterdam  |  The Netherlands