Subject: Accept Push Policy draft

From: Hervé Ruellan <[email-masked]>
Date: Mon, 26 Oct 2015 18:54:50 +0100

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

---

From: Cory Benfield <[email-masked]>
Date: Tue, 27 Oct 2015 09:30:08 +0900

> On 27 Oct 2015, at 02:54, Hervé Ruellan <[email-masked]> 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é.
> 
> 

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.
- 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.

Those are my initial notes, but I’m going to keep a close eye on this draft! Great work!

Cory

---

From: Hervé Ruellan <[email-masked]>
Date: Tue, 27 Oct 2015 19:06:54 +0100

Cory,

On 27/10/15 01:30, Cory Benfield 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.
> >
> 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é.
> >
> >
> 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

Thanks,

> Cory

Hervé