Re: Investigation of Existing Encoding Formats

Good idea, I'll generate protobuf, custom, and CBOR encodings for a few
sample request/responses so we can get a more concrete picture on the
encoding overhead for each format.

On Wed, Jan 27, 2021 at 7:06 PM Chris Lilley <chris@w3.org> wrote:

>
> On 2021-01-27 23:09, Garret Rieger wrote:
>
> CBOR (Concise Binary Object Representation)
>
> CBOR - Wikipedia <https://en.wikipedia.org/wiki/CBOR>, rfc8949
> <https://tools.ietf.org/html/rfc8949>
>
> I agree that CBOR looks like a good candidate; standardized, multiple
> implementations.
>
> It would perhaps be wise to encode some sample transactions in CBOR and in
> the originally proposed custom encoding, just to check that the overall
> sizes are comparable. But assuming that checks out, this does look like the
> best choice from the options you listed.
>
> Ah, I notice that this is one of the more modern RFCs which is also
> available as-authored in html, as well as the traditional IETF "looks like
> a lineprinter" format.
>
> Compare
>
>   https://tools.ietf.org/html/rfc8949
>
> and
>
>   https://www.rfc-editor.org/rfc/rfc8949.html
>
> Oh cool, specref already has this
>
>   https://api.specref.org/bibrefs?refs=rfc8949
>
> so a reference in the bikeshed like [[rfc8949]] will work correctly.
>
> --
> Chris Lilley
> @svgeesus
> Technical Director @ W3C
> W3C Strategy Team, Core Web Design
> W3C Architecture & Technology Team, Core Web & Media
>
>