Re: [urn] Registration request for urn:eris: namespace
Peter Saint-Andre <stpeter@stpeter.im> Wed, 27 September 2023 16:45 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 6CE4DC151085 for <urn@ietfa.amsl.com>; Wed, 27 Sep 2023 09:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level:
X-Spam-Status: No, score=-2.806 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_LOW=-0.7, RCVD_IN_MSPIKE_H5=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_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="gYh2my41"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="F0zX16yB"
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 w1W3Ff3DByPG for <urn@ietfa.amsl.com>; Wed, 27 Sep 2023 09:45:09 -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 D0A4EC15107C for <urn@ietf.org>; Wed, 27 Sep 2023 09:45:09 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 82DD65C0144; Wed, 27 Sep 2023 12:45:08 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 27 Sep 2023 12:45:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :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=fm3; t= 1695833108; x=1695919508; bh=W3LQWKyRNv/MCwaPlx9DJH/BBTDQX4ulOs/ f2HDgWk0=; b=gYh2my41PEsRsVYxOjkcXWlwn8ZiTDKZJGNfb4MUXhWOkJlvXnz uZg6/y5TXXC2V9jQu0QLoWotiVIzRZq0hCxbZk/6jEL8DxBlS5up5FQg8FuTP+Ia lyBsY9n466cg4lVrEa9qqeHkbHlZGoTjMZFlVbo+AiJpMTpPbZBvxKW0pIrBXubI nnU4JBEM0vjfkVO/8zpykJIJlM2fGuBStelMvUF3UhjAcO+ffYZP09XZfacUD4ZP GodwI61bBvloYmE6LY/w/fL3yrUgFHqeJn0bDvGcF7wUoZOxnN0CO2XTZE+2E5gu QJ5dgFVD0yXcOjcqc0J+6gvPOYIDSXkixpw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm2; t= 1695833108; x=1695919508; bh=W3LQWKyRNv/MCwaPlx9DJH/BBTDQX4ulOs/ f2HDgWk0=; b=F0zX16yBU8DFN+nTKvDlys+anz4L1n22rIVDPdIRB+3VkwugRFl 7fnO7iQpnl2B+89dzGHS39iIZMnX1GdjCfDGJXnwzjo4WuN9kpbpDlVAM0y2HeXZ h1HYELA/iF4hVq6HAnKLHd6AGkGwvSLVT7jkSPhB0nKrW1SJ0Et3yPACeMw1gkxy /OyWNCn8kNZPGAwa/mICz1OXbT3WjBZJiyho2oQnoYan05JxADXqD9rPHgF5WPZU QceGW8HPyj3Z+N+2L139PwMy13QEXuMpFk/8OgpQYEpmlp04I0AvwrGW4ScaX4Wz qjbm1pmV5o7lKuids91/Q6VHMRnEbxoVsCg==
X-ME-Sender: <xms:E1wUZQ38Vx33cYMI9vy1Xb_xtwodcviHzp3cXg3yvUmrIE-WciOgyw> <xme:E1wUZbEb3HS5_5AidGHXzDqu2FSiYd5-YpjAdPx3Sd6nBtiqF5NyBDYF34hBRCg2- LJPJhjiS0inCxn8JA>
X-ME-Received: <xmr:E1wUZY4oJX9mGp634o3tZpwbH3qoLZAzO3HWosVMbvaatnlX1v18uma7f73xmVkR>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvjedrtdeggdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhevhfgjtgfgsehtke ertddtvdejnecuhfhrohhmpefrvghtvghrucfurghinhhtqdetnhgurhgvuceoshhtphgv thgvrhesshhtphgvthgvrhdrihhmqeenucggtffrrghtthgvrhhnpeeuueegueeuheffje ekteegheevgfegteevfeduueekfeetffegheelvdfhteevleenucffohhmrghinhepihgv thhfrdhorhhgpdgtohguvggsvghrghdrphgrghgvpdhpuhhrlhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthhpvghtvghrsehs thhpvghtvghrrdhimh
X-ME-Proxy: <xmx:E1wUZZ1EDVHm4dsQvHaNDpaRHSbpL9qmqIp9PgJPsglSda6dySc0FA> <xmx:E1wUZTEJSxFerMcy5e7u3w5RG79AaXnfs4yADJWKCzgoVO_OUwtdQA> <xmx:E1wUZS-MRz8j-mtzYBnHrsdyc1ke6ZIAc-n0VN7-EdviYlCyZwbqNA> <xmx:FFwUZZNmWzlSs_wnCzWJKuJOKwGruxgFYG6OPLHZOnKSFZbaIb-WhA>
Feedback-ID: i24394279:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 27 Sep 2023 12:45:07 -0400 (EDT)
Message-ID: <ae80ff46-d209-40ca-9a5c-e97df767b4a6@stpeter.im>
Date: Wed, 27 Sep 2023 10:45:06 -0600
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Endo Renberg <ehmry@posteo.net>
References: <1694856169.lcxe8yiejf.astroid@garbage.none> <3701429d-b00c-bf22-2101-584970862868@stpeter.im> <1695801651.taoivbbs0y.astroid@garbage.none>
Cc: "urn@ietf.org" <urn@ietf.org>
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: <1695801651.taoivbbs0y.astroid@garbage.none>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/kuwuLBI_zE1AGJmx90oSz_r61TA>
Subject: Re: [urn] Registration request for urn:eris: namespace
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: Wed, 27 Sep 2023 16:45:14 -0000
[+ cc urn@ietf.org ] Thanks, Endo, I look forward to an updated registration request that clarifies the points that Dale and I have raised on list. On 9/27/23 2:47 AM, Endo Renberg wrote: > Excerpts from Peter Saint-Andre's message of September 16, 2023 11:08 pm: >> I suggest that you provide slightly more detail in the Purpose section. > > RFC8141 is a bit vague on how much detail one should provide and I wasn't > sure if this submission would just bounce. I will re-submit with more > details. > >>> These URNs may be conveyed in URLs using the "URN to Resource" method >>> described in RFC2169 (https://datatracker.ietf.org/doc/html/rfc2169) >> >> First, using RFC 2169 seems like a resolution method (that document >> "specifies the 'THTTP' resolution protocol") and thus this sentence >> might belong in the Resolution section of the registration request. >> >> Second, given that (a) RFC 2169 was Experimental and (b) HTTP 1.0 and >> 1.1 have been superseded by more modern and secure versions of HTTP, is >> this resolution method truly advisable at this time? > > I can move this to the Resolution section or I can drop it. RFC2169 is > obviously abandoned, but the "URN to Resource" method referred to does > not depend on THTTP or HTTP 1.0. RFC2169 need not be mentioned and we can > point instead to https://eris.codeberg.page/eer/http.xml. > > >> A reference to RFC 4648 might be appropriate regarding the definition of >> base32. > > Will do. > > >>> The use of r/q/f components in URNs is application specific and is neither >>> defined or prohibited. >> >> Is that helpful? In the context of ERIS as a simple block-encoding >> method (and quoting descriptions from RFC 8141), I wonder about the >> purpose, even at a high level, of: >> >> - "passing parameters to a URN resolution service" via the r-component? >> >> - "passing parameters to either the named resource or a system that can >> supply the requested service" via the q-component? >> >> - specifying "a location within, or region of, the named resource" via >> the f-component? > > There aren't any documents specifying r/q/f components for ERIS URNs but yes, > r-components could be passed to a URN resolution service, etc. Those > components would be specific to the resolution service or what data the URN > represents. > >>> Assignment: ERIS operates independently of any authority. Data is >>> assigned an ERIS URN by chunking it by one of two block-sizes and using >>> a convergent (deterministic) or unique block encoding. This results in two >>> possible convergent URNs for any given data or an unlimited number of unique >>> URNs. >> >> By "data" here do you mean a particular block of data or the content >> that is encoded into blocks? I suspect the former, but it would be good >> to ensure consistency with the terminology in the ERIS spec. (Strictly >> speaking, the URN seems to identify a "read capability", but I'm not >> sure how that differs from the content that is encoded into blocks.) > > Yes, data here refers to content. ERIS read capabilities are rendered to URNs > as a portable textual representation. > > >>> This behavior also permits the so-called >>> "Confirmation of A File" attack which may be partially mitigated by >>> creating URNs using unique encodings. >> >> What is meant here by "unique encodings"? Does that mean an encoding >> other than ERIS? > > Unique encoding means the content is processed into encrypted chunks in an > intentionally non-deterministic manner. The ERIS spec uses the term > "encoding" for the process of chunking and encrypting, which might be > confused with the encoding of the URN. > >>> Resolution: An ERIS URN may be resolved to content by standalone services >>> or embedded software libraries. No organization is responsible for hosting >>> and resolving ERIS encoded data. >> >> What does resolution mean in the context of ERIS as (seemingly) a fully >> decentralized system? Is the read-capability URN resolved to the content >> itself? How does that interact with the encryption properties of ERIS? > > Resolution of an ERIS URN should be taken to mean the fetching of encrypted > blocks from local or remote storage as well as decrypting and reassembling > the blocks to content. A resolution service can fetch, decrypt, and reassemble > or an application can fetch blocks remotely and decrypt and resassemble > locally. In the latter the remote service only handles encrypted blocks and > does not have knowledge of ERIS URNs. This is were urn:blake2b:… comes in… > >> BTW, do you also plan to register the blake2b namespace identifier >> mentioned in Section 2.7.1 of the ERIS spec? > > No, I don't plan to register this. An encrypted ERIS block is useless wihout > a URN (read capability) so it's not a meaningful outside the realm of ERIS > resolution. The "urn:blake2b:" prefix is a bit of a hack for interoperability. > > >>> Documentation: http://purl.org/eris >> >> Pointing to https://eris.codeberg.page/spec/ might be better if that is >> expected to be the longer-lived URI. > > We expect "purl.org" (Persistent URL service) to be longer lived than > "eris.codeberg.page". > > Thanks for the review, > E.
- Re: [urn] Registration request for urn:eris: name… worley
- [urn] Registration request for urn:eris: namespace Endo Renberg
- Re: [urn] Registration request for urn:eris: name… Peter Saint-Andre
- Re: [urn] Registration request for urn:eris: name… worley
- Re: [urn] Registration request for urn:eris: name… Peter Saint-Andre
- Re: [urn] Registration request for urn:eris: name… Endo Renberg
- Re: [urn] Registration request for urn:eris: name… Peter Saint-Andre
- Re: [urn] Registration request for urn:eris: name… worley
- Re: [urn] Registration request for urn:eris: name… worley
- Re: [urn] Registration request for urn:eris: name… Peter Saint-Andre
- Re: [urn] Registration request for urn:eris: name… worley
- Re: [urn] Registration request for urn:eris: name… Endo Renberg