[urn] Re: URN Namespace Registration for SAID (Self-Addres sing 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]