Re: [urn] corporate URN namespaces
Peter Saint-Andre <stpeter@stpeter.im> Fri, 02 February 2024 23:49 UTC
Return-Path: <stpeter@stpeter.im>
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 B9DBBC14F6B6 for <urn@ietfa.amsl.com>; Fri, 2 Feb 2024 15:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b="4qxtOMJ4"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="eBnCdQ0X"
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 VX73KWZiBQwZ for <urn@ietfa.amsl.com>; Fri, 2 Feb 2024 15:49:39 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 11C0EC14F5E4 for <urn@ietf.org>; Fri, 2 Feb 2024 15:49:38 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E98CC5C00BB; Fri, 2 Feb 2024 18:49:37 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 02 Feb 2024 18:49:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1706917777; x=1707004177; bh=n66vWZg+Vn0+xf17UQSzQkWQQNu+SMIXudhW9VWScEY=; b= 4qxtOMJ4EPT8etdlWbN5xDWA7IntQ+/uFZSW2NkEN7YWFFDH5tMU+Jh/5mkCMOHI Pl8s0GqLRXrsheHUFAnXNQelf3r1nNJ07U0OpYr7L+8S88lGbFB+luAioJIixk+g jhk4e4b0ER55vVuSV9aaUu3ZVKbq/TpTVU7wy/POGdTAzTPcCx7mqkaZ0Vqr9Lwr pIAlQch9ofGjixW9JiXR5CRUdtH+gFvt2EFSUYIsqZD6Xrg+Ep7nXZMzd7ULZqOy NoEGONflHqOwaxF2cb7Y5FKix1QO4kA6Wi6+EfWBGwxVUkroD+Dof5Sf+raSzqIc NPJlNc54zgh7CJDofTYsiw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1706917777; x= 1707004177; bh=n66vWZg+Vn0+xf17UQSzQkWQQNu+SMIXudhW9VWScEY=; b=e BnCdQ0XL2WGf7QaRbARHKZlyqVeYjSvvYomBJ937rP3HCiF2nIgl2toWlB9BDjK5 CJRQWjKYblv9U19Szlm+pqA33rP9h53Y/10Cjh8PXLAmMsnFVTSkxP15xrzkn/t2 euwOBBCZFaMaLJbPi02xn7Fm46pLfTnmPfDn7yORnqcEP6UMnYb/+o/2fagGOloQ OFZuVf75nT03ZoHH4JAAeEa/QZp3+A0porUWjY84JTI4yvyI7iqD0QwRaB2xq7PI SnMO2hRdG5bpx/TNqkeSw/8ZT5EhloXpgSacvOnhlskbxwcxXCRJ+PI5IHxfoNGA fV6BR0u+FHefGiM28x+Tw==
X-ME-Sender: <xms:kX-9ZWkT_xW9a6Oo8bNZxe_NI6VlB3a1XjsKYCjFlbxw7xiBxL6gMA> <xme:kX-9Zd21zcNBhw_jzhB9jRBiUy77g9UiUnlkWe4NhCeFPnkc6ur6wSWjT8FFGq5yE vCzvcP6Jhf_xf7cvQ>
X-ME-Received: <xmr:kX-9ZUpVF3VRIjkHnUqCBwWfeLrWTOuKshliVhEAesuRq7pxmk_6H-zO4KdeC-2F>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfeduhedgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtje ertddtvdejnecuhfhrohhmpefrvghtvghrucfurghinhhtqdetnhgurhgvuceoshhtphgv thgvrhesshhtphgvthgvrhdrihhmqeenucggtffrrghtthgvrhhnpeevueeigeevteegle ehteejjeetgeekffegffetkeektdfhvddtueduteejieejveenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthhpvghtvghrsehsthhpvghtvg hrrdhimh
X-ME-Proxy: <xmx:kX-9Zak4q-KodgwrliDt2MGg4DCobvKmOkbr6tRZ0UqMi6OqrfYoxA> <xmx:kX-9ZU263l3p59Q8jUc-FX-Wrha8dEQ16Mu1cUhMBvF2yZSSeclqrw> <xmx:kX-9ZRsdGRnFO-g2QpQfCqncwl8OsF8ZIYvQwWz4FshR_7xtOu-Gpw> <xmx:kX-9ZSDkV-ww_lfLk8rb2-bWTGicK4F-W7DXGbSbvkkBNwiFe6qI3Q>
Feedback-ID: i24394279:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 2 Feb 2024 18:49:36 -0500 (EST)
Message-ID: <71308ab2-e1fd-4f39-80f1-d8dbb248260e@stpeter.im>
Date: Fri, 02 Feb 2024 16:49:36 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: John C Klensin <john-ietf@jck.com>, urn@ietf.org
References: <6c0de4ca-dbc0-401d-b1df-34147ec9829b@stpeter.im> <0C274E40D3F576FC46A1D705@PSB> <7e4bec70-deb1-45e6-b432-c45ad365cdbb@stpeter.im> <9E698B7ECB692C39EE9ED28A@PSB>
From: Peter Saint-Andre <stpeter@stpeter.im>
Autocrypt: addr=stpeter@stpeter.im; keydata= xsFNBFETDzsBEAC0FOv1N3ZJzIIxN6cKD475KVS9CHDPeYpegcOIPnL5eY1DCHeh/IwS1S7R CePtmiybNoV9FsI4PKUknzXQxA6LVEdAR/LUlhgJKjq+gsgp8lqbEILhg13ecH66HwLS9rar bQkC47T7kL8miIPBFC6E3A4Lq1L+eueO6UcLhKgoYkMxOjdiWrMgKTnVpch5ydLkPm/z0Zo8 zRgqlPuTLeCrXXZYnjHXLVFN2xy04UzOs7P5u5KVfx5Z7uQisr8pXtyLd6SpTZo6SHgKBv15 uz0rqXhsJojiGtOXfWznAjaS5FUOORq9CklG5cMOUAT8TNftv0ktsxaWDL1ELDVQPy1m7mtz o+VREG+0xmU6AjMo/GHblW1UU7MI9yCiuMLsp/HLrFuiosqLVZ85wuLQ2junPe3tK8h15Ucx IXAcpQ1VqIaDQFbeuLOXJTF8YHpHdpHYt/ZM1ll7ZBKGAo8yd7uF7wJ9D3gUazwdz9fFjWV7 oIk7ATwOlFllzmWDn+M2ygbHOGUGMX5hSaa8eDSieiR2QoLdn27Fip7kMBTJ2+GISrfnJTN/ OQvmj0DXXAdxHmu2C4QgmZbkge35n129yzXn9NcqzrGLroV62lL3LgX6cSbiH5i7GgWY6CAP b1pMogV0K475n9FvOSDRiG4QSO5yqKiA3OP5aKrIRp2TNAk4IwARAQABzSZQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBzdHBldGVyLmltPsLBeQQTAQIAIwUCURMPOwIbAwcLCQgHAwIB BhUIAgkKCwQWAgMBAh4BAheAAAoJEOoGpJErxa2p6bgQAKpxu07cMDOLc4+EG8H19NWXIVVy bOEvfGuHYZaLKkPrhrMZwJiOwBpyISNRt9qzX1eLCVaojaoEVX6kD8MGc5zKFfiJZy3j7lBW l+Ybr7FfXYy2BbAXKx49e1n6ci9LmBrmVfAEaxtDNPITZ9N9oUAb9vS0nrG036EwteEHAveQ vlDjO7lhz6+Cv7lZQgBj9rZ6khfcQ4S3nSCQaKLQ9Iav4fqxI7SfuPKnx6quHX3JNLGnVo3w l+j/foCK0iTrmtHxCI3kc/bx6g32pRjHEPX0ALMBhmzU2uca+TE0zCEC96mgYXAUCwdnCFWy beIEbt6pz65iML13kAVAq0H/GqncnMGN0MbOatnw1Tdz/vkLojIy7QbPcQ0plUFxv5491xPf IrHhOWdRXp6WUt88fcqhT6MHZpVRtusj2ornKVVn+Y0GLsMMCTcrXJRG7Ao1YV72t/pJpzfG WSaaxolxDIZ6B+76jrIhUhiWgo/4nf+DN6BIlCZQ6j6xxjjx462cu02kuhIILTk2pzaMOufT BWx0uJhZk/KP2Fay/41pX7pvVOwRC4uIlKsLnJKLPS7EDa4BUUxENfd/9LqOGwlII8BbSe98 PLMI8sXkcigc3UXMVda9ll0YhQa+lbP1NaszmnBhwuiCsgnPGbImsJuRzgEEgckwP/dNeyr6 MlFMyfaezsFNBFETDzsBEADBzOsEHpUmhkRUjH9Tek87dn5P/Yh/L/HptgCGk40TL/C+kYdk d3HyteMEf061PNmsS/Rq8k37Fu3VODYb9SPYKxtgksKSYUtIkPKvao09K9QNWPqyWuNf0F+i AjVMUudaEVFJ7bHF310RDwLY5IvLeCXxtvG+Vv/i+g77d2WdPDp+zLJ8306C4yBKjSJV8xW0 cn2fd7NviIEN6cNHTsZNDZVMlgYPrxnwSq8GTEPGC7HsLIwGcx3hIe9QjnPw9CpAmQENpDEy WcxgF5uwo2NJECoDswKz1Nb0gfawF3ZIbD+GcLujTu94iJuVg25jATWm9wTgcfZo4UPllRGX dIb8uWwUFQlLQgd4ROLZZtXNGmHIymJrV2crx53gxup+1j0XqhlzKg8xbImWhEfS9oHZkRK8 VHgmWSIt7TNwNir6N5j3lqwWVBhnu6GzF01sKGNySlqNRbd0fqhakCkK71b8ot8tYTcYG5Lg 10z6HTbgQx2UwLthUjqbblDQ+GLmrOhiWklLXRsnlnPMwnEyFePAnsT5tasy2Cn9qjpttNDa h7PB8iFUi9mtTF/XDVgpFaB5G3CDV7Q2NgbAI6g6QhLIAmXzSP635G83mda0TKXHQXHDyLJT Tn+WVFU7t4m4uLt+0DsWU8jXHQWyUTNG9WPUrXhusDUAPHxFCQ/n/lQVBwARAQABwsFfBBgB AgAJBQJREw87AhsMAAoJEOoGpJErxa2pqfgP/ApN+TRu2bBIgaw1dr3AznSSha84DIpXUDh3 udZvQrGbUtz8/mA+e3iZEN/cmmBw2LGlAuQoJNILTZQ318yTP+E5QU7fJH7FVsohUyvrMfyt 3IMA9jg0Z9MuloLezvIjjMfFeNa0ROgDb/ubOT7JQzi1kwN8Lu3lO80HwqBHXEeOLoislUSn ZajRKvITbKWkZ6PHRjlMw1Wk4oIi6VLHgGgj79zzL3uhML2663m7imShvz1QcHTwvyR5i8cZ bNOEkotZyERiA1p7YHuruS+QvTi3ZPoQbnMUB3a7py9d11bw1+w3LiAUGZE/z5hBWOFxYtw+ w/U/Vx0BwJGYlwU3M2W20uEXe+qxz7wnakygKjmLiD2z4njfKjcNCiV3FmXrpmWgADln1c4j fxDh0NrndrsM8FPDf1TMPtOZgFDkKripc9xkZ/25P6xn27oTOHWKcAC0QhxSH+HuVBBRk8Ag F+zAbDZe4/L6+kanSrycIXW+wCzwBq61aWsz2QhhuKjozVkhk4dRG+CfjzAFjnyxwYERn3uX VKQAwTwcdNcTI9RV98IsNrw9Y4lJEAg6CjNPmiD5+EASycqaOuToRSGukr8sOQLWLPyTnez/ aG8Xf7a+fntWzK2HuDYoSDhJJrylWw/lMklOBm4wtMeNA0zcQH6AQV/GzQVQkSGqrLuMVIV/
In-Reply-To: <9E698B7ECB692C39EE9ED28A@PSB>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/oa_bA60nnP4eVAbmJiZNfT38VuE>
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: Fri, 02 Feb 2024 23:49:43 -0000
I agree with 90% of your 10%. The remaining 1% inline. On 2/1/24 6:22 AM, John C Klensin wrote: > Peter, > > I agree with 90% of what you say. Other 10% inline below. > > --On Wednesday, January 31, 2024 11:53 -0700 Peter Saint-Andre > <stpeter@stpeter.im> wrote: > >> Hi John, thanks for sharing your perspective. Comments inline. >> >> On 1/30/24 8:32 AM, John C Klensin wrote: >> >>> 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. >> >> RFC 8141 states: >> >> This document rests on two key assumptions: >> >> 1. Assignment of a URN is a managed process. >> >> 2. The space of URN namespaces is itself managed. >> >> One thing I'm uncomfortable with here - not with your proposal >> but with the underlying situation - is the fact that if at >> some level we accept unregistered URN namespaces, then we're >> not living up to assumption #2. > > Yes. > >> Overall I'd say we have done a decent job of managing the >> space of URN namespaces: the vast majority of SDOs and other >> projects we've engaged with have worked in good faith to >> define their usage of URNs, and for the most part this >> discussion list has led to improved transparency regarding URN >> usage on the Internet. (To be clear, we've had a few failures >> along the way, e.g. namespaces we didn't get registered >> because the registrants ran out of energy or patience with the >> review team.) >> >> It seems less than ideal to allow third-party registrations >> that are mere placeholders so that we can avoid conflicts. >> Indeed, those don't feel like *registrations* at all, in the >> sense of fulfilling our responsibility to manage the space of >> URN namespaces. (Furthermore, it feels disrespectful toward >> everyone who has properly registered their namespaces.) >> >> I'm not completely opposed to what you suggest, but I'm not >> completely happy with it, either. > > I agree and share your unhappiness. I was just trying to > reflect what seems to be a general IETF trend that I would > describe as "forget all that other stuff and the reasons for it, > just get it registered to prevent conflicts". That has resulted > in updates to several protocol specs moving, e.g., from "RFC or > IESG-approved Experimental" to "Specification Required" or > lower. That does not make me happy either, but I recognize the > reasoning and the trend. > > Given that, and given that allowing third-party registrations > would presumably require an update to RFC 8141 anyway, let me > suggest a different alternative. I haven't quite figured out > how this would be defined, much less what we would tell IANA > about naming (because any list they keep is called a registry) > but what would happen if created a separate list, not for > registration of a URN namespace but of names that had been seen > in the wild and, in violation of the clear intent of 8141, had > not gone through that process? It might not surprise you that I had a similar thought. ("Great minds think alike" or "fools never differ"?) > Such a listing would clearly require some minimal protection > against DoS attacks, but so would a third-party registration. > Submission of copies of web pages or messages would be a start. > > I think I'd rather see it as an IANA collection because presence > in that hall of shame might motivate some companies to actually > register but, if if that would be problematic, I could see a > wiki or github listing somewhere and a sentence in the header of > the IANA URN namespace registry that said something like "an > informal list of known names in use in violation of the specs > may be consulted to avoid unintentional naming conflicts if one > is considering a new namespace and name". To some extent, I think it depends on what we're trying to accomplish with this list. I see two main purposes: 1. Encouraging organizations to register their namespaces 2. Avoiding namespace conflicts It's not clear to me that purpose #1 will be met more effectively with a public list than with reaching out to people we know at the offending organizations, but just possibly it might help. Do we know if this method has been successful with other registries? Purpose #2 is more limited but potentially useful (and as you say could be met with a simple web page at a wiki or GitHub). Peter
- [urn] corporate URN namespaces Peter Saint-Andre
- Re: [urn] corporate URN namespaces worley
- Re: [urn] corporate URN namespaces Lars G. Svensson
- Re: [urn] corporate URN namespaces Peter Saint-Andre
- Re: [urn] corporate URN namespaces Palek, Stephanie
- Re: [urn] corporate URN namespaces Peter Saint-Andre
- Re: [urn] corporate URN namespaces Peter Saint-Andre
- Re: [urn] corporate URN namespaces John C Klensin
- Re: [urn] corporate URN namespaces John C Klensin
- Re: [urn] corporate URN namespaces Peter Saint-Andre
- Re: [urn] corporate URN namespaces John C Klensin
- Re: [urn] corporate URN namespaces Peter Saint-Andre
- Re: [urn] corporate URN namespaces Peter Saint-Andre
- Re: [urn] corporate URN namespaces John C Klensin