[saag] Re: Relative OIDs are the simpler form of OID (Re : A simpler form of OID)

Nico Williams <[email protected]>
Newsgroups gmane.ietf.saag
Message-ID <aM3YVhmIUfVmu+Oh@ubby>
On Fri, Sep 19, 2025 at 03:15:55PM -0700, Christian Huitema wrote:
> On 9/18/2025 4:20 PM, Nico Williams wrote:
> > On Thu, Sep 18, 2025 at 03:32:37PM -0400, Phillip Hallam-Baker wrote:
> > > OK, so I do want to keep hold of my 'can type identifier in BASE-32'
> > > constraint. Because that allows an identifier to be read over a telephone.
> > This is a UI issue.
> 
> Maybe, maybe not. Identifiers do leak into the UI, and there is some beauty
> in identifiers being WYSIWIG -- or rather, what you read over the phone is
> what you get, as Phill said. So I understand the beauty of an identifier
> made of a series of easy to read character strings. But why insist on
> Base32? Don't we already have identifiers made of series of easy to read
> alpha-numeric strings nicely separated by dots?

I meant that the UI ought to present them in whatever way is best for
the user.

I agree that OIDs are nice enough.  I'd prefer URNs.  But Phillip wants
something _small_ as well as presentable.

My take, again, is that relative OIDs (relative to an OID associated
with the protocol slot) are the best compromise because a) they can be
as small as one byte, b) you get to have arcs below which you use hashes
as sub-identifiers (which is what Phillip wanted), and c) because they
are small and dotted notation is nice enough, we're done.

But if one were to use large hashes as sub-identifiers (possibly spread
over several sub-identifiers) then they do get noisy and hard to
read/dictate/type if they leak into UIs.  But hey, IANA sub-arc
registrations could very well be so cheap that using hashes is not
necessary.

Nico
-- 

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.