You can consider my prior statement as grudging support, if that wasn’t clear. I’d prefer a format with zero representational ambiguity, because we’ve all seen how fun that ambiguity ends up being to deal with in the ecosystem, but that doesn’t stop it being true that zero is worse than one. -=R
From: QUIC <[email protected]> on behalf of Spencer Dawkins at IETF <[email protected]> Date: Thursday, August 5, 2021 at 10:18 AM To: Roberto Peon <[email protected]> Cc: Paul Hoffman <[email protected]>, QUIC WG <[email protected]>, QUIC WG Chairs <[email protected]>, Lucas Pardue <[email protected]> Subject: Re: [Ext] Consensus call for qlog serialization format (issue #144) On this point ... On Thu, Aug 5, 2021 at 11:55 AM Roberto Peon <[email protected]<mailto:[email protected]>> wrote: Including at least one interoperable format is good. Having it be ascii is annoying (not very performant, requires more I/O, and thus decreases the fidelity at which we can ultimately capture events) …but it is probably better than nothing. Having at least one interoperable format is excellent, since you and I can always exchange data using that format. Not having something that's fairly widely implemented, at least among early implementers, really is "nothing", so this is "better than nothing". Having the baseline format be annoying can be OK, because that motivates people to explore other formats while using the baseline format, if it's TOO annoying. I'm not saying it would have been a great plan, but at IETF 83 during discussions about RTCWeb codec selections, when the choice between VP8 and H.264 seemed deadlocked, the working group had a serious conversation about picking H.261 as an annoying (or worse) baseline so that we didn't have complete communication breakdowns, and then implementations could negotiate for a better choice if that seemed necessary. (see https://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.txt<https://www.ietf.org/proceedings/83/minutes/minutes-83-rtcweb.txt> for proof). Best, Spencer
