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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.