- From: Hervé Ruellan <herve.ruellan@crf.canon.fr>
- Date: Tue, 27 Oct 2015 19:06:54 +0100
- To: Cory Benfield <cory@lukasa.co.uk>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Cory, On 27/10/15 01:30, Cory Benfield wrote: > > > On 27 Oct 2015, at 02:54, Hervé Ruellan <herve.ruellan@crf.canon.fr> > wrote: > > > > The Accept Push Policy Draft [1] is a proposal for enabling a client > and a server negotiate how the server uses HTTP/2 push. This is > realized by defining possible "push policies", i.e. behaviours, that > the server can use while responding to the client's request. > > > > These ideas took their origin in the MPEG DASH FDH group, which is > looking on how DASH can take advantages of bidirectional protocols > such as HTTP/2 and WebSocket. > > > > The draft is a proposal to take these ideas and make them available > for wider usage, keeping only the "push policies" that can be used by > any generic HTTP/2 server. > > > > Comments are welcome ! > > > > Hervé. > > > > > > [1] https://tools.ietf.org/html/draft-ruellan-http-accept-push-policy-00 > > > > > Hervé, > > My first impression on this draft is really positive: it seems like an > extremely useful header field, and potentially extremely flexible. I > have some notes: > > - Section 3: Your italics didn’t render out, you have explicit > underscores. I assume that’s not intentional. I'll check that for the next draft. > - Section 3.1: I think the Accept-Push-Policy should be extended to > support a comma-separated list. It seems insufficiently flexible to > allow only one push policy to be requested, especially if > custom/private push-policies are defined. More generally, a > comma-separated list will help ensure that push policies are kept > simple and tightly scoped, rather than encouraging policies to be > monolithic to allow multiple behaviours. I we have only a small set of push-policies, requesting only one policy in the Accept-Push-Policy header may be sufficient. However, I rather agree with you that being able to specify several push-policies (potentially with a preference parameter) adds much more flexibility. > > Those are my initial notes, but I’m going to keep a close eye on this > draft! Great work! Thanks, > > Cory > Hervé
Received on Tuesday, 27 October 2015 18:07:27 UTC