Re: [urn] corporate URN namespaces

John C Klensin <john-ietf@jck.com> Tue, 30 January 2024 15:33 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83636C151072 for <urn@ietfa.amsl.com>; Tue, 30 Jan 2024 07:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV19yZqqA9yJ for <urn@ietfa.amsl.com>; Tue, 30 Jan 2024 07:33:12 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF2AC151075 for <urn@ietf.org>; Tue, 30 Jan 2024 07:32:49 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1rUq6S-000HDj-As; Tue, 30 Jan 2024 10:32:48 -0500
Date: Tue, 30 Jan 2024 10:32:42 -0500
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, urn@ietf.org
Message-ID: <0C274E40D3F576FC46A1D705@PSB>
In-Reply-To: <6c0de4ca-dbc0-401d-b1df-34147ec9829b@stpeter.im>
References: <6c0de4ca-dbc0-401d-b1df-34147ec9829b@stpeter.im>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/R9rLLuzslePuDTx5fzhbxMW4zqc>
Subject: Re: [urn] corporate URN namespaces
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jan 2024 15:33:14 -0000


--On Friday, January 26, 2024 12:36 -0700 Peter Saint-Andre
<stpeter@stpeter.im> 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