RFC 4350

A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government

📅 published February 2006, from ietf

A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government 🎀

Title block, the tea ☕

  • Request for Comments: 4350 📄
  • Network Working Group
  • Authors: F. Hendrikx and C. Wallis, both from the New Zealand Government 🇳🇿
  • Category: Informational 💜
  • Date: February 2006 📅
  • Obsoletes / Updates: nothing is listed in the header, so this doc doesn't obsolete or update any other RFC 🙅‍♀️

Okay so this is an Informational doc, which means it's sharing info with the Internet community and is NOT a standard. Totally fine, just good to know going in 💅

Status of This Memo ✨

Okay so, bestie, this memo is here to give info to the Internet community. It doesn't specify an Internet standard of any kind, so don't go treating it like one 🙈 Distribution of this memo is unlimited, so share it with everyone who's obsessed with URNs 💖

Copyright (C) The Internet Society (2006). That's the whole vibe here 💅

Abstract 🌸

So the gist is that this doc describes a Uniform Resource Name (URN) Namespace Identification (NID) convention. It's prescribed by the World Wide Web Consortium (W3C) and it's for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New Zealand Government. Main character energy, honestly 👑

1. Introduction ✨

Okay so the New Zealand Government has already adopted XML as its primary way of storing and exchanging data 💅 It publishes documents, schemas, and other government artefacts all the time 📚

Now it wants to define a namespace convention and structure for its agencies 🧚 The goal is creating and managing globally unique, persistent, location-independent identifiers for their schema resources and XML artefacts. Iconic, and it's giving stability 💜

This is kind of a natural next step from the Dublin Core based New Zealand Government metadata standard (New Zealand Government Locator Service, or NZGLS) 🌈 Government agencies already use NZGLS to create metadata, and it's live for the public through an all-of-government portal. So this is just building on something that already slaps 🔥

The government also wants to give its agencies guidance on namespaces, so they use a portion of the adopted namespace. The reason is to lower the risk of agencies making different (and potentially conflicting) namespace structures 🫶 This could reach past government into the private sector of New Zealand too. So the government feels it has an obligation to provide guidance on assigning and managing additional namespaces 😭

Here's the structure part, bestie. The New Zealand Government wants to register the country NID, NZL, with its Name Specific String (NSS) split into two parts 🍓 The first part is a specific sub-type, <nz-specifier>, and the second part is a <nz-specifier defined string>. Very organised, very cute 🎀

As part of the URN structure, the government wants to define and then manage the "govt" specifier 👑 It will also assign extra specifiers that other New Zealand organisations request, as long as they follow the rules and processes proposed in this doc ✨

Now, the tea ☕ The government originally hoped to use the two-letter Namespace Identifier (NID) combo for its ubiquitous country code, NZ. But there's no process yet to register those (see RFC 3406 [1]), so the government went with its well-known alternative: the three-letter country code (see ISO 3166 [3]). Not the glow-up it wanted, but still valid 🙈

This namespace specification requests a formal namespace (see [6] for more information about formal namespaces) 🧚 Okay, reference slayed.

Heads up, bestie: this paper talks about diacritic marks, specifically Maori macrons. Maori is an official language of New Zealand, so it matters 🇳🇿 RFCs get published in ASCII for a global audience, and ASCII can't show diacritics, so the text here is presented without macrons. It's a practical choice, not a typo 💖

To be continued in part 2! 🦋

2. Specification Template ✨

okay bestie, this section is the official ID card for the namespace 🪪💖. it lays out every single field, so let's go through them 💅

Namespace ID

"NZL"

Registration Information

Version Number: 1
Date: 2005-03-31

Declared registrant of the namespace

State Services Commission
New Zealand Government
100 Molesworth Street
Wellington,
New Zealand

Email: e-GIF@ssc.govt.nz

Declaration of structure

the identifier is hierarchical, and it looks like this 🌳✨

urn:nzl:<nz-specifier>[:<nz-specifier defined string>]+

the + just means one or more occurrences of nz-specifier defined strings, all separated by a colon. here are some examples that are giving real government vibes 🏛️

urn:nzl:govt:registering:dogs:registration:1-0
urn:nzl:govt:registering:firearms:form:1-3
urn:nzl:govt:registering:recreational_fishing:form:1-0

the <nz-specifier> and <nz-specifier defined string> can be any UTF-8 characters that are compliant with URI syntax, but they must not contain the ":" character (see STD 66, RFC 3986 [2]). ngl the colon being banned is so smart, because it means a colon can only ever show up as a delimiter between values 🧠 the values come from the terms listed in the NZGLS.

the State Services Commission (SSC) is in charge of the <nz-specifier> "govt" and its sub level <nz-specifier defined string> terms, e.g., "registering". 👑

the SSC will also assign other <nz-specifiers> to organisations that apply and can prove to the SSC that they can manage the sub level and its applicable <nz-specifier defined string(s)>. 🫶

Relevant ancillary documentation

the function and noun syntax in the <nz-specifier defined string> is based on and taken from the NZGLS, which lives at http://www.e.govt.nz/standards/nzgls/thesauri/ 📚

Identifier uniqueness considerations

identifiers in the <nz-specifier> "govt" are defined and assigned in the requested namespace by the SSC, after it makes sure the URNs are unique. 🔍 uniqueness is checked against the registry of previously assigned names.

the SSC will also make sure the URNs assigned to other organisations applying for other <nz-specifier(s)> (e.g., mil, co, org) are unique, again by checking the registry of previously assigned names. 💜

the SSC will develop and publish the process for this, which, where applicable, is consistent with the process it uses for moderating the .govt.nz Top Level Domain (TLD). 🌈

Identifier persistence considerations

the New Zealand Government is committed to keeping every resource identified by an assigned URN unique and persistent. 🦋

the URN being sought is NZL, which is the long-held ISO 3166 Alpha-3 representation of the country. since the country's independence from any other jurisdiction is expected to continue indefinitely, the URN should also persist indefinitely. 🇳🇿✨

the <nz-specifier> "govt" has a very long life expectancy and can be expected to stay unique for the foreseeable future. the assignment process guarantees that names are not reassigned, and the binding between the name and its resource is permanent. 🔒

the SSC will make sure that other organisations applying to manage other <nz-specifier> Second Level Name (2LN) sub-levels of the NZL URN namespace (e.g., mil, co, org) uniquely assign the namespace at this level. 💅

Process of identifier assignment

under the "NZL" NID, the New Zealand Government will manage the <nz-specifier> "govt" and leverage the existing NZGLS thesaurus for identifier resources to keep everything unique. 🧩

the process of assigning URNs at the <nz-specifier> sub-level will be managed by the SSC of the New Zealand Government. (the SSC has managed and maintained the NZGLS thesauri since its inception in 2002, and it has moderated the TLD .govt.nz 🥹)

the SSC will develop and publish the process for this, which is consistent with the process it uses for moderating the .govt.nz TLD, where applicable. the process for marketing the ".govt.nz" TLD can be found at these links:

the process is drawn from the 2LD policies and procedures of the New Zealand Office of the Domain Name Commissioner, http://dnc.org.nz (and specifically http://www.dnc.org.nz/story/30043-35-1.html). 📖

other New Zealand organisations may apply to the SSC to delegate specifiers for resolution and management that they've been assigned. 🤝 delegation will not be unreasonably withheld, provided that the processes for their resolution and management are robust and are followed. 💖

organisations that apply to have a <nz-specifier> assigned to them must satisfy the SSC that they can manage the 2LN sub-level and its applicable <nz-specifier defined string(s)> responsibly. the policies and procedures in the links above will be given to applicants as a guide, and the SSC will use them to determine the applicant's capability. 🎀

Process of identifier resolution

for the <nz-specifier> "govt", the SSC will maintain lists of assigned identifiers on its web pages at http://www.e.govt.nz/. 🌸

the SSC will require other organisations that apply to manage other <nz-specifier> sub-levels to follow this practice, unless there are specific reasons (e.g., security) not to. 🔐

Rules for Lexical Equivalence

the lexical equivalence of the NZL namespace-specific strings (NSSs) is defined as an exact, but not case-sensitive, string match. Best Practice guidelines will specify:

  • a) NZL in either uppercase or lowercase. (the New Zealand government will assign names as case-insensitive, so there will never be two NZL URNs that differ only by case 🙌)
  • b) the first letter of each <nz-specifier> and <nz specifier defined string> in uppercase, or the whole value in lowercase.
  • c) any identifier in NZL namespaces can be compared using the normal mechanisms for percent-encoded UTF-8 strings.
ok this part is important textual data containing diacritic marks (such as Maori macrons) will NOT be treated as lexically equivalent to textual data without them. in other words, a distinction will be made. a macron can literally change the meaning of a word in the Maori language, so this matters a lot 🥺🌈

here's the guidance for it. NSS is any UTF-8-encoded string that is compliant with the URN syntax (i.e., following the encoding rules for 8-bit characters). UTF-8 allows diacritic marks like New Zealand Maori macrons. since Maori is an official language in New Zealand and its use of diacritic marks (in this case, macrons) invokes the requirement to percent-encode reserved characters, the following extract from RFC 3986 [4] applies:

   When a new URI scheme defines a component that represents
   textual data consisting of characters from the Universal
   Character Set [UCS], the data should first be encoded as octets
   according to the UTF-8 character encoding [STD63]; then only
   those octets that do not correspond to characters in the
   unreserved set should be percent-encoded.  For example, the
   character A would be represented as "A", the character LATIN
   CAPITAL LETTER A WITH GRAVE would be represented as "%C3%80",
   and the character KATAKANA LETTER A would be represented as
   "%E3%82%A2".

in the New Zealand context, the word "Maori" has a diacritic mark over the "a". a URI including the macronised word "Maori" would be percent-encoded as M%C4%81ori ✨

now, the "govt" namespaces draw from the NZGLS thesaurus, which doesn't currently use diacritic marks. so the "govt" <nz-specifier> will NOT use UTF-8's percent-encoding convention for diacritic marks. an "a" with a diacritic mark will just be presented as a plain "a". there's no mapping or equivalence table, so the requirement to tell apart terms with and without diacritic marks won't come up in the <nz-specifier> "govt" 🙈

other organisations may use diacritic marks under certain conditions. organisations that apply to manage other <nz-specifier> sub-levels of the NZL URN namespace could use UTF-8's diacritic functionality, provided they have the applicable processes to separate Maori language terms that use macrons from those that don't, in order to keep everything unique under rule c) above. 🧐

Conformance with URN Syntax

no special considerations. ✅

Validation mechanism

none other than names being derived from the NZGLS thesaurus "dictionary". 📚

Scope

global, but primarily of national interest. 🌏💖

3. Namespace Considerations 🔭

the SSC did a preliminary study of the URI alternatives against the key requirements. the options were narrowed down to five: a private URI scheme, URL, PURL, IRI, and URN. URN came out as the most appropriate URI against the criteria. 🏆

consultation on the preliminary study was actively sought from the Internet Society of NZ (InternetNZ), the NZ Computer Society, applicable vendors, and government agencies. publication on the e-government web site allowed for public participation too. 🫶

points that should be noted are:

  • a) with respect to the NID, the New Zealand Government is the first known jurisdiction to apply its globally known ISO 3166 Alpha-3 country code to become a URN. one objective of the ISO 3166 Alpha-2 and 3-letter country codes was to provide uniqueness. 🌟
  • b) the namespace follows the logical structure of the NZGLS, as shown in the examples above. 🧠

4. Community Considerations 🌈

providers of government information for data exchange benefit from the publication of the namespace, because it gives much-needed guidance on generating target namespaces for schema development. it uses a process that reflects what they already know, namely metadata creation in NZGLS. the identifiers under the "govt" specifier will track the terms used in the New Zealand government thesaurus. 📊✨

consequently, New Zealanders will ultimately benefit, since the exchange of more structured information could improve online experiences in areas such as forms design. 🇳🇿💜

any citizen or organisation with Internet web browser capability is entitled to access the namespace and its associated application, registration, and resolution services. 🌐 while the assignment of identifiers will be managed by the SSC, additional specifiers (such as mil, co, org, and their <nz-specifier defined string(s)>) can be openly applied for and registered by anyone, following an approved namespace governance process and proof of the applicant's bona fide association with the intended specifier (i.e., no squatting or hoarding). 🚫🦋

5. IANA Considerations 🧚

this document includes a URN NID registration for NZL, for entry in the IANA registry of URN NIDs (see RFC 2434 [5] for more information). 🎀

6. Security Considerations 🔐

okay bestie, the security section is short but it's giving "stay alert" 👀. The main worry is spoofing, meaning someone pretending to be someone they're not 🎭. Nothing else serious is expected. The good news is that the people applying for a specifier, registering it, and getting it assigned will be checked through existing government processes, so the applicants and their link to the proposed specifier get authenticated ✅. Trust is the whole vibe here 🫶.

7. Acknowledgements 🌸

this one is a shoutout to everyone who came before us 💖. The specification here is built on STD 66, RFC 3986, and RFC 3406, so whatever those documents acknowledged still counts. The authors also want to thank Leslie Daigle and Ted Hardie for their suggestions and review, because they helped make this doc so much better 🙌✨.

8. References 📚

8.1. Normative References 💅

  • [1] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
  • [2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [3] ISO 3166, "Country name codes", ISO 3166-1:1997.

8.2. Informative References 🦋

  • [4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  • [6] URI Planning Interest Group, W3C/IETF (See acknowledgments) September 2001, <http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/>.

Authors' Addresses 🎀

Ferry Hendrikx
Information & Communications Technology (ICT) Branch
State Services Commission
PO Box 329
Wellington
New Zealand

Phone: +64 4 495 6600
EMail: ferry.hendrikx@ssc.govt.nz


Colin Wallis
Information & Communications Technology (ICT) Branch
State Services Commission
PO Box 329
Wellington
New Zealand

Phone: +64 4 495 6600
EMail: colin.wallis@ssc.govt.nz

Copyright (C) The Internet Society (2006). 🌈

okay so this document is covered by the rights, licenses, and restrictions in BCP 78, and unless BCP 78 says otherwise, the authors keep all their rights 💜.

This document and the information contained herein 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 doesn't take a side on whether any Intellectual Property Rights (or other rights) claimed for the technology in this document are valid or how far they reach, and it doesn't say whether licenses for them are available either 🙈. It also hasn't done its own search for any such rights. 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 available, along with any promised licenses, or the results of any attempt to get a general license or permission for implementers or users of this spec to use the proprietary rights. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🔍.

the IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to tell them about it. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 🫶

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💖✨.

📦 where this page comes from