On Aug 2, 2021, at 6:23 AM, Lucas Pardue <[email protected]> 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. --Paul HOffman
smime.p7s
Description: S/MIME cryptographic signature
