On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre <say...@gmail.com> wrote:
> Judging by the mailing list archives, the design of the field is >>> intentional. It's not clear to me why "zeros" wasn't specified as >>> variable-length with a prose restriction, though. >>> >> >> Because then you have a spurious length field. >> > > I don't understand why it would be spurious. In this case, the > deserializing implementation needs to inspect every byte anyway. > Because if you set padding to be the length of the maximum value, then a length byte makes every message one longer. > >> This part of the spec is also just generally difficult to follow, in my >>> opinion. I had no trouble following the ESNIKeys section. Perhaps the >>> problem is in the interaction of prose order, serialization order, and >>> procedural code order. >>> >> >> Well, this structure is likely to change a fair bit, so probably not >> worth trying to update the text right at this moment. >> > > Fair enough. I would also suggest making sure that this section does not > span a page boundary. That made things worse for me. > At this early stage, we usually don't worry over-much about page breaks. -Ekr > thanks, > Rob >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
