Is Type-Length-Value (TLV) Encoding Of Value For Future Proofing GPAP?

[ForrestErickson]

TLV-Based Encoding

My former employee computer genus suggested we read about,

Type-Length-Value (TLV) Encoding

Each NDN packet is encoded in TLV format. NDN Interest and Data packets are distinguished by the type number in the first and outermost TLV0.
.....

See:
https://docs.named-data.net/NDN-packet-spec/current/tlv.html

There is something of interest:

Considerations for Evolvability of TLV-Based Encoding
To ensure that the TLV-based protocol can evolve over time without requiring flag days, the least significant bit of TLV-TYPE (unless overridden by the specification of a particular

New to me was the phrase "requiring flag day" which is like the issue of which I was writing about how we have to evolve not only the Krake but the PMDs of all flavors.

[TheBakedPotato]

I would say yes and no. Using a TLV scheme would be beneficial for messages that regularly have payloads of different lengths. With the GPAP, the message types, for example, are always a single byte, a single ASCII character. If, for example, the command was a wide range of bytes, maybe anywhere from 1-10 bytes, a TLV encoding scheme would be very beneficial. In the message, it will tell you first with the type byte a message type follows, then it will tell you how many bytes make up the message, and then you know how many bytes to deserialize to get the message type.

In the protocol currently it uses { } to identify the message ID while there is no size restriction to it. To deserialize that message ID, when parsing the full string to make up the message, it has to see if it finds the {, then iterate through the characters until it finds the } character, and now it knows how many bytes made up the message. In a TLV scheme it would simply say something like "this is an alarm ID, it uses 10 bytes" and then the 10 bytes making up the message ID. Then when deserializing the message it wouldn't have to be iterated through to find the length. It will be told the length. For that part specifically it would make deserializing easier.

[ForrestErickson]

I did a little googeling requesting a TVL encoder / decoder in C++ and the AI came back with this:
https://share.google/aimode/Q8WhAYhKee4FQNznS

There is both an encoder and decoder.

The Decoder:

// Function to decode a TLV byte stream
std::vector<TLVElement> decodeTLV(const std::vector<uint8_t>& buffer) {
    std::vector<TLVElement> elements;
    size_t pos = 0;

    while (pos < buffer.size()) {
        // 1. Read the Type (1 byte)
        TLVType type = static_cast<TLVType>(buffer[pos++]);

        // 2. Read the Length (4 bytes, reverse of encoding for big-endian assumption)
        if (pos + 4 > buffer.size()) {
            std::cerr << "Error: Malformed TLV, not enough bytes for length" << std::endl;
            break;
        }
        uint32_t length = (static_cast<uint32_t>(buffer[pos]) << 24) |
                          (static_cast<uint32_t>(buffer[pos+1]) << 16) |
                          (static_cast<uint32_t>(buffer[pos+2]) << 8) |
                          static_cast<uint32_t>(buffer[pos+3]);
        pos += 4;

        // 3. Read the Value
        if (pos + length > buffer.size()) {
            std::cerr << "Error: Malformed TLV, not enough bytes for value" << std::endl;
            break;
        }
        std::vector<uint8_t> value(buffer.begin() + pos, buffer.begin() + pos + length);
        pos += length;

        elements.push_back({type, length, value});
    }

    return elements;
}

and it identified some libraries

Note: This example uses a simple fixed-size length field (4 bytes) and assumes a certain byte order for demonstration. Real-world protocols, such as NDN or BER, often use more complex variable-length encoding schemes for 'T' and 'L' to optimize size and flexibility. You can find C++ libraries that implement these specific standards, such as the NDN-CPP library or a simple Arduino BER-TLV library on GitHub