Subject: Re: Registration of media type application/xhtml-voice+xml
From: Bruce Lilly <[email-masked]>
To: [email-masked]
Cc: Martin Duerst <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 20 Jul 2005 09:27:49 -0400
List-Id: <ietf-xml-mime.imc.org>

[dropping IANA and duplicates from Ccs]

On Thu July 14 2005 02:49, Martin Duerst wrote:
> I agree with that reviewer that the type should not contain
> '+' characters except before 'xml'. All other subtypes have used '-'
> as a separator. The '+' separator was specifically introduced to
> express the fact that the '+xml' part is something more than
> a simple subtype.

Neither the MIME specifications nor draft-freed-media-type-reg-04.txt
define any "separator" (other than '/' between type and subtype).  The
syntax merely provides a set of acceptable characters.  A subtype name
of "!#$&.+-^_" is perfectly acceptable and contains no "separator".
The draft does mention "+xml" as a suffix convention as documented in
RFC 3023.  We need to bear in mind the difference between rules and
conventions, as well as the voluntary nature of RFC conformance.

> Although there is probably nothing in RFC 3023 explicitly
> disallowing the use of '+' for "arbitrary use", I think that
> the whole rationale for '+xml' in Appendix A of RFC 3023
> (in particular http://www.ietf.org/rfc/rfc3023.txt, A.12)
> seem to indicate that it shouldn't be done.

3023 defines a convention (3023 term) using a suffix (also the 3023
term).  There is nothing in the MIME specifications, the Freed draft,
or RFC 3023 that implies that '+' has any special status per se.

> >I believe this argument is not strong enough to prevent approval of the 
> >application/xhtml+voice+xml media type:

I concur.
 
> >2. The argument for having "+" in the subtype is unconvincing, given that 
> >the simplest method to determine if something is XML is also the safest, 
> >that is, if the last four characters are "+xml" or "/xml" then the 
> >document is XML, otherwise it is not.

I vehemently disagree.  The name and the content are different things --
sometimes content is mislabeled.  It is absolutely not "the safest" to
assume particular content based solely on the name.  Reasonable security
practice dictates examination of the content itself.  The practice of
assuming particular content based solely upon the name, coupled with
automatic execution, has led to the spread of many, probably most, MS
Windows "worms".

To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Registration of media type application/xhtml-voice+xml
From: Gerald McCobb <[email-masked]>
Date: Fri, 15 Jul 2005 09:53:26 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 004C4B788525703F_=
Content-Type: text/plain; charset="US-ASCII"

* Bjoern Hoehrmann wrote:
>* Gerald McCobb wrote:
>>However, as noted in the Internet-Draft, XHTML+Voice user agents have
>>special processing requirements including support for XML Events and
>>VoiceXML.  An initialized VoiceXML interpreter is a specific 
requirement.
>>This mime type is limited to XHTML+Voice applications and I don't 
propose
>>to change the limited designation in the internet draft.

>Much of the existing application/xhtml+xml content relies on support of
>a variety of features such as the Macromedia Flash format and scripting.
>I think the litmus test here is simple: are user agents that do not
>support XHTML+Voice but XHTML 1.0/1.1 required to reject application/
>xhtml-voice+xml content as beeing in an unsupported format?

XHTML+Voice adds the voice mode of interaction to web applications.  This
additional mode of interaction is not that important for desktop clients.
Voice Interaction is useful for clients with limited processing, memory,
and network resources, such as cell phones and wireless PDAs.  For clients
that don't accept XHTML+Voice markup it matters whether it has to receive
and ignore additional markup.  For these clients it is important that
applications send markup dedicated to what they support.

>If yes, a new media type is certainly justified. If it is acceptable or
>even encouraged to process the content by ignoring the unknown bits then
>there does not seem to be considerable value in this new type. As you
>pointed out, W3C might at some point produce a recommendation where you
>can use XHTML with inline SVG content; with application/xhtml-voice+xml
>it's not really clear whether XHTML+Voice+SVG content should use
>application/xhtml+xml, application/xhtml-voice+xml, or some third type.

XHTML+Voice adds voice as another mode of interaction with the 
application,
while SVG is in most cases an important informational part of the
application.

>XHTML+SVG content, unless the SVG fragments are in the <head> element
>and referenced via something like <object data="#svg" />, would depend
>even more on inline-SVG support than XHTML+Voice on inline VoiceXML
>support, if we need to define a new media type for each combination of
>XML formats, we'll quickly get a system where it simply does not matter
>whether one uses specialized types or just application/xml.

This is one of the issues before the W3C CDF working group.

>>Are "+suffix" constructs the same as putting "+" within the subtype?  A
>>mime type such as application/xhtml+voice+xml that maps directly to
>>XHTML+Voice is easy for authors to understand.  I still see the "-" as
>>minus.  What does application/xhtml-voice+xml mean but XHTML minus 
voice.
>>As you know, XHTML already doesn't have voice...

>And application/xml-dtd is for XML documents without DTD? Registered
>types with "-" typically use the "-" to separate words. As you pointed
>out, there aren't really types for "compound" formats yet; but it is
>also not clear to me whether we should have such types at all. If the
>CDF Working Group is really considering to have a single type for a
>very wide range of combinations, why can't you use that type instead?

I'm talking about a perception that leads to a misunderstanding that I
have already received.  I understand that application/xml-dtd means
"xml dtd" but "application/xhtml-voice" means "xhtml voice" and the
language is "xhtml+voice".
 
We don't know today what the CDF working group will decide and their
decision is probably a few years away.  In the meantime, there are
XHTML+Voice applications in operation today.

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109

--=_alternative 004C4B788525703F_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2><tt>* Bjoern Hoehrmann wrote:</tt></font>
<br><font size=2><tt>&gt;* Gerald McCobb wrote:<br>
&gt;&gt;However, as noted in the Internet-Draft, XHTML+Voice user agents
have<br>
&gt;&gt;special processing requirements including support for XML Events
and<br>
&gt;&gt;VoiceXML. &nbsp;An initialized VoiceXML interpreter is a specific
requirement.<br>
&gt;&gt;This mime type is limited to XHTML+Voice applications and I don't
propose<br>
&gt;&gt;to change the limited designation in the internet draft.<br>
<br>
&gt;Much of the existing application/xhtml+xml content relies on support
of<br>
&gt;a variety of features such as the Macromedia Flash format and scripting.<br>
&gt;I think the litmus test here is simple: are user agents that do not<br>
&gt;support XHTML+Voice but XHTML 1.0/1.1 required to reject application/<br>
&gt;xhtml-voice+xml content as beeing in an unsupported format?</tt></font>
<br>
<br><font size=2><tt>XHTML+Voice adds the voice mode of interaction to
web applications. &nbsp;This</tt></font>
<br><font size=2><tt>additional mode of interaction is not that important
for desktop clients.</tt></font>
<br><font size=2><tt>Voice Interaction is useful for clients with limited
processing, memory,</tt></font>
<br><font size=2><tt>and network resources, such as cell phones and wireless
PDAs. &nbsp;For clients</tt></font>
<br><font size=2><tt>that don't accept XHTML+Voice markup it matters whether
it has to receive</tt></font>
<br><font size=2><tt>and ignore additional markup. &nbsp;For these clients
it is important that</tt></font>
<br><font size=2><tt>applications send markup dedicated to what they support.</tt></font>
<br>
<br><font size=2><tt>&gt;If yes, a new media type is certainly justified.
If it is acceptable or</tt></font>
<br><font size=2><tt>&gt;even encouraged to process the content by ignoring
the unknown bits then</tt></font>
<br><font size=2><tt>&gt;there does not seem to be considerable value in
this new type. As you</tt></font>
<br><font size=2><tt>&gt;pointed out, W3C might at some point produce a
recommendation where you</tt></font>
<br><font size=2><tt>&gt;can use XHTML with inline SVG content; with application/xhtml-voice+xml</tt></font>
<br><font size=2><tt>&gt;it's not really clear whether XHTML+Voice+SVG
content should use</tt></font>
<br><font size=2><tt>&gt;application/xhtml+xml, application/xhtml-voice+xml,
or some third type.</tt></font>
<br>
<br><font size=2><tt>XHTML+Voice adds voice as another mode of interaction
with the application,</tt></font>
<br><font size=2><tt>while SVG is in most cases an important informational
part of the</tt></font>
<br><font size=2><tt>application.</tt></font>
<br><font size=2><tt><br>
&gt;XHTML+SVG content, unless the SVG fragments are in the &lt;head&gt;
element<br>
&gt;and referenced via something like &lt;object data=&quot;#svg&quot;
/&gt;, would depend<br>
&gt;even more on inline-SVG support than XHTML+Voice on inline VoiceXML<br>
&gt;support, if we need to define a new media type for each combination
of<br>
&gt;XML formats, we'll quickly get a system where it simply does not matter<br>
&gt;whether one uses specialized types or just application/xml.</tt></font>
<br>
<br><font size=2><tt>This is one of the issues before the W3C CDF working
group.<br>
<br>
&gt;&gt;Are &quot;+suffix&quot; constructs the same as putting &quot;+&quot;
within the subtype? &nbsp;A<br>
&gt;&gt;mime type such as application/xhtml+voice+xml that maps directly
to<br>
&gt;&gt;XHTML+Voice is easy for authors to understand. &nbsp;I still see
the &quot;-&quot; as<br>
&gt;&gt;minus. &nbsp;What does application/xhtml-voice+xml mean but XHTML
minus voice.<br>
&gt;&gt;As you know, XHTML already doesn't have voice...<br>
<br>
&gt;And application/xml-dtd is for XML documents without DTD? Registered<br>
&gt;types with &quot;-&quot; typically use the &quot;-&quot; to separate
words. As you pointed<br>
&gt;out, there aren't really types for &quot;compound&quot; formats yet;
but it is<br>
&gt;also not clear to me whether we should have such types at all. If the<br>
&gt;CDF Working Group is really considering to have a single type for a<br>
&gt;very wide range of combinations, why can't you use that type instead?</tt></font>
<br>
<br><font size=2><tt>I'm talking about a perception that leads to a misunderstanding
that I</tt></font>
<br><font size=2><tt>have already received. &nbsp;I understand that application/xml-dtd
means</tt></font>
<br><font size=2><tt>&quot;xml dtd&quot; but &quot;application/xhtml-voice&quot;
means &quot;xhtml voice&quot; and the</tt></font>
<br><font size=2><tt>language is &quot;xhtml+voice&quot;.<br>
 </tt></font>
<br><font size=2><tt>We don't know today what the CDF working group will
decide and their</tt></font>
<br><font size=2><tt>decision is probably a few years away. &nbsp;In the
meantime, there are</tt></font>
<br><font size=2><tt>XHTML+Voice applications in operation today.</tt></font>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
Regards,<br>
Gerald McCobb<br>
IBM<br>
8051 Congress Avenue<br>
Boca Raton, FL 33487<br>
Tel. # 561-862-2109 T/L 975-2109<br>
</font>
<br>
--=_alternative 004C4B788525703F_=--

From: Bjoern Hoehrmann <[email-masked]>
To: Gerald McCobb <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Registration of media type application/xhtml-voice+xml
Date: Thu, 14 Jul 2005 20:51:12 +0200
Sender: [email-masked]

* Gerald McCobb wrote:
>However, as noted in the Internet-Draft, XHTML+Voice user agents have
>special processing requirements including support for XML Events and
>VoiceXML.  An initialized VoiceXML interpreter is a specific requirement.
>This mime type is limited to XHTML+Voice applications and I don't propose
>to change the limited designation in the internet draft.

Much of the existing application/xhtml+xml content relies on support of
a variety of features such as the Macromedia Flash format and scripting.
I think the litmus test here is simple: are user agents that do not
support XHTML+Voice but XHTML 1.0/1.1 required to reject application/
xhtml-voice+xml content as beeing in an unsupported format?

If yes, a new media type is certainly justified. If it is acceptable or
even encouraged to process the content by ignoring the unknown bits then
there does not seem to be considerable value in this new type. As you
pointed out, W3C might at some point produce a recommendation where you
can use XHTML with inline SVG content; with application/xhtml-voice+xml
it's not really clear whether XHTML+Voice+SVG content should use
application/xhtml+xml, application/xhtml-voice+xml, or some third type.

XHTML+SVG content, unless the SVG fragments are in the <head> element
and referenced via something like <object data="#svg" />, would depend
even more on inline-SVG support than XHTML+Voice on inline VoiceXML
support, if we need to define a new media type for each combination of
XML formats, we'll quickly get a system where it simply does not matter
whether one uses specialized types or just application/xml.

>Are "+suffix" constructs the same as putting "+" within the subtype?  A
>mime type such as application/xhtml+voice+xml that maps directly to
>XHTML+Voice is easy for authors to understand.  I still see the "-" as
>minus.  What does application/xhtml-voice+xml mean but XHTML minus voice.
>As you know, XHTML already doesn't have voice...

And application/xml-dtd is for XML documents without DTD? Registered
types with "-" typically use the "-" to separate words. As you pointed
out, there aren't really types for "compound" formats yet; but it is
also not clear to me whether we should have such types at all. If the
CDF Working Group is really considering to have a single type for a
very wide range of combinations, why can't you use that type instead?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Registration of media type application/xhtml-voice+xml
From: Gerald McCobb <[email-masked]>
Date: Thu, 14 Jul 2005 14:20:46 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 0064C4FC8525703E_=
Content-Type: text/plain; charset="US-ASCII"

Bjoern Hoehrmann wrote:

>* Gerald McCobb wrote:
>>1. In particular there is the work in the W3C Compound Document Format 
>>(CDF) working group.  They are looking at defining a single media type 
>>that will handle the many possible document format combinations of 
XHTML, 
>>SVG, Voice, SMIL, XForms, etc.  This media type may include multiple "+" 

>>put in a profile attribute.

>From http://w3.org/2004/CDF/admin/charter and http://w3.org/TR/CDRReqs/
>it rather seems they are currently working on the first draft on using
>XHTML 1.x where the user agent supports some version of SVG through the
>XHTML object element. The media type for XHTML 1.x is application/
>xhtml+xml, I seriously doubt they are going to propose new media types
>for something that had a media type for many years now and has in fact
>been implemented for quite some time. It would cause a lot of confusion
>for no good reason. 

>Other than that, it is quite obvious that use of media type parameters
>or deploying new media types for XML-over-HTTP content is difficult,
>to say the least. It's difficult to see how new types or type+parameter
>combinations might work with running code or which infrastructural
>changes are supposed to support this; or what we might gain from it.

>Clearly though, if the CDF Working Group is working on architectural
>solutions here they should publish their current thinking as Internet-
>Draft.

I'm not a member of the CDF Working group but I believe they plan to
do more than standardizing referencing SVG from the XHTML object tag.
>From http://w3.org/TR/CDRReqs/ there is also document compounding by
inclusion.  XHTML+Voice is an informative example.

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109

--=_alternative 0064C4FC8525703E_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2><tt>Bjoern Hoehrmann wrote:</tt></font>
<br>
<br><font size=2><tt>&gt;* Gerald McCobb wrote:<br>
&gt;&gt;1. In particular there is the work in the W3C Compound Document
Format <br>
&gt;&gt;(CDF) working group. &nbsp;They are looking at defining a single
media type <br>
&gt;&gt;that will handle the many possible document format combinations
of XHTML, <br>
&gt;&gt;SVG, Voice, SMIL, XForms, etc. &nbsp;This media type may include
multiple &quot;+&quot; <br>
&gt;&gt;put in a profile attribute.<br>
<br>
&gt;From http://w3.org/2004/CDF/admin/charter and http://w3.org/TR/CDRReqs/<br>
&gt;it rather seems they are currently working on the first draft on using<br>
&gt;XHTML 1.x where the user agent supports some version of SVG through
the<br>
&gt;XHTML object element. The media type for XHTML 1.x is application/<br>
&gt;xhtml+xml, I seriously doubt they are going to propose new media types<br>
&gt;for something that had a media type for many years now and has in fact<br>
&gt;been implemented for quite some time. It would cause a lot of confusion<br>
&gt;for no good reason. <br>
<br>
&gt;Other than that, it is quite obvious that use of media type parameters<br>
&gt;or deploying new media types for XML-over-HTTP content is difficult,<br>
&gt;to say the least. It's difficult to see how new types or type+parameter<br>
&gt;combinations might work with running code or which infrastructural<br>
&gt;changes are supposed to support this; or what we might gain from it.<br>
<br>
&gt;Clearly though, if the CDF Working Group is working on architectural<br>
&gt;solutions here they should publish their current thinking as Internet-<br>
&gt;Draft.</tt></font>
<br>
<br><font size=2><tt>I'm not a member of the CDF Working group but I believe
they plan to</tt></font>
<br><font size=2><tt>do more than standardizing referencing SVG from the
XHTML object tag.</tt></font>
<br><font size=2><tt>From http://w3.org/TR/CDRReqs/ there is also document
compounding by</tt></font>
<br><font size=2><tt>inclusion. &nbsp;XHTML+Voice is an informative example.</tt></font>
<br><font size=2 face="sans-serif"><br>
Regards,<br>
Gerald McCobb<br>
IBM<br>
8051 Congress Avenue<br>
Boca Raton, FL 33487<br>
Tel. # 561-862-2109 T/L 975-2109<br>
</font>
--=_alternative 0064C4FC8525703E_=--

To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Registration of media type application/xhtml-voice+xml
From: Gerald McCobb <[email-masked]>
Date: Thu, 14 Jul 2005 14:14:45 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 006437E28525703E_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

* Bjoern Hoehrmann wrote:

>* Gerald McCobb wrote:
>>I asked the IESG to postpone the publication of the=20
>>application/xhtml-voice+xml media type as an informational RFC.  The=20
>>registration is not correct.  It should be application/xhtml+voice+xml.=20
>>The application/xhtml+voice+xml media type was the original submission.

>As I pointed out earlier, I do not really see a good reason to add this
>http://eikenes.alvestrand.no/pipermail/ietf-types/2005-March/000662.html
>type. http://www.ietf.org/rfc/rfc3236.txt notes the possibility of using
>application/xhtml+xml for XHTML M12N-based formats.

>http://www.voicexml.org/specs/multimodal/x+v/12/ also takes steps to
>increase the likelyhood that XHTML+Voice documents degrade in down-level
>clients that just support application/xhtml+xml, so indeed, as noted in
>the Internet-Draft, the type would be of limited use.

I'm not sure what you mean by "degrade."  It is true that XHTML+Voice
follows the XHTML 1.1 modularization standard and the XML-Events,
VoiceXML, and X+V markup is isolated from the XHTML by their respective
namespaces.  An XHTML+Voice application running successfully as an
XHTML-only application has been thoroughly tested on MS Internet Explorer
and Mozilla Firefox browsers.

However, as noted in the Internet-Draft, XHTML+Voice user agents have
special processing requirements including support for XML Events and
VoiceXML.  An initialized VoiceXML interpreter is a specific requirement.
This mime type is limited to XHTML+Voice applications and I don't propose
to change the limited designation in the internet draft.

>http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt
>notes 'While it is possible for a given media type to be assigned
>additional names, the use of different names to identify the same media
>type is discouraged'.

This mime type is for user agents that support the specific processing
requirements of XHTML+Voice applications.

>>One of the reviewers pointed out that "a certain class of error could be =

>>avoided by renaming this application/xhtml-plus-voice+xml... I don't=20
know=20
>>of any other "+xml" [see RFC3023] media types that have a "+" in the=20
>>name... a poorly-constructed regexp looking for +xml along the lines of=20
>>/\+(.*)$/  would miss this one."

>http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt
>notes 'More generally, use of "+suffix" constructs should be done with
>care given the possibility of conflicts with future suffix definitions'.

Are "+suffix" constructs the same as putting "+" within the subtype?  A
mime type such as application/xhtml+voice+xml that maps directly to
XHTML+Voice is easy for authors to understand.  I still see the "-" as
minus.  What does application/xhtml-voice+xml mean but XHTML minus voice.
As you know, XHTML already doesn't have voice...

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109

Bjoern Hoehrmann <[email-masked]>
07/14/2005 10:21 AM
=20
        To:     Gerald McCobb/Boca Raton/IBM@IBMUS
        cc:     [email-masked], [email-masked]
        Subject:        Re: Registration of media type=20
application/xhtml-voice+xml

* Gerald McCobb wrote:
>I asked the IESG to postpone the publication of the=20
>application/xhtml-voice+xml media type as an informational RFC.  The=20
>registration is not correct.  It should be application/xhtml+voice+xml.=20
>The application/xhtml+voice+xml media type was the original submission.

As I pointed out earlier, I do not really see a good reason to add this
http://eikenes.alvestrand.no/pipermail/ietf-types/2005-March/000662.html
type. http://www.ietf.org/rfc/rfc3236.txt notes the possibility of using
application/xhtml+xml for XHTML M12N-based formats.

http://www.voicexml.org/specs/multimodal/x+v/12/ also takes steps to
increase the likelyhood that XHTML+Voice documents degrade in down-level
clients that just support application/xhtml+xml, so indeed, as noted in
the Internet-Draft, the type would be of limited use.

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt
notes 'While it is possible for a given media type to be assigned
additional names, the use of different names to identify the same media
type is discouraged'.

>One of the reviewers pointed out that "a certain class of error could be=20
>avoided by renaming this application/xhtml-plus-voice+xml... I don't know =

>of any other "+xml" [see RFC3023] media types that have a "+" in the=20
>name... a poorly-constructed regexp looking for +xml along the lines of=20
>/\+(.*)$/  would miss this one."

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt
notes 'More generally, use of "+suffix" constructs should be done with
care given the possibility of conflicts with future suffix definitions'.
--=20
Bj=F6rn H=F6hrmann =B7 mailto:[email-masked] =B7 http://bjoern.hoehrma=
nn.de
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld.de
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/=
=20

--=_alternative 006437E28525703E_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<br><font size=3D2><tt>* Bjoern Hoehrmann wrote:</tt></font>
<br>
<br><font size=3D2><tt>&gt;* Gerald McCobb wrote:<br>
&gt;&gt;I asked the IESG to postpone the publication of the <br>
&gt;&gt;application/xhtml-voice+xml media type as an informational RFC.
&nbsp;The <br>
&gt;&gt;registration is not correct. &nbsp;It should be application/xhtml+v=
oice+xml.
<br>
&gt;&gt;The application/xhtml+voice+xml media type was the original submiss=
ion.<br>
<br>
&gt;As I pointed out earlier, I do not really see a good reason to add
this<br>
&gt;http://eikenes.alvestrand.no/pipermail/ietf-types/2005-March/000662.htm=
l<br>
&gt;type. http://www.ietf.org/rfc/rfc3236.txt notes the possibility of
using<br>
&gt;application/xhtml+xml for XHTML M12N-based formats.<br>
<br>
&gt;http://www.voicexml.org/specs/multimodal/x+v/12/ also takes steps to<br>
&gt;increase the likelyhood that XHTML+Voice documents degrade in down-leve=
l<br>
&gt;clients that just support application/xhtml+xml, so indeed, as noted
in<br>
&gt;the Internet-Draft, the type would be of limited use.</tt></font>
<br>
<br><font size=3D2><tt>I'm not sure what you mean by &quot;degrade.&quot;
&nbsp;It is true that XHTML+Voice</tt></font>
<br><font size=3D2><tt>follows the XHTML 1.1 modularization standard and
the XML-Events,</tt></font>
<br><font size=3D2><tt>VoiceXML, and X+V markup is isolated from the XHTML
by their respective</tt></font>
<br><font size=3D2><tt>namespaces. &nbsp;An XHTML+Voice application running
successfully as an</tt></font>
<br><font size=3D2><tt>XHTML-only application has been thoroughly tested
on MS Internet Explorer</tt></font>
<br><font size=3D2><tt>and Mozilla Firefox browsers.</tt></font>
<br>
<br><font size=3D2><tt>However, as noted in the Internet-Draft, XHTML+Voice
user agents have</tt></font>
<br><font size=3D2><tt>special processing requirements including support
for XML Events and</tt></font>
<br><font size=3D2><tt>VoiceXML. &nbsp;An initialized VoiceXML interpreter
is a specific requirement.</tt></font>
<br><font size=3D2><tt>This mime type is limited to XHTML+Voice applications
and I don't propose</tt></font>
<br><font size=3D2><tt>to change the limited designation in the internet
draft.</tt></font>
<br><font size=3D2><tt><br>
&gt;http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt<b=
r>
&gt;notes 'While it is possible for a given media type to be assigned<br>
&gt;additional names, the use of different names to identify the same media=
<br>
&gt;type is discouraged'.</tt></font>
<br>
<br><font size=3D2><tt>This mime type is for user agents that support the
specific processing</tt></font>
<br><font size=3D2><tt>requirements of XHTML+Voice applications.<br>
<br>
&gt;&gt;One of the reviewers pointed out that &quot;a certain class of
error could be <br>
&gt;&gt;avoided by renaming this application/xhtml-plus-voice+xml... I
don't know <br>
&gt;&gt;of any other &quot;+xml&quot; [see RFC3023] media types that have
a &quot;+&quot; in the <br>
&gt;&gt;name... a poorly-constructed regexp looking for +xml along the
lines of <br>
&gt;&gt;/\+(.*)$/ &nbsp;would miss this one.&quot;<br>
<br>
&gt;http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt<b=
r>
&gt;notes 'More generally, use of &quot;+suffix&quot; constructs should
be done with<br>
&gt;care given the possibility of conflicts with future suffix definitions'=
.</tt></font>
<br>
<br><font size=3D2><tt>Are &quot;+suffix&quot; constructs the same as putti=
ng
&quot;+&quot; within the subtype? &nbsp;A</tt></font>
<br><font size=3D2><tt>mime type such as application/xhtml+voice+xml that
maps directly to</tt></font>
<br><font size=3D2><tt>XHTML+Voice is easy for authors to understand. &nbsp=
;I
still see the &quot;-&quot; as</tt></font>
<br><font size=3D2><tt>minus. &nbsp;What does application/xhtml-voice+xml
mean but XHTML minus voice.</tt></font>
<br><font size=3D2><tt>As you know, XHTML already doesn't have voice...</tt=
></font>
<br><font size=3D2 face=3D"sans-serif"><br>
Regards,<br>
Gerald McCobb<br>
IBM<br>
8051 Congress Avenue<br>
Boca Raton, FL 33487<br>
Tel. # 561-862-2109 T/L 975-2109<br>
</font>
<br>
<br>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td>
<td><font size=3D1 face=3D"sans-serif"><b>Bjoern Hoehrmann &lt;derhoermi@gm=
x.net&gt;</b></font>
<p><font size=3D1 face=3D"sans-serif">07/14/2005 10:21 AM</font>
<td><font size=3D1 face=3D"Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
&nbsp; &nbsp; &nbsp; &nbsp;Gerald McCobb/Boca Raton/IBM@IBMUS</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;[email-masked], [email-masked]</font>
<br><font size=3D1 face=3D"sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;Re: Registration of media type application/xhtml=
-voice+xml</font></table>
<br>
<br>
<br><font size=3D2><tt>* Gerald McCobb wrote:<br>
&gt;I asked the IESG to postpone the publication of the <br>
&gt;application/xhtml-voice+xml media type as an informational RFC. &nbsp;T=
he
<br>
&gt;registration is not correct. &nbsp;It should be application/xhtml+voice=
+xml.
<br>
&gt;The application/xhtml+voice+xml media type was the original submission.=
<br>
<br>
As I pointed out earlier, I do not really see a good reason to add this<br>
http://eikenes.alvestrand.no/pipermail/ietf-types/2005-March/000662.html<br>
type. http://www.ietf.org/rfc/rfc3236.txt notes the possibility of using<br>
application/xhtml+xml for XHTML M12N-based formats.<br>
<br>
http://www.voicexml.org/specs/multimodal/x+v/12/ also takes steps to<br>
increase the likelyhood that XHTML+Voice documents degrade in down-level<br>
clients that just support application/xhtml+xml, so indeed, as noted in<br>
the Internet-Draft, the type would be of limited use.<br>
<br>
http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt<br>
notes 'While it is possible for a given media type to be assigned<br>
additional names, the use of different names to identify the same media<br>
type is discouraged'.<br>
<br>
&gt;One of the reviewers pointed out that &quot;a certain class of error
could be <br>
&gt;avoided by renaming this application/xhtml-plus-voice+xml... I don't
know <br>
&gt;of any other &quot;+xml&quot; [see RFC3023] media types that have a
&quot;+&quot; in the <br>
&gt;name... a poorly-constructed regexp looking for +xml along the lines
of <br>
&gt;/\+(.*)$/ &nbsp;would miss this one.&quot;<br>
<br>
http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt<br>
notes 'More generally, use of &quot;+suffix&quot; constructs should be
done with<br>
care given the possibility of conflicts with future suffix definitions'.<br>
-- <br>
Bj=F6rn H=F6hrmann =B7 mailto:[email-masked] =B7 http://bjoern.hoehrma=
nn.de<br>
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld.d=
e<br>
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/
<br>
</tt></font>
<br>
--=_alternative 006437E28525703E_=--

From: Bjoern Hoehrmann <[email-masked]>
To: Gerald McCobb <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Registration of media type application/xhtml-voice+xml
Date: Thu, 14 Jul 2005 17:28:05 +0200
Sender: [email-masked]

* Gerald McCobb wrote:
>1. In particular there is the work in the W3C Compound Document Format 
>(CDF) working group.  They are looking at defining a single media type 
>that will handle the many possible document format combinations of XHTML, 
>SVG, Voice, SMIL, XForms, etc.  This media type may include multiple "+" 
>put in a profile attribute.

>From http://w3.org/2004/CDF/admin/charter and http://w3.org/TR/CDRReqs/
it rather seems they are currently working on the first draft on using
XHTML 1.x where the user agent supports some version of SVG through the
XHTML object element. The media type for XHTML 1.x is application/
xhtml+xml, I seriously doubt they are going to propose new media types
for something that had a media type for many years now and has in fact
been implemented for quite some time. It would cause a lot of confusion
for no good reason. 

Other than that, it is quite obvious that use of media type parameters
or deploying new media types for XML-over-HTTP content is difficult,
to say the least. It's difficult to see how new types or type+parameter
combinations might work with running code or which infrastructural
changes are supposed to support this; or what we might gain from it.

Clearly though, if the CDF Working Group is working on architectural
solutions here they should publish their current thinking as Internet-
Draft.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From: Bjoern Hoehrmann <[email-masked]>
To: Gerald McCobb <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Registration of media type application/xhtml-voice+xml
Date: Thu, 14 Jul 2005 16:21:05 +0200
Sender: [email-masked]

* Gerald McCobb wrote:
>I asked the IESG to postpone the publication of the 
>application/xhtml-voice+xml media type as an informational RFC.  The 
>registration is not correct.  It should be application/xhtml+voice+xml. 
>The application/xhtml+voice+xml media type was the original submission.

As I pointed out earlier, I do not really see a good reason to add this
http://eikenes.alvestrand.no/pipermail/ietf-types/2005-March/000662.html
type. http://www.ietf.org/rfc/rfc3236.txt notes the possibility of using
application/xhtml+xml for XHTML M12N-based formats.

http://www.voicexml.org/specs/multimodal/x+v/12/ also takes steps to
increase the likelyhood that XHTML+Voice documents degrade in down-level
clients that just support application/xhtml+xml, so indeed, as noted in
the Internet-Draft, the type would be of limited use.

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt
notes 'While it is possible for a given media type to be assigned
additional names, the use of different names to identify the same media
type is discouraged'.

>One of the reviewers pointed out that "a certain class of error could be 
>avoided by renaming this application/xhtml-plus-voice+xml... I don't know 
>of any other "+xml" [see RFC3023] media types that have a "+" in the 
>name... a poorly-constructed regexp looking for +xml along the lines of 
>/\+(.*)$/  would miss this one."

http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt
notes 'More generally, use of "+suffix" constructs should be done with
care given the possibility of conflicts with future suffix definitions'.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Thu, 14 Jul 2005 12:31:10 +0200
From: "Jonny Axelsson" <[email-masked]>
To: "Martin Duerst" <[email-masked]>, "Gerald McCobb" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Registration of media type application/xhtml-voice+xml
Cc: "[email-masked]" <[email-masked]>
Organization: Opera Software ASA
Sender: [email-masked]

On Thu, 14 Jul 2005 08:49:12 +0200, Martin Duerst <[email-masked]>  
wrote:

> I agree with that reviewer that the type should not contain
> '+' characters except before 'xml'. All other subtypes have used '-'
> as a separator. The '+' separator was specifically introduced to
> express the fact that the '+xml' part is something more than
> a simple subtype.

They have used it for a entirely different purpose, as a space (word)  
substitution. Examples are application/java-byte-code (Java byte code),  
octet-stream (octet stream), ringing-tones (ringing tones),  
x-nokia-9000-communicator-add-on-software (Nokia 9000 Communicator add-on  
software).

XHTML+Voice is not "XHTML Voice". Turning the content type for XHTML+Voice  
into xhtml-voice is bound to cause endless confusion. "Remember that in  
the MIME type the plus turns into a minus" is exactly that kind of rule  
that cause authors to be frustrated with Internet standards.

> Although there is probably nothing in RFC 3023 explicitly
> disallowing the use of '+' for "arbitrary use", I think that
> the whole rationale for '+xml' in Appendix A of RFC 3023
> (in particular http://www.ietf.org/rfc/rfc3023.txt, A.12)
> seem to indicate that it shouldn't be done.

What they did was to examine if their use of '+' caused problems with the  
existing specs or implementations. In particular they discounted use of  
parameters though even they were a function of the spec, the existing  
implementations didn't handle them properly.

This examination is something we should do too. If xhtml+voice+xml breaks  
existing implementations (it doesn't break existing specs, including  
RFC3023) we shouldn't do it.

But this content type has had considerable exposure for several years in  
its x-xhtml+voice+xml form and we have not encountered a single problem  
this far. I am not claiming we have exposed it to more than a fraction of  
the complete net. But consider that no processor should automatically  
apply XML processing to subtypes like e.g.

ccxml
xmlcc
xml+zz
z+xml+z
z+xmlz
z-xml

where (+)xml is in the middle of the string and not at the end, it follows  
that any algorithm that breaks on xhtml+voice+xml is bound to break on  
other cases too.

Furthermore what would this hypothetical break imply? Unlike parameters  
(in the spec, poor implemetation record) all processors can handle media  
types that contain one or more '+' (RFC 3023 is dependent on this too).

A failure would either be a false positive ("it has a '+' so it must be  
XML") or a false negative ("the character following '+' is not 'x'"). A  
false positive cause no harm (this format is XML), a false negative would  
lead to processing of application/octet-stream which in practice is  
something the agent is highly likely to handle rationally too.

-- 
Jonny Axelsson, Core Technology, Opera Software ASA

Date: Thu, 14 Jul 2005 15:49:12 +0900
To: Gerald McCobb <[email-masked]>, [email-masked], [email-masked]
From: Martin Duerst <[email-masked]>
Subject: Re: Registration of media type application/xhtml-voice+xml
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 01:33 05/07/14, Gerald McCobb wrote:

>I asked the IESG to postpone the publication of the 
>application/xhtml-voice+xml media type as an informational RFC.  The 
>registration is not correct.  It should be application/xhtml+voice+xml. 
>The application/xhtml+voice+xml media type was the original submission.
>
>There is an issue with the original submission:
>
>One of the reviewers pointed out that "a certain class of error could be 
>avoided by renaming this application/xhtml-plus-voice+xml... I don't know 
>of any other "+xml" [see RFC3023] media types that have a "+" in the 
>name... a poorly-constructed regexp looking for +xml along the lines of 
>/\+(.*)$/  would miss this one."

I agree with that reviewer that the type should not contain
'+' characters except before 'xml'. All other subtypes have used '-'
as a separator. The '+' separator was specifically introduced to
express the fact that the '+xml' part is something more than
a simple subtype.

Although there is probably nothing in RFC 3023 explicitly
disallowing the use of '+' for "arbitrary use", I think that
the whole rationale for '+xml' in Appendix A of RFC 3023
(in particular http://www.ietf.org/rfc/rfc3023.txt, A.12)
seem to indicate that it shouldn't be done.

>I believe this argument is not strong enough to prevent approval of the 
>application/xhtml+voice+xml media type:

>2. The argument for having "+" in the subtype is unconvincing, given that 
>the simplest method to determine if something is XML is also the safest, 
>that is, if the last four characters are "+xml" or "/xml" then the 
>document is XML, otherwise it is not. If that has to be done with regexps, 
>instead of just examining the last four bytes, that would be /[/+]xml$/. 
>If type and subtype were split already it would be /\+?xml$/ for the subtype.

I think the regexp example is only the tip of the iceberg. Not using
the plus will allow better future extensibility.

Regards,    Martin. 

To: Chris Lilley <[email-masked]>
Cc: [email-masked], [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: Registration of media type application/xhtml-voice+xml
From: Gerald McCobb <[email-masked]>
Date: Wed, 13 Jul 2005 18:06:17 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 00796AE38525703D_=
Content-Type: text/plain; charset="US-ASCII"

Chris Lilly wrote:

CL> GM> I asked the IESG to postpone the publication of the
GM> application/xhtml-voice+xml media type as an informational RFC.  The
CL> GM> registration is not correct.  It should be
GM> application/xhtml+voice+xml.  The application/xhtml+voice+xml media
CL> GM> type was the original submission.

CL> The entire reason that the +xml suffix was changed from the original
CL> -xml suffix was beczause there were a number of hyphenated types in
CL> use but little/no types where the terms were separated by +.

The application/xhtml+voice+xml media was chosen because it directly
maps to "XHTML+Voice", the name of the language, and is thus an easy
mnemonic help for authors - whereas I might imagine people getting
confused by XHTML+Voice using the application/xhtml-voice+xml or 
application/xhtml-plus-voice+xml type.

CL> GM> There is an issue with the original submission: 
 
CL> GM> One of the reviewers pointed out that "a certain class of error
CL> GM> could be avoided by renaming this
CL> GM> application/xhtml-plus-voice+xml... I don't know of any other
CL> GM> "+xml" [see RFC3023] media types that have a "+" in the name...
CL> GM> a poorly-constructed regexp looking for +xml along the lines of
CL> GM> /\+(.*)$/  would miss this one."

CL> I agree that so far there are no types with a + in the name, and
CL> that using some other allowed separator would be preferable.

As far as I know, XHTML+Voice is the first example of a compound document
format requesting registration of a media type.  There has not been
a reason before to have a type with a "+" in the name.  The fact that
"+" has not been used before is not a reason to exclude using it for the
first time.

CL> GM> 1. In particular there is the work in the W3C Compound Document
CL> GM> Format (CDF) working group.  They are looking at defining a
CL> GM> single media type that will handle the many possible document
CL> GM> format combinations of XHTML, SVG, Voice, SMIL, XForms, etc.
CL> GM> This media type may include multiple "+" put in a profile
CL> GM> attribute.

CL> Probably not (I for one would argue against it, being a member of
CL> that group). But 'may include' is pretty weak.

Regardless of what the CDF working group will eventually decide this
XHTML+Voice media type registration could set a precedent for all
formats that add language subsets to container languages (such as XHTML).
I'm not comfortable with setting a precedent for "xhtml-plus-svg-plus-
smil-plus-xforms", for example.

CL> GM> 2. The argument for having "+" in the subtype is unconvincing,
CL> GM> given that the simplest method to determine if something is XML
CL> GM> is also the safest, that is, if the last four characters are
CL> GM> "+xml" or "/xml" then the document is XML, otherwise it is not.
CL> GM> If that has to be done with regexps, instead of just examining
CL> GM> the last four bytes, that would be /[/+]xml$/.  If type and
CL> GM> subtype were split already it would be /\+?xml$/ for the
CL> GM> subtype.

CL> True.

Then we agreed that "poorly written regexps" is not a good reason for
excluding use of "+" in the type?

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109

--=_alternative 00796AE38525703D_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">Chris Lilly wrote:</font>
<br>
<br><font size=2><tt>CL&gt; GM&gt; I asked the IESG to postpone the publication
of the<br>
GM&gt; application/xhtml-voice+xml media type as an informational RFC.
&nbsp;The<br>
CL&gt; GM&gt; registration is not correct. &nbsp;It should be<br>
GM&gt; application/xhtml+voice+xml. &nbsp;The application/xhtml+voice+xml
media<br>
CL&gt; GM&gt; type was the original submission.<br>
<br>
CL&gt; The entire reason that the +xml suffix was changed from the original<br>
CL&gt; -xml suffix was beczause there were a number of hyphenated types
in<br>
CL&gt; use but little/no types where the terms were separated by +.</tt></font>
<br>
<br><font size=2><tt>The application/xhtml+voice+xml media was chosen because
it directly</tt></font>
<br><font size=2><tt>maps to &quot;XHTML+Voice&quot;, the name of the language,
and is thus an easy</tt></font>
<br><font size=2><tt>mnemonic help for authors - whereas I might imagine
people getting</tt></font>
<br><font size=2><tt>confused by XHTML+Voice using the application/xhtml-voice+xml
or </tt></font>
<br><font size=2><tt>application/xhtml-plus-voice+xml type.<br>
<br>
CL&gt; GM&gt; There is an issue with the original submission: <br>
 <br>
CL&gt; GM&gt; One of the reviewers pointed out that &quot;a certain class
of error<br>
CL&gt; GM&gt; could be avoided by renaming this<br>
CL&gt; GM&gt; application/xhtml-plus-voice+xml... I don't know of any other<br>
CL&gt; GM&gt; &quot;+xml&quot; [see RFC3023] media types that have a &quot;+&quot;
in the name...<br>
CL&gt; GM&gt; a poorly-constructed regexp looking for +xml along the lines
of<br>
CL&gt; GM&gt; /\+(.*)$/ &nbsp;would miss this one.&quot;<br>
<br>
CL&gt; I agree that so far there are no types with a + in the name, and<br>
CL&gt; that using some other allowed separator would be preferable.</tt></font>
<br>
<br><font size=2><tt>As far as I know, XHTML+Voice is the first example
of a compound document</tt></font>
<br><font size=2><tt>format requesting registration of a media type. &nbsp;There
has not been</tt></font>
<br><font size=2><tt>a reason before to have a type with a &quot;+&quot;
in the name. &nbsp;The fact that</tt></font>
<br><font size=2><tt>&quot;+&quot; has not been used before is not a reason
to exclude using it for the</tt></font>
<br><font size=2><tt>first time.</tt></font>
<br><font size=2><tt><br>
CL&gt; GM&gt; 1. In particular there is the work in the W3C Compound Document<br>
CL&gt; GM&gt; Format (CDF) working group. &nbsp;They are looking at defining
a<br>
CL&gt; GM&gt; single media type that will handle the many possible document<br>
CL&gt; GM&gt; format combinations of XHTML, SVG, Voice, SMIL, XForms, etc.<br>
CL&gt; GM&gt; This media type may include multiple &quot;+&quot; put in
a profile</tt></font>
<br><font size=2><tt>CL&gt; GM&gt; attribute.<br>
<br>
CL&gt; Probably not (I for one would argue against it, being a member of<br>
CL&gt; that group). But 'may include' is pretty weak.</tt></font>
<br>
<br><font size=2><tt>Regardless of what the CDF working group will eventually
decide this</tt></font>
<br><font size=2><tt>XHTML+Voice media type registration could set a precedent
for all</tt></font>
<br><font size=2><tt>formats that add language subsets to container languages
(such as XHTML).</tt></font>
<br><font size=2><tt>I'm not comfortable with setting a precedent for &quot;xhtml-plus-svg-plus-</tt></font>
<br><font size=2><tt>smil-plus-xforms&quot;, for example.</tt></font>
<br><font size=2><tt><br>
CL&gt; GM&gt; 2. The argument for having &quot;+&quot; in the subtype is
unconvincing,<br>
CL&gt; GM&gt; given that the simplest method to determine if something
is XML<br>
CL&gt; GM&gt; is also the safest, that is, if the last four characters
are<br>
CL&gt; GM&gt; &quot;+xml&quot; or &quot;/xml&quot; then the document is
XML, otherwise it is not.</tt></font>
<br><font size=2><tt>CL&gt; GM&gt; If that has to be done with regexps,
instead of just examining</tt></font>
<br><font size=2><tt>CL&gt; GM&gt; the last four bytes, that would be /[/+]xml$/.
&nbsp;If type and</tt></font>
<br><font size=2><tt>CL&gt; GM&gt; subtype were split already it would
be /\+?xml$/ for the<br>
CL&gt; GM&gt; subtype.</tt></font>
<br><font size=2><tt><br>
CL&gt; True.</tt></font>
<br>
<br><font size=2><tt>Then we agreed that &quot;poorly written regexps&quot;
is not a good reason for</tt></font>
<br><font size=2><tt>excluding use of &quot;+&quot; in the type?</tt></font>
<br><font size=2 face="sans-serif"><br>
Regards,<br>
Gerald McCobb<br>
IBM<br>
8051 Congress Avenue<br>
Boca Raton, FL 33487<br>
Tel. # 561-862-2109 T/L 975-2109<br>
</font>
<br>
--=_alternative 00796AE38525703D_=--

Date: Wed, 13 Jul 2005 18:59:33 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Gerald McCobb <[email-masked]>
Cc: [email-masked], [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: Registration of media type application/xhtml-voice+xml
Sender: [email-masked]

On Wednesday, July 13, 2005, 6:33:04 PM, Gerald wrote:

GM> I asked the IESG to postpone the publication of the
GM> application/xhtml-voice+xml media type as an informational RFC.  The
GM> registration is not correct.  It should be
GM> application/xhtml+voice+xml.  The application/xhtml+voice+xml media
GM> type was the original submission.

The entire reason that the +xml suffix was changed from the original
-xml suffix was beczause there were a number of hyphenated types in use
but little/no types where the terms were separated by +.

GM> There is an issue with the original submission: 
 
GM> One of the reviewers pointed out that "a certain class of error
GM> could be avoided by renaming this
GM> application/xhtml-plus-voice+xml... I don't know of any other "+xml"
GM> [see RFC3023] media types that have a "+" in the name... a
GM> poorly-constructed regexp looking for +xml along the lines of
GM> /\+(.*)$/  would miss this one."

I agree that so far there are no types with a + in the name, and that
using some other allowed separator would be preferable.
 
GM> 1. In particular there is the work in the W3C Compound Document
GM> Format (CDF) working group.  They are looking at defining a single
GM> media type that will handle the many possible document format
GM> combinations of XHTML, SVG, Voice, SMIL, XForms, etc.  This media
GM> type may include multiple "+" put in a profile attribute.

Probably not (I for one would argue against it, being a member of that
group). But 'may include' is pretty weak.
 
GM> 2. The argument for having "+" in the subtype is unconvincing,
GM> given that the simplest method to determine if something is XML is
GM> also the safest, that is, if the last four characters are "+xml" or
GM> "/xml" then the document is XML, otherwise it is not. If that has to
GM> be done with regexps, instead of just examining the last four bytes,
GM> that would be /[/+]xml$/.  If type and subtype were split already it
GM> would be /\+?xml$/ for the subtype.

True.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead

Date: Wed, 13 Jul 2005 12:49:51 -0400
From: Mark Baker <[email-masked]>
To: Gerald McCobb <[email-masked]>
Cc: [email-masked], [email-masked], "[email-masked]" <[email-masked]>
Subject: Re: Registration of media type application/xhtml-voice+xml
Sender: [email-masked]

On Wed, Jul 13, 2005 at 12:33:04PM -0400, Gerald McCobb wrote:
> 1. In particular there is the work in the W3C Compound Document Format 
> (CDF) working group.  They are looking at defining a single media type 
> that will handle the many possible document format combinations of XHTML, 
> SVG, Voice, SMIL, XForms, etc.  This media type may include multiple "+" 
> put in a profile attribute.

As a member of that WG, I can state (though not speaking for it) that
I've not seen this proposed, though it's possible it was mentioned in
passing.  You might be interested to know that of all the possible media
type names that have been suggested, all use "-" instead of "+" in the
subtype name preceding the "+xml" suffix.

Cheers,

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com

To: [email-masked], [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Registration of media type application/xhtml-voice+xml
From: Gerald McCobb <[email-masked]>
Date: Wed, 13 Jul 2005 12:33:04 -0400
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 005AE9588525703D_=
Content-Type: text/plain; charset="US-ASCII"

I asked the IESG to postpone the publication of the 
application/xhtml-voice+xml media type as an informational RFC.  The 
registration is not correct.  It should be application/xhtml+voice+xml. 
The application/xhtml+voice+xml media type was the original submission.

There is an issue with the original submission:

One of the reviewers pointed out that "a certain class of error could be 
avoided by renaming this application/xhtml-plus-voice+xml... I don't know 
of any other "+xml" [see RFC3023] media types that have a "+" in the 
name... a poorly-constructed regexp looking for +xml along the lines of 
/\+(.*)$/  would miss this one."

I believe this argument is not strong enough to prevent approval of the 
application/xhtml+voice+xml media type:

1. In particular there is the work in the W3C Compound Document Format 
(CDF) working group.  They are looking at defining a single media type 
that will handle the many possible document format combinations of XHTML, 
SVG, Voice, SMIL, XForms, etc.  This media type may include multiple "+" 
put in a profile attribute.

2. The argument for having "+" in the subtype is unconvincing, given that 
the simplest method to determine if something is XML is also the safest, 
that is, if the last four characters are "+xml" or "/xml" then the 
document is XML, otherwise it is not. If that has to be done with regexps, 
instead of just examining the last four bytes, that would be /[/+]xml$/. 
If type and subtype were split already it would be /\+?xml$/ for the 
subtype.

Regards,
Gerald McCobb
IBM
8051 Congress Avenue
Boca Raton, FL 33487
Tel. # 561-862-2109 T/L 975-2109

"Scott Hollenbeck" <[email-masked]>
07/12/2005 06:09 PM
 
        To:     <[email-masked]>
        cc:     <[email-masked]>, Gerald McCobb/Boca Raton/IBM@IBMUS
        Subject:        RE: application/xhtml-voice+xml vs. 
application/xhtml-vocie+xml

That registration was just added.  The author has been asked to review it
and confirm correctness.  He hasn't replied yet.  I've cc'd him here to 
let
him know about the issue.

-Scott-

> -----Original Message-----
> From: Bruce Lilly [mailto:[email-masked]] 
> Sent: Tuesday, July 12, 2005 4:08 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: application/xhtml-voice+xml vs. application/xhtml-vocie+xml
> 
> draft-mccobb-xplusv-media-type-04 provides a registration 
> template for type application/xhtml-voice+xml.  The IANA 
> registry now has an entry for application/xhtml-vocie+xml (i 
> and c transposed in voice).
> 
> Can this be fixed, please.  Hopefully, nobody else has 
> noticed the ...vocie... type and it can be safely elided...
> 

--=_alternative 005AE9588525703D_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">I asked the IESG to postpone the publication
of the application/xhtml-voice+xml media type as an informational RFC.
&nbsp;The registration is not correct. &nbsp;It should be application/xhtml+voice+xml.
&nbsp;The application/xhtml+voice+xml media type was the original submission.</font>
<br>
<br><font size=2 face="sans-serif">There is an issue with the original
submission:</font>
<br>
<br><font size=2 face="sans-serif">One of the reviewers pointed out that
&quot;a certain class of error could be avoided by renaming this application/xhtml-plus-voice+xml...
I don't know of any other &quot;+xml&quot; [see RFC3023] media types that
have a &quot;+&quot; in the name... a poorly-constructed regexp looking
for +xml along the lines of /\+(.*)$/ &nbsp;would miss this one.&quot;</font>
<br>
<br><font size=2 face="sans-serif">I believe this argument is not strong
enough to prevent approval of the application/xhtml+voice+xml media type:</font>
<br>
<br><font size=2 face="sans-serif">1. In particular there is the work in
the W3C Compound Document Format (CDF) working group. &nbsp;They are looking
at defining a single media type that will handle the many possible document
format combinations of XHTML, SVG, Voice, SMIL, XForms, etc. &nbsp;This
media type may include multiple &quot;+&quot; put in a profile attribute.</font>
<br>
<br><font size=2 face="sans-serif">2. The argument for having &quot;+&quot;
in the subtype is unconvincing, given that the simplest method to determine
if something is XML is also the safest, that is, if the last four characters
are &quot;+xml&quot; or &quot;/xml&quot; then the document is XML, otherwise
it is not. If that has to be done with regexps, instead of just examining
the last four bytes, that would be /[/+]xml$/. &nbsp;If type and subtype
were split already it would be /\+?xml$/ for the subtype.</font>
<br><font size=2 face="sans-serif"><br>
Regards,<br>
Gerald McCobb<br>
IBM<br>
8051 Congress Avenue<br>
Boca Raton, FL 33487<br>
Tel. # 561-862-2109 T/L 975-2109<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Scott Hollenbeck&quot; &lt;[email-masked]&gt;</b></font>
<p><font size=1 face="sans-serif">07/12/2005 06:09 PM</font>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To:
&nbsp; &nbsp; &nbsp; &nbsp;&lt;[email-masked]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc:
&nbsp; &nbsp; &nbsp; &nbsp;&lt;[email-masked]&gt;, Gerald McCobb/Boca
Raton/IBM@IBMUS</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject:
&nbsp; &nbsp; &nbsp; &nbsp;RE: application/xhtml-voice+xml vs.
application/xhtml-vocie+xml</font></table>
<br>
<br>
<br><font size=2><tt>That registration was just added. &nbsp;The author
has been asked to review it<br>
and confirm correctness. &nbsp;He hasn't replied yet. &nbsp;I've cc'd him
here to let<br>
him know about the issue.<br>
<br>
-Scott-<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: Bruce Lilly [mailto:[email-masked]] <br>
&gt; Sent: Tuesday, July 12, 2005 4:08 PM<br>
&gt; To: [email-masked]<br>
&gt; Cc: [email-masked]<br>
&gt; Subject: application/xhtml-voice+xml vs. application/xhtml-vocie+xml<br>
&gt; <br>
&gt; draft-mccobb-xplusv-media-type-04 provides a registration <br>
&gt; template for type application/xhtml-voice+xml. &nbsp;The IANA <br>
&gt; registry now has an entry for application/xhtml-vocie+xml (i <br>
&gt; and c transposed in voice).<br>
&gt; <br>
&gt; Can this be fixed, please. &nbsp;Hopefully, nobody else has <br>
&gt; noticed the ...vocie... type and it can be safely elided...<br>
&gt; <br>
<br>
</tt></font>
<br>
--=_alternative 005AE9588525703D_=--

Date: Mon, 11 Jul 2005 11:17:24 -0400
From: Liam Quin <[email-masked]>
To: John Cowan <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: W3C Last Call and Media Type request for comments: XQuery and XQueryX
Sender: [email-masked]

On Thu, May 19, 2005 at 01:45:35PM -0400, John Cowan wrote:
> Liam Quin scripsit:
>>  Interchange of a database query language over the Web in its own
>>  Internet Type is likely for machine execution or to interchange
>>  files, not for reading by humans, as then text/plain might be
>>  more appropriate... but this is conjecture on my part right now.
> 
> FWIW, I think this is a Bad Thing.  Programming language content should
> go in text/plain files (despite the nasty problem with the encoding
> type imposed by text/*), so as to *discourage* browsers from attempting
> to execute them, which is a big fat security hole.

Execution of a query in this context could better be written as
evaluation of an expression; the side-effects in XQuery are very
limited, although I agree that whenever code is executed remotely
there are some serious security concerns.

> The use of text/css in HTML link elements and XML stylesheet PIs is
> essentially a hack so that browsers can decide whether to fetch the
> stylesheet, and is not consistent with the intention of IETF media
> types, which are designed to specify a minimal mapping from raw
> octets to interpretable objects such as characters or pixels.

I think this is a different case -- tect/css is a subsidiary document,
and the "type=" pseudo-attribute in a processing instruction is only
(I believe) there because the work predated widespread adoption of
XML namespaces.

Here, the XML Query document is likely to be the primary object
of transfer, not a subsidiary that applies to something else.

> Unless it was by accident that I had            John Cowan
> offended someone, I never apologized.           [email-masked]
>         --Quentin Crisp                         http://www.ccil.org/~cowan

Oh to be on the same page as Quentin Crisp, there can be
no higher honour!

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

Date: Mon, 11 Jul 2005 10:47:05 -0400
From: Liam Quin <[email-masked]>
To: MURATA Makoto <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: W3C Last Call and Media Type request for comments: XQuery and XQueryX
Sender: [email-masked]

On Thu, May 19, 2005 at 11:56:03PM +0900, MURATA Makoto wrote:
> > Please note that this is for application/xquery -- a non-XML format.
> > For application/xqueryx+xml I'll send separate mail.
> 
> I will then wait for your next mail for application/xqueryx+xml.

I just realised, in reviewing the document, that I answered you
in a way that was misleading -- sorry!

I sent two applications (application/xquery and application/xquery+xml)
in the same message.  We are dropping the optional charset parameter
for application/xquery, but for application/xquery+xml we are of
course bound by the existing rules for XML media types.

Here is the relevant extract from the text:

    MIME media type name: application
    MIME subtype name: xquery+xml
    Required parameters: none
    Optional parameters: charset

    This parameter has identical semantics to the charset parameter of
    the application/xml media type as specified in [RFC3023].

Possibly we should instead say

    Required parameters: see RFC 3023 or successor

    Optional parameters: see RFC 3023 or successor

so that when RFC 3023 is updated, we don't need to change
this document, if definitions of parameters change.

What do you think?

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/