RFC 4179

Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)

πŸ“… published October 2005, from ietf

RFC 4179: Using Universal Content Identifier (UCI) as Uniform Resource Names (URN) πŸŽ€

okay bestie, this one is a PROTOCOL NAMESPACE doc πŸ¦‹ and I'm obsessed. Here's the title block:

  • Network Working Group πŸ’œ
  • Request for Comments: 4179 ✨
  • Author: S. Kang, National Computerization Agency 🌸
  • Category: Informational πŸ“š
  • Date: October 2005 πŸ“
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🫢

Status of This Memo πŸ’…

so this memo is just information for the Internet community. it is not an Internet standard of any kind. distribution is unlimited, so share it with everyone πŸ’–

Copyright (C) The Internet Society (2005).

Abstract ✨

this doc describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) πŸ›οΈ. the point is naming persistent digital resources like music, videos, texts, images, e-books, and other digital stuff produced or managed by NCA. the whole vibe is permanent names for digital things 🧚

1. Introduction πŸ‘‘

okay so NCA is a non-profit with a mandate to build up information infrastructure and manage public digital content in Korea and possibly worldwide 🌏

NCA has been supervising digitalization projects with lots of different organizations πŸ™ˆ and the content in those projects is honestly massive: millions of technical papers, cultural properties, educational materials, and scientific research reports. those organizations manage their digital content in a standardized way that NCA sets, and they give users all kinds of content services over the internet πŸ’»

NCA wants to issue globally unique, persistent IDs for digital resources and assign relevant organizations as its registration agencies under the Universal Content Identifier (UCI) scheme ✨ it's giving organized. it's beneficial for NCA, its registration agencies, and the value chain players in e-commerce to have a UCI URN namespace where everything NCA produces and manages gets registered, identified, and resolved πŸ’…

NCA has been developing and operating the UCI system, which handles registration, resolution, search, and administration πŸ”₯

the functionalities are going to be added and modified once the use of the UCI URN namespace is approved. NCA would like to assign unique, permanent, and location-independent names based on URNs for the resources it produces or manages πŸ¦‹ more info on NCA lives at http://www.nca.or.kr/eindex.htm 🫢

this namespace specification is for a formal namespace, so it's serious business πŸ’€

2. Specification Template 🌸

Namespace ID:

"UCI" πŸ’–

Registration Information:

Registration Version Number: 1 Registration Date: 2004-07-xx πŸ“…

Declared registrant of the namespace:

  • Name : Sang-ug Kang
  • Affiliation: National Computerization Agency
  • Address : NCA Bldg. 77 Mookyo-Dong, Chung-Ku, Seoul, Korea
  • Phone : +82 (2) 2131-0443
  • Email : <sukang@nca.or.kr>
  • Web : <http://www.nca.or.kr> or <http://home.uci.or.kr>

Declaration of syntactic structure:

okay the NSS (namespace specific string) of every URN NCA assigns conforms to the syntax in section 2.2 of RFC2141, "URN Syntax" [1] 🧠 the syntax convention is written as ABNF rules [2], and it looks like this:

UCI = prefix "-" instance *1(":" qualifier)

prefix = 1*(alphaDigit) *1(":" 1*(alphaDigit))
         *1("+" 1*(alphaDigit))
instance = 1*(trans / "%" HEXDIG HEXDIG)
qualifier = head 1*(alphaDigit) *2("-" head 1*(alphaDigit))
trans = alphaDigit / other
alphaDigit = ALPHA / DIGIT
head = "C" / "R" / "F"
other = "(" / ")" / "+" / "," / "-" / "." / "=" / "@" /
        ";" / "$" / "_" / "!" / "*" / "'"

so a UCI identifier has two parts, the prefix code and the content code ✨ the content code splits into an instance code and a qualifier code, and the qualifier is optional πŸŽ€ prefix codes go to a registration agency, a subordinate registration agency, and/or its registrants, like 'G3000+music', 'I600', 'I500+paper', and so on 🌈 content codes go to each individual digital resource, like 'cii90007', '8987409', and so on πŸ“

Relevant ancillary documentation:

None. nothing extra, it's all here bestie 🫢

Identifier uniqueness considerations:

it's the registration authority's job, which means NCA's, to guarantee uniqueness of identifiers and the names of subordinate naming authorities πŸ”’ for example, a software tool NCA developed and uses checks whether a UCI identifier is being reassigned and verifies that it's assigned to at most one resource during registration πŸ™Œ

Identifier persistence considerations:

registration agencies are all eligible to keep UCI URNs usable for a reasonably long period ⏳ as a government-sponsored org, NCA will run a backup service and try to find a substitute if a registration agency goes out of operation πŸ«‚

Process of identifier assignment:

assignment of UCI identifiers is delegated to the registration agencies πŸ¦‹ NCA appoints UCI registration agencies and provides its namespace by assigning each one a unique registration agency code, which is part of the NSS πŸ’œ after the authorized namespace, each registration agency sets its own identifier scheme that conforms to the UCI syntactic structure ✨

a UCI for a digital resource is issued by the registration agency when a registrant asks for one 🌸 here's an example:

urn:uci:I700-2987098

so I700 is a registration agency code and 2987098 is an identifier assigned to a digital content πŸ’–

Process for identifier resolution:

resolution is controlled by NCA and its delegatees πŸ‘‘ the list of UCI registration agency codes is maintained by the registration authority, and each registration agency keeps its own list of subordinate registrant codes and the identifiers registered to it πŸ“‹

the resolution steps go like this:

  • (Step1) Global resolution: NCA figures out which RA is dealing with the resource by parsing the registration agency code in the UCI. 🌍
  • (Step2) Local resolution: the corresponding RA parses and resolves the rest of the identifier. 🎯

the global resolution is handled by a UCI resolution server that's open to the public. (currently, http://rootadmin.uci.or.kr:9000/{UCI identifier} gives you resolution results ✨)

Rules for Lexical Equivalence:

the "prefix" is case-insensitive, so there won't be two registration agencies whose names differ only in case πŸ™…β€β™€οΈ

urn:uci:{prefix code}:

that part is case-insensitive for matches. the rest of the identifier is case-sensitive 🧐

Conformance with URN Syntax:

the UCI syntax fully conforms to the RFC2141 syntax rules for both the NSS and the NID βœ…

Validation mechanism:

a valid list of prefix codes is available both online and offline on request πŸ“¬ the validity of the rest of an identifier can be checked with the online service (currently at http://rootadmin.uci.or.kr:9000/{UCI identifier}, by typing in a query UCI identifier) πŸ”

Scope:

Global. 🌏

3. Security Considerations πŸ”

⚠️ okay this one is serious, so listen up πŸ™ˆ there are no additional security considerations beyond those normally associated with the use and resolution of URNs in general.

4. Namespace Considerations 🌈

the Korean government has been funding the UCI project because it's meant to be an essential piece in making digital content from different institutes and organizations interoperable πŸ‡°πŸ‡· the resolution service run by NCA and its registration agencies over networks is going to play a central role in getting there πŸ’… and the resolution service is open to the public without discrimination 🫢

the assignment and use of identifiers follows the rules NCA sets. it abides by the URN requirements and syntax πŸ“ inside a UCI namespace, a registration agency manages subordinate namespaces and keeps the metadata for digital content πŸ—‚οΈ

to make the service available to the public, NCA runs a global resolution service through a service server, and the corresponding registration agency provides local resolution service 🧚

5. Community Considerations πŸ’œ

assignment and use of identifiers within the namespace are open, and NCA establishes the related rules 🌸 registration agencies are evaluated and selected fairly, and they shall have the responsibility of processing registrants' requests for registering digital contents πŸ™Œ the registration authority and registration agencies shall operate resolution servers for the UCI namespace and subordinate namespaces, respectively πŸ–₯️ digital content users can access those resolution servers to fetch results πŸ¦‹ the reference software has been developed, and the resolution servers are now in operation πŸŽ‰

6. IANA Considerations πŸ“

IANA has registered the "UCI" namespace in the IANA registry of URN NIDs βœ… for more on URN namespaces, check [3] πŸ“š

7. Normative References πŸ“–

  • [1] Moats, R., "URN Syntax", RFC 2141, May 1997.
  • [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [3] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.

Author's Address 🫢

  • Sang-ug Kang
  • National Computerization Agency
  • Bldg. 77 Mookyo-Dong,
  • Joong-Ku, Seoul,
  • Korea
  • Phone: 82-2-2131-0443
  • EMail: sukang@nca.or.kr

Copyright (C) The Internet Society (2005).

this document is subject to the rights, licenses, and restrictions contained in BCP 78, and except as set forth there, the authors retain all their rights πŸ’–

this document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. πŸ’€

Intellectual Property πŸ”₯

the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology in this document, or on whether any license under those rights might or might not be available. it also doesn't claim to have made any independent effort to identify such rights 🧐 information on the procedures for rights in RFC documents is in BCP 78 and BCP 79 πŸ“š

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification can be found in the IETF online IPR repository at http://www.ietf.org/ipr πŸ—ƒοΈ

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org πŸ“¨

Acknowledgement πŸŽ€

funding for the RFC Editor function is currently provided by the Internet Society 🫢✨

πŸ“¦ where this page comes from