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

Offset-based generic SAID validation can work for encodings that guarantee canonical byte serialization and placeholder-invariant embedding of fixed-length SAID values. CESR satisfies these properties by design; text encodings such as JSON or binary encodings such as CBOR may satisfy them only under additional constraints. So, the question may be one for ecosystems to consider. Conceptually, might this be a cleaner framing?

Similarly, if a label needs to be reserved (or a URI scheme etc.) for a searchable field label, that seems also be a question for an ecosystem to decide?

With that overall framing, I am open to a future extension that appends such optional locator information to the urn:said string to facilitate schema-independent validation.

Best,
Wenjing



From: ProSapien Sam Smith <[email protected]>
Date: Wednesday, February 4, 2026 at 10:03 AM
To: Dale R. Worley <[email protected]>
Cc: Wenjing Chu <[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)

Dale,

This is a great suggestion.  The two main use cases for SAIDs are  1) concatenated serializations of self-framing fields 2) field maps.  In the first case an offset from the start
of the block is enough to position the start of the SAID field (which is itself a self-framing serialization)  2) for field maps, a field label may be more usable.

Sam


> On Feb 3, 2026, at 19:22, Dale R. Worley <[email protected]> wrote:
>
> 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]