Network Working Group M. Mealling
Request for Comments: 3688 VeriSign, Inc.
BCP: 81 January 2004
Category: Best Current Practice
The IETF XML Registry
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document describes an IANA maintained registry for IETF
standards which use Extensible Markup Language (XML) related items
such as Namespaces, Document Type Declarations (DTDs), Schemas, and
Resource Description Framework (RDF) Schemas.
Over the past few years, the Extensible Markup Language (XML)
[W3C.REC-xml] has become a widely used method for data markup. There
have already been several IETF Working Groups that have produced
standards that define XML Document Type Definitions (DTDs), XML
Namespaces [W3C.REC-xml-names], and XML Schemas [W3C.REC-xmlschema-
1]. Each one of these technologies uses Uniform Resource Identifiers
(URIs) [RFC2396] and other standardized identifiers to identify
For example, while it has been the practice within some standards
that use Document Type Definitions (DTDs) to forego the use of the
PUBLIC identifiers in favor of 'well known' SYSTEM identifiers, it
has proven to be more trouble than its worth to attempt to
standardize SYSTEM identifiers. The result is that several IETF
standards that have simply created non-resolvable URIs in order to
simply identify but not resolve the DTD for some given XML document.
This document seeks to standardize and improve these practices by
creating an IANA maintained registry of XML element identifiers so
that document authors and implementors have a well maintained and
Mealling Best Current Practice [Page 1]RFC 3688 The IETF XML Registry January 2004
authoritative location for their XML elements. As part of this
standard, the IANA will maintain:
o the public representation of the document,
o the URI for the elements if one is provided at the time of
o a registry of Public Identifiers as URIs.
In the case where the registrant does not request a particular URI,
the IANA will assign it a Uniform Resource Name (URN) that follows
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
3. Registerable Documents3.1. The Assigned/Registered URI
All elements (except PUBLIC identifiers) in this registry will
require a URI in order to be registered. If the registrant wishes to
have a URI assigned, then a URN of the form
will be assigned where <class> is the type of the document being
registered (see below). <id> is a unique id generated by the IANA
based on any means the IANA deems necessary to maintain uniqueness
and persistence. NOTE: in order for a URN of this type to be
assigned, the item being registered MUST have been through the IETF
consensus process. Basically, this means that it must be documented
in a RFC. The RFC 3553 [RFC3553] URN registration template is found
in Section 6.
The IANA will also maintain a file server available via at least HTTP
and FTP that contains all of the registered elements in some publicly
accessible file space in the same way that all of the IANA's
registered elements are available via
http://www.iana.org/assignments/. While the directory structure of
this server is up to the IANA, it is suggested that the files be
organized by the <class> and the individual files have the <id> as
Mealling Best Current Practice [Page 2]RFC 3688 The IETF XML Registry January 2004
Implementors are warned that they should not programatically rely on
those resources being available or the directory structure remaining
static for any reason. It is explicitly recognized that some
software tools attempt to download DTDs, schema, etc., 'on the fly'