Several proposals have been drafted specifying the use of media ('MIME') types and subtypes in connection with XML documents. See references below for IETF RFCs, IDs, and commentary.

Key Resources

• IANA MIME Media Types
• Application for Requesting a Media Type
• IANA Application Media-Types
• IANA Text Media-Types
  (e.g. css, html, plain, sgml, xml, xml-external-parsed-entity)
• ietf-xml-mime — IETF Mailing list archives for discussion of MIME types for XML
• XHTML Media Type Test: Results
• W3C Markup Validation Service. With the "Verbose Output" activated, the validator will report the Content-Type used by the server.

IETF Standards for Media Types

• RFC 2045. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
• RFC 2046. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
• RFC 2077. The Model Primary Content Type for Multipurpose Internet Mail Extensions
• RFC 3023. XML Media Types [with updates]
• RFC 3798. Message Disposition Notification
• RFC 4288. Media Type Specifications and Registration Procedures
• RFC 4289. Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
• RFC 5147. URI Fragment Identifiers for the text/plain Media Type

Specifications, Articles, Reports

• [August 15, 2005] "The Atom Syndication Format." Approved by the IESG as an IETF Proposed Standard. Edited by Mark Nottingham [WWW] and Robert Sayre [WWW]. Preliminary draft contributions from Tim Bray, Mark Pilgrim, and Sam Ruby; Norman Walsh provided the Relax NG schema. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-11'. August 15, 2005, expires February 16, 2006. 56 pages. HTML, tracker, and the RELAX NG RNC grammar. According to the IANA Considerations: "An Atom Document, when serialized as XML 1.0, can be identified with the following media type: MIME media type name: application, MIME subtype name: atom+xml. File extension: .atom. The 'charset' parameter has identical semantics to the charset parameter of the application/xml media type as specified in RFC 3023. On the atom:content element, the value of the "type" attribute MAY be one of "text", "html", or "xhtml". Failing that, it MUST conform to the syntax of a MIME media type, but MUST NOT be a composite type... If neither the type attribute nor the src attribute is provided, Atom Processors MUST behave as though the type attribute were present with a value of "text". Atom Processors MUST interpret atom:content according to the first applicable rule. (1) If the value of "type" is "text", the content of atom:content MUST NOT contain child elements. Such text is intended to be presented to humans in a readable fashion. Thus, Atom Processors MAY collapse white-space (including line-breaks), and display the text using typographic techniques such as justification and proportional fonts. (2) If the value of "type" is "html", the content of atom:content MUST NOT contain child elements, and SHOULD be suitable for handling as HTML. The HTML markup MUST be escaped... The HTML markup SHOULD be such that it could validly appear directly within an HTML <DIV> element. Atom Processors that display the content MAY use the markup to aid in displaying it. (3) If the value of "type" is "xhtml", the content of atom:content MUST be a single XHTML div element, and SHOULD be suitable for handling as XHTML. The XHTML div element itself MUST NOT be considered part of the content. Atom Processors that display the content MAY use the markup to aid in displaying it. The escaped versions of characters such as "&" and ">" represent those characters, not markup. (4) If the value of "type" is an XML media type per RFC 3023, or ends with "+xml" or "/xml" (case-insensitive), the content of atom:content MAY include child elements, and SHOULD be suitable for handling as the indicated media type. If the "src" attribute is not provided, this would normally mean that the "atom:content" element would contain a single child element which would serve as the root element of the XML document of the indicated type. (5) If the value of "type" begins with "text/" (case-insensitive), the content of atom:content MUST NOT contain child elements. (6) For all other values of "type", the content of atom:content MUST be a valid Base64 encoding, as described in RFC 3548, section 3. When decoded, it SHOULD be suitable for handling as the indicated media type. In this case, the characters in the Base64 encoding MAY be preceded and followed in the atom:content element by white-space, and lines are separated by a single newline (U+000A) character..."

• [June 29, 2005] The DocBook Schema. Working Draft 5.0a1. June 29, 2005. Edited by Norman Walsh (Sun Microsystems, Inc). Document identifier: 'wd-docbook-docbook-5.0a1'. A work product of the DocBook Technical Committee at OASIS. "DocBook is general purpose XML schema particularly well suited to books and papers about computer hardware and software, though it is by no means limited to these applications. The Version 5.0 release is a complete rewrite of DocBook in RELAX NG. The intent of this rewrite is to produce a schema that is true to the spirit of DocBook while simultaneously removing inconsistencies that have arisen as a natural consequence of DocBook's long, slow evolution. The Technical Committee has taken this opportunity to simplify a number of content models and tighten constraints where RELAX NG makes that possible. The Technical Committee provides the DocBook 5.0 schema in other schema languages, including W3C XML Schema and an XML DTD, but the RELAX NG Schema is now the normative schema..." Appendix A 'The DocBook Media Type' registers a new MIME media type, application/docbook+xml. The charset parameter has identical semantics to the charset parameter of the application/xml media type as specified in RFC 3023 or its successors. For documents labeled as application/docbook+xml, the fragment identifier notation is exactly that for application/xml, as specified in RFC 3023 or its successors..." See the posting.

• [June 08, 2005] "Just Use Media Types?" By Joe Gregorio. From XML.com (June 08, 2005). "[In our 'Resources in the Bookmark Service' example, column two] lists the media types of the representations we will accept at each of our resources. For now we'll assume that application/xbel+xml is a valid media type, even though it is not, in fact, registered. IANA maintains a list of the registered media types. If it's not on that list, it's not really a valid type. If you want to officially register a media type, the IANA has a web page for doing so. For the simple format that we are using as the representation of [user]/config, we will use the media type application/xml. See RFC 3023 and Mark Pilgrim's XML.com article XML on the Web Has Failed to learn why we don't use text/xml... MIME or Media? The first confusion to get out of the way is MIME versus media. In many discussions of HTTP you will see reference to both MIME types and media types. What's the difference? MIME stands for Multipurpose Internet Mail Extensions, which are extensions to RFC 822 that allow the transporting of something besides plain ASCII text. If you are going to allow other stuff--that is, other media besides plain text — then you will need to know what type of media it is. Thus RFC 2054 gave birth to MIME Media-Types. They have spread beyond mail messages — that is, beyond MIME — and that includes HTTP. The list of types is used by both MIME and HTTP, but that doesn't mean the HTTP entities are valid RFC 2045 entities — in fact, they aren't. So where does that leave us? MIME Media-Type is rather awkward, so it's often shortened to MIME type or media type. For our purposes here, they are the same thing..." See also the August 17, 2005 installment.

• [May 04, 2005] "Describing Media Content of Binary Data in XML." Edited by Anish Karmarkar (Oracle) and Ümit Yalçinalp (SAP). W3C Working Group Note. 4-May-2005. "This document addresses the need to indicate the content-type associated with binary element content in an XML document and the need to specify, in XML Schema, the expected content-type(s) associated with binary element content. It is expected that the additional information about the content-type will be used for optimizing the handling of binary data that is part of a Web services message... The document specifies: (1) An attribute (xmime:contentType) to indicate the content-type of an XML element content whose type is xs:base64Binary or xs:hexBinary. The value of the attribute is a valid content-type string (e.g., "text/xml; charset=utf-16"). This attribute specifies the content-type of the element content on which it occurs. (2) A XML Schema annotation attribute (xmime:expectedContentTypes) to indicate, in XML Schema, the expected content-type(s) for an element content whose type is xs:base64Binary or xs:hexBinary. The XML Schema annotation, xmime:expectedContentTypes, specifies the expected range of values for the xmime:contentType attribute and the expected range of content-type for the binary element content. Note that the use of this mechanism, in particular the xmime:contentType attribute, does not require the implementation, in whole or in part, of XML Schema..."

• [January 05, 2005] "XML Media Types." By MURATA Makoto (IBM Tokyo Research Laboratory), Dan Kohn (skymoon ventures), and Chris Lilley (W3C). IETF Network Working Group. Internet Draft, Reference: 'draft-murata-kohn-lilley-xml-01.txt'. 45 pages. This document standardizes three media types — application/xml, application/xml-external-parsed-entity, and application/xml-dtd — for use in exchanging network entities that are related to the Extensible Markup Language (XML) while deprecating text/xml and text/xml-external-parsed-entity. This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from RFC 3023 are deprecation of text/xml and text/xml-external-parsed-entity, the addition of XPointer and XML Base (XBase) as fragment identifiers and base URIs, respectively, and the addition of XML 1.1..." See source

• [November 01, 2004] "MIME Media Type for SAML: 'application/samlassertion+xml'. Announcement from the Internet Engineering Steering Group (IESG). Summary: On November 01, 2004 the IETF Secretariat announced the approval of two requests for registration of MIME media type in the standards tree as outlined in IETF's Media Type Specifications and Registration Procedures: application/samlmetadata+xml and application/samlassertion+xml. Details: The Internet Engineering Steering Group (IESG) has approved a request to register the "application/samlassertion+xml" MIME media type in the standards tree. This media type is a product of the Organization for the Advancement of Structured Information Systems (OASIS). "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0" explicitly specifies use of the application/samlassertion+xml MIME media type. However, it is conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1) might in practice be conveyed using SAMLv2 bindings. Applications which use this media type include potentially any application implementing SAML, as well as those applications implementing specifications based on SAML, e.g. those available from the Liberty Alliance. SAML assertions are explicitly versioned. Relying parties should ensure that they observe assertion version information and behave accordingly... samlassertion+xml registered 15 December 2004, so also samlmetadata+xml. See also the SAML 2.0 CD Review and SAML references.

• [September 2004] "The 'application/soap+xml' Media Type." By Mark A. Baker and Mark Nottingham (BEA). IETF Network Working Group, Request for Comments #3902. September 2004. "SOAP version 1.2 (SOAP) is a lightweight protocol intended for exchange of structured information between peers in a decentralized, distributed environment. It defines an extensible messaging framework that contains a message construct based on XML technologies that can be exchanged over a variety of underlying protocols. This specification defines the media type "application/soap+xml" which can be used to identify SOAP 1.2 message envelopes that have been serialized with XML 1.0. Such serializations are useful as the basis of "wire formats" for SOAP 1.2 Protocol Binding Specifications [W3C.REC-soap12-part1-20030624], or in other situations where an XML serialization of a SOAP envelope is required. The "application/soap+xml" media type explicitly identifies SOAP 1.2 message envelopes that have been serialised with XML 1.0; message envelopes with a different SOAP namespace version or using another XML serialisation MUST NOT use it..."

• [September 2004] application/rdf+xml Media Type Registration. By Aaron Swartz. IETF Network Working Group. Request for Comments: 3870. September 2004. "This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of the Resource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide Web Consortium (W3C) design principles of interoperability, evolution, and decentralization..."

• [July 21, 2004] "XML on the Web Has Failed." By Mark Pilgrim. From XML.com (July 21, 2004). "HTTP has its own method of determining character encoding, that looks like this: Content-Type: text/xml; charset='koi8-r'. So if we're serving XML over HTTP, suddenly we have two places to look for the character encoding. Not a problem if they're both the same, but what if they're not? The answer is simple and universal: when an XML document is served over HTTP, HTTP's method always wins... In both HTTP and XML, the encoding declaration is optional. So now we run into cases where the XML file declares an encoding but the HTTP headers do not or vice-versa. This is actually very common, especially in the case of feeds. According to RFC 3023, every single one of the cached feeds being served as text/xml has a character encoding of us-ascii, not the encoding declared in the XML declaration. How bad is this problem? I recently surveyed 5,096 active feeds from Syndic8.com. The results were astonishing... Over 20% of the feeds I surveyed weren't even served with an XML content type, so they're automatically ill-formed. The vast majority of the rest were served as text/xml with no charset parameter. These could be well-formed, but RFC 3023 says they must be treated as us-ascii. But many contained non-ASCII characters, so they were not well-formed. They were properly encoded, but not properly served. That is, they were encoded in some non-ASCII character encoding that the publisher carefully declared in the XML declaration -- which must be ignored because of the HTTP Content-Type. Remember those wonderful 'off-the-shelf' libraries that are supposed to reject ill-formed XML documents? After all, 'draconian error handling' is one of the fundamental principles of XML. Since determining the actual character encoding of an XML document is a prerequisite for determining its well-formedness, you would think that every XML parser on Earth supported RFC 3023. And you'd be wrong. Dead wrong, in fact. None of the most popular XML parsers support RFC 3023. Many can download XML documents over HTTP, but they don't look at the Content-Type header to determine the character encoding. So they all get it wrong in the case where the feed is served as text/* and the HTTP encoding is different from the XML encoding. Which is the case 90% of the time. Well, 89%, but who's counting? Multiple specifications and circumstances conspire to force 90% of the world into publishing XML as ASCII. But further widespread bugginess counteracts this accidental conspiracy, and allows XML to fulfill its first promise ('publish in any character encoding') at the expense of the second ('draconian error handling will save us')..."

• [June 13, 2004] " application/saml+xml Media Type Registration." By Jeff Hodges. IETF Network Working Group Internet Draft. The SAML specification sets, SAML V1.0 and SAML V1.1, are work products of the OASIS Security Services Technical Committee (SSTC). The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. For example, one can assert that an authentication event pertaining to some subject has occured and convey said assertion to a relying party. This document defines a MIME media type 'application/saml+xml' for use with the XML serialization of SAML (Security Assertion Markup Language) assertions, or other SAML-defined objects.

• [October 15, 2003] "The Atom API." By Mark Pilgrim. From XML.com (October 15, 2003). "Atom is an up-and-coming format for editing, syndicating, and archiving weblogs and other episodic web sites. The final details are still being hashed out. The Atom API was designed with several guiding principles in mind: Well-defined data model, with schemas and everything; doc-literal style web services, not RPC; take full advantage of XML and namespaces; take full advantage of HTTP; secure, so allow no passwords in the clear. The Atom content model can handle more than just XHTML: any MIME type can be expressed (specify it in the @type attribute), and non-XML content (such as HTML or plain text) is simply escaped or put in a CDATA block, with a mode="escaped" attribute on the content element. It can even handle binary content (such as an image), including a base64-encoded representation of the data. So we're back to a document- centric, REST-inspired service again. The Atom API has several other methods beyond add, edit, delete, retrieve, search. It can be used for posting comments on entries, managing users and user preferences, managing categories, managing site templates; eventually it will be usable for everything you can do manually with your weblog through your server's browser-based interface...

• [March 19, 2003] "The Road to XHTML 2.0: MIME Types." By Mark Pilgrim. From XML.com (March 19, 2003). "XHTML's Dirty Little Secret: Let's pretend that you've migrated to XHTML — probably XHTML 1.0 Transitional, unless you're one of those weird geek alpha designers who insist on doing everything with Strict DOCTYPEs. It wasn't that hard, right? Lowercase all your tags; add some end tags to match your <p> and <li> tags; add some slashes to <br /> and <img />; update your DOCTYPE; get on with your life! Let's also pretend, for the sake of argument, that you're validating your spiffy new XHTML markup on a regular basis. You might even have one of those sporty 'valid XHTML' badges lurking at the bottom of pages. Good for you. Now here's a dirty little secret: browsers aren't actually treating your XHTML as XML. Your validated, correctly DOCTYPE'd, completely standards compliant XHTML markup is being treated as if it were still HTML with a few weird slashes in places they don't belong... Why? The answer is MIME types. You can start using the application/xhtml+xml MIME type immediately for your existing XHTML pages, but there are a few serious caveats you need to consider first... It can be difficult to get JavaScript to work properly in both HTML and XML modes. This is a short-term problem (XHTML 2.0 only has one mode: XML), but it's a serious one. If you use any JavaScript on your pages now, you may be better off waiting to make the jump to XHTML 2.0 all at once, rather than migrating slowly... Mozilla is the only major browser that currently handles application/xhtml+xml correctly; for all other browsers, you'll need to serve your XHTML as HTML, using the old text/html MIME type..."

• [February 28, 2002] "Registration of xmlns Media Feature Tag." By Simon St.Laurent and Ian Graham (Emfisys, Bank of Montreal). February 22, 2002; expires: August 23, 2002. Reference: 'draft-stlaurent-feature-xmlns-02.txt.' Posting from Simon St.Laurent: "A new Internet-Draft of '"Registration of xmlns Media Feature Tag' is available... This draft includes clarifications in its introduction, more explicit notice that the order in which features are listed is unimportant, and a new author (Ian Graham). Please direct comments to ietf-xml-mime@imc.org. Abstract: "This document specifies an xmlns Media Feature per RFC 2506 for identifying some or all of the URIs defining XML namespaces in a given XML resource, and the relative importance of these namespaces. This feature is designed primarily for use with the XML Media Types defined in RFC 3023, to provide additional hints as to the processing requirements of a given XML resource." From the Introduction: "MIME Content-Type identifiers have proven very useful as tools for describing homogeneous information. They do not fare as well at describing content which is unpredictably heterogeneous. XML documents may be homogeneous, but are also frequently heterogeneous. It is not difficult to create, for instance, an XHTML document which also contains RDF metadata, MathML equations, hypertext using XLink, XForms,and SVG graphics. XSLT stylesheets routinely include information in both the XSLT namespace and in the namespaces of the literal result elements. RFC 3023 defines a set of XML media types capable of indicating, among other things, a 'most important' type for an XML resource. For example, the content-type header: Content-Type: application/xslt+xml indicates that the data is XML and that it should be processed by an XSLT processor. In XML terminology, this is more or less the same as saying that the XSLT 'namespace' is the 'most important' namespace relevant to the processing of the data... XML data can contain many different 'types' of data, each identified by a namespace URI, and successful processing of a resource may depend on knowledge of some or all of these. For example, using XSLT to produce XHTML output is likely useful only if the recipient is also capable of processing XHTML. Similarly, a program may be better able to choose among a set of XSLT stylesheets if it knows the namespaces of the results they generate, or a renderer may take advantage of foreknowledge to begin setting up components before content actually arrives. Alternatively, processors working with SOAP envelopes may find it useful to know what they will be facing inside the envelope. The Media feature described in this document can provide additional information about some or all of the namespaces relevant to a given XML resource beyond that indicated by the basic content-type. Such a list can provide guidance to a recipient application as to how best to process the XML data it receives..."

• [October 03, 2001] "XML Security for Multipart MIME: Multipart/Signed and Multipart/Encrypted." IETF Network Working Group, Internet Draft. Reference: 'draft-fhirsch-xml-mime-security-00'. October 1, 2001. Expires: April 1, 2002. By Frederick Hirsch (Zolera Systems). Abstract: "This draft defines how XML Digital Signatures and XML Encryption may be used with Multipart MIME security to provide MIME integrity and confidentiality. It extends RFC 1847 by defining application/signature+xml and application/encryption+xml protocols for the Multipart/Signed and Multipart/Encrypted MIME types. Although non-XML content may be signed or encrypted based on XML signing and encryption, additional capabilities are available for XML MIME content. This draft defines a signature transform parameter for partial signing or manipulation of XML MIME content as well as processing rules in addition to the XML Digital Signature and XML Encryption processing rules." From the Introduction: "RFC 1847 defines a general mechanism for security multiparts in MIME, defining the Multipart/Signed and Multipart/Encrypted types. This mechanism uses a protocol parameter to specify the signature or encryption mechanism. Multipart/Signed enables the first MIME part to contain arbitrary MIME content and the second to contain a signature over that content. Common mail applications currently use application/x-pkcs7-signature as the signing protocol, creating a PKCS#7 signature in the signature part. Multipart/Encrypted uses the first part to contain encryption control information, and the second part encrypted content. An alternative to Multipart/Encrypted is to pass a single MIME part containing encrypted content using using application/x-pkcs7-mime, as done by common mail applications. XML DIGITAL SIGNATURE and XML ENCRYPTION recommendations enable signing and encryption of arbitary content as well as providing advanced support for XML content. This includes the ability to sign or encrypt portions of XML, reference multiple objects in a signature and include metadata information with signed or encrypted content. XML signatures support multiple signatures, useful when content is routed for approvals. Both XML Signatures and Encryption support inclusion of the signature or encrypted content in the orginal XML document, creating a close binding. Signatures may also be separate from the signed content, especially useful when the content is large or binary and would interfere with XML processing of the signature. Likewise, encrypted cipherdata may be included in an XML encrypted element or managed separately. Combining the XML security mechanisms with Multipart MIME security enables MIME applications to benefit from XML security as well as enabling XML security to use a defined mechanism for handling multiple parts. This draft extends the existing Multipart MIME security mechanism by defining two new protocol parameters to be used with RFC 1847, application/signature+xml and application/encryption+xml. These names follow the XML naming convention defined in RFC 3023, XML MEDIA TYPES. This draft defines these parameters and a minimal set of processing rules..." Also in text format.

• [January 19, 2001] XML Media Types." Network Working Group, Request for Comments: 3023. January 2001. By MURATA Makoto, Simon St.Laurent, and Dan Kohn. Abstract: "This document standardizes five new media types: (1) text/xml, (2) application/xml, (3) text/xml-external-parsed-entity, (4) application/xml- external-parsed-entity, and (5) application/xml-dtd. [They are designed] for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix +xml) for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from RFC 2376 are: (1) the addition of text/xml- external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the +xml suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of 'utf-16le' and 'utf-16be'." Discussion: "XML entities are currently exchanged on the World Wide Web, and XML is also used for property values and parameter marshalling by the WebDAV [RFC2518] protocol for remote web authoring. Thus, there is a need for a media type to properly label the exchange of XML network entities. Although XML is a subset of the Standard Generalized Markup Language (SGML) ISO 8879 [SGML], which has been assigned the media types text/sgml and application/sgml, there are several reasons why use of text/sgml or application/sgml to label XML is inappropriate. First, there exist many applications that can process XML, but that cannot process SGML, due to SGML's larger feature set. Second, SGML applications cannot always process XML entities, because XML uses features of recent technical corrigenda to SGML. Third, the definition of text/sgml and application/sgml in [RFC1874] includes parameters for SGML bit combination transformation format (SGML- bctf), and SGML boot attribute (SGML-boot). Since XML does not use these parameters, it would be ambiguous if such parameters were given for an XML MIME entity. For these reasons, the best approach for labeling XML network entities is to provide new media types for XML. Since XML is an integral part of the WebDAV Distributed Authoring Protocol, and since World Wide Web Consortium Recommendations have conventionally been assigned IETF tree media types, and since similar media types (HTML, SGML) have been assigned IETF tree media types, the XML media types also belong in the IETF media types tree. Similarly, XML will be used as a foundation for other media types, including types in every branch of the IETF media types tree. To facilitate the processing of such types, media types based on XML, but that are not identified using text/xml or application/xml, should be named using a suffix of +xml as described in Section 7. This will allow XML-based tools -- browsers, editors, search engines, and other processors -- to work with all XML-based media types..." [cache]

• [May 05, 2001] "The 'application/xhtml+xml' Media Type." By Mark A. Baker. IETF I-D 'draft-baker-xhtml-media-reg-01.txt'. [W3C note:] "An updated Internet Draft of the 'application/xhtml+xml' media type registration has been published. 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'. Note that while the revision number still says -01, this is the third draft which should have been numbered as -02. Please send comments to www-html@w3.org (archive)." [cache]

• [January 19, 2001] "The 'application/xhtml+xml' Media Type." IETF 'draft-baker-xhtml-media-reg-00.txt'. By Mark A. Baker (Sun Microsystems Inc.). "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. 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 with archives at http://lists.w3.org/Archives/Public/www-html/... 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. The HTML WG expects to publish further documentation on this subject, including but not limited to, information about rules for which documents should and should not be described with this new media type, and further information about recognizing XHTML documents..." [cache]

• [April 24, 2001] "Media Type for Resource Description Framework (RDF)." Draft. By Aaron Swartz. [Reference: 'Not-Yet-Internet-Draft'. Post to RDF Interest list: I've taken Dan Connolly's rough draft and tried to put it together into a media type proposal...] Abstract: "This memorandum describes a media type (application/rdf+xml) for use with the XML serialization of the Resource Description Framework (RDF). RDF is currently used for semantically-meaningful data on the World Wide Web, and is meant to help bring about the creation of a "Semantic Web" with semantically-meaningful information which machines are better able to process." Details: "The World Wide Web Consortium has issued Resource Description Framework (RDF) Model and Syntax Specification. To enable the exchange of RDF network entities, serialized using XML, this document registers the application/rdf+xml media type. Resource Description Framework (RDF) is a foundation for transmitting and processing semantically-meaningful data on the World Wide Web. It emphasizes facilities to enable automated processing of Web resources. While the RDF model can be serialized in a number of different ways, the media type registered by this document only deals with the XML serialization. Future registrations are expected to deal with alternate serializations. Because RDF is a format for semantically-meaningful information, it is important to note that transmission of RDF via HTTP, SMTP or some similar protocol, means that the sender asserts the content of the RDF document..."

• [August 24, 2000] XML Media Types [draft-murata-xml-07.txt]. Internet-Draft, Network Working Group. August 9, 2000. "This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from RFC 2376 are: (1) the addition of text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the '+xml' suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of 'utf-16le' and 'utf-16be'. [...] Since XML is an integral part of the WebDAV Distributed Authoring Protocol, and since World Wide Web Consortium Recommendations have conventionally been assigned IETF tree media types, and since similar media types (HTML, SGML) have been assigned IETF tree media types, the XML media types also belong in the IETF media types tree. Similarly, XML will be used as a foundation for other media types, including types in every branch of the IETF media types tree. To facilitate the processing of such types, media types based on XML, but that are not identified using text/xml or application/xml, SHOULD be named using a suffix of '+xml' as described in Section 7. This will allow XML-based tools -- browsers, editors, search engines, and other processors -- to work with all XML-based media types." [cache]

• [July 05, 2000] XML Media Types. Network Working Group Internet-Draft 'draft-murata-xml-06.txt', June 15, 2000. "This document standardizes five media types related to XML MIME entities: text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Registration information for these media types is described in the sections below... Major differences from RFC 2376 are (1) the addition of text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the '+xml' suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of 'utf-16le' and 'utf-16be'." [cache]

• [June 19, 2000] MURATA Makoto (IBM Tokyo Research Laboratory) recently announced the release of a revised version of the Internet Draft for XML Media Types . Reference: Network Working Group, Internet-Draft 'draft-murata-xml-05.txt', May 2000. By MURATA Makoto, Simon St.Laurent, and Daniel Kohn. Abstract: This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains." Some changes from the previous version: "added XML, MIME, and this document definitions for entity. Added new invalid example. Fixed magic number by adding 'l' to UTF-16 examples. Added IANA considerations. Removed extraneous notes. Made clear that examples are not registrations. Mention the standalone declaration. Removed normative references to XML Base, XLink, and XPointer, since they are still working drafts. Fragment identifiers are still undefined. Mechanisms for embedding the base URI are still undefined. Strengthened and filled out Referencing section, and moved to section 7.1." [cache]

• [November 17, 1999] A posting from MURATA Makoto (Fuji Xerox Information Systems) announces the availability of a revised IETF Internet Draft on "XML Media Types." Reference: draft-murata-xml-01.txt. IETF [Network Working Group] Internet-Draft, November 8, 1999. By MURATA Makoto and Simon St.Laurent. Makoto writes: "On the basis of [mailing list discussions] this version ['draft-murata-01' (November 8, 1999)] clarifies when text/xml is more appropriate than application/xml and vice versa. Non-XPointer fragment identifiers for XML vocabularies like SVG and SMIL requires further discussion." Abstract: "This document proposes three new media subtypes, text/xml, application/xml, and application/xml-dtd, for use in exchanging network entities which are conforming Extensible Markup Language (XML). This document also proposes a convention for naming media subtypes outside of these three subtypes when those subtypes represent XML entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains." [local archive copy]

• [September 29, 1999] An IETF Internet Draft from the Network Working Group was published recently on the topic of XML Media Types. References: Internet-Draft September 24, 1999, draft-murata-xml-00.txt, by MURATA Makoto and Simon St. Laurent. Abstract: "This document proposes three new media subtypes, text/xml, application/xml, and application/xml-dtd, for use in exchanging network entities which are conforming Extensible Markup Language (XML). . ." [local archive copy]

• [August 5, 1998] In July 1998, the Internet Engineering Task Force (IETF) Network Working Group has published the document on XML Media Types as Internet Informational Request for Comments 2376 . This RFC officially makes text/xml and application/xml Internet media types. A version of the document in HTML format provides links to related RFCs. In this connection, the Internet Assigned Numbers Authority (IANA) has added text/xml and application/xml to the list of registered media types; see the IANA list of media 'Content Types and Subtypes...'. The RFC 2376 abstract: "This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains." The editors have requested that references to this RFC be created by resource providers to promote compliance, since it "has significant discussion on i18n and security issues." The document editors are E. James Whitehead, Jr. (Department of Information and Computer Science, University of California, Irvine) and Murata Makoto (Fuji Xerox Information Systems). The document credits Chris Newman, Yaron Y. Goland, and Dan Connolly, along with "members of the W3C XML Working Group and XML Special Interest group [who] have made significant contributions to this document, and the authors would like to specially recognize James Clark, Martin Duerst, Rick Jelliffe, Gavin Nicol for their many thoughtful comments."

• [April 12, 1999] Murata Makoto (Fuji Xerox Information Systems) announced a new 'ietf-xml-mime' mailing list for discussing MIME types for XML. The principal reference document for the discussion group is XML Media Types (IETF Network Working Group RFC 2376), authored by E. James Whitehead and Murata Makoto. To subscribe to the list, send the message 'subscribe' in the body of an email message to ietf-xml-mime-request@imc.org. Messages posted to the forum are archived. Other subscription information is available via the Internet Mail Consortium Web server.

• [August 5, 1998] RFC 2376 - [local archive copy]; and: MEDIA TYPES - Content Types and Subtypes, etc. From IANA. [local archive copy, 980805].

• [July 18, 1998] Jim Whitehead indicated in a post of July 8, 1998 that the IETF has approved the media types text/xml and application/xml. The draft is to be sent to the RFC editor "who will do some formatting tweaks, and will assign it an RFC number before releasing it as part of the RFC series. But this is just mechanical -- the draft has been approved by the IESG." The IESG contact persons are Keith Moore and Patrik Faltstrom.

• [June 05, 1998] Release of a new Internet-Draft for "XML Media Types," by E. J. Whitehead, Jr. (UC Irvine) and M. Murata (Fuji Xerox Information Systems). Reference: draft-whitehead-mime-xml-04, May 31, 1998. Abstract: "This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains." [local archive copy]

• [June 05, 1998] Note from Jim Whitehead on the "XML Media Types" version 04 release. Posted to the W3C SIG.

• [May 26, 1998] Release of a new Internet-Draft for "XML Media Types," by E. J. Whitehead, Jr. (UC Irvine) and M. Murata (Fuji Xerox Information Systems). Reference: draft-whitehead-mime-xml-03, May 15, 1998. Abstract: "This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conformant Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, and are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains." [local archive copy]

• [May 11, 1998] See the preceding item. Release of the Internet Draft XML Media Types, authored by E. J. Whitehead, Jr. (UC Irvine) and M. Murata (Xerox Information Systems). Document: 'draft-whitehead-mime-xml-02', May 8, 1998. [local archive copy]

• [May 08, 1998] See the preceding [two] items. "Work in progress": publication of an Internet Draft "The text/xml Media Type" [draft-whitehead-mime-xml-00], by E. J. Whitehead, Jr. (UC Irvine). April 24, 1998, 17:43. Perhaps under current revision. alt FTP location]; [local archive copy]. See: Version 01, May 3, 1998; [local archive copy]

• Edward Levinson, "Exchanging SGML Documents Using Internet Mail and MIME." In Computer Standards & Interfaces 18/1 (January 1996) 93-102 (with 11 references). See the bibliographic entry for the abstract and related documents.

• See also: Don Stinchfield, Using Catalogs and MIME to Exchange SGML Documents . MIMESGML Working Group, INTERNET-DRAFT. Providence, RI: EBT and MIMESGML Working Group, IETF, 1995. "This draft proposes a standard for exchanging SGML documents over the World Wide Web using catalogs and MIME. This draft extends SGML Open's definition of catalogs. . ." See the bibliographic entry for the full abstract and online availability.

• Cf. XML Directory - an Internet Directory of XML websites, with XML-ized news. By Duane Nickull.

• See the database entry: MIME-SGML (Multipurpose Internet Mail Extensions).

Document URI: http://xml.coverpages.org/xmlMediaMIME.html — Legal stuff
Robin Cover, Editor: robin@oasis-open.org