Re: [urn] "relative URNs"

John C Klensin <john-ietf@jck.com> Tue, 05 September 2023 17:52 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 CBF6FC151711 for <urn@ietfa.amsl.com>; Tue, 5 Sep 2023 10:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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
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 NNSlZmC38VRJ for <urn@ietfa.amsl.com>; Tue, 5 Sep 2023 10:52:40 -0700 (PDT)
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 E2CB8C151984 for <urn@ietf.org>; Tue, 5 Sep 2023 10:52:39 -0700 (PDT)
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 1qdaE7-000F1K-HK; Tue, 05 Sep 2023 13:52:35 -0400
Date: Tue, 05 Sep 2023 13:52:30 -0400
From: John C Klensin <john-ietf@jck.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, Julian Reschke <julian.reschke@gmx.de>, urn@ietf.org
Message-ID: <834CD96DF71552A6F5BB8BCE@PSB>
In-Reply-To: <6c595b6a-1355-e420-725e-9134a41b89c9@stpeter.im>
References: <87v8cp93bv.fsf@hobgoblin.ariadne.com> <dd749384-b2ba-4635-1ab5-84da235467e3@it.aoyama.ac.jp> <5e942fd0-e8e1-ac4b-5682-b6c8d099dc58@gmx.de> <6c595b6a-1355-e420-725e-9134a41b89c9@stpeter.im>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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/gpQC9wx16KjVFg9ZgBmAgaPetJA>
Subject: Re: [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 17:52:43 -0000


--On Tuesday, September 5, 2023 09:32 -0600 Peter Saint-Andre
<stpeter@stpeter.im> wrote:

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

FWIW and with co-author hat off but in reach:

(1) Agree with Peter.

(2) My recollection of the conversations to which he referred is
that they also included an argument that properly defining what
a "relative URN" might be while being consistent with RFC 3986
would require opening the latter and revising its description,
perhaps limiting it to URLs.  To say there was general sentiment
(taken to be rough consensus) that opening 3986 to deal with the
needs of what became 8141 was not an option would be a bit of an
understatement.  Getting started on that discussion leads
quickly to another one about whether RFC 3986 (and 2986), in
moving from the URL specifications of RFC 1738 (and 1808) to a
URI specification/description overreached in ways that
constrained non-URL URI types in ways that reduced their
potential utility.  It would almost certainly be a bad idea to
revisit those issues and specifying or referring to "relative
URNs" in a document would take us there rather quickly.

Recommendation for anyone who needs a "relative" relationship
for a namespace: Define what you are trying to accomplish and
the associated syntax carefully.  Avoid using the term "relative
URN" or any other use of the term "relative".    That should not
be very hard and would avoid a good deal of negative feedback.

   john

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