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. > 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? It does, thanks! If the WG wants to have a canonical, interoperable serialization instead of a set of data types (such as Section 1.1 in the draft), I support JSON because of its commonness and mostly-useful mapping to the problem space. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
