Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KDRwtI068340; Wed, 20 Jul 2005 06:27:58 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6KDRwRj068339; Wed, 20 Jul 2005 06:27:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from ns1.townisp.com (ns1a.townisp.com [216.195.0.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6KDRumt068321 for ; Wed, 20 Jul 2005 06:27:57 -0700 (PDT) (envelope-from blilly@erols.com) Received: from mail.blilly.com (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.49.158.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marty.blilly.com", Issuer "Bruce Lilly" (not verified)) by ns1.townisp.com (Postfix) with ESMTP id 0FFF5299BA; Wed, 20 Jul 2005 09:27:55 -0400 (EDT) Received: from marty.blilly.com (marty.blilly.com [192.168.99.98] (may be forged)) by mail.blilly.com with ESMTP id j6KDRr07001114(8.13.1/8.13.1/mail.blilly.com /etc/sendmail.mc.mail 1.26 2005/06/24 20:47:59) (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) ; Wed, 20 Jul 2005 09:27:53 -0400 Received: from marty.blilly.com (localhost [127.0.0.1]) (authenticated (0 bits)) by marty.blilly.com with ESMTP id j6KDRqi9001113(8.13.1/8.13.1/blilly.com submit.mc 1.3 2005/04/08 12:29:31) (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 20 Jul 2005 09:27:53 -0400 From: Bruce Lilly Reply-To: ietf-types@alvestrand.no Organization: Bruce Lilly To: ietf-types@alvestrand.no Subject: Re: Registration of media type application/xhtml-voice+xml Date: Wed, 20 Jul 2005 09:27:49 -0400 User-Agent: KMail/1.8.1 Cc: Martin Duerst , "ietf-xml-mime@imc.org" References: <20050712220929.GWHV23513.lakermmtao04.cox.net@A31P> <6.0.0.20.2.20050714153404.08e76ec0@itmail.it.aoyama.ac.jp> In-Reply-To: <6.0.0.20.2.20050714153404.08e76ec0@itmail.it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507200927.50460@mail.blilly.com> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [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". Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FDrblo058302; Fri, 15 Jul 2005 06:53:37 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6FDrbsB058301; Fri, 15 Jul 2005 06:53:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6FDrZ2K058290 for ; Fri, 15 Jul 2005 06:53:35 -0700 (PDT) (envelope-from mccobb@us.ibm.com) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j6FDrTRu503292 for ; Fri, 15 Jul 2005 09:53:29 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6FDrTVM433472 for ; Fri, 15 Jul 2005 07:53:29 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6FDrSuX023091 for ; Fri, 15 Jul 2005 07:53:29 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j6FDrS4e023085; Fri, 15 Jul 2005 07:53:28 -0600 In-Reply-To: <42eeadbd.276864609@smtp.bjoern.hoehrmann.de> To: Bjoern Hoehrmann Cc: ietf-types@iana.org, ietf-xml-mime@imc.org MIME-Version: 1.0 Subject: Re: Registration of media type application/xhtml-voice+xml X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Gerald McCobb Date: Fri, 15 Jul 2005 09:53:26 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 07/15/2005 07:53:27, Serialize complete at 07/15/2005 07:53:27 Content-Type: multipart/alternative; boundary="=_alternative 004C4B788525703F_=" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 element >and referenced via something like , 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"
* 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_=-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EIpN9W067428; Thu, 14 Jul 2005 11:51:23 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6EIpMM8067427; Thu, 14 Jul 2005 11:51:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6EIpLsV067413 for ; Thu, 14 Jul 2005 11:51:22 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 14 Jul 2005 18:51:15 -0000 Received: from dsl-084-056-238-087.arcor-ip.net (EHLO localhost) [84.56.238.87] by mail.gmx.net (mp008) with SMTP; 14 Jul 2005 20:51:15 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Gerald McCobb Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: Registration of media type application/xhtml-voice+xml Date: Thu, 14 Jul 2005 20:51:12 +0200 Message-ID: <42eeadbd.276864609@smtp.bjoern.hoehrmann.de> References: <42e66b43.259846015@smtp.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * 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 element and referenced via something like , 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:bjoern@hoehrmann.de · 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/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EIL178063433; Thu, 14 Jul 2005 11:21:01 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6EIL1w0063432; Thu, 14 Jul 2005 11:21:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EIL0vf063415 for ; Thu, 14 Jul 2005 11:21:00 -0700 (PDT) (envelope-from mccobb@us.ibm.com) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j6EIKqfj054284 for ; Thu, 14 Jul 2005 14:20:52 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6EIKqQD254210 for ; Thu, 14 Jul 2005 12:20:52 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6EIKp3o026030 for ; Thu, 14 Jul 2005 12:20:52 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j6EIKpVN026024; Thu, 14 Jul 2005 12:20:51 -0600 In-Reply-To: <42e774ef.262322656@smtp.bjoern.hoehrmann.de> To: Bjoern Hoehrmann Cc: ietf-types@alvestrand.no, ietf-xml-mime@imc.org, public-cdf@w3.org MIME-Version: 1.0 Subject: Re: Registration of media type application/xhtml-voice+xml X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Gerald McCobb Date: Thu, 14 Jul 2005 14:20:46 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 07/14/2005 12:20:51, Serialize complete at 07/14/2005 12:20:51 Content-Type: multipart/alternative; boundary="=_alternative 0064C4FC8525703E_=" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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"
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_=-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EIF5SM063009; Thu, 14 Jul 2005 11:15:05 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6EIF5Rr063008; Thu, 14 Jul 2005 11:15:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EIF3Z7062988 for ; Thu, 14 Jul 2005 11:15:04 -0700 (PDT) (envelope-from mccobb@us.ibm.com) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j6EIEmeR484518 for ; Thu, 14 Jul 2005 14:14:50 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6EIEmQD090290 for ; Thu, 14 Jul 2005 12:14:48 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6EIEl40010327 for ; Thu, 14 Jul 2005 12:14:48 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j6EIEluD010313; Thu, 14 Jul 2005 12:14:47 -0600 In-Reply-To: <42e66b43.259846015@smtp.bjoern.hoehrmann.de> To: Bjoern Hoehrmann Cc: ietf-types@iana.org, ietf-xml-mime@imc.org MIME-Version: 1.0 Subject: Re: Registration of media type application/xhtml-voice+xml X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Gerald McCobb Date: Thu, 14 Jul 2005 14:14:45 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 07/14/2005 12:14:46, Serialize complete at 07/14/2005 12:14:46 Content-Type: multipart/alternative; boundary="=_alternative 006437E28525703E_=" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 07/14/2005 10:21 AM =20 To: Gerald McCobb/Boca Raton/IBM@IBMUS cc: ietf-types@iana.org, ietf-xml-mime@imc.org 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:bjoern@hoehrmann.de =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
* Bjoern Hoehrmann wrote:

>* 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+v= oice+xml.
>>The application/xhtml+voice+xml media type was the original submiss= ion.

>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.htm= l
>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-leve= l
>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 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'= .

Are "+suffix" constructs the same as putti= ng "+" 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 <derhoermi@gm= x.net>

07/14/2005 10:21 AM

       
        To:        Gerald McCobb/Boca Raton/IBM@IBMUS
        cc:        ietf-types@iana.org, ietf-xml-mime@imc.org
        Subject:        Re: Registration of media type application/xhtml= -voice+xml



* Gerald McCobb wrote:
>I asked the IESG to postpone the publication of the
>application/xhtml-voice+xml media type as an informational RFC.  T= he
>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=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehrma= nn.de
Weinh. Str. 22 =B7 Telefon: +49(0)621/4309674 =B7 http://www.bjoernsworld.d= e
68309 Mannheim =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/

--=_alternative 006437E28525703E_=-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EFSGCO044130; Thu, 14 Jul 2005 08:28:16 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6EFSGsS044129; Thu, 14 Jul 2005 08:28:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6EFSEYU044118 for ; Thu, 14 Jul 2005 08:28:15 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 14 Jul 2005 15:28:08 -0000 Received: from dsl-084-056-238-087.arcor-ip.net (EHLO localhost) [84.56.238.87] by mail.gmx.net (mp033) with SMTP; 14 Jul 2005 17:28:08 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Gerald McCobb Cc: ietf-types@alvestrand.no, ietf-xml-mime@imc.org, public-cdf@w3.org Subject: Re: Registration of media type application/xhtml-voice+xml Date: Thu, 14 Jul 2005 17:28:05 +0200 Message-ID: <42e774ef.262322656@smtp.bjoern.hoehrmann.de> References: <20050712220929.GWHV23513.lakermmtao04.cox.net@A31P> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * 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:bjoern@hoehrmann.de · 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/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EELF94037130; Thu, 14 Jul 2005 07:21:15 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6EELFHs037129; Thu, 14 Jul 2005 07:21:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j6EELE3k037117 for ; Thu, 14 Jul 2005 07:21:14 -0700 (PDT) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 14 Jul 2005 14:21:07 -0000 Received: from dsl-084-056-238-087.arcor-ip.net (EHLO localhost) [84.56.238.87] by mail.gmx.net (mp006) with SMTP; 14 Jul 2005 16:21:07 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Gerald McCobb Cc: ietf-types@iana.org, ietf-xml-mime@imc.org Subject: Re: Registration of media type application/xhtml-voice+xml Date: Thu, 14 Jul 2005 16:21:05 +0200 Message-ID: <42e66b43.259846015@smtp.bjoern.hoehrmann.de> References: <20050712220929.GWHV23513.lakermmtao04.cox.net@A31P> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: * 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:bjoern@hoehrmann.de · 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/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EAXw3i063559; Thu, 14 Jul 2005 03:33:58 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6EAXviw063555; Thu, 14 Jul 2005 03:33:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from sam.opera.com (sam.opera.com [193.69.113.81]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6EAXIrv063312 for ; Thu, 14 Jul 2005 03:33:19 -0700 (PDT) (envelope-from jax@opera.com) Received: from jax-xp.oslo.opera.com (dsl-104-102.oeke.tiscali.no [213.234.104.102]) (authenticated bits=0) by sam.opera.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id j6EAWxWe030142 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 14 Jul 2005 10:33:02 GMT Date: Thu, 14 Jul 2005 12:31:10 +0200 From: "Jonny Axelsson" To: "Martin Duerst" , "Gerald McCobb" , iana@iana.org, ietf-types@iana.org Subject: Re: Registration of media type application/xhtml-voice+xml Cc: "ietf-xml-mime@imc.org" References: <20050712220929.GWHV23513.lakermmtao04.cox.net@A31P> <6.0.0.20.2.20050714153404.08e76ec0@itmail.it.aoyama.ac.jp> Organization: Opera Software ASA Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <6.0.0.20.2.20050714153404.08e76ec0@itmail.it.aoyama.ac.jp> User-Agent: Opera M2/8.01 (Win32, build 7642) X-Scanned-By: MIMEDefang 2.39 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 14 Jul 2005 08:49:12 +0200, 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. 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 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6E6pG4x073071; Wed, 13 Jul 2005 23:51:16 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6E6pGHG073070; Wed, 13 Jul 2005 23:51:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from scmailgw1.scop.aoyama.ac.jp (scmailgw1.scop.aoyama.ac.jp [133.2.251.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6E6obpl072780 for ; Wed, 13 Jul 2005 23:51:15 -0700 (PDT) (envelope-from duerst@it.aoyama.ac.jp) Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6E6oVC08616; Thu, 14 Jul 2005 15:50:31 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 39b68724_f435_11d9_9592_0030482532aa_12528; Thu, 14 Jul 2005 16:02:22 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0083C4; 14 Jul 05 15:56:09 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 14 Jul 05 15:55:47 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.227.17) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0083C2; 14 Jul 05 15:55:40 +0900 Message-Id: <6.0.0.20.2.20050714153404.08e76ec0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Jul 2005 15:49:12 +0900 To: Gerald McCobb , iana@iana.org, ietf-types@iana.org From: Martin Duerst Subject: Re: Registration of media type application/xhtml-voice+xml Cc: "ietf-xml-mime@imc.org" In-Reply-To: References: <20050712220929.GWHV23513.lakermmtao04.cox.net@A31P> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DM6K71087201; Wed, 13 Jul 2005 15:06:20 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6DM6Kts087200; Wed, 13 Jul 2005 15:06:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DM6JCD087190 for ; Wed, 13 Jul 2005 15:06:20 -0700 (PDT) (envelope-from mccobb@us.ibm.com) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j6DM6Efj503192 for ; Wed, 13 Jul 2005 18:06:14 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6DM6ESl411514 for ; Wed, 13 Jul 2005 16:06:14 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6DM6DsV008087 for ; Wed, 13 Jul 2005 16:06:13 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j6DM6DAb008073; Wed, 13 Jul 2005 16:06:13 -0600 In-Reply-To: <2710257396.20050713185933@w3.org> To: Chris Lilley Cc: iana@iana.org, ietf-types@iana.org, "ietf-xml-mime@imc.org" MIME-Version: 1.0 Subject: Re: Registration of media type application/xhtml-voice+xml X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Gerald McCobb Date: Wed, 13 Jul 2005 18:06:17 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 07/13/2005 16:06:12, Serialize complete at 07/13/2005 16:06:12 Content-Type: multipart/alternative; boundary="=_alternative 00796AE38525703D_=" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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"
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_=-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DGxfbR058896; Wed, 13 Jul 2005 09:59:41 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6DGxf93058895; Wed, 13 Jul 2005 09:59:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DGxaDN058884 for ; Wed, 13 Jul 2005 09:59:36 -0700 (PDT) (envelope-from chris@w3.org) Received: from localhost (localhost [127.0.0.1]) by homer.w3.org (Postfix) with ESMTP id 3F8C74F05B; Wed, 13 Jul 2005 12:59:34 -0400 (EDT) Date: Wed, 13 Jul 2005 18:59:33 +0200 From: Chris Lilley Reply-To: Chris Lilley Organization: W3C X-Priority: 3 (Normal) Message-ID: <2710257396.20050713185933@w3.org> To: Gerald McCobb Cc: iana@iana.org, ietf-types@iana.org, "ietf-xml-mime@imc.org" Subject: Re: Registration of media type application/xhtml-voice+xml In-Reply-To: References: <20050712220929.GWHV23513.lakermmtao04.cox.net@A31P> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DGmgjO057962; Wed, 13 Jul 2005 09:48:42 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6DGmgws057961; Wed, 13 Jul 2005 09:48:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from bork.markbaker.ca (static-80-155.dsl.cuic.ca [216.126.80.155] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DGmfc9057955 for ; Wed, 13 Jul 2005 09:48:41 -0700 (PDT) (envelope-from distobj@acm.org) Received: from mbaker by bork.markbaker.ca with local (Exim 3.36 #1 (Debian)) id 1DskQh-0001Mq-00; Wed, 13 Jul 2005 12:49:51 -0400 Date: Wed, 13 Jul 2005 12:49:51 -0400 From: Mark Baker To: Gerald McCobb Cc: iana@iana.org, ietf-types@iana.org, "ietf-xml-mime@imc.org" Subject: Re: Registration of media type application/xhtml-voice+xml Message-ID: <20050713164951.GK6315@markbaker.ca> References: <20050712220929.GWHV23513.lakermmtao04.cox.net@A31P> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DGXKNv056549; Wed, 13 Jul 2005 09:33:20 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6DGXKxH056548; Wed, 13 Jul 2005 09:33:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6DGXHoc056524 for ; Wed, 13 Jul 2005 09:33:17 -0700 (PDT) (envelope-from mccobb@us.ibm.com) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j6DGX8M7183070 for ; Wed, 13 Jul 2005 12:33:09 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6DGX8Sl389132 for ; Wed, 13 Jul 2005 10:33:08 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6DGX8Xf021454 for ; Wed, 13 Jul 2005 10:33:08 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j6DGX8GF021449; Wed, 13 Jul 2005 10:33:08 -0600 In-Reply-To: <20050712220929.GWHV23513.lakermmtao04.cox.net@A31P> To: iana@iana.org, ietf-types@iana.org Cc: "ietf-xml-mime@imc.org" MIME-Version: 1.0 Subject: Registration of media type application/xhtml-voice+xml X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Gerald McCobb Date: Wed, 13 Jul 2005 12:33:04 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 07/13/2005 10:33:08, Serialize complete at 07/13/2005 10:33:08 Content-Type: multipart/alternative; boundary="=_alternative 005AE9588525703D_=" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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" 07/12/2005 06:09 PM To: cc: , 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:blilly@erols.com] > Sent: Tuesday, July 12, 2005 4:08 PM > To: ietf-types@alvestrand.no > Cc: iana@iana.org > 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"
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" <sah@428cobrajet.net>

07/12/2005 06:09 PM

       
        To:        <ietf-types@alvestrand.no>
        cc:        <iana@iana.org>, 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:blilly@erols.com]
> Sent: Tuesday, July 12, 2005 4:08 PM
> To: ietf-types@alvestrand.no
> Cc: iana@iana.org
> 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_=-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BFHQCV055178; Mon, 11 Jul 2005 08:17:26 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6BFHQ6O055177; Mon, 11 Jul 2005 08:17:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BFHPV2055170 for ; Mon, 11 Jul 2005 08:17:25 -0700 (PDT) (envelope-from liam@w3.org) Received: by homer.w3.org (Postfix, from userid 16040) id 6FD124F061; Mon, 11 Jul 2005 11:17:24 -0400 (EDT) Date: Mon, 11 Jul 2005 11:17:24 -0400 From: Liam Quin To: John Cowan Cc: ietf-types@iana.org, ietf-xml-mime@imc.org, public-qt-comments@w3.org Subject: Re: W3C Last Call and Media Type request for comments: XQuery and XQueryX Message-ID: <20050711151724.GC5665@w3.org> References: <425e9d44.15417140@smtp.bjoern.hoehrmann.de> <20050517180227.GA10669@w3.org> <20050519101540.67F4.MURATA@hokkaido.email.ne.jp> <20050519143859.GA27635@w3.org> <20050519174534.GD2322@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050519174534.GD2322@skunk.reutershealth.com> X-Feet: bare, comfortable. happy and free! User-Agent: Mutt/1.5.9i Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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. jcowan@reutershealth.com > --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/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BEl7Gs052253; Mon, 11 Jul 2005 07:47:07 -0700 (PDT) (envelope-from owner-ietf-xml-mime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j6BEl7AG052252; Mon, 11 Jul 2005 07:47:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-xml-mime@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6BEl6GJ052244 for ; Mon, 11 Jul 2005 07:47:07 -0700 (PDT) (envelope-from liam@w3.org) Received: by homer.w3.org (Postfix, from userid 16040) id E91984F181; Mon, 11 Jul 2005 10:47:05 -0400 (EDT) Date: Mon, 11 Jul 2005 10:47:05 -0400 From: Liam Quin To: MURATA Makoto Cc: ietf-types@iana.org, ietf-xml-mime@imc.org, public-qt-comments@w3.org Subject: Re: W3C Last Call and Media Type request for comments: XQuery and XQueryX Message-ID: <20050711144705.GB5665@w3.org> References: <20050519101540.67F4.MURATA@hokkaido.email.ne.jp> <20050519143859.GA27635@w3.org> <20050519235511.6C29.MURATA@hokkaido.email.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20050519235511.6C29.MURATA@hokkaido.email.ne.jp> X-Feet: bare, comfortable. happy and free! User-Agent: Mutt/1.5.9i Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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/