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

ProSapien Sam Smith <[email protected]> Wed, 4 Feb 2026 11:02:46 -0700
Newsgroups gmane.ietf.urn
Message-ID <[email protected]>
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]