rfc3023.txt

RFC3023:XML Media Types

   Person and email address for further information: Same as Section
      3.1.

   Intended usage: COMMON

   Author/Change controller: Same as Section 3.1.

3.4 Application/xml-external-parsed-entity Registration

   MIME media type name: application

   MIME subtype name: xml-external-parsed-entity

   Mandatory parameters: none

   Optional parameters: charset

      The charset parameter of application/xml-external-parsed-entity is
      handled the same as that of application/xml as described in
      Section 3.2.

   Encoding considerations: Same as Section 3.2.

   Security considerations: See Section 10.

   Interoperability considerations: Same as those for text/xml-
      external-parsed-entity as described in Section 3.3.

   Published specification: Same as text/xml as described in Section
      3.1.



Murata, et al.              Standards Track                    [Page 12]

RFC 3023                    XML Media Types                 January 2001


   Applications which use this media type: Same as Section 3.1.

   Additional information:

      Magic number(s): Same as Section 3.1.

      File extension(s): .xml or .ent

      Macintosh File Type Code(s): "TEXT"

   Person and email address for further information: Same as Section
      3.1.

   Intended usage: COMMON

   Author/Change controller: Same as Section 3.1.

3.5 Application/xml-dtd Registration

   MIME media type name: application

   MIME subtype name: xml-dtd

   Mandatory parameters: none

   Optional parameters: charset

      The charset parameter of application/xml-dtd is handled the same
      as that of application/xml as described in Section 3.2.

   Encoding considerations: Same as Section 3.2.

   Security considerations: See Section 10.

   Interoperability considerations: XML DTDs have proven to be
      interoperable by DTD authoring tools and XML browsers, among
      others.

   Published specification: Same as text/xml as described in Section
      3.1.

   Applications which use this media type: DTD authoring tools handle
      external DTD subsets as well as external parameter entities.  XML
      browsers may also access external DTD subsets and external
      parameter entities.






Murata, et al.              Standards Track                    [Page 13]

RFC 3023                    XML Media Types                 January 2001


   Additional information:

      Magic number(s): Same as Section 3.1.

      File extension(s): .dtd or .mod

      Macintosh File Type Code(s): "TEXT"

   Person and email address for further information: Same as Section
      3.1.

   Intended usage: COMMON

   Author/Change controller: Same as Section 3.1.

3.6 Summary

   The following list applies to text/xml, text/xml-external-parsed-
   entity, and XML-based media types under the top-level type "text"
   that define the charset parameter according to this specification:

   o  Charset parameter is strongly recommended.

   o  If the charset parameter is not specified, the default is "us-
      ascii".  The default of "iso-8859-1" in HTTP is explicitly
      overridden.

   o  No error handling provisions.

   o  An encoding declaration, if present, is irrelevant, but when
      saving a received resource as a file, the correct encoding
      declaration SHOULD be inserted.

   The next list applies to application/xml, application/xml-external-
   parsed-entity, application/xml-dtd, and XML-based media types under
   top-level types other than "text" that define the charset parameter
   according to this specification:

   o  Charset parameter is strongly recommended, and if present, it
      takes precedence.

   o  If the charset parameter is omitted, conforming XML processors
      MUST follow the requirements in section 4.3.3 of [XML].








Murata, et al.              Standards Track                    [Page 14]

RFC 3023                    XML Media Types                 January 2001


4. The Byte Order Mark (BOM) and Conversions to/from the UTF-16 Charset

   Section 4.3.3 of [XML] specifies that XML MIME entities in the
   charset "utf-16" MUST begin with a byte order mark (BOM), which is a
   hexadecimal octet sequence 0xFE 0xFF (or 0xFF 0xFE, depending on
   endian).  The XML Recommendation further states that the BOM is an
   encoding signature, and is not part of either the markup or the
   character data of the XML document.

   Due to the presence of the BOM, applications that convert XML from
   "utf-16" to a non-Unicode encoding MUST strip the BOM before
   conversion.  Similarly, when converting from another encoding into
   "utf-16", the BOM MUST be added after conversion is complete.

   In addition to the charset "utf-16", [RFC2781] introduces "utf-16le"
   (little endian) and "utf-16be" (big endian) as well.  The BOM is
   prohibited for these charsets.  When an XML MIME entity is encoded in
   "utf-16le" or "utf-16be", it MUST NOT begin with the BOM but SHOULD
   contain an encoding declaration.  Conversion from "utf-16" to "utf-
   16be" or "utf-16le" and conversion in the other direction MUST strip
   or add the BOM, respectively.

5. Fragment Identifiers

   Section 4.1 of [RFC2396] notes that the semantics of a fragment
   identifier (the part of a URI after a "#") is a property of the data
   resulting from a retrieval action, and that the format and
   interpretation of fragment identifiers is dependent on the media type
   of the retrieval result.

   As of today, no established specifications define identifiers for XML
   media types.  However, a working draft published by W3C, namely "XML
   Pointer Language (XPointer)", attempts to define fragment identifiers
   for text/xml and application/xml.  The current specification for
   XPointer is available at http://www.w3.org/TR/xptr.

6. The Base URI

   Section 5.1 of [RFC2396] specifies that the semantics of a relative
   URI reference embedded in a MIME entity is dependent on the base URI.
   The base URI is either (1) the base URI embedded in the MIME entity,
   (2) the base URI of the encapsulating MIME entity, (3) the URI used
   to retrieve the MIME entity, or (4) the application-dependent default
   base URI, where (1) has the highest precedence.  [RFC2396] further
   specifies that the mechanism for embedding the base URI is dependent
   on the media type.





Murata, et al.              Standards Track                    [Page 15]

RFC 3023                    XML Media Types                 January 2001


   As of today, no established specifications define mechanisms for
   embedding the base URI in XML MIME entities.  However, a Proposed
   Recommendation published by W3C, namely "XML Base", attempts to
   define such a mechanism for text/xml, application/xml, text/xml-
   external-parsed-entity, and application/xml-external-parsed-entity.
   The current specification for XML Base is available at
   http://www.w3.org/TR/xmlbase.

7. A Naming Convention for XML-Based Media Types

   This document recommends the use of a naming convention (a suffix of
   '+xml') for identifying XML-based MIME media types, whatever their
   particular content may represent.  This allows the use of generic XML
   processors and technologies on a wide variety of different XML
   document types at a minimum cost, using existing frameworks for media
   type registration.

   Although the use of a suffix was not considered as part of the
   original MIME architecture, this choice is considered to provide the
   most functionality with the least potential for interoperability
   problems or lack of future extensibility.  The alternatives to the '
   +xml' suffix and the reason for its selection are described in
   Appendix A.

   As XML development continues, new XML document types are appearing
   rapidly.  Many of these XML document types would benefit from the
   identification possibilities of a more specific MIME media type than
   text/xml or application/xml can provide, and it is likely that many
   new media types for XML-based document types will be registered in
   the near and ongoing future.

   While the benefits of specific MIME types for particular types of XML
   documents are significant, all XML documents share common structures
   and syntax that make possible common processing.

   Some areas where 'generic' processing is useful include:

   o  Browsing - An XML browser can display any XML document with a
      provided [CSS] or [XSLT] style sheet, whatever the vocabulary of
      that document.

   o  Editing - Any XML editor can read, modify, and save any XML
      document.

   o  Fragment identification - XPointers (work in progress) can work
      with any XML document, whatever vocabulary it uses and whether or
      not it uses XPointer for its own fragment identification.




Murata, et al.              Standards Track                    [Page 16]

RFC 3023                    XML Media Types                 January 2001


   o  Hypertext linking - XLink (work in progress) hypertext linking is
      designed to connect any XML documents, regardless of vocabulary.

   o  Searching - XML-oriented search engines, web crawlers, agents, and
      query tools should be able to read XML documents and extract the
      names and content of elements and attributes even if the tools are
      ignorant of the particular vocabulary used for elements and
      attributes.

   o  Storage - XML-oriented storage systems, which keep XML documents
      internally in a parsed form, should similarly be able to process,
      store, and recreate any XML document.

   o  Well-formedness and validity checking - An XML processor can
      confirm that any XML document is well-formed and that it is valid
      (i.e., conforms to its declared DTD or Schema).

   When a new media type is introduced for an XML-based format, the name
   of the media type SHOULD end with '+xml'.  This convention will allow
   applications that can process XML generically to detect that the MIME
   entity is supposed to be an XML document, verify this assumption by
   invoking some XML processor, and then process the XML document
   accordingly.  Applications may match for types that represent XML
   MIME entities by comparing the subtype to the pattern '*/*+xml'.  (Of
   course, 4 of the 5 media types defined in this document -- text/xml,
   application/xml, text/xml-external-parsed-entity, and
   application/xml-external-parsed-entity -- also represent XML MIME
   entities while not conforming to the '*/*+xml' pattern.)

      NOTE: Section 14.1 of HTTP[RFC2616] does not support Accept
      headers of the form "Accept: */*+xml" and so this header MUST NOT
      be used in this way.  Instead, content negotiation[RFC2703] could
      potentially be used if an XML-based MIME type were needed.

   XML generic processing is not always appropriate for XML-based media
   types.  For example, authors of some such media types may wish that
   the types remain entirely opaque except to applications that are
   specifically designed to deal with that media type.  By NOT following
   the naming convention '+xml', such media types can avoid XML-generic
   processing.  Since generic processing will be useful in many cases,
   however -- including in some situations that are difficult to predict
   ahead of time -- those registering media types SHOULD use the '+xml'
   convention unless they have a particularly compelling reason not to.

   The registration process for these media types is described in
   [RFC2048].  The registrar for the IETF tree will encourage new XML-
   based media type registrations in the IETF tree to follow this
   guideline.  Registrars for other trees SHOULD follow this convention



Murata, et al.              Standards Track                    [Page 17]

RFC 3023                    XML Media Types                 January 2001


   in order to ensure maximum interoperability of their XML-based
   documents.  Similarly, media subtypes that do not represent XML MIME