Re: corporate URN namespaces
Peter Saint-Andre <[email protected]>
| Newsgroups | gmane.ietf.urn |
|---|---|
| Message-ID | <[email protected]> |
On 2/2/24 4:55 PM, Peter Saint-Andre wrote: > On 1/31/24 12:03 PM, Peter Saint-Andre wrote: >> On 1/29/24 1:14 PM, Dale R. Worley wrote: >>> Peter Saint-Andre <[email protected]> writes: >>>> I'm curious how community participants and expert review team members >>>> see the matter. >>> >>> Hmmmm... I'm not so concerned by circumscribed organizations creating >>> their own pseudo-URNs for their internal usage. I am concerned, though, >>> about a namespace that's meant to be used to interoperate between >>> systems operated by many organizations, but the details of the namespace >>> are not made public. This happens particularly when a trade group >>> standardizes a bundle of technology but keeps the details secret. >>> "*This* part of the Internet is private to members of the club!" Even >>> in the situation of the Thread Group, where it seems anybody can obtain >>> the details, but nobody is allowed to discuss them in public. >> >> To your first point about circumscribed organizations, when I worked >> at Cisco 10+ years ago, engineers on a project I was advising wanted >> to create a namespace "urn:cisco". That would have been convenient for >> them, but no one proposed reasonable governance for the namespace >> (e.g., Cisco has multiple CTO offices for different product lines, so >> it wouldn't have been easy to centralize issuance of URNs, although >> perhaps folks could have used "sub-namespaces"). In the end I believe >> the project decided to use HTTP URIs as XML namespace names, not URNs. >> >> But yes, that kind of thing would have been tucked away in a single >> company's product. I suppose the same is true of what LinkedIn and >> Amazon are doing in the examples I mentioned. We need to ask ourselves >> whether we really care about such things. Perhaps I'm making a >> mountain out of a molehill... > > Thanks to a message sent to IANA on a related topic, I just now found > documentation for the urn:li namespace: > > https://learn.microsoft.com/en-us/linkedin/shared/api-guide/concepts/urns?context=linkedin%2Fcontext > > This usage is especially problematic because it violates Section 5.1 of > RFC 8141, which states the following constraint on NIDs: > > 3. It MUST be more than two characters long, and it MUST NOT start > with ALPHA ALPHA "-", i.e., any string consisting of two letters > followed by one hyphen; such strings are reserved for potential > use as NIDs based on ISO alpha-2 country codes [ISO.3166-1] for > eventual national registrations of URN namespaces (however, the > definition and scoping of rules for allocation of responsibility > for such country-code-based URN namespaces are beyond the scope > of this document). As a consequence, it MUST NOT start with the > string "xn--" or any other string consisting of two letters > followed by two hyphens; such strings are reserved for potential > representation of DNS A-labels and similar strings in the future > [RFC5890]. > > (Note that "li" is the country code for Liechtenstein.) > > I'm going to try again with some of our contacts at Microsoft. After much digging, I might have found a repository where I could file an issue with the LinkedIn team, so I've done that: https://github.com/linkedin/rest.li/issues/976 Next, Amazon! Peter _______________________________________________ urn mailing list [email protected] https://www.ietf.org/mailman/listinfo/urn