Note that it is not my suggestion to do the experiment this way. However, one could theorise that the work required to support generating, sending, receiving and processing new non-core frame types is greater than implementing some conditional code inside the frame parser. Yes frames are cheap, but they also offer an API surface that things get sticky to. For example, reporting and metrics based on frame type counts etc. That adds more overhead to an ad-hoc short-lived data-gathering experiment. Lucas On Thu, Aug 8, 2019 at 6:39 PM Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote: > < ⋯ > > > > In Montreal we also discussed a possible experiment where the H2 > PRIORITY > > > frame contents would be repurposed, which requires a compatible server > to > > > read it correctly. In this case the signal would be more like "will > send in > > > an RFC7540-incompatible format". > > > > > > Lucas > > > > > > > Eurgh, why? Are we that short on frame types? > > > > Cheers > > -- > > Matthew Kerwin > > https://matthew.kerwin.net.au/ > > Yes, it makes sense to allocate new type number for PRIORITY when frame > content is repurposed. > > Also is make sense to allocate new type number for HEADERS when > "Stream Dependency" or "Weight" field of HEADERS frame conrent is > repurposed. > > That avaind dance about on what point on time change of "Stream > Dependency" / "Weight" field" > field happens. > > > If you are running out of framer's type numbers, reserve some number for > "extended type number". ☻ > > / Kari Hurtta > >
Received on Thursday, 8 August 2019 17:57:32 UTC