Re: Registration of media type application/xhtml-voice+xml

Bjoern Hoehrmann <derhoermi@gmx.net> Thu, 14 July 2005 18:51 UTC

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 <ietf-xml-mime@imc.org>; 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 <derhoermi@gmx.net>
To: Gerald McCobb <mccobb@us.ibm.com>
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> <OF919D8740.C53D7F12-ON8525703E.00547F83-8525703E.006437E8@us.ibm.com>
In-Reply-To: <OF919D8740.C53D7F12-ON8525703E.00547F83-8525703E.006437E8@us.ibm.com>
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: <http://www.imc.org/ietf-xml-mime/mail-archive/>
List-ID: <ietf-xml-mime.imc.org>
List-Unsubscribe: <mailto:ietf-xml-mime-request@imc.org?body=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 <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: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/