[urn] Re: Registration request for urn:thread:
Esko Dijk <[email protected]>
| Newsgroups | gmane.ietf.urn |
|---|---|
| Message-ID | <DU0P190MB1978F2DCCBAEF4831547DE27FD272@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> |
Hi all, Based on the prior discussion in January, and internal discussions after that, we decided on maintaining the URN registry for "thread" in a Github repo. (So, not in a downloadable doc on our website.) This can be easily browsed by clicking the links. Access link: https://github.com/ThreadGroup/urn-thread-registry/ If new items are added by new specifications, this will be reflected in the registry. Also we've updated our registration request template based on the review and to provide the reference to this online registry. New template: https://github.com/ThreadGroup/urn-thread-registry/blob/main/urn-registration-v1.txt (still at v1, since the previous request was never completed & approved). Based on this template, we're now requesting for the "thread" URN namespace allocation. Hopefully all the required information is now available! If not, just let me know. Best regards Esko Dijk IoTconsultancy.nl (on behalf of Thread Group, Inc.) -----Original Message----- From: Peter Saint-Andre <[email protected]> Sent: Monday, January 29, 2024 21:15 To: Dale R. Worley <[email protected]>; Esko Dijk <[email protected]> Cc: [email protected] Subject: Re: [urn] Registration request for urn:thread: On 1/29/24 1:06 PM, Dale R. Worley wrote: > Esko Dijk <[email protected]> writes: >>> Section 5.1 of RFC 8141 states: >>> >>> Formal URN namespaces might be appropriate even when some >>> aspects are not fully open. For example, a URN namespace might make >>> use of a fee-based, privately managed, or proprietary registry for >>> assignment of URNs in the URN namespace. However, it might still >>> benefit some Internet users if the associated services have openly >>> published names. >>> >>> In this case, I would say that the letter of RFC 8141 overrides the >>> spirit of the IETF. >> >> Indeed this section was the basis for including a privately managed >> (members-only) and non-public registry in the request. (Non-public, >> because viewing it requires accepting the EULA.) >> >> There is a suggestion there to have at least the names - that are in >> the registry - published. That is something we could add as a >> requirement for any entries in the internal registry, if that helps? >> >> The public version of the registry would be in a separate document >> that can be downloaded from www.threadgroup.org without providing a >> name or accepting a EULA. And each registered URN would provide the >> name and a short description also. Something like the table provided >> by 3GPP >> (https://www.3gpp.org/3gpp-groups/core-network-terminals-ct/ct-wg1/uniform-resource-identifier-uri-list) >> for example. It would then provide a link / doc-reference pointing >> into the non-public specification. > > Given what Peter and Lars have said (and what RFC 8141 says!), I agree > that this is a reasonable solution to all of these concerns. Excellent. I'm on board with this, as well. Peter _______________________________________________ urn mailing list -- [email protected] To unsubscribe send an email to [email protected]