RFC 3121

A URN Namespace for OASIS

πŸ“… published June 2001, from ietf

RFC 3121: A URN Namespace for OASIS πŸ’–

Okay bestie, here's the header facts first πŸŽ€

  • Network Working Group 🌸
  • Request for Comments: 3121
  • Category: Informational (it's for info, not a standard) ✨
  • Authors: Karl Best of OASIS, Inc. and Norman Walsh of Sun Microsystems, Inc. πŸ‘‘
  • Date: June 2001 πŸ“…
  • Obsoletes / Updates: the header doesn't list either one πŸ™ˆ

Status of This Memo ✨

This memo just gives info to the Internet community. It is not an Internet standard of any kind, so don't treat it like one πŸ’… Distribution is totally unlimited, so share away πŸ¦‹

The Internet Society owns the copyright here (2001), all rights reserved. Full legal stuff is at the very end, bestie πŸ’œ

Abstract πŸ”₯

So this doc describes a URN (Uniform Resource Name) namespace that OASIS (the Organization for the Advancement of Structured Information Standards) set up to name the persistent stuff it publishes. Think OASIS Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other docs πŸ“š

1. Introduction 🧚

OASIS makes a LOT of documents: specs, working drafts, technical resolutions, schemas, stylesheets, and more πŸ“

They want global, distributed, persistent, location-independent names for all of it, so the names keep working even if the stuff moves around 🫢

Here's the vibe check on XML. Every resource has to have a system identifier, which must be a URI. There's also an optional public identifier, which is an alternate way to build identifiers. Plus, tons of specs (XML Namespaces, XML Schema, XSLT, etc.) need people to identify docs by URI alone 😭

So OASIS wants to give URNs to some of its resources, so they keep unique, permanent, location-independent names forever πŸ’…

This namespace spec is for a formal namespace, periodt ✨

2. Specification Template πŸŽ€

This section is the official form for the namespace, bestie. Let's go πŸ’–

Namespace ID

The namespace ID is "oasis" requested.

Registration Information

  • Registration Version Number: 3
  • Registration Date: 2001-02-05

Declared registrant of the namespace

The registrant is Karl Best at OASIS (Organization for the Advancement of Structured Information Standards), Post Office Box 455, Billerica, MA USA 01821.

  • Phone: +1 (978) 667 5115 πŸ“ž

Declaration of structure

All the Namespace Specific Strings (NSS) for URNs that OASIS assigns follow a hierarchy. There are two branches at the top: "names" and "member" 🌳

The Names Hierarchy

The NSS in the names hierarchy starts with a document class identifier. There are three classes: "specification", "tc", and "technical" πŸ¦‹

Specifications

The "specification" hierarchy is for OASIS Specifications. The NSS looks like this:

            urn:oasis:names:specification:{specification-id}
                           :{type}{:subtype}?:{document-id}

Here, specification-id is a unique ID for the spec. type tells you the doc type (document, schema, stylesheet, entity, xmlns, etc.). The optional subtype gives extra info about the doc type, like the stylesheet or schema language. And document-id is a unique ID for the doc πŸ”₯

The Director of Technical Operations at OASIS assigns the doc types, subtypes, and all unique IDs. That person is the boss of IDs, no cap πŸ‘‘

Technical Committee Work Products

The "tc" hierarchy is for work products from OASIS Technical Committees. The NSS looks like this:

            urn:oasis:names:tc:{tc-id}:{type}{:subtype}?:{document-id}

Here, tc-id is a unique ID for the Technical Committee. Everything else gets assigned the same way as in the specification hierarchy 🌸

Technical Papers

The "technical" hierarchy is for legacy docs: Technical Notes, Resolutions, Memoranda, and Research Papers. The NSS looks like this:

            urn:oasis:names:technical:{document-type}
                           :{document-id}:{amendment-id}

The document type is one of these: "note", "resolution", "memorandum", or "researchpaper" πŸ“

The document and amendment IDs come from the old system used to name these docs. The document ID is a two digit year plus a sequential number. The amendment ID is the year of the amendment πŸ•°οΈ

The Members Hierarchy

The NSS in the members hierarchy starts with a unique member ID that OASIS assigns. The string after the member ID is opaque, meaning you can't read into it. Here's an example:

            urn:oasis:member:A00024:x

The Director of Technical Operations at OASIS assigns the member IDs. The opaque string is defined by whoever owns the branch that starts with urn:oasis:member:{member-id}: 🫢

Relevant ancillary documentation

None πŸ™ˆ

Identifier uniqueness considerations

The Director of Technical Operations enforces uniqueness. They're the one who gives unique IDs to every doc identified by a URN ✨

Identifier persistence considerations

OASIS is committed to keeping every resource with a URN accessible and persistent. Forever vibes πŸ’œ

Process of identifier assignment

Only the owner, and the authorities the owner specifically designates, can assign identifiers. OASIS will hand out portions of its namespace (specifically, the ones under the members hierarchy) to other parties to assign πŸ¦‹

Process of identifier resolution

The owner will distribute catalogs (OASIS TR9401 Catalogs) that map assigned URNs to resource identifiers, like URLs. A more interactive, online resolution system is also coming soon πŸ‘€

The owner will also authorize extra resolution services as needed 🌈

Rules for Lexical Equivalence

URNs are lexically equivalent if they are lexically identical. Basically, they have to match character for character πŸ’…

Conformance with URN Syntax

No special considerations here πŸŽ€

Validation mechanism

None specified. The owner will publish OASIS TR9401 Catalogs. If a URN is in a catalog, that means it's valid βœ…

Scope

Global 🌍

3. Examples ⭐

These examples aren't guaranteed to be real. They're just here for teaching purposes, so don't go hunting for them, bestie πŸ™ˆ

urn:oasis:names:specification:docbook:dtd:xml:4.1.2
urn:oasis:names:tc:docbook:dtd:xml:docbook:5.0b1
urn:oasis:names:technical:memo:9502:1995
urn:oasis:member:A00024:x

4. Security Considerations πŸ’€

Okay, this part is serious. There are no extra security considerations beyond the ones that come with using and resolving URNs in general. So be careful out there, babe πŸ”₯

References

  • [1] Goldfarb, C. F., "ISO (International Organization for Standardization) ISO 8879:1986(E) Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML)", 1986.
  • [2] W3C, XML WG, "Extensible Markup Language (XML) 1.0", February 1998, <http://www.w3.org/TR/REC-xml>.
  • [3] W3C, Namespaces WG, "Namespaces in XML", January 1999, <http://www.w3.org/TR/REC-xml-names>.
  • [4] OASIS, Entity Mgmt. TC, "Entity Management: OASIS Technical Resolution 9401:1997 (Amendment 2 to TR 9401)", January 1994, <http://www.oasis-open.org/html/a401.htm>.
  • [5] Moats, R., "URN Syntax", RFC 2141, May 1997.
  • [6] Mealling, M. and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999.

Authors' Addresses πŸ’Œ

Karl Best, OASIS, Inc., P.O. Box 455, Billerica, MA 01821, US. Email: karl.best@oasis-open.org πŸ’–

Norman Walsh, Sun Microsystems, Inc., One Network Drive, MS UBUR02-201, Burlington, MA 01803-0902, US. Email: Norman.Walsh@East.Sun.COM 🫢

The Internet Society owns the copyright (2001), all rights reserved. You're allowed to copy and share this document and translations of it, and to make derivative works that comment on or explain it or help with implementing it. You can publish and distribute those in whole or in part with no restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work 🌸

The document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exception is when you're developing Internet standards, in which case you follow the copyright procedures in the Internet Standards process. The other exception is translating it into languages other than English 🌍

These limited permissions are perpetual, and the Internet Society or its successors or assigns won't revoke them πŸ’œ

This document and its info are 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 πŸŽ€

The RFC Editor function is currently funded by the Internet Society. Thank you, Internet Society 🫢✨

πŸ“¦ where this page comes from