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