[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]