RFC 3688

The IETF XML Registry

📅 published January 2004, from ietf

The IETF XML Registry 🎀

Okay bestie, here's the title-block tea ☕ This is RFC 3688, called The IETF XML Registry, from the Network Working Group. M. Mealling at VeriSign, Inc. wrote it. It's a Best Current Practice (BCP 81), dated January 2004, and the title block doesn't list anything it obsoletes or updates. 💅

Status of this Memo 📌

This one specifies an Internet Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements. Distribution of this memo is unlimited. 🫶

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

Abstract ✨

This doc describes an IANA maintained registry for IETF standards that use Extensible Markup Language (XML) related items, like Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. It's giving organized 🗂️

1. Introduction 🦋

Okay so over the past few years, Extensible Markup Language (XML) [W3C.REC-xml] has become a seriously popular way to do data markup 📈 Several IETF Working Groups have already made standards that define XML Document Type Definitions (DTDs), XML Namespaces [W3C.REC-xml-names], and XML Schemas [W3C.REC-xmlschema-1]. Every one of these technologies uses Uniform Resource Identifiers (URIs) [RFC2396] and other standardized identifiers to name its parts. 🧚

Here's where it gets messy 😭 Some standards that use DTDs skip PUBLIC identifiers and go for "well known" SYSTEM identifiers instead. Honestly, trying to standardize SYSTEM identifiers turned out to be more trouble than it was worth. So several IETF standards just made up URIs that don't resolve, which means they name the DTD for a given XML document but never actually fetch it. Iconic behavior from the URI world, not it 🙈

This document wants to fix that by setting up an IANA maintained registry of XML element identifiers. That way, document authors and implementors have one well maintained, authoritative place for their XML elements. 💖 As part of this standard, IANA will maintain:

  • the public representation of the document,
  • the URI for the elements if one is provided at the time of registration,
  • a registry of Public Identifiers as URIs.

If the registrant doesn't ask for a particular URI, IANA will give it a Uniform Resource Name (URN) that follows [RFC3553]. 🎀

2. Terminology 📖

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 [RFC2119]. These are the official keywords, so read them carefully 🔥

3. Registerable Documents 📚

3.1. The Assigned/Registered URI 🔗

Every element in this registry (except PUBLIC identifiers) will require a URI before it can be registered. If the registrant wants a URI assigned, they get a URN of this form:

urn:ietf:params:xml:<class>:<id>

<class> is the type of the document being registered (more on that below), and <id> is a unique id that IANA generates by whatever means it deems necessary to keep things unique and persistent. ✨

NOTE: For a URN of this type to be assigned, the item being registered MUST have been through the IETF consensus process. Basically, that means it has to be documented in an RFC. The RFC 3553 [RFC3553] URN registration template is in Section 6. 🫶

IANA will also run a file server that's available via at least HTTP and FTP. It holds all the registered elements in some publicly accessible file space, the same way all of IANA's registered elements show up at http://www.iana.org/assignments/. The directory structure is up to IANA, but it's suggested that files get organized by <class>, with each individual file named by its <id>. 🗂️

Now the warning bit ⚠️ Implementors should not programatically rely on those resources being available, or on the directory structure staying the same, for any reason. Some software tools try to download DTDs, schemas, etc. "on the fly," and developers need to understand when that's happening and when to avoid treating IANA network resources as a "schema download repository." That's exactly why IANA will not register or provide SYSTEM identifiers. 🙅‍♀️

3.2. Registerable Classes 🧁

Here's the list of XML element types that can be registered with IANA:

publicid -- An XML document that contains a DOCTYPE declaration, or any other external reference, can identify that reference with both a PUBLIC identifier and a SYSTEM identifier. The SYSTEM identifier is system-specific info that helps the entity manager of an XML system find the file, memory location, or pointer inside a file where the entity lives. It should also be noted that a system identifier could be an invocation of a program that controls access to the entity being identified. Because of that, they aren't registered items. In lots of cases SYSTEM identifiers are also URIs, but then the URI is still only used for system-specific info. If a PUBLIC Identifier is also a URI, the SYSTEM Identifier can contain that same URI, but this behavior is not recommended unless its side effects are well known and understood to not cause any unacceptable harm. 👀

A PUBLIC identifier is a name that's meant to make sense across systems and different user environments. Usually it's a name with a registered owner attached, so public identifiers are guaranteed unique and no two entities share one. In practice, PUBLIC identifiers are typically Formal Public Identifiers [ISO.8879.1986], but they aren't limited to just that set. As [RFC3151] says:

"Any string which consists only of the public identifier characters (defined by Production 13 of Extensible Markup Language (XML) 1.0 Second Edition) is a legal public identifier."

So it's legal for a PUBLIC identifier to be a URN, as long as it follows the character set restrictions. 💜

The identifier registered with a DTD is its PUBLIC identifier, and the only restriction is that it has to follow the character set restrictions. If the registrant doesn't give one, IANA will assign one of the form 'urn:ietf:params:xml:pi:<id>. Registrants are encouraged to check out RFC 3151 [RFC3151] as a recommended way to mint a URN that can also be represented as an FPI. 🌈

ns -- XML Namespaces [W3C.REC-xml-names] are named by a URI. They have no real, machine-parseable representation, so the registered document will be either the specification or a reference to it. If the registrant doesn't provide a URI, IANA will assign a URN of the form 'urn:ietf:params:xml:ns:<id>, which becomes the XML Namespace's name. 🍓

schema -- XML Schemas [W3C.REC-xmlschema-1] are also identified by a URI, but their contents are machine parseable. The IANA registered document will be the XML Schema file. The URN IANA assigns can be used as the URI for the schema, and it looks like 'urn:ietf:params:xml:schema:<id>'. 🦋

rdfschema -- The Resource Description Format (RDF) [W3C.CR-rdf-schema] is an XML serialization of a connected graph based data model used for metadata expression. RDF uses schemas that express grammars about relationships between URIs, and those grammars are identified by URIs. The URN IANA assigns can be used as the identifying URI, and it looks like 'urn:ietf:params:xml:rdfschema:<id>'. 🧚‍♀️

7. Normative References ✨

okay so these are the docs you NEED to read first 📚 they're the foundation this RFC is built on, no cap:

  • [ISO.8879.1986] International Organization for Standardization, "Information processing - Text and office systems - Standard generalized markup language (SGML)", ISO Standard 8879, 1986.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
  • [RFC3151] Walsh, N., Cowan, J. and P. Grosso, "A URN Namespace for Public Identifiers", RFC 3151, August 2001.
  • [RFC3553] Mealling, M., Masinter, L., Hardie, T. and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
  • [W3C.CR-rdf-schema] Brickley, D. and R. Guha, "Resource Description Framework (RDF) Schema Specification 1.0", W3C CR-rdf-schema, March 2000, http://www.w3.org/TR/2000/CR-rdf-schema-20000327.
  • [W3C.REC-xml] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, http://www.w3.org/TR/REC-xml.
  • [W3C.REC-xml-names] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, http://www.w3.org/TR/REC-xml-names.
  • [W3C.REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, http://www.w3.org/TR/xmlschema-1/.

8. Intellectual Property Statement 💅

the IETF is not picking a side here 🙈 it doesn't say whether any IP rights floating around for this tech are valid or how far they reach, and it doesn't claim it went hunting for them either. if you want the IETF's rules on rights for standards-track and standards-related docs, check BCP-11. copies of claimed rights, assurances of licenses, or results of attempts to get a general license for implementers or users can be requested from the IETF Secretariat.

the IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to practice this standard. send that info to the IETF Executive Director 📬

9. Author's Address 🖊️

Michael Mealling
VeriSign, Inc.
Mountain View, CA
USA

EMail: michael@verisignlabs.com
URI:   http://www.research.verisignlabs.com

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

okay the legal bit, but make it cute 🫶 you're totally allowed to copy and share this doc, and to make derivative works that comment on it or explain it or help people implement it. you can publish and distribute those too, in whole or in part, no restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative. BUT the doc itself can't be edited in any way. that means no removing the copyright notice or the references to the Internet Society or other Internet orgs. the exceptions are: using it to develop Internet standards (then the Internet Standards process copyright procedures must be followed), or translating it into languages other than English.

these permissions are perpetual, so the Internet Society and its successors or assignees won't revoke them ✨

this doc and everything in it is provided "AS IS", 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. 🫶💜

📦 where this page comes from