summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3236.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3236.txt')
-rw-r--r--doc/rfc/rfc3236.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3236.txt b/doc/rfc/rfc3236.txt
new file mode 100644
index 0000000..7ca4482
--- /dev/null
+++ b/doc/rfc/rfc3236.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+Baker & Stark Informational [Page 1]
+
+RFC 3236 The 'application/xhtml+xml' Media Type January 2002
+
+
+ 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].
+
+
+
+
+
+
+
+Baker & Stark Informational [Page 2]
+
+RFC 3236 The 'application/xhtml+xml' Media Type January 2002
+
+
+ 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.
+
+
+
+
+
+
+
+Baker & Stark Informational [Page 3]
+
+RFC 3236 The 'application/xhtml+xml' Media Type January 2002
+
+
+ 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.
+
+
+
+
+
+
+
+Baker & Stark Informational [Page 4]
+
+RFC 3236 The 'application/xhtml+xml' Media Type January 2002
+
+
+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.
+
+
+
+
+
+
+
+
+
+Baker & Stark Informational [Page 5]
+
+RFC 3236 The 'application/xhtml+xml' Media Type January 2002
+
+
+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"
+
+
+
+
+
+Baker & Stark Informational [Page 6]
+
+RFC 3236 The 'application/xhtml+xml' Media Type January 2002
+
+
+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>
+
+
+
+
+
+Baker & Stark Informational [Page 7]
+
+RFC 3236 The 'application/xhtml+xml' Media Type January 2002
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Stark Informational [Page 8]
+