[urn] Re: URN Namespace Registration for SAID (Self-Addres sing Identifiers)

Hi Dale

Thank you for the detailed review comments! Let me try to respond to each of your questions/points and hopefully clarify what we may need to do with the registration document.


  *   SAID identifier string derivation

Yes, the current document was written assuming we could rely on CESR spec for the details of a SAID string’s derivation, coding, and verification procedures. I was not certain if such procedures are in scope for the registration application or not, but I agree with you that from a reader’s perspective, a stand-alone summary of the above details would be helpful, and they could then go into the CESR spec itself for further information. I do still have a question about the scope of the registration document, however. At some point, we will need to rely on references of course. Would it be OK / a good idea that we provide a concise description of SAID derivation here but not replicate the entire spec?


  *   The code table for the digest algorithms

This code table is included in the CESR spec. However, it is somewhat independent of the rest of CESR. We could replicate the portion of the table defining current digest algorithms or could give several examples with several algorithms. As you pointed out, one example only is not enough.  This table may be expanded in the future by CESR and I hope we would not need to re-submit this registration again every time another digest algorithm is added. The SAID is self-describing as it includes a one-character code for the algorithm used to derive it. If possible, the reference to CESR Sections 11.4 and 11.6 could give us that future extensibility without going through re-registration. Let me know if this is appropriate. If not, we may need to incorporate a part of the above reference.


  *   Reference to CESR spec.

For the derivation of SAID string, the most relevant sections are 11.4 and 11.6 in Annex A. The rest of the CESR spec is not directly related to the SAID string itself. Again, any guidance will be greatly appreciated if we need to incorporate some of those two sections into this registration application.


  *   Serialization of digital assets

Yes, before we can derive a SAID string for urn:said, the digital asset will need to have a consistent serialization. CESR is one of such serializations. The terms ‘binary’ and ‘text’ are referring to the property of CESR encoding such that CESR representation allows two-way conversions from binary to text and back to binary (or the other way) and always arrives at the same thing. CESR is not the only consistent serialization however that can satisfy urn:said requirements.

Note that the SAID string itself MUST be CESR encoded but the digital asset that the SAID identifies does NOT need to be CESR encoded. Since SAID is to be contained in the serialized data itself, so the serialization method should of course at least allow the CESR encoded SAID string.

When I was drafting the registration doc, I was thinking that we may give some examples of how one could apply SAID but not strictly define all cases nor restrict it. I thought that’d be out of scope. Is that the right thing to do?

In summary, I’m thinking that we might address your comments by

  1.  Providing a concise summary of the SAID derivation and encoding as defined in CESR spec sections 11.4 and 11.6.
  2.  Giving 2 different digest algorithms and 2 different digital asset format examples to illustrate SAID.

What do you think?

Best regards
Wenjing



From: Dale R. Worley <[email protected]>
Date: Saturday, November 1, 2025 at 11:26 AM
To: Wenjing Chu <[email protected]>
Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>
Subject: Re: [urn] URN Namespace Registration for SAID (Self-Addressing Identifiers)
Initial comments on urn:said:

The text seems to be written on the assumption that the reader is already
thoroughly familiar with the CESR system.  It would help if there were
fewer prerequisites.  Ideally, someone with no knowledge of CESR, but a
need that CESR could satisfy, could read this document and then realize
that CESR was a technology they desired to adopt.  That is, the more the
registration is an entry point into CESR technology, the better.

The Syntax section should more emphasize the ABNF and the information in
the text part should be attached to the corresponding parts of the ABNF
in a form like this:

    said-urn = "urn:said:" said

    ; SAID, in string representation as per Composable Event Streaming
    ; Representation (CESR) version 2.0, Section 11.6
    said = said-256 / said-512

    ; 256-bit SAIDs: 44 characters total (1 char code + 43 Base64URLSafe)
    said-256 = one-char-code 43base64urlsafe
    ; specifies which digest algorithm is used
    one-char-code = "E" / "F" / "G" / "H" / "I"

    ; 512-bit SAIDs: 88 characters total (2 char code + 86 Base64URLSafe)
    said-512 = two-char-code 86base64urlsafe
    ; specifies which digest algorithm is used
    two-char-code = "0D" / "0E" / "0F" / "0G"

    ; The "The "URL and Filename safe" Base 64 Alphabet" of RFC 4648
    ; section 5, excluding padding, which CSER uses to represent digests
    base64urlsafe = ALPHA / DIGIT / "-" / "_"

There's some missing information regarding what the different
one-char-code values mean, other than that the digest can be represented
in 43 characters.  Similarly for the different two-char-code values.  Is
there a table of which codes mean which digest algorithms?

There are two examples that use the same one-char-code.  It seems to me
better if there were examples of both lengths and multiple digest
algorithms.

Is the system extensible in that new digest algorithms might be
supported in the future?  You can always update the registration later,
but if there are mechanisms for extension already defined (e.g. perhaps
all upper-case letters are reserved for various 43-char digests) it
might be worth incorporating that into the ABNF now.

The CESR document is quite long.  Is there some section of it that
states in a stand-alone way the algorithm for calculating the SAID?

    The SAID derivation procedure defined by CESR version 2.0 requires a
    consistent serialization scheme for the digital assets in order for
    correct representation and verification. In other words, SAID
    identifies the serialization of the digital assets where it is also
    contained.

Does this mean that the CESR standard *defines* a consistent
serialization scheme that can be applied to any digital asset, or does
it mean that the user of CESR for some class of digital assets must
define a consistent serialization scheme for the user's class of assets?

A larger question is what class of "digital assets" can CESR, and thus
this URN namespace, be applied to.  There is one example in the
registration, which appears to be the source code version of a Python
data structure.  And the words "binary" and "text" appear throughout the
CESR document.

Dale

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]