Re: New Version Notification for draft-benfield-http2-p2p-01.txt

Hi all,

Apologies for the slow reply, I found myself traveling to a couple of conferences during the month of August that consumed my full availability.

This extension to the HTTP2 Protocol looks very good indeed and fulfils the our expectations of using the robust framing layer designed for HTTP2 in P2P application scenarios. There are just only two segments that I need some clarification, namely:


2.2 CLIENT_AUTHORITY Frame
...
The purpose of this frame is to allow a client to advertise
the authority or authorities for which it is prepared to accept
requests.
Does this mean that a HTTP2-P2P client would have to announce every single authority it is willing to accept requests from? Would it be possible to do this with an header or simply by not sending the SETTINGS_PEER_TO_PEER frame if the client verifies that it is speaking with a server it is not interested in receiving requests from?

2.4 Client Behavioural Changes
…
The client MUST NOT
send a PUSH_PROMISE frame on a stream that it opened by means of a
HEADERS frame: only server-initiated streams may be used for sending
PUSH_PROMISE frames.  All other limitations about PUSH_PROMISE frames
in RFC 7540 [RFC7540] continue to apply, except that the words
'server' and 'client' are defined on a per-stream basis.
I believe the intended behaviour would be for a server to be able to send a PUSH_PROMISE frame on a client-initiated stream (a first request from the client) and not on a server-initiate stream.

One another thing I would like to point out is that we learned that declaring the participants in a connection as ‘dialer’ and ‘listener’ instead of ‘client’ and ‘server’, help achieve a better understanding how the system is designed to be distributed, meaning that every entity speak and implement the same protocol and respective semantics.

Thank you for working on this specification, we are really excited and looking forward to see it as a final RFC, so that we can collaborate on a unified implementation with the other groups who have been implementing their own versions of the spdy/http2 framing layer.

Best regards,




> On 27 Jul 2015, at 01:43, Fedor Indutny <fedor@indutny.com> wrote:
> 
> Thank you, looks even better now!
> 
> On Sun, Jul 26, 2015 at 10:12 AM, Cory Benfield <cory@lukasa.co.uk <mailto:cory@lukasa.co.uk>> wrote:
> I’ve updated the HTTP/2 P2P draft in response to the feedback received this week. Particular thanks to Ilari, who provided substantial feedback and corrections. The major change here is that the server no longer needs to advertise its support for the extension.
> 
> Once again, more feedback would be appreciated!
> 
> Cory
> 
> > Begin forwarded message:
> >
> > From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
> > Subject: New Version Notification for draft-benfield-http2-p2p-01.txt
> > Date: 26 July 2015 18:09:38 BST
> > To: "Cory Benfield" <cory@lukasa.co.uk <mailto:cory@lukasa.co.uk>>, "Cory Benfield" <cory@lukasa.co.uk <mailto:cory@lukasa.co.uk>>
> >
> >
> > A new version of I-D, draft-benfield-http2-p2p-01.txt
> > has been successfully submitted by Cory Benfield and posted to the
> > IETF repository.
> >
> > Name:         draft-benfield-http2-p2p
> > Revision:     01
> > Title:                Peer-to-peer Extension to HTTP/2
> > Document date:        2015-07-26
> > Group:                Individual Submission
> > Pages:                8
> > URL:            https://www.ietf.org/internet-drafts/draft-benfield-http2-p2p-01.txt <https://www.ietf.org/internet-drafts/draft-benfield-http2-p2p-01.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-01 <https://tools.ietf.org/html/draft-benfield-http2-p2p-01>
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-benfield-http2-p2p-01 <https://www.ietf.org/rfcdiff?url2=draft-benfield-http2-p2p-01>
> >
> > 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 <http://tools.ietf.org/>.
> >
> > The IETF Secretariat
> >
> 
>