RFC 5138

RFC 5138: A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI) 🎀

Okay bestie, the title block first 💅 This is an Informational RFC from the Network Working Group, dated February 2008. It was written by S. Cox (full name S.J.D. Cox) from CSIRO in Australia. It doesn't obsolete or update any other RFC. It's just giving info for the internet community, so it's not an internet standard. 🦋

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌈

Abstract 🌸

So this doc describes a URN (Uniform Resource Name) namespace that the Commission for the Management and Application of Geoscience Information (CGI) is building. It's for naming two things: (i) persistent resources the CGI publishes, and (ii) resources published by organizations that want them used in services that follow CGI protocols and agreements. The formal Namespace Identifier (NID) is "cgi" 🧚

1. Introduction 💖

Here's the tea. CGI is a Commission of the International Union of Geological Sciences (IUGS), and its whole job is figuring out best practices for managing and using geoscience information 🪨 The active members are mostly organizations that have a legal duty to give geoscience info to outside users (e.g., Geologic Surveys). Their big focus is making standards for networked data exchange that can replace or upgrade the old-school map product 🗺️

Lots of documents, definitions, and other artifacts are needed to make this work. CGI wants to give them persistent, location-independent identifiers 🔖 Organizations that sign up for CGI's interchange standards also need external identifiers for the data objects that get transferred. So CGI wants a scheme that lets data providers uniquely identify data in a way that matches what the interchange framework needs 🫶

Products and services that follow CGI-endorsed interchange specs let users swap and process geoscience info across networks, computing platforms, and products 💅 Interop in that world is way easier when your identifiers are global in scope. CGI is the lead forum for the statutory organizations that act as the main providers of technical data in this domain ✨

So, because of all this, CGI wants to assign formal URNs to published resources so they get persistent, location-independent identifiers 🦋 The process for registering a namespace identifier is written up in [RFC3406].

The official IANA registry of URN namespaces lives here: <http://www.iana.org/assignments/urn-namespaces> 🌷

2. URN Specification for the "cgi" NID 👑

Here's the full spec for the cgi NID, and honestly it's iconic 🔥

Namespace ID:

cgi

Registration Information:

Registration Version Number: 1
Registration Date: 2007-10-04

Declared registrant of the namespace:

Commission for Geoscience Information (Secretariat)
c/o British Geological Survey
Kingsley Dunham Centre
Keyworth
Nottingham
Nottinghamshire
NG12 5GG
U K
Attn. Ian Jackson (ij@bgs.ac.uk)

Declaration of syntactic structure:

The Namespace Specific String (NSS) of all URNs that use the "cgi" NID has this structure, no cap 💀

urn:cgi:{CGIResource}:{ResourceSpecificString}

The "CGIResource" is a US-ASCII string that conforms to the URN syntax requirements in [RFC2141]. It defines a specific class of resource type. Each resource type has its own labeling scheme, which is covered by "ResourceSpecificString", and that also has to conform to the naming requirements of [RFC2141] 🧁

The CGI keeps a naming authority, the CGI Naming Authority (CGINA). CGINA manages the assignment of CGIResource classes and the specific registration values for each resource class 👩‍💻

Relevant ancillary documentation:

The CGINA provides info on the registered resources and the registrations for each one. More about CGINA, plus the registration activities and procedures you need to follow, is over at <http://www.cgi-iugs.org/CGIIdentifierScheme> 📚

There's also a URN resolver at <http://www.cgi-iugs.org/uri>. It gives you a registry of CGI URNs used in CGI services 🫧

Identifier uniqueness considerations:

CGINA manages resources using the "cgi" NID, and it's the authority for managing those resources and the strings linked to them. In its procedures, CGINA makes sure the strings themselves are unique, or it hands over secondary responsibility for well-defined sub-trees 🌳

Quick heads up: CGI might allow experimental-type values that never get registered. That means multiple users could end up using the same value for different things. Experimental usage is only meant for testing, so it shouldn't mess with operational services ⚠️

Experimental values aren't registered, so two people can end up with the same one. It's fine for testing, just don't run your real services on them 🙈

Identifier persistence considerations:

CGINA gives clear docs on the registered uses of the "cgi" NID. It's structured so each CGIResource has its own description and its own ResourceSpecificString, with separate registration tables for the parts of the strings that get maintained separately 💜

CGINA publishes and maintains the registration tables and info on the CGI web site mentioned above 🌐

Process of identifier assignment:

CGINA defines the CGIResource classes used with the "cgi" NID, and it specifies the assignment process for each class. You can find these at:

<http://www.cgi-iugs.org/CGIIdentifierScheme>

and a set of registers is linked from that page. Each resource may have three types of registration activities:

1. Registered values associated with CGI resources
2. Registration of values or sub-trees to other entities
3. Name models for use in experimental purposes

Process for Identifier Resolution:

The namespace isn't listed with a Resolution Discovery System (RDS). That's not relevant here 🙅‍♀️

Rules for Lexical Equivalence:

No special considerations. The rules for lexical equivalence in [RFC2141] apply ✨

Conformance with URN Syntax:

No special considerations 🌸

Validation mechanism:

None specified. URN assignment is handled by the procedures set up to support CGINA activities 🫶

Scope:

Global 🌍

---

Part 1 of 2. The rest of the RFC (Sections 3 through 9, plus the author's address) is coming next. 🦋

Full Copyright Statement ✨

Okay bestie, the legal bit 💅. The IETF Trust owns the copyright here, and it's dated 2008 🎀. This document is covered by the rights, licenses, and restrictions in BCP 78. Outside of those terms, the authors keep all their rights 🦋.

This document and everything in it come "AS IS," no guarantees 🙈. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all say there are no warranties, express or implied. That covers non-infringement, merchantability, and fitness for a particular purpose. Nobody promises the info here won't step on anyone's rights 💀.

Intellectual Property

The IETF is not picking a side on whether any Intellectual Property Rights or other rights that someone might claim over this technology are valid, or how wide they reach 🔥. It also doesn't say whether licenses for those rights are available. The IETF hasn't independently gone looking for any of them either 👀. If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79 🧚.

Copies of IPR disclosures sent to the IETF Secretariat are kept, along with any promised licenses. You'll also find the results of anyone who tried to get a general license or permission to use those proprietary rights for implementing or using this specification. All of that lives in the IETF's online IPR repository at http://www.ietf.org/ipr 💜.

The IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard 🌈. Send that info to the IETF at ietf-ipr@ietf.org ✨. It's giving transparency, periodt 💖.