Re: [Ext] Consensus call for qlog serialization format (issue #144)

[Lucas Pardue <[e-mail]>]

Hi Paul,

Response in-line:

On Mon, Aug 2, 2021 at 4:59 PM Paul Hoffman <[e-mail]> wrote:

> On Aug 2, 2021, at 6:23 AM, Lucas Pardue <[e-mail]>
> wrote:
> >
> > Hello QUIC WG,
> >
> > During the IETF 111 meeting discussion of qlog, we discussed the
> serialization format tracked on issue #114 [1].
> >
> > The feeling in the room was to keep the JSON serialization format.
> Noting that implementations can use their own intermediate formats and
> transform to and from JSON as needed, and that future documents could
> specify other interop formats if there is sufficient interest.
> >
> > The proposed resolution for this matter is to keep the JSON
> serialization format as the canonical interoperable format. This email
> seeks to establish consensus for this. If you have comments, for or
> against, please respond on the issue. The call will run until EoD August 9
> 2021.
>
> Which JSON serialization is being discussed here? If it is the one in
> Section 6.1, it is explicitly not canonical, and not interoperable. For
> example, 6.1.1 gives QLOG emitters a choice of writing large numbers a
> numbers or strings. Section 6.1.2.1 gives multiple ways of truncating byte
> strings. Section 6.1.4 allows QLOG emitters use non-standard JSON (trailing
> commas). There are also other SHOULD-level requirements for JSON emitters
> in other parts of the draft, such as in section 3.


> I would support having a JSON serialization format as the canonical
> interoperable format, but only if there is eventually a canonical JSON
> format, which there is not currently. Without a canonical JSON
> serialization, there can be no interoperability with other formats.
>

Great question!

The intention here is to determine consensus on using _a JSON_
serialization and not a completely different format. The current draft is a
starting point but is not intended to be the final solution.

Should the WG determine consensus on using _a JSON_ serialization, the
editors and WG will unblocked on iterating the finer details of _the JSON_
serialization. The specific examples you provide are good, they can be
tracked as issues against the draft.

I'd also like to clarify that this consensus call relates to only a JSON
serialization. Although the issue mentions streaming serialization (and
NDJSON) and Robin presented some slides on the topic during the IETF 111
meeting, our intention continue that discussion separately pending the
outcome of this call. I've created a new issue to make this clear [1].

Does that clarify things sufficiently?

Cheers
Lucas

[1] - https://github.com/quicwg/qlog/issues/172