[urn] Re: Request for Registration of CTS namespace
[email protected] Fri, 12 Jun 2026 10:22:28 +0000
| Newsgroups | gmane.ietf.urn |
|---|---|
| Message-ID | <trinity-e718897e-5a13-43ce-80d4-4d6741c35b90-1781259748772@trinity-msg-rest-gmx-gmx-live-5b7c84747d-l4w94> |
--===============0878539400338587377== Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><body>Hi Dale,<br><br>I don't have a a full list=2E The namespaces th= at are connected to my project are listed at <a href=3D"https://urncts=2Eeu= ">https://urncts=2Eeu</a>=2E<br>Then there is perseus with greekLit and lat= inLit, which are not part of my project as their syntax conflicts with the = specs in my opinion=2E I also saw others but generally I think that my proj= ect is the biggest collection=2E<br><br>The registration process will be an= interesting topic to discuss=2E I understand your comment in a way that le= ads to a central authority=2E <br>My abstract idea is an open registra= tion, hosted *somewhere* that works purely on FCFS without an authority tha= t decides who may or may not register a new namespace as long as it does no= t collide=2E With the option to choose your registry similiar to how you ca= n choose your DNS provider=2E Choosing your registry would also limit the h= arm that could arise from misuse=2E<br><br>The authority would be optional,= which implies that it does not have to be named=2E<br><br>I am sure that t= his is too idealistic but if something in that direction is doable, it woul= d be my preferred direction=2E A strict authorative central registry might = be risky w=2Er=2Et=2E bottleneck problems and also invite misuse=2E<br><br>= You have to consider that each text data set that gets build up is a potent= ial CTS URN namespace while edition-projects are becoming its own "research= genre"=2E It is not unlikely that a lot of namespaces will appear within t= he CTS URN domain that would have to be manually checked in an authorative = registration process=2E<br><br>Another issue with a central registry might = come from the domain=2E It seems that the need to register namespaces is no= t very strong in the humanities :) =2E The problem with unregistered URNs w= ould escalate further if new data sets appear without registration=2E A dec= entralised registry would eliminate this problem because then it is the use= rs responsibility=2E<br><br>And finally I don't see, how a central registry= could prevent "namespace brokers" from registering and selling namespaces = to academic institutions=2E In a decentralised registry, this business mode= l cannot appear=2E<br><br><br>This will be interesting to discuss further d= uring the design of the RFC request but I think other things need to be map= ped out beforehand in order to make qualified decisions=2E<br><br><br>Best = regards<br>Jochen<br><br><br><br><div class=3D"signature">--<br>Gesendet mi= t der GMX Mail App</div><div class=3D"mail_android_quote" style=3D"line-hei= ght: 1"><br><meta name=3D"viewport" content=3D"width=3Ddevice-width"><meta = http-equiv=3D"Content-Type" content=3D"text/vnd=2Eui=2Einsecure+html;charse= t=3Dutf-8"><div class=3D"mail_android_quote" style=3D"line-height: 1"><br>A= m 11=2E06=2E26, 18:04 schrieb "Dale R=2E Worley" <worley@<a href=3D"http= ://ariadne=2Ecom">ariadne=2Ecom</a>>:<blockquote class=3D"gmail_quote" s= tyle=3D"margin: 0=2E8ex 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204, 20= 4, 204); padding-left: 1ex;"> Peter Saint-Andre <stpeter@stpeter=2Eim> writes:<br> > As team lead for the reviewers, and co-author of RFC 8141, I would be= <br> > happy to provide a letter of support=2E I will coordinate with you<br= > > offlist regarding your requirements=2E<br> <br> I agree that Peter's plan is both completely appropriate as a committee<br= > action and highly desirable=2E<br> <br> Jochen Tiepmar <tiepilab@<a href=3D"http://gmx=2Ede">gmx=2Ede</a>&= gt; writes:<br> > I am trying my best to solve that bc I dont<br> > actually want to be responsible for naming the sub-namespaces and see= <br> > it as a decentralised system=2E<br> <br> >From CTS Registraiton Request=2Etxt:<br> > Assignment: The definition of data namespaces is completely<br> > open=2E Data namespaces can be registered for the namespace resolver<= br> > based on FCFS principle=2E Data namespaces are mapped server<br> > addresses=2E<br> <br> I was just thinking that while there must be an assignment system for<br> data namespaces to ensure URN uniqueness, we don't have to have Jochen<br> do that work, or even the Saxon Academy of Sciences=2E We can just have a= <br> first-come-first-served IANA registry, so IANA does the work=2E (My<br> apologies if someone has mentioned this before; I'm trying to catch up<br> on the discussion=2E)<br> <br> Compare with the "Alert URN providers" registry in<br> <a href=3D"https://www=2Eiana=2Eorg/assignments/alert-urns/alert-urns=2Exh= tml#providers">https://www=2Eiana=2Eorg/assignments/alert-urns/alert-urns= =2Exhtml#providers</a><br> All that would be needed to define such a registry for CTS is to clone<br> RFC 7462 section 9=2E3:<br> <a href=3D"https://datatracker=2Eietf=2Eorg/doc/html/rfc7462#section-9=2E3= ">https://datatracker=2Eietf=2Eorg/doc/html/rfc7462#section-9=2E3</a><br> <br> 9=2E3=2E 'Alert URN Providers' Registry<br> <br> Values of <provider>, which are used to create <private-name&g= t;s, are<br> recorded in a new registry called "Alert URN Providers"=2E (Private<br= > extension "alert" URNs that are defined are not recorded by IANA=2E)<br= > The registry is managed by IANA under the policy 'First Come First<br> Served' [RFC5226]=2E<br> <br> The registry contains entries in the following format:<br> <br> <provider> Registrant Contact URI<br> ---------------------------------------------------------------------<b= r> example IETF rai-ads@<a href=3D"http://ietf=2Eorg">ietf=2Eorg</a><br> <br> The first value in each row is the <provider> value that is<br> registered=2E This value is case-insensitive and MUST comply with the<= br> syntax for Non-Reserved LDH labels [RFC5890]=2E<br> <br> The second value in each row is the name of the registrant of the<br> value=2E<br> <br> The third value is a contact URI for the registrant=2E<br> <br> The registry initially contains the one entry shown above, which can<br= > be used for constructing examples of private extension URNs=2E<br> <br> It is unclear to me what is required to get such a registry created=2E<br> Clearly an RFC would suffice=2E But searching on the web suggests that<br= > there are other possibilities; what is essential is (1) authority and<br> (2) a fixed, durable specification=2E<br> <br> In regard to specification, we could insert it in the CTS registration;<br= > once CTS is approved and recorded, the IANA URN Namespace registry links<b= r> to the registration, so there would be a durable specification on<br> record=2E<br> <br> In regard to authority, it's arguable that this committee has adequate<br> authority=2E Alternatively, we could request the IESG (through the AD(s)<= br> that supervise this committee) to approve the creation of the registry=2E<= br> Probably Peter should query our supervising AD(s) regarding this=2E In<br= > either case, this would create the registry more quickly than processing<b= r> an RFC through a working group=2E<br> <br> Jochen, do you perhaps have a list of the data namespaces that are<br> currently in use?<br> <br> Also, the IANA registry must contain the data namespaces and the owning<br= > organizations=2E Should it also contain the names of the associated<br> servers? Or are those just recorded in the "namespace resolver"?<br> <br> Dale<br> </blockquote></div></div></body></html> --===============0878539400338587377== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KdXJuIG1haWxp bmcgbGlzdCAtLSB1cm5AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB1 cm4tbGVhdmVAaWV0Zi5vcmcK --===============0878539400338587377==--