On Aug 5, 2021, at 5:20 AM, Lucas Pardue <[email protected]> wrote: > On Mon, Aug 2, 2021 at 7:38 PM Paul Hoffman <[email protected]> wrote: > >> On Aug 2, 2021, at 10:52 AM, Lucas Pardue <[email protected]> wrote: >> > The intention here is to determine consensus on using _a JSON_ >> > serialization and not a completely different format. >> >> The associated question, which was not asked on this thread is "should there >> be any serialization format chosen, or just a data definition?". I would >> have leaned towards that, particularly because of the thorny JSON >> serialization issues brought up in the draft. However, that discussion often >> gets too meta for folks who want to start debugging and logging now. > > There's quite a large population of people already using JSON for qlog, prior > to WG adoption. So far, there has been a practical benefit to an > interoperable serialization format that was strongly linked to the schema > definition by draft version. During the adoption call I don't recall there > being suggestions for dropping serialization altogether from > draft-ietf-quic-qlog-main-schema. > > Wearing no hats: I think including at least one serialization format as part > of the work is a useful function to drive design and development decisions. > There might be a question about whether draft-ietf-quic-qlog-main-schema > should include the concrete serialization or if it should be spun out to a > separate document. However, I think this question is tangential to the > current call.
We are having a disconnect here that is central to the question in this consensus call. The original call said: > 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. > The call asked whether the (now "a") JSON serialization format will be the canonical interoperable format. That is quite different than "including at least one serialization format". As a concrete example: - The JSON serialization says that numbers such as packet_number may be represented as a number or a string - The data format says that the numbers such as packet_number are uint64 If the JSON serialization format is the canonical interoperable format, and I'm writing a CBOR emitter, I would be allowed to write packet_number as a number or string because both could convert to JSON. However, if the data format is the canonical interoperable format, I would only be able to write it as a number. Thus, it is critical for interoperability between formats to specify if the data definition is canonical, or if the JSON serialization is canonical. If the latter, there really is no need for the data definitions at all; if this choice is made, interoperability would be more likely if the data definitions were removed. I hope this helps clarify why the WG needs to choose one or the other. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
