[saag] Re: A simpler form of OID

Phillip Hallam-Baker <[email protected]>
Newsgroups gmane.ietf.saag
Message-ID <CAMm+LwgRSFJWVkbD0M-yd_bvXYhefsxTKRtntVYZOvqWe-coEg@mail.gmail.com>
On Wed, Sep 17, 2025 at 11:38 PM Michael Richardson <[email protected]>
wrote:

>
> Phillip Hallam-Baker <[email protected]> wrote:
>     > So I had a bunch of thoughts on using variants for the purpose and
>     > suddenly realized there is a much simpler approach than specifying
> the
>     > conversion of integers to strings of octets: The octet sequence is
>     > sufficient.
>
> Yes.  I think you've just repeated how DER encodes integers in unbounded
> ways.
>

Yes and no. The original pattern here is from Ken Thompson.

My original design was 'the version number is a varint'. Then I realized
that the conceit of making the initial letter of the BASE-32 encoding
indicate purpose would require multiple byte encodings for Z, so I tweaked
it to make the 'end of unit' indicator bit 0 instead of bit 7.

Then I literally spent a whole day writing up a concise description of the
encoding scheme. Yuk!

And then, I suddenly realized that all I need is the byte stream itself,
the actual numeric representation is unnecessary and only introduces
complexity and pain and not good stuff.


Type identifiers can be made very, very general.

So for example, I am writing a spec that uses some file format and I want
to make the initial (or final) bytes of the format a globally unique
identifier. So I splice in a UUID in binary form. No biggie. But then I
have 16 extra bytes in every file and those can start to add up in a
production system. They are even more painful if I am trying to squeeze
things into Ethernet packets.  If I make it a Type Identifier, my
production 'file type' indicator can be 4 bytes long and globally unique.

I am probably not going to be remembering the binary sequence values but if
am dealing with the FOO protocol a lot, I might well recognize something
like GQZD-QNBT as the FOO protocol.

_______________________________________________
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.