Re: corporate URN namespaces

Dear all,


I agree with John - the biggest issue really is that the namespaces are unregistered and if repeated attempts to contact them to do so failed, this proposal seems like a good compromise. It's not ideal, but would definitely be preferable to the current situation... (obviously this ignores the other issues, but it's a start).


All the best


Steffi

________________________________
Von: urn <[email protected]> im Auftrag von John C Klensin <[email protected]>
Gesendet: Dienstag, 30. Januar 2024 16:32:42
An: Peter Saint-Andre; [email protected]
Betreff: Re: [urn] corporate URN namespaces



--On Friday, January 26, 2024 12:36 -0700 Peter Saint-Andre
<[email protected]> wrote:

> Hi all,
>
> You might be aware that various corporations have created
> their own URN namespace IDs without registering them. As
> examples:
>
> URLs for LinkedIn posts are of the form
> https://www.linkedin.com/feed/update/urn:li:activity:somelongn
> umberhere/ (presumably they use the standalone URNs somewhere
> in their system).
>
> Similarly, Amazon uses URLs containing
> urn:rtn:msg:somethingsomething in emails to you about product
> returns; here is a truncated example:
>
> https://www.amazon.com/gp/f.html?C=2WFAH2342Q3N1&K=3SEUCCRFF9W
> AS&M=urn:rtn:msg:202401201905199531b363910d4325b9b8a9dd8910p0na
>
> And so on.
>
> So far, I have tried without success to contact people I know
> at these companies about the namespaces they are using.
> (Naturally, it is not our job to chase these people down, but
> the current situation seems less than optimal.)
>
> Under RFC 2141 / RFC 3406 we actively discouraged registration
> of URN namespace IDs by commercial entities, but we dropped
> "policy" that in RFC 8141. As long as a corporation provided
> documentation of their URN structure and followed the
> registration rules in RFC 8141 (etc.), it seems to me that
> we'd likely approve such registrations.
>
> I'm curious how community participants and expert review team
> members see the matter.

Peter, a few quick thoughts...

This situation stinks although I think we should be glad they
recognize the value of URNs and are willing to use them.  Part
of the stink is not the fault of the companies involved but the
decisions elsewhere that result in their having to embed the
URNs in https URIs.

I wonder whether we could borrow a note from some very early
IANA registration policies and allow third-party registrations,
e.g., allow you or someone else who notices one of these things
to record the usage in the database as a third-party
registration.  If one of our primary goals for having the
registry is to avoid inadvertent name conflicts, then knowing
that (using your examples) LinkedIn is using "li" for a
namespace and Amazon is using "rtn", and both are using them on
the public Internet (embedded or not), there would seem to be a
public interest in having those names registered.  Having them
register them would be ideal.   However, if they won't even
after reasonable efforts are made to contact them, having a
registry record that looks something like:

 li  (3rd party) (Observed YYYY-MM-DD in the wild
        embedded in https://www.linkedin.com/feed/update/ )

would seem to be in the interest of a better Internet and URN
system.  If the result is that they decide to "claim" the
registration and replace the information with their own, so much
the better.


There should be no privacy or IPR issues in doing that.  The
information is clearly publicly visible and I can find nothing
in their Ts&Cs that prohibit sharing their URI formats.

I hope that allowing third-party registrations of that type
would not require an RFC but, if it does, I'd be happy to do
some writing.

best,
  john

_______________________________________________
urn mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/urn

_______________________________________________
urn mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/urn