Re: [urn] Registration request for urn:eris: namespace Fri, 29 September 2023 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58073C15199B for <>; Fri, 29 Sep 2023 12:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.992
X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u4ecvuSNsEGh for <>; Fri, 29 Sep 2023 12:33:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9722C151717 for <>; Fri, 29 Sep 2023 12:33:58 -0700 (PDT)
Received: from ([]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by with ESMTP id mH96qfLOJc4I0mJDQqm8zW; Fri, 29 Sep 2023 19:31:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20211018a; t=1696015916; bh=jxAXb7J4v9LDimyIk9pPQJBQ4k3HE0n8VIa3n6g03R0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=qiBG1+9ELKVztWzLjRRpmOQk8nvU8UFcwK1pjLMnw5j3wFksLFtMy1D3+YG3QgalT efUdvl7stJhacCXtsInmPyoJRt+ZoaeXnBgM8OhLX+YC29sWR085Ke97Xn47sM2bjb GwFo5QjAe4pRlu6eehCA/oIarsfEEUsxHbdaMuEzd1NeNd9kMUhRH1pOQ1XEuLsjET 2VDyfUKKB6ZG7Y6fbwE9XuIPbDaDohUP/Yx10BlIWhV78dGrvbsN2rBvyXj82+z88m 6KfhG2XoCKkcP9jZZ/t8u0yFvQpVwsn0rSsOMzMFpm6m8sya8oMmmIrtdJlcbIYlei 2hdZ8gdsgKCNg==
Received: from ([IPv6:2601:192:4a00:430::a771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by with ESMTPA id mJD1qRvNjzyjXmJD2q2RAb; Fri, 29 Sep 2023 19:31:33 +0000
Received: from (localhost []) by (8.16.1/8.16.1) with ESMTPS id 38TJVVHx2169597 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 29 Sep 2023 15:31:31 -0400
Received: (from worley@localhost) by (8.16.1/8.16.1/Submit) id 38TJVU2X2169594; Fri, 29 Sep 2023 15:31:30 -0400
X-Authentication-Warning: worley set sender to using -f
To: Peter Saint-Andre <>
In-Reply-To: <>
Date: Fri, 29 Sep 2023 15:31:30 -0400
Message-ID: <>
Archived-At: <>
Subject: Re: [urn] Registration request for urn:eris: namespace
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Sep 2023 19:34:03 -0000

(I still want to see a versioning device in the Eris URN, but that's not
what this message is about.)

Peter Saint-Andre <> writes:
> Thanks for your comments. Indeed, it's unclear to me why the ERIS system 
> really needs to use URNs - why not use system-specific identifiers of 
> some kind rather than the "persistent, location-independent resource 
> identifiers" (RFC 8141) that URNs provide?

Ah, thank you!  I'd tried to track down text in the RFCs that captured
my intuition, but I'd overlooked the passage in RFC 8141 section 7.1
that you mention:

   URI Scheme Semantics:  The "urn" scheme identifies Uniform Resource
      Names, which are persistent, location-independent resource

(I keep wanting to read the "U" as meaning "universal", but it means
"uniform".  OTOH, "uniform" includes "uniform across the Internet".)

To restate what I meant in a way that hopefully is clear, what I don't
like about the current proposal is that the identifiers aren't
*location-independent*.  There's no way to use them that is
location-independent, even to the point of being able to examine one to
see if one can use it, other than by simply giving it to the local "Eris
system" and checking whether it returns a resource vs. an error.  In the
end, everything that can be done with them is done using the implicit
context of "the local Eris system".

I foresee this is will become a practical problem as well.  The current
vision seems to be that there will be many "Eris systems", but that any
particular use of Eris URNs will be isolated within exactly one Eris
system.  That design decision is often made in information systems, but
it rarely remains valid; work proceeds to interconnect multiple systems,
and eventually the operational context becomes "all of the Internet".
In the latter situation, every Eris URN usage will have to have attached
to it an identifier of the system within which it is to be used.

I think as a practical matter, this issue can be fixed in a number of
ways.  One would be to presume that each "Eris system" will have a
unique DNS name, and insert that into its URNs.  E.g.

For initial/limited/experimental usage, assigning a DNS name might be
awkward, but that can be finessed by e.g. using "localhost" as the
well-known name for "wherever we are now"


or even allowing the system name to be null


(That last is valid URN syntax according to RFC 8141.)  Either of those
forms carries a marking that it's not interoperable with other Eris

Indeed, it would be reasonable to consider constructing an Eris *URL*
along the lines of


but the effort to register that would be a lot higher than registering a
URN namespace.  Also, you'd have to decide what the default protocol for
accessing the server is, and I don't think you've solidified that.