Re: [urn] Registration request for urn:eris: namespace Tue, 03 October 2023 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F4CFC1526ED for <>; Tue, 3 Oct 2023 08:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.993
X-Spam-Status: No, score=-5.993 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id snExNoEYPMYi for <>; Tue, 3 Oct 2023 08:46:35 -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 D2150C15257A for <>; Tue, 3 Oct 2023 08:46:35 -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 nePDqpUht6z80nhZaq6r1A; Tue, 03 Oct 2023 15:44:34 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20211018a; t=1696347874; bh=LsFXL5x0Xv9nlUkn1+KdMjUcrswZmjzaiogwx1MBSTQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=klmIav5h0G+rxD4jP5xM3O7rvUFHsyxHda/EOAL23AwJSiqP++Q9rird4pggB8EvT sMHgAvs5trO1rJAOiHzstoHrwkr23DeQjQzniJYv+bfwGYha3rG4FEnTey01cpyE/I OvkpH8knUHY+sdjLceuQakaJmTc1Sse30iMGzcvg1iICQFo7lt3EBAjXgIoBmTmq5O cE0dMuhoRzujPTv2mIFlktq/fau6IEDpVc+KlIv7ohb3Z1P0fn6gs/rehLylrP6C/3 oolbkqVyUbFaHw0VT8HEHZbg4uwsPAdEQZg9xbgvdIuu9ECfndYuKcYEYUBP7MnqEU 1vLtMzboQvH6g==
Received: from ([IPv6:2601:192:4a00:430::fa19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by with ESMTPA id nhZWqenHI17ipnhZXqTjkX; Tue, 03 Oct 2023 15:44:33 +0000
Received: from (localhost []) by (8.16.1/8.16.1) with ESMTPS id 393FiUIR2951169 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 3 Oct 2023 11:44:30 -0400
Received: (from worley@localhost) by (8.16.1/8.16.1/Submit) id 393FiT6w2951166; Tue, 3 Oct 2023 11:44:29 -0400
X-Authentication-Warning: worley set sender to using -f
In-Reply-To: <> (
Date: Tue, 03 Oct 2023 11:44:29 -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: Tue, 03 Oct 2023 15:46:40 -0000

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

To flesh out some aspects of this:  On one hand, I'm objecting that the
design of the namespace doesn't allow, doesn't conceptualize, that the
URNs are location-independent names.  On the other hand, I'm proposing
ways that the namespace can reserve a subspace for identifiers that,
indeed, aren't location-independent names.

This is like what happens with IP addresses.  IP addresses, of course,
are globally unique.  Except for addresses et al., which only
have a meaning within a local context that defines it.

The current Eris proposal, both in concept and in details, is like the
identifiers passed around in all distributed file systems:  "filesystem
ID"/"file ID"/"block offset".  None of those consider their identifiers
to be *names*.  But while I want y'all to reconceptualize the namespace
as names and add details to support that, I don't want you to have to
adjust your experimental implementations to have to support real names