Re: Registration request for urn:eris: namespace

[+ cc [email protected] ]

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.

_______________________________________________
urn mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/urn