Registration of xmlns Media Feature Tag
Network Working GroupS. St.Laurent
Internet-DraftO'Reilly & Associates
Expires: August 23, 2002I. Graham
 Emfisys, Bank of Montreal
 February 22, 2002

Registration of xmlns Media Feature Tag

Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on August 23, 2002.

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved.


This document specifies an xmlns Media Feature per RFC 2506[5] for identifying some or all of the URIs defining XML namespaces[14] 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[12], to provide additional hints as to the processing requirements of a given XML resource.


Table of Contents


1. 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[26] document which also contains RDF[19] metadata, MathML[20] equations, hypertext using XLink[22], XForms[25],and SVG[21] graphics. XSLT[17] stylesheets routinely include information in both the XSLT namespace and in the namespaces of the literal result elements.

RFC 3023[12] 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.

This content-type statement does not imply that there is only one namespace associated with the resource, nor does it is necessarily identify the namespace of the root element of the resource. Indeed, this example content-type could easily be associated with a resource whose root element is in the XHTML namespace, but where the resource requires processing by an XSLT processor to generate XHTML output suitable for display.

Moreover, 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[18] 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.

It is important to recall that, like all MIME header data, the namespace information in a Media feature is specific to a given application context. Thus the same XML resource, delivered to different applications, may have different namespace information associated with it.

Applications faced with "unknown" XML namespaces may want to attempt to download RDDL[16] documents to collect information on how to process them. Applications may also choose to reject documents containing unknown namespaces.


2. Registration

Media feature tag name:
ASN.1 identifier associated with feature tag:
New assignment by IANA
Summary of the media feature indicated by this feature tag:
This feature tag is used to identify XML namespaces either contained in a given document or processable by a given recipient.
Values appropriate for use with this feature tag:
The feature tag must contain a String conforming to the RFC 2396[4] syntax for URI references, as restricted by plenary[15]. URI references must be absolute. Alternatively, in place of a URI, the empty string may be used to represent "no default namespace" as defined in Section 5.2 of Namespaces in XML[14]
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:
Any protocol that exchanges XML-formatted information in MIME encapsulation
Examples of typical use:

For an XHTML document containing SVG, MathML, SMIL, and XLink content:

     Content-Type: application/xhtml+xml
     Content-features: (|

Note that order is not important in this list.

Or, using multiple Content-features headings:

     Content-Type: application/xhtml+xml
     Content-features: (xmlns="")
     Content-features: (xmlns="")
     Content-features: (xmlns="")
     Content-features: (xmlns="")
     Content-features: (xmlns="")

Again, note that order is not important in this list.

For an application indicating that it accepts SMIL, XHTML, or SVG content:

  (| (xmlns="");q=1.0
Applications that want to specify combinations of namespaces they consider acceptable may do so using combinations of & and |, and may also mix the xmlns feature with other media features, as described in RFC 2533[6].
Related standards or documents:
Namespaces in XML[14], XML Media Types[12]
Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms:
Interoperability considerations:
Security considerations:
If it is known that there is a security bug in the handling of a particular namespace in a particular environment, knowing that a device can accept that namespace may slightly help an attacker.
Additional information:
Name(s) & email address(es) of person(s) to contact for further information:
Simon St.Laurent <>
Intended usage
Author/Change controller:


3. Registration issues

3.1 General interest to the Internet Community

While XML processing may generally seem like something specific to the XML community, XML's reach is growing rapidly. XML is now in regular use for Web Services (XML-RPC, SOAP), vector graphics (SVG), mathematics (MathML), instant messaging (Jabber), information transformation (XSLT), and a wide variety of other projects.

Because of this general and growing interest, this document recommends registering the 'xmlns' feature in the IETF tree per RFC 2506[5].

3.2 Namespaces as Media Features

Namespaces are not strictly presentational media information, as are many of the previously registered media features. They do, however, define the set of tools used to present information, much as the type[10], charset[11], and language[11] media features do.

3.3 Relation to MIME Media Types

While namespaces, especially on the root element, are often linked to a particular MIME Media Type, these connections are not always direct.

There are well-known cases (especially in XSLT) where the root element's relation to the rest of the document is misleading. A commonly-used XSLT practice uses a shell document with stylesheet instructions nested inside. Applications which only look at the namespace of the root document will encounter trouble (whether they notice it or not) in rendering the document as expected by its designers and probable readers.

There are other cases where the root element's relation to the rest of the document is tenuous or even irrelevant. A collection of rules for processing namespaces[28], for one example, can contain rules in various namespaces, and can even reside quite naturally in documents whose root element has nothing explicit to do with namespace processing.

In these cases, some mechanism must determine the overall MIME Media Type. The list of xmlns Media Features can supplement the Media Type, but applications should look to the Media Type initially.

3.4 Security Considerations

Security considerations for this registration are listed in the registration above. Considerations for Media Features in general are described in RFC 2506.

3.5 IANA Considerations

Section 2 of this document calls for the registration of a media feature tag, per RFC 2506.



[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[3] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999.
[6] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[7] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[8] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[9] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[10] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000.
[11] Hoffman, P., "Registration of Charset and Languages Media Features Tags", RFC 2987, November 2000.
[12] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[13] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", World Wide Web Consortium Recommendation REC-xml, February 1998.
[14] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", World Wide Web Consortium Recommendation REC-xml-names, January 1999.
[15] Connolly, D., "W3C XML Plenary Decision on relative URI References In namespace declarations", September 2000.
[16] Borden, J. and T. Bray, "Resource Directory Description Language (RDDL)", June 2001.
[17] Clark , J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation XSLT, November 1999.
[18] Mitra , N., "SOAP Version 1.2", World Wide Web Consortium Working Draft SOAP, December 2001.
[19] Lassila, O. and R. Swick, "Resource Description Framework (RDF) Model and Syntax Specification", World Wide Web Consortium Recommendation RDF-syntax, February 1999.
[20] Carlisle, D., Ion, P., Miner, R. and N. Poppelier, "Mathematical Markup Language 2.0 (MathML)", World Wide Web Consortium Recommendation MathML, February 2001.
[21] Ferraiolo, J., "Scalable Vector Graphics (SVG)", World Wide Web Consortium Working Draft SVG, August 1999.
[22] DeRose, S., Maler, E. and D. Orchard, "XML Linking Language (XLink)", World Wide Web Consortium Recommendation XLink, June 2001.
[23] DeRose, S., Daniel Jr., R. and E. Maler, "XML Pointer Language (XPointer)", World Wide Web Consortium Working Draft XPointer, July 1999.
[24] Marsh, J., "XML Base", World Wide Web Consortium Recommendation XML Base, June 2000.
[25] Dubinko, M., Dietl, J., Klotz, L., Merrick, R. and T. Raman, "XForms 1.0", World Wide Web Consortium Working Draft XForms, January 2002.
[26] Pemberton, S. and et al, "XHTML 1.0: The Extensible HyperText Markup Language", World Wide Web Consortium Recommendation REC-xhtml1, January 2000.
[27] Altheim, M. and S. McCarron, "XHTML 1.1: Module-based XHTML", World Wide Web Consortium Recommendation REC-xhtml11, January 2000.
[28] St.Laurent, S., "Namespaces for Namespace-based Processing", September 2001.


Authors' Addresses

  Simon St.Laurent
  O'Reilly & Associates
  1259 Dryden Road
  Ithaca, New York 14850
  Ian Graham
  Emfisys, Bank of Montreal
  120 Bloor Street E, 5th Floor
  Toronto, Ontario M4W 3X1


Appendix A. Acknowledgements

Thanks to Graham Klyne, Jonathan Borden, Murata Makoto, Edd Dumbill, and Eric van der Vlist for editorial and technical comments on an early version of this document. Their help does not, of course, constitute endorsement.

Additional thanks to Mark Baker, Don Box, Tim Bray, Paul Prescod, Ian Graham, G. Ken Holman, Mark Nottingham, and Len Bullard for suggestions and discussion.


Appendix B. Revision History

00 - First version.

01 - Fixed typos in abstract and introduction. Restored colons to examples. Added XForms to introduction. Added section "Relation to MIME Media Types". Added references for XForms and Namespaces for Namespace-based Processing.

02 - Made it explicit that sequence does not matter in Content-features headers. Added language permitting "no default namespace" as does Namespaces in XML. Tightened up description of XSLT stylesheet contents. Reorganized front-matter per suggestions from Ian Graham. Added Ian as co-author.

[To be deleted before publication.]


Full Copyright Statement