<div dir="ltr"><div class="gmail_quote">On Tue, May 3, 2016 at 6:46 AM, Tony Arcieri <span dir="ltr"><<a href="mailto:bascule@gmail.com" target="_blank">bascule@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><div></div></div><div><div><div dir="ltr"></div></div></div></span><div><br></div><div></div><div dir="ltr"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"></blockquote></div></div><span style="font-size:12.8px">Granted this is generally less of a problem with Protobufs than other formats, but it seems like one with solving with some standard method than an ad hoc format-specific invention...</span></div>
</blockquote></div><div><br></div><div>It's not too "ad hoc".  The protobufs encoding specification recommends minimal integer encoding and field ordering by tag number anyway, so the "canonical" format is the same as the "recommended" format for protobufs.  If you use a regular protobuf library in the recommended way to write then canonical should "just happen".  The standard encoding does allow for other field orderings so that multiple protobufs can be concatenated to create one larger parsable protobuf.  We don't need that except for certificate chains.</div><div><br></div><div>And yes, I do realise the irony of saying "MUST be canonical" one day, and then "canonical maybe doesn't matter" the next. :-)</div><div><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Rhys.</div><div class="gmail_extra"><br></div></div>