[urn] "relative URNs"

Peter Saint-Andre <stpeter@stpeter.im> Tue, 05 September 2023 15:32 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 C97F2C151552 for <urn@ietfa.amsl.com>; Tue, 5 Sep 2023 08:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_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="pFl4FKbf"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="EgJ2xPQx"
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 arpxeou_6XB1 for <urn@ietfa.amsl.com>; Tue, 5 Sep 2023 08:32:40 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 17FD5C14CF15 for <urn@ietf.org>; Tue, 5 Sep 2023 08:32:39 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 36AA05C0060; Tue, 5 Sep 2023 11:32:39 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 05 Sep 2023 11:32:39 -0400
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:sender:subject:subject:to:to; s=fm2; t= 1693927959; x=1694014359; bh=F7jIE8WAoXFh4CCYerIRJXJHe9636ySt8Md mwLD3NW8=; b=pFl4FKbfIg3fPOCUpp6vFiA05GQtgA1W4VrYHRXF18FHFK0OXLY 4ttzDNO0fISk63fkjl6MIdn2dLnJMKpBSOWT3osaPZntcpYmFGS+MatxW/ACt4/9 UDv5/v4x3g950vub35IWaxUSL8n5H2BsG3t/+xl7pWOnVFWdap0L7Ijt67ARmj/N WpVQM5QsZMZ6Ce0ocahEZrECbJGXKDEVDwBuW5L/zZc+AiJYPxjnHvclN+DggIru LubquZXeGh13umvBcI/Y5fSL58JQewHODcslZ5gAO48Rj3nuEpSEdNbKO752qHhR vCu/ZstpfqQhpAppp18TGWEL8VuNiz6f9Lw==
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:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1693927959; x= 1694014359; bh=F7jIE8WAoXFh4CCYerIRJXJHe9636ySt8MdmwLD3NW8=; b=E gJ2xPQxiIw3HvN/Kgf+us8r/OgqhpbNbvcvLwEq1XO3WxYmxw6G/8kqzNoKPc4VF m+beWkMC/7X1S/Hcwl7wk46n+qg790iT9tMGL6VAwOh/rJ9U1AwxH+fcX8yyhkR4 56P9nNkjhsdGuArMtWuZF4ymBVg9snUYI+5fPjAqONUMHoQnpsxOVW0pCR5454uZ H/bGdYU8tasOQnDGY12PsQAC5ul5BDFJu75r9rnPSbRp13S5MZNodBh+Yy3dF7vL bfrThxozLmE8Pzo/R8+bUe1yA9fnAuNtyVZCQbnHN3gtCl5KLoWqywFPklIdjnSw Ea+HP5TW6wtfkzi91L0OQ==
X-ME-Sender: <xms:Fkr3ZCOeV0HVEiYGtybiok0kP-xSXzDaH3HGRGZLhh94a9beyllMrQ> <xme:Fkr3ZA_jm_RODAFgwf5wt19OIs0f5MsnvVsGdMnzU2whnFzeUCFRUuoyypMdLJQON OURCSRrSRL0_LhlsQ>
X-ME-Received: <xmr:Fkr3ZJR_k3_2WCA_kh6AtSsW48MqWsTSofJchcMHzD0oSYS-TnqfE73XyR0DxxAB>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudehuddgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfvfhfhffujggtgfesthekredttdefjeenucfhrhhomheprfgvthgv rhcuufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimheqne cuggftrfgrthhtvghrnhepgfeugeefvdekteefgeekkeeggffgueetteehgedvgfffveeg kefgleehtdegteefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm
X-ME-Proxy: <xmx:Fkr3ZCu2vw8QXt-3EonXEdLq5OE3CM0J56L6rdpNezSwV8SZub5Lew> <xmx:Fkr3ZKf2MmjQLMQGumajMnDE3CNb3LNV--9T6zUQ_b-n4CrzJr0a7g> <xmx:Fkr3ZG2rJ9xJb1zBKpLpmcJDjIIowFxTXBlePPLHOX1FfuH1rkGTaw> <xmx:F0r3ZOE7aT5SK3p8j-H3tSYR7GBpiN4Ih15eblXtLo-DIUi-psmH5g>
Feedback-ID: i24394279:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 5 Sep 2023 11:32:38 -0400 (EDT)
Message-ID: <6c595b6a-1355-e420-725e-9134a41b89c9@stpeter.im>
Date: Tue, 05 Sep 2023 09:32:37 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.0
Content-Language: en-US
To: Julian Reschke <julian.reschke@gmx.de>, urn@ietf.org
References: <87v8cp93bv.fsf@hobgoblin.ariadne.com> <dd749384-b2ba-4635-1ab5-84da235467e3@it.aoyama.ac.jp> <5e942fd0-e8e1-ac4b-5682-b6c8d099dc58@gmx.de>
From: Peter Saint-Andre <stpeter@stpeter.im>
In-Reply-To: <5e942fd0-e8e1-ac4b-5682-b6c8d099dc58@gmx.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/sB4bdK9MD_loHJ9qO17Fr38BqMw>
Subject: [urn] "relative URNs"
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, 05 Sep 2023 15:32:44 -0000

On 9/5/23 3:15 AM, Julian Reschke wrote:
> On 05.09.2023 10:30, Martin J. Dürst wrote:
>> ...
>> I'm really concerned that starting to use the term "relative URN" in two
>> different ways will cause I lot of confusion. I strongly suggest that
>> the KNX spec do not use the term "relative URN". If it turns out that
>> there's no good other word for the concept, at least make sure that it's
>> always written "KNX relative URN", and that the spec clearly calls out
>> the fact that this is different from "relative URN".
>> ...
> 
> FWIW, what *is* a relative URN?

We had a long discussion about this within the URN WG back in 2015 and 
2016. Part of the conclusion was *not* to define "relative URN" as a 
term of art (you won't find it in RFC 8141) and to say as little as 
possible about base URIs, relative references, etc. It's true that there 
is text in Section 4.3 of RFC 8141, which merely points out that 
applying the algorithm defined in Section 5.2 of RFC 3986 to URNs should 
yield predictable results. However, that doesn't necessarily mean that 
applying the algorithm is a great idea.

IMHO this is not the time or place to relitigate the question of 
"relative URNs" and (with no hats on) I'd strongly discourage use of 
that term, since it is undefined.

Peter