Re: [urn] corporate URN namespaces

"Palek, Stephanie" <S.Palek@dnb.de> Wed, 31 January 2024 18:09 UTC

Return-Path: <S.Palek@dnb.de>
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 44E52C14F5F3 for <urn@ietfa.amsl.com>; Wed, 31 Jan 2024 10:09:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 THLW98buPrm6 for <urn@ietfa.amsl.com>; Wed, 31 Jan 2024 10:09:52 -0800 (PST)
Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14087C14F5E5 for <urn@ietf.org>; Wed, 31 Jan 2024 10:09:51 -0800 (PST)
Received: from dnb-tmg.ad.ddb.de (tmg.dnb.de [10.69.66.203]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.dnb.de (Postfix) with ESMTPS id 52B744507CDA; Wed, 31 Jan 2024 19:09:48 +0100 (CET)
Received: from dnb-tmg.ad.ddb.de (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DC8D7A4056; Wed, 31 Jan 2024 19:09:47 +0100 (CET)
Received: from dnb-tmg.ad.ddb.de (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C7DC5A4055; Wed, 31 Jan 2024 19:09:47 +0100 (CET)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.215]) by dnb-tmg.ad.ddb.de (Postfix) with ESMTPS; Wed, 31 Jan 2024 19:09:47 +0100 (CET)
Received: from dnbf-ex1.AD.DDB.DE (10.69.63.215) by dnbf-ex1.AD.DDB.DE (10.69.63.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7; Wed, 31 Jan 2024 19:09:47 +0100
Received: from dnbf-ex1.AD.DDB.DE ([fe80::3518:9c6b:49b8:3f94]) by dnbf-ex1.AD.DDB.DE ([fe80::3518:9c6b:49b8:3f94%16]) with mapi id 15.02.1118.007; Wed, 31 Jan 2024 19:09:47 +0100
From: "Palek, Stephanie" <S.Palek@dnb.de>
To: John C Klensin <john-ietf@jck.com>, Peter Saint-Andre <stpeter@stpeter.im>, "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] corporate URN namespaces
Thread-Index: AQHaUI76XXxCj/P/c0i7JMbrUKp5Z7DycT8AgAHMsAU=
Date: Wed, 31 Jan 2024 18:09:47 +0000
Message-ID: <dae037cabcc4448bb3ca45c0d89a9a4e@dnb.de>
References: <6c0de4ca-dbc0-401d-b1df-34147ec9829b@stpeter.im>, <0C274E40D3F576FC46A1D705@PSB>
In-Reply-To: <0C274E40D3F576FC46A1D705@PSB>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.62.20]
Content-Type: multipart/alternative; boundary="_000_dae037cabcc4448bb3ca45c0d89a9a4ednbde_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2164-9.0.0.1002-28152.007
X-TM-AS-User-Approved-Sender: Yes
X-TMASE-Version: IMSVA-9.1.0.2164-9.0.1002-28152.007
X-TMASE-Result: 10--38.950900-10.000000
X-TMASE-MatchedRID: N9BlHcIKJ5oH7SgbGDpYTBlJKXOepS1tyqyllX6UJIu33eLTZUJxwBy7 MkaYvOFgPjJw/cad5tbRhlG8MjLrXFyDR0kMA1NK2Qe1DVqRHy+xT02+VRUpqXndpHng2VQm/L4 h+S8DcywHKWdS7YRsImZYfrhq18sLwROGkfcOBpOdVNZaI2n6/8TGavmGo0vWGcsNJAT81Srjo+ A3552ljVHbg+Jua+gG4sZl7t7wI3+cUExL+2VdygewBVjD2SDGeLLCA0PD7ahuS8Amg5D32UQd/ UFh0JGKhN/EeTvmsNo+DG6b9HwFgSfXYAYR9ZYlSXIxnjwYrBR2ZYwNBqM6Igtll7E078ZRyFsn 4GiRCXzmYym+srOznLvLap9h7c1qjD8/BqGun12If3m0sUfx50+crEA4+nhZ7VXIF599T6OH3wo cULY39IQchiWv8b5WedrhR73fo6Kp3KXgFaJmvrhXT+72mpTN9pLnYtQ99xJmGa/QeHIhYfNO7f lRFqXmV6FnwkMygZcf1AdLUyG7nW0Xr+fj3ww/rNKxm3nhqPt2L/JYguM0e0v/etCZatMGOCjyk McvhP5heLlCUerNR4KjoYyABoT3b0esXyL20NDda2gq6UV1auKBFzn2Pnofnt/M15zYPUNyYyYB ymq60x40pxVe/+IJ8bpNuDuv/Pn8p0smSIbGaKmvdEdMifXcv/7xdLQjXSLcdI9VufmgkJKKyPj QM7x/rkcpU1TB3MY+1BK+Wn6hYTTVrcg/lInnBxsweNg3EaHHVXsVzWFAqWNDj9w6cf26oOaQvO 0H0Bbi8zVgXoAltk77e4Y1xq/3CIEb6m1h9zyx5amWK2anSCUIayx+Skid
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/_3KnOHOBDP752Bm9MVuPw2agU6M>
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: Wed, 31 Jan 2024 18:09:56 -0000

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 <urn-bounces@ietf.org> im Auftrag von John C Klensin <john-ietf@jck.com>
Gesendet: Dienstag, 30. Januar 2024 16:32:42
An: Peter Saint-Andre; urn@ietf.org
Betreff: Re: [urn] corporate URN namespaces



--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

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn