RFC 7738

A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS)

📅 published January 2016, from ietf

RFC 7738: A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS) 🚀✨

Series: Internet Engineering Task Force (IETF) 🌐 Request for Comments: 7738 🎀 Category: Informational 🦋 ISSN: 2070-1721 Date: January 2016 📅

Authors:

  • M. Blanchet (Viagenie) 💜
  • A. Schiltknecht (Viagenie/SANA) 💜
  • P. Shames (Jet Propulsion Laboratory, NASA) 💜

Obsoletes / Updates: This RFC doesn't obsolete or update anything. Its header has no Obsoletes or Updates line. 🌸

Abstract 🌟

okay so this doc describes a Uniform Resource Name (URN) namespace 🏷️ that's meant to give resources published by the Consultative Committee for Space Data Systems (CCSDS) names that are persistent AND unique, so they stick around forever and nobody else can claim them. no cap, that's the whole pitch 💅

Status of This Memo ✨

this doc is NOT an Internet Standards Track specification 🙈 it's just published for informational purposes, so it's more of a "here's the info" vibe than a "you MUST do this" thing (fr, we're getting to the real rules in Section 2 💖).

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶 it got public review and the Internet Engineering Steering Group (IESG) approved it for publication. not every IESG-approved doc is a candidate for any level of Internet Standard though, so check out Section 2 of RFC 5741 if you want the deets 🧚

if you want the current status, any errata, or a way to send feedback, go here: http://www.rfc-editor.org/info/rfc7738 🔗

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date it was published. please actually read those, bestie, because they spell out your rights and restrictions for this doc 📜

also, any Code Components you pull out of this doc have to include the Simplified BSD License text, like Section 4.e of the Trust Legal Provisions says, and they come with no warranty, per the Simplified BSD License 🍓

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Requirements Language Section . . . . . . . . . . . . . . . .   3
3.  URN Specification for "ccsds" Namespace ID  . . . . . . . . .   3
  3.1.  Namespace ID  . . . . . . . . . . . . . . . . . . . . . .   3
  3.2.  Registration Information  . . . . . . . . . . . . . . . .   3
  3.3.  Declared Registrant of the Namespace  . . . . . . . . . .   3
  3.4.  Declaration of Syntactic Structure  . . . . . . . . . . .   4
  3.5.  Relevant Ancillary Documentation  . . . . . . . . . . . .   4
  3.6.  Identifier Uniqueness Considerations  . . . . . . . . . .   4
  3.7.  Identifier Persistence Considerations . . . . . . . . . .   4
  3.8.  Process of Identifier Assignment  . . . . . . . . . . . .   5
  3.9.  Process for Identifier Resolution . . . . . . . . . . . .   5
  3.10. Rules for Lexical Equivalence . . . . . . . . . . . . . .   5
  3.11. Conformance with URN Syntax . . . . . . . . . . . . . . .   5
  3.12. Validation Mechanism  . . . . . . . . . . . . . . . . . .   5
  3.13. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
5.  Namespace Considerations  . . . . . . . . . . . . . . . . . .   6
6.  Community Considerations  . . . . . . . . . . . . . . . . . .   6
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction 🛰️

okay, the Consultative Committee for Space Data Systems (CCSDS) [CCSDS] got started in 1982 when the major space agencies of the world decided they needed a forum to talk through common problems in building and running space data systems 🌌 when this doc was published, it had eleven member agencies, twenty-eight observer agencies, and over 100 industrial associates. ever since, CCSDS has been putting out recommendations for data and information-systems standards to make things interoperable and help cooperating space agencies support each other 💖

CCSDS has a permanent secretariat that reports to the CCSDS Engineering Steering Group, and that group keeps the CCSDS protocol docs up to date 📚 CCSDS also has its own Naming Authority under the Space Assigned Number Authority (SANA) [SANA], and that Naming Authority runs its registries and namespaces 🗃️

CCSDS makes protocol standards docs that need a permanent and unique namespace, which is so iconic of them 👑 they also use Extensible Markup Language (XML) schemas to define XML messaging across their protocol recommendations. those schemas need a persistent, unique, and location-independent namespace for identification, so it's literally the same energy as everything else on this list 🫶

this namespace spec is for a formal namespace identifier (NID), as per [RFC3406] 🎀

2. Requirements Language Section 📏

here's where the big keywords live, bestie 💅 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 [RFC2119] ✨

3. URN Specification for "ccsds" Namespace ID 🌈

3.1. Namespace ID 🏷️

the namespace ID is just:

"ccsds"

3.2. Registration Information 📝

Registration version number: 1
Registration date: 2015-10-19

3.3. Declared Registrant of the Namespace 🧑‍💼

the registering organization is the CCSDS Secretariat, and here's how to reach them:

Consultative Committee for Space Data Systems (CCSDS) Secretariat

Office of Space Communication (Code M-3)

National Aeronautics and Space Administration

Washington, DC 20546, USA

Email: secretariat@mailman.ccsds.org

the designated contact is the Space Assigned Numbers Authority (SANA) 🌟

Space Assigned Numbers Authority (SANA)

Email: info@sanaregistry.org

http://sanaregistry.org

3.4. Declaration of Syntactic Structure 🧩

the formal syntax definitions below are written in ABNF [RFC5234], so they're super precise 🔍

the namespace-specific string (NSS) in the urn:ccsds names hierarchy starts with a subnamespace identifier (SNID), then a delimiter, then a subnamespace-dependent string 🪄 the whole shape looks like this:

CCCSDS-URN = "urn:ccsds:" SNID ":" SUBNAMESPACE-SPECIFIC-STRING

in that, <SNID> is a unique subnamespace identifier for the specification, and <SUBNAMESPACE-SPECIFIC-STRING> is a unique identifier within the scope of that subnamespace identifier 💜

<SNID> has the same syntax as an <NID> defined in [RFC2141] ✨

SANA assigns SNIDs 👑

the syntax of <SUBNAMESPACE-SPECIFIC-STRING> depends on the <SNID>, and a CCSDS document MUST define it 📜 this doc doesn't add any extra restrictions to <SUBNAMESPACE-SPECIFIC-STRING> beyond what the NSS syntax in [RFC2141] already says:

SUBNAMESPACE-SPECIFIC-STRING = 1*<URN chars>

<URN chars> is defined in Section 2.2 of [RFC2141] 🫧

3.5. Relevant Ancillary Documentation 📚

SANA keeps the "urn:ccsds" namespace as a registry [SANA-Reg] 🗂️ the procedures for registering a subnamespace identifier are described in the header of that registry 🍓

3.6. Identifier Uniqueness Considerations 🔐

SANA is the authority responsible for making sure identifiers are unique, per the CCSDS recommendations 💖 SANA assigns unique identifiers and keeps a public registry [SANA-Reg] 🌸

3.7. Identifier Persistence Considerations ⏳

CCSDS is committed to guaranteeing the accessibility and persistence of all the resources that are assigned URNs. ✨ that's a big promise, and honestly it's giving reliability 🫶

3.8. Process of Identifier Assignment 🎫

assigning identifiers is limited to CCSDS and to any authorities CCSDS explicitly designates 🙌 CCSDS is committed to assigning URN identifiers only according to the rules in this document, or in future updates to it. those updates might come out as IETF RFC documents or as CCSDS recommendations 🦋

3.9. Process for Identifier Resolution 🔎

the CCSDS namespace isn't currently listed with a Resolution Discovery System (RDS). BUT nothing about the namespace stops future resolution methods from being defined, or from getting listed with an RDS later on 🌈

3.10. Rules for Lexical Equivalence 🪞

the <SNID> part of URNs in the CCSDS hierarchy is case insensitive 💅 so the <SNID> MUST be case normalized before comparison, so "CCSDS" and "ccsds" don't end up looking like two different things 🙈

3.11. Conformance with URN Syntax 🧾

this doc only restricts the syntax of the <SNID>. the syntax of the <SUBNAMESPACE-SPECIFIC-STRING> follows the general syntax of a URN:

SUBNAMESPACE-SPECIFIC-STRING = 1*<URN chars>

docs that define a subnamespace identifier SHOULD spell out further syntactic restrictions for the <SUBNAMESPACE-SPECIFIC-STRING> 🎀 it is RECOMMENDED that those docs forbid URNs containing the characters in the <reserved> set ("%", "/", "?", and "#") from [RFC2141] 🧁 this lines up with Section 2.2 of [RFC3986] 🌟

3.12. Validation Mechanism 🛡️

the validation mechanism for URNs in this hierarchy is specific to each SNID, and it SHOULD be defined when that SNID gets assigned 💜

URNs in the hierarchy without an assigned SNID are considered invalid 🚫 no SNID, no entry, periodt 💅

3.13. Scope 🌍

global URNs matter for the space agencies' networks, both in space and on Earth 🛰️🌏✨

Continued in Part 2

9.1. Normative References 📚✨

okay bestie, these are the docs the spec leans on to work, so they're basically its emotional support references 💅 here they are, every single one:

9.2. Informative References 🧠

these ones are more like "bonus reading if you're curious" vibes, not required to get the core idea 🫶

Acknowledgements 🎀

okay the shoutouts 😭 this document is based on earlier draft versions written by Martin A. Soto and Louis Reich, and it got reviewed by the XML Steering Group (XSG) of the Systems Engineering and Architecture Area (SEA) in CCSDS. the people who made this possible, literally iconic 👑

Authors' Addresses 💌

here's who wrote it and how to find them, all copied exactly:

Marc Blanchet
Viagenie/SANA
246 Aberdeen
Quebec, QC  G1R 2E1
Canada

Email: Marc.Blanchet@viagenie.ca
URI:   http://viagenie.ca


Audric Schiltknecht
Viagenie/SANA
246 Aberdeen
Quebec, QC  G1R 2E1
Canada

Email: audric.schiltknecht@viagenie.ca
URI:   http://viagenie.ca


Peter Shames
Jet Propulsion Laboratory, NASA

Email: peter.m.shames@jpl.nasa.gov
URI:   http://cwe.ccsds.org/sea/default.aspx

that's the whole spec, bestie 🌈💖 you did amazing reading all the way through 🥹✨

📦 where this page comes from