RFC 4179
Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)
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 Notice π
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 KangAffiliation: National Computerization AgencyAddress : NCA Bldg. 77 Mookyo-Dong, Chung-Ku, Seoul, KoreaPhone : +82 (2) 2131-0443Email : <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
Full Copyright Statement π
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
- ietf: rfc4179 2005-10
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms