RFC 6924

RFC 6924: Registration of Second-Level URN Namespaces under "ietf" 💖

Okay bestie, here's the paperwork. 🎀

• Who wrote it: Barry Leiba (B. Leiba) from Huawei Technologies 👑
• Where it lives: Request for Comments 6924, from the Internet Engineering Task Force (IETF) ✨ (ISSN 2070-1721)
• Category: Informational 🌸, which means it's published for info and is not a Standards Track spec
• Date: April 2013 📅
• Updates: RFC 2648 🦋 (it doesn't list anything it obsoletes)

---

Abstract

RFC 2648 defines the "ietf" URN namespace and a bunch of sub-namespaces under it 🌈. RFC 3553 adds one more sub-namespace, "params", plus a registry to track what gets allocated under it. But there's no single place that lists all the sub-namespaces of "ietf", which is kind of chaotic ngl 😭. This document creates that registry and fills it in, and it changes how RFC 2648 says new sub-namespaces of "ietf" get added 💅.

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes 🧚.

This one is a product of the IETF. It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🔥.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6924 🫶.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 👀. Any Code Components pulled from this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes ⭐.

1. Introduction 🌸

Okay so the "ietf" URN namespace and its sub-namespaces come from "A URN Namespace for IETF Documents" [RFC2648]. Then "An IETF URN Sub-namespace for Registered Protocol Parameters" [RFC3553] adds the "params" sub-namespace and its allocation registry. Still, nobody has a single list of every sub-namespace of "ietf" 🙈.

This document makes that list. It's a registry, and it changes the way RFC 2648 handles adding new sub-namespaces of "ietf" ✨.

2. IANA Considerations 🦋

Right now there's a top-level registry group called "IETF Protocol Parameter Identifiers", and it holds one registry: "IETF URN Sub-namespace for Registered Protocol Parameters". IANA handled three actions, and they're all about tidying this up 🧹.

Action 1: IANA renamed the group from "IETF Protocol Parameter Identifiers" to "Uniform Resource Name (URN) Namespace for IETF Use". The existing registry is still in there with the same name. Its registration procedure is now "IETF Review", which used to be called "IETF Consensus" 🎀.

Action 2: IANA added a new registry to the renamed group, called "IETF URN Sub-namespaces". New registrations will use the IETF Review policy [RFC5226], which provides for IETF consensus when adding a new URN namespace under "ietf". The new registry sits at the very top of the group so you can read the namespace hierarchy top-down, which is honestly so helpful 💅.

Action 3: IANA filled the new registry like this:

IETF URN Sub-namespaces

Registration Procedures: IETF Review
Reference: [RFC6924]

Note: This is the Official Registry for sub-namespaces of the 'IETF'
URN Namespace.

Sub-namespace | Reference | IANA Registry Reference
--------------+-----------+-----------------------------------------
rfc           | [RFC2648] | none
fyi           | [RFC2648] | none
std           | [RFC2648] | none
bcp           | [RFC2648] | none
id            | [RFC2648] | none
mtg           | [RFC2648] | none
params        | [RFC3553] | [http://www.iana.org/assignments/params]
--------------+-----------+-----------------------------------------

3. Security Considerations 🔐

This is a procedural document and is entirely unrelated to security. Not me being dramatic, it's just a paperwork update 🙈.

4. Acknowledgments 🫶

Alfred Hoenes noticed this registry was missing and suggested making it. Iconic behavior, honestly 👑.

5. References 📚

5.1. Normative References

• [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
• [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

5.2. Informative References

• [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.

Author's Address 💌

Barry Leiba Huawei Technologies

Phone: +1 646 827 0648 EMail: barryleiba@computer.org URI: http://internetmessagingtechnology.org/