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

After this version of the namespace is registered, you can always update 
the registration to version 2 (etc.) in the future as you learn more.

On 2/4/26 1:13 PM, Wenjing Chu wrote:
> 
> 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]

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