Subject: Fwd: New Version Notification for draft-benfield-http2-p2p-00.txt

From: Cory Benfield <[email-masked]>
Date: Mon, 20 Jul 2015 16:51:21 +0100

For those who are interested, I’ve submitted an initial draft for the HTTP/2 P2P extension to the IETF data tracker: you can find information about that draft below.

Feedback and discussion would be very much appreciated!

Cory

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-benfield-http2-p2p-00.txt
> Date: 20 July 2015 16:46:54 BST
> To: "Cory Benfield" <[email-masked]>, "Cory Benfield" <[email-masked]>
> 
> 
> A new version of I-D, draft-benfield-http2-p2p-00.txt
> has been successfully submitted by Cory Benfield and posted to the
> IETF repository.
> 
> Name:		draft-benfield-http2-p2p
> Revision:	00
> Title:		Peer-to-peer Extension to HTTP/2
> Document date:	2015-07-20
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-benfield-http2-p2p-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-benfield-http2-p2p/
> Htmlized:       https://tools.ietf.org/html/draft-benfield-http2-p2p-00
> 
> 
> Abstract:
>   This document introduces a negotiated extension to HTTP/2 that turns
>   a single HTTP/2 connection into a bi-directional communication
>   channel.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 20 Jul 2015 19:41:11 +0300

On Mon, Jul 20, 2015 at 04:51:21PM +0100, Cory Benfield wrote:
> For those who are interested, I’ve submitted an initial draft for
> the HTTP/2 P2P extension to the IETF data tracker: you can find
> information about that draft below.
> > 

The seemingly only reason server-side SETTINGS_PEER_TO_PEER
is if client wants to wait for acknowledge of server support
before sending its CLIENT_AUTHORITY frames. But omitting that
wait would just cause the CLIENT_AUTHORITY frames to be harmlessly
ignored.

What are the semantics if client sends multiple CLIENT_AUTHRORITY
frames?

The document seems to assume authorities are always global, not
either global or of restricted scope (including link-local).
But usage of authorities of restricted scope has its own issues.

The descriptions of PUSH_PROMISE behavior look bit convoluted.

One seems to say that (given certain conditions) server MAY
set SETTINGS_PUSH_PROMISE to 1.

The other seems to say that to push, one must have per-stream
server role on associated stream.

-Ilari

---

From: David Dias <[email-masked]>
Date: Mon, 20 Jul 2015 17:42:33 +0000

This looks very good indeed, thank you for pushing it forward, Cory!

Best,

> On 20 Jul 2015, at 10:20, Fedor Indutny <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Thank you, looking good!
> 
> On Mon, Jul 20, 2015 at 8:51 AM, Cory Benfield <[email-masked] <mailto:[email-masked]>> wrote:
> > From: [email-masked] <mailto:[email-masked]>
> > To: "Cory Benfield" <[email-masked] <mailto:[email-masked]>>, "Cory Benfield" <[email-masked] <mailto:[email-masked]>>
> >
> >
> > URL:            https://www.ietf.org/internet-drafts/draft-benfield-http2-p2p-00.txt <https://www.ietf.org/internet-drafts/draft-benfield-http2-p2p-00.txt>
> > Status:         https://datatracker.ietf.org/doc/draft-benfield-http2-p2p/ <https://datatracker.ietf.org/doc/draft-benfield-http2-p2p/>
> > Htmlized:       https://tools.ietf.org/html/draft-benfield-http2-p2p-00 <https://tools.ietf.org/html/draft-benfield-http2-p2p-00>
> >
> >
> > Abstract:
> > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> >
> > The IETF Secretariat
> >
> 
>

---

From: Fedor Indutny <[email-masked]>
Date: Mon, 20 Jul 2015 17:21:15 +0000

Thank you, looking good!

Cory

---

From: Cory Benfield <[email-masked]>
Date: Tue, 21 Jul 2015 13:48:13 +0100

> On 20 Jul 2015, at 17:41, Ilari Liusvaara <[email-masked]> wrote:
> 

Thanks for the feedback Ilari! It’s much appreciated

> wait would just cause the CLIENT_AUTHORITY frames to be harmlessly

That’s not the reason. The reason the server would emit SETTINGS_PEER_TO_PEER is to indicate that it’s willing to accept PUSH_PROMISE frames sent from the client. Note that this spec forbids the client from pushing streams without that setting being sent by the server.

I don’t *think* the spec is unclear here, but I’d welcome suggestions for clearer wording if you have any.

> What are the semantics if client sends multiple CLIENT_AUTHRORITY

Good question, I’ll update the spec to cover this. The best approach seems to be to say that each CLIENT_AUTHORITY frame is the complete set of information, so any subsequent CLIENT_AUTHORITY frame overrides the information in earlier ones.

> But usage of authorities of restricted scope has its own issues.

Yeah, this is tricky. I’m not sure whether any guidance can be given here without making the matter even less clear.

> server role on associated stream.

Both things are true. In order to push a stream, the remote peer must have sent SETTINGS_PUSH_PROMISE with value 1, and also the local peer must have per-stream server role on the associated stream. Can you suggest some clearer wording for this?

Cory

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 21 Jul 2015 15:54:17 +0300

On Tue, Jul 21, 2015 at 01:48:13PM +0100, Cory Benfield wrote:
> That’s not the reason. The reason the server would emit SETTINGS_PEER_TO_PEER
> is to indicate that it’s willing to accept PUSH_PROMISE frames sent from the
> client. Note that this spec forbids the client from pushing streams without
> that setting being sent by the server.

Can't server just set SETTINGS_PUSH_PROMISE to 1 after obtaining
SETTINGS_PEER_TO_PEER 1 from client? And SETTINGS_PEER_TO_PEER 1
from client would mean that the server MAY do that?

-Ilari

---

From: Cory Benfield <[email-masked]>
Date: Wed, 22 Jul 2015 17:21:10 +0100

> On 21 Jul 2015, at 13:54, Ilari Liusvaara <[email-masked]> wrote:

Oh that makes more sense! Yeah, I think that can work just fine. I’ll make that revision. Thanks!