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

[email protected] (Dale R. Worley) Tue, 03 Feb 2026 21:22:04 -0500
Newsgroups gmane.ietf.urn
Message-ID <[email protected]>
To wrap up my commentary on this:

I approve of the current version of this registration.  Even if it only
sees use in the CESR space, that is sufficient justification for
registering a URN.

However, I think that y'all should keep the following issue in mind for
long-term development:  The point of SAID is that a CESR object bears
within itself the SAID and an application handling the object can
validate that the SAID is correct.  However that requires that the
application know how to examine the object to extract the SAID, and also
how to recompute the SAID (serializing the object and inserting the
placeholder).  As you emphasize, there can be a variety of hash
algorithms, and the SAID specifies the one to use, but none of the other
aspects of the algorithm are explicitly specified by the URN.

If a different "ecosystem" adopts SAID, then it has to define, for its
type of object, the serialization, placeholding, etc.  Again, that isn't
a significant problem within one ecosystem.

Where trouble arises is if there come to be a considerable number of
object types using SAID.  Then if an application wants to "generically"
handle all of these object types, it needs some sort of table of all the
supported object types, and the serialization/placeholding/etc. rules
for each of them.  You can see how this rapidly becomes unmaintainable.

I suggest you remain open to the idea of a long-term development of a v2
SAID URN which (through some syntax extension) can contain enough
information that an application that does not know anything specific
about the type of an object that embeds an SAID can nonetheless validate
that the SAID for the object is correct.

Consider this as a rough approximation an extension:

    urn:said: <hash algorithm code> <hash> , <B or T> <offset>

where <B or T> is either B or T to indicate that the SAID is present
within the object as either Binary or Text, and <offset> is a 1*DIGIT
specifying the octet offset within the object where the SAID is located.

To my understanding, given this information, the SAID validation process
can be carried out on the object without understanding the internal
structure of the object.

Dale

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