Approach for CDDL extension points

[rmarx]

It is expected that the initial 3 qlog documents will be extended in the future with new events and frames (e.g., for QUIC and H3 extensions like DATAGRAM or Multipath, but also for other protocols like H2, TLS and TCP).

The proposed approach is to define these qlog extensions in their own documents (either standalone or integrated into the docs that define the protocol extensions themselves). Ideally, these new documents wouldn't just extend qlog in prose only, but also properly extend the existing CDDL event and data type definitions.

To this end, the current documents define a few CDDL plugs/sockets/extension points to make this possible:

• $ProtocolEventBody
• $QuicFrame
• $HTTPFrame

However, when trying to define a simple extension for the QUIC and H3 DATAGRAM frames, I found we might need more extension points, specifically for QUIC Transport Parameters and HTTP SETTINGS (the DATAGRAM RFCs use those to negotiate support). These currently don't exist and the extension document uses some not-really-compatible CDDL at this point.

While it's not a big problem to define new extension points for those two things, it begs the question if that would be enough. Do we need even more extension points down the line (e.g., for the ConnectionState in connection_state_updated? For StreamState in stream_state_updated? For data handling points in data_moved? For metrics in metrics_updated? etc.)

Conceptually, we can make EVERYTHING a CDDL extension point, but I'm not sure that's the best approach either. So the real question is: where do we draw the line? and what happens if it turns out we made the wrong decision/missed an important extension point down the line?

Related to #176, #170 and #124

[LPardue]

I think we should provide strong support for every formal extension point in the protocols: frames, TPs, settings, error codes, etc.

The other type of extension point is for flexibility. qlog is very flexible for new/custom/undefined fields. As an implementer and user of qlog, sometimes I have a need of adding a new ad-hoc enumeration value (say, to StreamState). On the deserialization side, what I want to support the strongly-typed enumeration values and also any adhoc values that might be in there. One way I've though about supporting this is to add an "any" field to pretty much everything (probably text, or json). So fields that aren't primitive types end up as field = EnumerationType / any. The deserialization code would then try to match the strong type, and if needed fall back to a generic container holding "any", whereby my user-specific application code can manage the adhoc stuff I added.