The 'application/xhtml+xml' Media Type
Registers the MIME type for XHTML pages, so that a receiver is told it is dealing with XML.
Baker, M. and P. Stark, "The 'application/xhtml+xml' Media Type", RFC 3236, DOI 10.17487/RFC3236, January 2002, <https://www.rfc-editor.org/info/rfc3236>.
@misc{rfc3236,
series = {Request for Comments},
number = 3236,
howpublished = {RFC 3236},
publisher = {RFC Editor},
doi = {10.17487/RFC3236},
url = {https://www.rfc-editor.org/info/rfc3236},
author = {M. Baker and P. Stark},
title = {{The 'application/xhtml+xml' Media Type}},
pagetotal = 8,
year = 2002,
month = jan,
} RFC text
Contents
Network Working Group M. Baker
Request for Comments: 3236 Planetfred, Inc.
Category: Informational P. Stark
Ericsson Mobile Communications
January 2002
The 'application/xhtml+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 (2002). All Rights Reserved.
Abstract
This document defines the 'application/xhtml+xml' MIME media type for
XHTML based markup languages; it is not intended to obsolete any
previous IETF documents, in particular RFC 2854 which registers
'text/html'.
1. Introduction
In 1998, the W3C HTML working group began work on reformulating HTML
in terms of XML 1.0 [XML] and XML Namespaces [XMLNS]. The first part
of that work concluded in January 2000 with the publication of the
XHTML 1.0 Recommendation [XHTML1], the reformulation for HTML 4.01
[HTML401].
Work continues in the Modularization of XHTML Recommendation
[XHTMLM12N], the decomposition of XHTML 1.0 into modules that can be
used to compose new XHTML based languages, plus a framework for
supporting this composition.
This document only registers a new MIME media type,
'application/xhtml+xml'. It does not define anything more than is
required to perform this registration.
This document follows the convention set out in [XMLMIME] for the
MIME subtype name; attaching the suffix "+xml" to denote that the
entity being described conforms to the XML syntax as defined in XML
1.0 [XML].
This document was prepared by members of the W3C HTML working group
based on the structure, and some of the content, of RFC 2854, the
registration of 'text/html'. Please send comments to www-
html@w3.org, a public mailing list (requiring subscription) with
archives at <http://lists.w3.org/Archives/Public/www-html/>.
2. Registration of MIME media type application/xhtml+xml
MIME media type name: application
MIME subtype name: xhtml+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 [XMLMIME].
profile
See Section 8 of this document.
Encoding considerations:
See Section 4 of this document.
Security considerations:
See Section 7 of this document.
Interoperability considerations:
XHTML 1.0 [XHTML10] specifies user agent conformance rules that
dictate behaviour that must be followed when dealing with, among
other things, unrecognized elements.
With respect to XHTML Modularization [XHTMLMOD] and the existence
of XHTML based languages (referred to as XHTML family members)
that are not XHTML 1.0 conformant languages, it is possible that
'application/xhtml+xml' may be used to describe some of these
documents. However, it should suffice for now for the purposes of
interoperability that user agents accepting
'application/xhtml+xml' content use the user agent conformance
rules in [XHTML1].
Although conformant 'application/xhtml+xml' interpreters can
expect that content received is well-formed XML (as defined in
[XML]), it cannot be guaranteed that the content is valid XHTML
(as defined in [XHTML1]). This is in large part due to the
reasons in the preceding paragraph.
Published specification:
XHTML 1.0 is now defined by W3C Recommendation; the latest
published version is [XHTML1]. It provides for the description of
some types of conformant content as "text/html", but also doesn't
disallow the use with other content types (effectively allowing
for the possibility of this new type).
Applications which use this media type:
Some content authors have already begun hand and tool authoring on
the Web with XHTML 1.0. However that content is currently
described as "text/html", allowing existing Web browsers to
process it without reconfiguration for a new media type.
There is no experimental, vendor specific, or personal tree
predecessor to 'application/xhtml+xml'. This new type is being
registered in order to allow for the expected deployment of XHTML
on the World Wide Web, as a first class XML application where
authors can expect that user agents are conformant XML 1.0 [XML]
processors.
Additional information:
Magic number:
There is no single initial byte sequence that is always present
for XHTML files. However, Section 5 below gives some
guidelines for recognizing XHTML files. See also section 3.1 in
[XMLMIME].
File extension:
There are three known file extensions that are currently in use
for XHTML 1.0; ".xht", ".xhtml", and ".html".
It is not recommended that the ".xml" extension (defined in
[XMLMIME]) be used, as web servers may be configured to
distribute such content as type "text/xml" or
"application/xml". [XMLMIME] discusses the unreliability of
this approach in section 3. Of course, should the author
desire this behaviour, then the ".xml" extension can be used.
Macintosh File Type code: TEXT
Person & email address to contact for further information:
Mark Baker <mark.baker@canada.sun.com>
Intended usage: COMMON
Author/Change controller:
The XHTML specifications are a work product of the World Wide Web
Consortium's HTML Working Group. The W3C has change control over
these specifications.
3. Fragment identifiers
URI references (Uniform Resource Identifiers, see [RFC2396] as
updated by [RFC2732]) may contain additional reference information,
identifying a certain portion of the resource. These URI references
end with a number sign ("#") followed by an identifier for this
portion (called the "fragment identifier"). Interpretation of
fragment identifiers is dependent on the media type of the retrieval
result.
For documents labeled as 'text/html', [RFC2854] specified that the
fragment identifier designates the correspondingly named element,
these were identified by either a unique id attribute or a name
attribute for some elements. For documents described with the
application/xhtml+xml media type, fragment identifiers share the same
syntax and semantics with other XML documents, see [XMLMIME], section
5.
At the time of writing, [XMLMIME] does not define syntax and
semantics of fragment identifiers, but refers to "XML Pointer
Language (XPointer)" for a future XML fragment identification
mechanism. The current specification for XPointer is available at
http://www.w3.org/TR/xptr. Until [XMLMIME] gets updated, fragment
identifiers for XHTML documents designate the element with the
corresponding ID attribute value (see [XML] section 3.3.1); any XHTML
element with the "id" attribute.
4. Encoding considerations
By virtue of XHTML content being XML, it has the same considerations
when sent as 'application/xhtml+xml' as does XML. See [XMLMIME],
section 3.2.
5. Recognizing XHTML files
All XHTML documents will have the string "<html" near the beginning
of the document. Some will also begin with an XML declaration which
begins with "<?xml", though that alone does not indicate an XHTML
document. All conforming XHTML 1.0 documents will include an XML
document type declaration with the root element type 'html'.
XHTML Modularization provides a naming convention by which a public
identifier for an external subset in the document type declaration of
a conforming document will contain the string "//DTD XHTML". And
while some XHTML based languages require the doctype declaration to
occur within documents of that type, such as XHTML 1.0, or XHTML
Basic (http://www.w3.org/TR/xhtml-basic), it is not the case that all
XHTML based languages will include it.
All XHTML files should also include a declaration of the XHTML
namespace. This should appear shortly after the string "<html", and
should read 'xmlns="http://www.w3.org/1999/xhtml"'.
6. Charset default rules
By virtue of all XHTML content being XML, it has the same
considerations when sent as 'application/xhtml+xml' as does XML. See
[XMLMIME], section 3.2.
7. Security Considerations
The considerations for "text/html" as specified in [TEXTHTML] and and
for 'application/xml' as specified in [XMLMIME], also hold for
'application/xhtml+xml'.
In addition, because of the extensibility features for XHTML as
provided by XHTML Modularization, it is possible that
'application/xhtml+xml' may describe content that has security
implications beyond those described here. However, if the user agent
follows the user agent conformance rules in [XHTML1], this content
will be ignored. Only in the case where the user agent recognizes
and processes the additional content, or where further processing of
that content is dispatched to other processors, would security issues
potentially arise. And in that case, they would fall outside the
domain of this registration document.
8. The "profile" optional parameter
This parameter is meant to solve the short-term problem of using MIME
media type based content negotiation (such as that done with the HTTP
"Accept" header) to negotiate for a variety of XHTML based languages.
It is intended to be used only during content negotiation. It is not
expected that it be used to deliver content, or that origin web
servers have any knowledge of it (though they are welcome to). It is
primarily targeted for use on the network by proxies in the HTTP
chain that manipulate data formats (such as transcoders).
The parameter is intended to closely match the semantics of the
"profile" attribute of the HEAD element as defined in [HTML401]
(section 7.4.4.3), except it is applied to the document as a whole
rather than just the META elements. More specifically, the value of
the profile attribute is a URI that can be used as a name to identify
a language. Though the URI need not be resolved in order to be
useful as a name, it could be a namespace, schema, or a language
specification.
As an example, user agents supporting only XHTML Basic (see
http://www.w3.org/TR/xhtml-basic) currently have no standard means to
convey their inability to support the additional functionality in
XHTML 1.0 [XHTML1] that is not found in XHTML Basic. While XHTML
Basic user agent conformance rules (which are identical to XHTML 1.0)
provide some guidance to its user agent implementators for handling
some additional content, the additional content in XHTML 1.0 that is
not part of XHTML Basic is substantial, making those conformance
rules insufficient for practical processing and rendering to the end
user. There is also the matter of the potentially substantial burden
on the user agent in receiving and parsing this additional content.
The functionality afforded by this parameter can also be achieved
with at least two other more general content description frameworks;
the "Content-features" MIME header described in RFC 2912, and UAPROF
from the WAPforum (see http://www.wapforum.org/what/technical.htm).
At this time, choosing one of these solutions would require excluding
the other, as interoperability between the two has not been defined.
For this reason, it is suggested that this parameter be used until
such time as that issue has been addressed.
An example use of this parameter as part of a HTTP GET transaction
would be;
Accept: application/xhtml+xml;
profile="http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"
9. Author's Address
Mark A. Baker
Planetfred, Inc.
44 Byward Market, Suite 240
Ottawa, Ontario, CANADA. K1N 7A2
Phone: +1-613-789-1818
EMail: mbaker@planetfred.com
EMail: distobj@acm.org
Peter Stark
Ericsson Mobile Communications
Phone: +464-619-3000
EMail: Peter.Stark@ecs.ericsson.com
10. References
[HTML401] Raggett, D., et al., "HTML 4.01 Specification", W3C
Recommendation. Available at
<http://www.w3.org/TR/html401> (or
<http://www.w3.org/TR/1999/REC-html401-19991224>).
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[XHTML1] "XHTML 1.0: The Extensible HyperText Markup Language: A
Reformulation of HTML 4 in XML 1.0", W3C Recommendation.
Available at <http://www.w3.org/TR/xhtml1>.
[XML] "Extensible Markup Language (XML) 1.0", W3C
Recommendation. Available at <http://www.w3.org/TR/REC-
xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).
[TEXTHTML] Connolly, D. and L. Masinter, "The 'text/html' Media
Type", RFC 2854, June 2000.
[XMLMIME] Murata, M., St.Laurent, S. and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[XHTMLM12N] "Modularization of XHTML", W3C Recommendation. Available
at: <http://www.w3.org/TR/xhtml-modularization>
11. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1Why a New Media Type
In 1998 the W3C HTML working group began work on reformulating HTML in terms of XML 1.0 and XML Namespaces. The first part of that work concluded in January 2000 with the publication of the XHTML 1.0 Recommendation, the reformulation for HTML 4.01. Work continues in the Modularization of XHTML Recommendation, the decomposition of XHTML 1.0 into modules that can be used to compose new XHTML based languages, plus a framework for supporting that composition.
This document only registers a new MIME media type, application/xhtml+xml. It does not define anything more than is required to perform that registration, and it is not intended to obsolete any previous IETF document, in particular the document that registers text/html.
The memo follows the convention set out in the XML Media Types document for the MIME subtype name, attaching the suffix +xml to denote that the entity being described conforms to the XML syntax as defined in XML 1.0. It was prepared by members of the W3C HTML working group based on the structure, and some of the content, of the registration of text/html.
There was already a media type for HTML pages. This one says the same thing about a different flavour of HTML, and the memo is careful to say it adds to the older one rather than replacing it.
§2The Registration
The registration is for the media type application with the subtype name xhtml+xml. There are no required parameters. Two optional parameters are defined. The charset parameter has identical semantics to the charset parameter of the application/xml media type. The profile parameter is described later in the memo.
On interoperability, XHTML 1.0 specifies user agent conformance rules that dictate behaviour which must be followed when dealing with, among other things, unrecognized elements. With respect to XHTML Modularization and the existence of XHTML based languages that are not XHTML 1.0 conformant, it is possible that application/xhtml+xml may be used to describe some of these documents. However, the memo says it should suffice for now that user agents accepting application/xhtml+xml content use the user agent conformance rules in XHTML 1.0.
Although conformant interpreters can expect that content received is well-formed XML, it cannot be guaranteed that the content is valid XHTML, in large part because of the previous paragraph. The published specification, XHTML 1.0, provides for describing some types of conformant content as text/html but does not disallow its use with other content types, which effectively allows for the possibility of this new type.
On the media type's use, the memo notes that some content authors have already begun hand and tool authoring on the Web with XHTML 1.0, but that this content is currently described as text/html, which allows existing web browsers to process it without reconfiguration for a new media type. There is no experimental, vendor specific or personal tree predecessor to application/xhtml+xml. The new type is being registered to allow for the expected deployment of XHTML on the World Wide Web as a first class XML application, where authors can expect that user agents are conformant XML 1.0 processors.
There is no single initial byte sequence always present in an XHTML file, but the memo gives guidelines for recognising them. There are three known file extensions in use for XHTML 1.0, .xht, .xhtml and .html. It is not recommended that the .xml extension be used, since web servers may be configured to distribute such content as text/xml or application/xml. The Macintosh file type code is TEXT, and the intended usage is COMMON. The XHTML specifications are a work product of the World Wide Web Consortium's HTML Working Group, and the W3C has change control over them.
Because XHTML content is XML, sending it as application/xhtml+xml has the same encoding considerations and the same charset default rules as XML.
The registration is short on purpose: a type name, two optional parameters, and a note that a receiver may assume the file is well-formed XML but not that it is valid XHTML. The rest is housekeeping, such as which file extensions are in use and who controls the specification.
| Aspect | text/html | application/xhtml+xml |
|---|---|---|
| Status | Registered earlier, and not obsoleted by this memo | Registered by this memo |
| What a receiver may assume | The rules of the HTML registration | Well-formed XML, and the XHTML 1.0 conformance rules |
| Fragment identifier names | The element with a matching id or name attribute | The element with the matching ID attribute |
| Charset parameter | Defined by its own registration | Same semantics as the application/xml charset parameter |
| Macintosh file type code | Not stated in this memo | TEXT |
§3Fragment Identifiers
URI references may contain additional reference information identifying a certain portion of the resource. Such references end with a number sign followed by an identifier for that portion, called the fragment identifier, and the interpretation of fragment identifiers depends on the media type of the retrieval result.
For documents labelled as text/html, the registration of that type specified that the fragment identifier designates the correspondingly named element, identified by either a unique id attribute or a name attribute for some elements. For documents described with the application/xhtml+xml media type, fragment identifiers share the same syntax and semantics with other XML documents.
At the time of writing, the XML Media Types document does not define the syntax and semantics of fragment identifiers, but refers to the XML Pointer Language for a future XML fragment identification mechanism. Until that document is updated, fragment identifiers for XHTML documents designate the element with the corresponding ID attribute value, that is, any XHTML element with an id attribute.
When you follow a link to a named spot inside a page, the receiver works out which element you meant from the type of the page. For an XHTML page the rule is the XML one: the element whose id attribute matches the text after the number sign.
§5Recognizing XHTML Files
All XHTML documents will have the string <html near the beginning of the document. Some will also begin with an XML declaration which begins with <?xml, though that alone does not indicate an XHTML document. All conforming XHTML 1.0 documents will include an XML document type declaration with the root element type html.
XHTML Modularization provides a naming convention by which a public identifier for an external subset in the document type declaration of a conforming document will contain the string //DTD XHTML. Some XHTML based languages require the doctype declaration to occur within documents of that type, such as XHTML 1.0 and XHTML Basic, but it is not the case that all XHTML based languages will include it.
All XHTML files should also include a declaration of the XHTML namespace. This should appear shortly after the string <html, and should read xmlns='http://www.w3.org/1999/xhtml'.
There is no magic byte sequence for an XHTML file, so the memo lists the things to look for instead: the html tag near the top, a doctype naming html as the root element, and a declaration of the XHTML namespace just after the tag.
- The html tagEvery XHTML document has an opening html tag near the beginning.
- The XML declarationSome files start with an XML declaration, but that alone does not identify an XHTML file.
- The doctypeEvery conforming XHTML 1.0 document has a document type declaration with html as the root element.
- The namespaceA conforming file declares the XHTML namespace just after the html tag.
§8The profile Parameter
The profile parameter is meant to solve the short-term problem of using MIME media type based content negotiation, such as the HTTP Accept header, to negotiate for a variety of XHTML based languages. It is intended to be used only during content negotiation, and it is not expected to be used to deliver content or that origin web servers have any knowledge of it, though they are welcome to. It is primarily targeted for use on the network by proxies in the HTTP chain that manipulate data formats, such as transcoders.
The parameter is intended to closely match the semantics of the profile attribute of the HEAD element as defined in HTML 4.01, except that it is applied to the document as a whole rather than just the META elements. The value of the profile attribute is a URI that can be used as a name to identify a language. The URI need not be resolved to be useful as a name, and it could be a namespace, a schema or a language specification.
The example the memo gives is that user agents supporting only XHTML Basic have no standard means to convey their inability to support the additional functionality in XHTML 1.0 that is not found in XHTML Basic. The XHTML Basic conformance rules, which are identical to XHTML 1.0, give some guidance, but the additional content in XHTML 1.0 that is not part of XHTML Basic is substantial, which makes those rules insufficient for practical processing and rendering to the end user. There is also the potentially substantial burden on the user agent in receiving and parsing that additional content.
The same functionality can be achieved with at least two other more general content description frameworks, the Content-features MIME header described in RFC 2912 and UAPROF from the WAPforum. Choosing one of these solutions would require excluding the other, because interoperability between the two has not been defined, so the memo suggests that this parameter be used until that issue is addressed. As part of an HTTP GET transaction the example is:
Accept: application/xhtml+xml;
profile='http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd'
When a browser says which kinds of XHTML it can handle, this parameter lets it say which version. The value is a name, not a location, so nothing has to fetch it. The memo notes that two other frameworks could do the same job, but since they do not interoperate with each other it picked one for now.
Accept: application/xhtml+xml;
profile="http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"§7Security Considerations
The considerations for text/html and for application/xml also hold for application/xhtml+xml. In addition, because of the extensibility features for XHTML provided by XHTML Modularization, it is possible that application/xhtml+xml may describe content that has security implications beyond those described. However, if the user agent follows the user agent conformance rules in XHTML 1.0, that content will be ignored. Security issues could potentially arise only where the user agent recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, and in that case they would fall outside the domain of this registration document.
The usual rules for HTML and for XML apply. The extra risk of modular XHTML comes from content a receiver does not recognise, and the memo's position is that a receiver following the XHTML rules will ignore such content anyway.