personally I wouldn't call it optional - it is just unenforceable and has no wire level requirements. So I guess its optional from an interop perspective, but its impossible to do useful mux without it. The definition of how the peer interprets weights is going to be a local decision and as I mentioned in the next post you can't really know what is instantaneously available to send from the other end of the pipe. Other stuff flows into that - paging and buffering algorithms and what not. Some priority is absolutely required to build a useful h2 implementation, but there really are no MUSTs that can be put around it that mean anything. we can certainly write some version of "when choosing which stream to send the peer MUST choose the highest priority stream that has data currently available." But that doesn't actually do anything useful for compliance or interop because "currently available" needs to be open ended and is unknowable by the peer. Its a pointless MUST. On Mon, Jul 14, 2014 at 9:44 AM, <K.Morgan@iaea.org> wrote: > On Monday,14 July 2014 15:41, patrick.ducksong@gmail.com wrote: > > I've been doing interop with a spdy proxy that doesn't implement > priority - its > > way worse than h1. Click on a download and try and load a new page - the > page > > blocks on the download :) > > > > That begs the question, if it's so important, why isn't PRIORITY a > *required* aspect of h2? > > > > This email message is intended only for the use of the named recipient. > Information contained in this email message and its attachments may be > privileged, confidential and protected from disclosure. If you are not the > intended recipient, please do not read, copy, use or disclose this > communication to others. Also please notify the sender by replying to this > message and then delete it from your system. >
Received on Monday, 14 July 2014 13:53:53 UTC