The application/xv+xml Media Type
Media type identifier for multimodal documents mixing web pages and voice
McCobb, G., "The application/xv+xml Media Type", RFC 4374, DOI 10.17487/RFC4374, January 2006, <https://www.rfc-editor.org/info/rfc4374>.
@misc{rfc4374,
series = {Request for Comments},
number = 4374,
howpublished = {RFC 4374},
publisher = {RFC Editor},
doi = {10.17487/RFC4374},
url = {https://www.rfc-editor.org/info/rfc4374},
author = {G. McCobb},
title = {{The application/xv+xml Media Type}},
pagetotal = 6,
year = 2006,
month = jan,
} RFC text
Contents
Network Working Group G. McCobb
Request for Comments: 4374 IBM Corporation
Category: Informational January 2006
The application/xv+xml Media Type
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the registration of the MIME sub-type
application/xv+xml. This sub-type is intended for use as a media
descriptor for XHTML+Voice multimodal language documents.
1. Introduction
XHTML+Voice is a member of the XHTML family of document types, as
specified by XHTML Modularization [4]. XHTML+Voice extends XHTML 1.1
[5] with a modularized subset of VoiceXML 2.0 [9], XML Events [7],
and a few extensions to both XHTML and VoiceXML 2.0. XHTML 1.1,
VoiceXML 2.0, and XML Events are W3C Recommendations.
The language integration defined by XHTML+Voice supports all modules
defined by XHTML Modularization and adds voice interaction to XHTML
elements in order to enable multimodal applications. The defined
document type for XHTML+Voice is XHTML Host language document type
conformant.
XHTML+Voice 1.2 [8] is maintained by the VoiceXML Forum, at URI
location <http://www.voicexml.org/specs/multimodal/x+v/12/>.
1.1. application/xv+xml Usage
The application/xv+xml media type is intended to be a media
descriptor for XHTML+Voice multimodal documents. It is used to
inform applications that additional markup for running a voice
browser component and activating handlers for DOM Level 2 events [6]
via XML Events [7] can be processed.
This media type registration is not intended for e-mail usage.
2. IANA Registration
To: ietf-types@iana.org
Subject: Registration of MIME media type
application/xv+xml
MIME media type name: application
MIME subtype name: xv+xml
Required parameters: none
Optional parameters:
charset: has the same semantics as the charset parameter of the
"application/xml" media type specified in [1].
Encoding considerations:
XHTML+Voice has the same media type encoding considerations
specified in Section 3.2 of [1].
Security considerations:
XHTML+Voice is an extension of XHTML and has the same security
issues as XHTML. These include interpreting anchors and forms in
XHTML documents, and scripting languages and other dynamic
interactive capabilities. See Section 7 of [2].
In addition, the scripting language can be accessed by both the
XHTML and the VoiceXML 2.0 markup embedded in the XHTML+Voice
document. See Section 1.3.1.5 of [8].
XML-Events [7] allows an author to attach a handler to any node in
the document. The handler that is activated in response to a
specified event may be either a voice dialog or a script that can
be in either the same or an external document.
Interoperability considerations:
Because XHTML+Voice is built upon W3C standard recommendations, it
is designed to be interoperable across a wide range of platforms
and client devices. Because the extensions to XHTML are
identified by their namespaces, all browsers that have namespace
support can run an XHTML+Voice document as an XHTML document
without voice interaction.
Published specification:
The latest published version of XHTML+Voice is [8].
Applications which use this media type:
XHTML+Voice documents are intended to be deployed on the World
Wide Web and rendered by multimodal browsers that support the
visual and voice modes of interaction. Because XHTML+Voice is an
application of XML, authors can expect XHTML+Voice user agents to
be conformant XML 1.0 [3] processors. See section 2 of [2].
Additional information:
Magic number(s): There is no single string that is always present.
File extension(s): mxml, xhvml, xvml, xvm
Macintosh File Type Code(s): TEXT
Person & e-mail address to contact for further information:
Gerald McCobb
mccobb@us.ibm.com
Intended usage: LIMITED USE
Author/Change controller: Gerald McCobb
Further information:
3. Fragment Identifiers
See Section 3 of [2]. Following [2], fragment identifiers for XHTML+
Voice documents designate the element with the corresponding ID
attribute value (see [3], Section 3.3.1).
While XHTML+Voice adds new ID attributes with fragment identifier
namespaces that are not in the same namespace as XHTML, uniqueness of
the ID attribute values is preserved within the document. See
sections 1.3.1 and 5.3 of [8].
4. Recognizing XHTML+Voice files
Because XHTML+Voice is XML, an XHTML+Voice document (optionally)
starts with an XML declaration that begins with "<?xml" and has a
DOCTYPE declaration "<!DOCTYPE html". XHTML+Voice 1.2 has the
following DOCTYPE declaration:
<!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN"
"http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd">
Because XHTML+Voice is in the XHTML family of languages, the root
element of an XHTML+Voice document is 'html', and '<html' can be
found near the top of the document.
5. Security Considerations
Security considerations for this media type are discussed in the MIME
type registration that appears in Section 2.
6. IANA Considerations
As described in Section 2, this document specifies the registration
of a MIME type for XHTML+Voice documents according to [1].
7. Normative References
[1] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[2] Baker, M. and P. Stark, "The 'application/xhtml+xml' Media
Type", RFC 3236, January 2002.
[3] Bray, T. and others, "Extensible Markup Language (XML) 1.0", W3C
Recommendation, http://www.w3.org/TR/REC-xml", February 2004.
[4] Dooley, S. and others, "Modularization of XHTML", W3C
Recommendation, http://www.w3.org/TR/xhtml-modularization",
April 2001.
[5] Altheim, M. and S. McCarron, "XHTML 1.1 - Module-based XHTML",
W3C Recommendation, http://www.w3.org/TR/xhtml11/, May 2001.
[6] Pixley, T., "Document Object Model Level 2 Events
Specification", W3C Recommendation,
http://www.w3.org/TR/DOM-Level-2-Events/, November 2000.
[7] Pemberton, S., Raman, T., and S. McCarron, "XML Events - An
events syntax for XML", W3C Recommendation,
http://www.w3.org/TR/xml-events/, January 2002.
[8] Axelsson, J. and others, "XHTML+Voice Profile 1.2",
http://www.voicexml.org/specs/multimodal/x+v/12/, March 2004.
[9] McGlashan, S. and others, "Voice Extensible Markup Language
(VoiceXML)", W3C Recommendation,
http://www.w3.org/TR/voicexml20/, March 2004.
Author's Address
Gerald McCobb
International Business Machines Corporation
8051 Congress Ave.
Boca Raton, FL 33487
USA
Phone: +1 561 862 2109
EMail: mccobb@us.ibm.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
AI ELI5
On this page
§1XHTML+Voice: Web Pages With Voice
XHTML+Voice is an extension of XHTML that adds voice interaction capabilities. It combines standard XHTML markup (the language of web pages) with a subset of VoiceXML (a language for voice-based interactions) and XML Events (a standard way to attach event handlers to document elements). This lets a single document provide both a visual interface and a voice interface.
For example, a document might have a text input field for a user to type a search query, but also voice commands so the user can say the search term. The same document can be displayed visually on a screen and understood by a voice browser that reads the page aloud and accepts spoken input.
XHTML+Voice is specified by the VoiceXML Forum as a modularized host language conformant with XHTML Modularization. It uses the same W3C standards as regular XHTML, ensuring broad compatibility. The document type is maintained and published by the VoiceXML Forum.
A document type that puts web page instructions and voice instructions in the same file, so a device with a screen and a microphone can show you a page and let you talk to it.
§2Why a Media Type Was Needed
When a web server sends a document to a browser, it includes a MIME media type header that describes what kind of document it is. The media type tells the browser whether it is receiving an HTML page (text/html), a JPEG image (image/jpeg), a PDF (application/pdf), or something else. The browser uses this label to decide which rendering engine to use.
Without a standard media type, an XHTML+Voice document served by a web server would need to be labeled as generic application/xml or application/xhtml+xml, which would not indicate that voice capabilities are present. An XHTML+Voice-capable browser would have to guess, based on the file extension or document structure, that it should invoke the voice engine.
By registering a dedicated MIME type, XHTML+Voice documents can be unambiguously identified in transit. Servers can correctly label them, and multimodal browsers know immediately that both visual and voice rendering capabilities are needed.
Without a label, a document just says 'I am some XML.' With a real label, it says 'I am an XHTML+Voice page, with web visual stuff and voice stuff,' so the right program knows how to open it.
§3MIME Type Registration
This RFC registers the MIME media type application/xv+xml according to the IANA process defined in RFC 3023. The registration specifies:
Required parameters: none. Every application/xv+xml document is processed the same way.
Optional parameters: the charset parameter works the same way as for application/xml, allowing the document to specify the character encoding (such as UTF-8).
Encoding considerations: XHTML+Voice follows the same encoding rules as XML, defined in RFC 3023.
Interoperability: Because XHTML+Voice uses W3C standard modules and identifies its extensions by XML namespace, a standard XML processor that does not know about voice elements can still parse and render the XHTML portions without the voice features. This namespace-based approach ensures backward compatibility. A browser without voice capabilities can display the XHTML content as a regular web page.
File extensions: common file extensions include .mxml, .xhvml, .xvml, and .xvm, though the media type is the authoritative label.
Intended usage: Limited use. XHTML+Voice is designed for specific multimodal applications rather than universal web use.
The official registration says: when you see the label application/xv+xml, it is an XHTML+Voice document. You can optionally say what character set it uses. It follows XML encoding rules.
§4Identifying XHTML+Voice Documents
An XHTML+Voice document is XML, so it optionally begins with an XML declaration like <?xml version='1.0'?>. It must have a DOCTYPE declaration specifying the XHTML+Voice document type. For XHTML+Voice 1.2, the DOCTYPE is:
<!DOCTYPE html PUBLIC "-//VoiceXML Forum//DTD XHTML+Voice 1.2//EN" "http://www.voicexml.org/specs/multimodal/x+v/12/dtd/xhtml+voice12.dtd">
Like all XHTML documents, the root element is <html>, which appears near the top of the file. The presence of this DOCTYPE, together with voice elements from the VoiceXML namespace, uniquely identifies the document as XHTML+Voice.
An XHTML+Voice file starts with an XML declaration and a DOCTYPE that says 'I am XHTML+Voice 1.2,' then the HTML content begins with <html>.
§5Security and Interoperability
XHTML+Voice inherits security considerations from both XHTML and VoiceXML. XHTML security includes the usual web risks: interpreting hyperlinks and form submissions, and executing embedded scripts. These are the same risks present in ordinary web pages.
VoiceXML security adds voice-specific concerns: voice dialogs and speech recognition, which can be triggered by both the XHTML and VoiceXML markup. A malicious document could use voice commands to execute unintended actions.
XML Events allow attaching handlers to any node in the document. These handlers can trigger voice dialogs or scripts, either in the same document or by loading external code. This power requires careful content security policies.
Interoperability is strong because XHTML+Voice is built on W3C standards. Browsers with namespace support can render the XHTML portions of an XHTML+Voice document as regular HTML, ignoring the voice elements if voice rendering is not available. This graceful degradation means the document is not entirely useless in non-multimodal browsers.
XHTML+Voice has the same risks as web pages plus voice risks: injected commands, script execution, and event handlers. But it degrades gracefully—a regular browser can show the visual part without voice.