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

Argh, nope, my last post is nonsense.

The Type identifier is a name, the combination of a type identifier and a
digest value is indexical.


The advantage of this approach over OIDs is compactness. It allows us to
assign really short identifiers to the most frequently used algorithms in
the contexts that most need compactness.

At this point in the process, I just want to get those applications done in
a way that does not foreclose anything later on. There are three separate
areas of concern:

1) Registered names.
2) Randomly assigned names.
3) Mapping legacy names.

Registered names can be short or human readable. When the net was starting,
they were the only names we needed to use. Now the net is very large with
five billion users and registries aren't going to be able to keep up.

A second area of concern in these times is that any registry is a potential
point of control. That is why DNS politics are so fraught with ICANN
meetings being filled with folk who have held 'cultural attache' posts at
various embassies.


A naming scheme that provides a bridge between all three forms might well
be advantageous at some point. For the past 25 years, application protocol
development has essentially been 'how do you layer that over HTTP'. Which
is a PITA because HTTP is a very limited communication pattern designed for
a very specific purpose. It only supports subordination. Now we have QUIC
and cheap TLS certs, it makes good sense to revisit that.

All I really get out of the HTTP layer is service separation via the
.well-known convention and a not particularly efficient chunking scheme
which was the best we could do in the circumstances. So I am looking
towards MOQ and similar for future patterns.

One scheme that might prove interesting is to use SHAKE-256 (well-known,
dns) as an opaque identifier...




On Sat, Sep 20, 2025 at 11:53 AM Phillip Hallam-Baker <[email protected]>
wrote:

>
>
> On Fri, Sep 19, 2025 at 6:16 PM Christian Huitema <[email protected]>
> 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?
>>
>
> DNS Names are Names, signifiers of type thirdness that have a purely
> conventional relation to the signified.
>
> These identifiers are mostly Indexical, signifiers of type secondness
> having a direct relationship to the thing signified and a few are direct
> being the thing signified.
>
>
>

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