- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 15 Jul 2014 15:30:02 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Martin Thomson <martin.thomson@gmail.com>
It sounds like we've converged on getting rid of END_SEGMENT. I've marked it as editor-ready. Regards, On 3 Jul 2014, at 1:43 am, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > Explicit acknowledgements are required for extensions which change semantics, which would include (re-)defining a flag on the DATA frame. On the other hand, without acknowledgement, an END_SEGMENT frame could be defined with no payload and would be discarded by implementations that don’t understand it. > > Sent from Windows Mail > > From: Yutaka Hirano > Sent: Tuesday, July 1, 2014 10:32 PM > To: Mark Nottingham > Cc: HTTP Working Group, Martin Thomson > > It is OK for me if an "explicit acknowledgement" (including proxies) mechanism for extensions is specified in the HTTP/2 spec. Otherwise, not. > IIUC such mechanism is not specified, right? Is there any discussion? > > Thanks, > > > > On Wed, Jul 2, 2014 at 2:02 PM, Mark Nottingham <mnot@mnot.net> wrote: > <https://github.com/http2/http2-spec/issues/537> > > On 1 Jul 2014, at 4:40 am, Martin Thomson <martin.thomson@gmail.com> wrote: > > > On 30 June 2014 11:23, David Krauss <potswa@gmail.com> wrote: > >>> That's an argument for the new application negotiation token. > >> > >> Such a proxy should only be put in a place where no negotiation is necessary. Bailing out at any END_SEGMENT would be acceptable then. > > > > There's an obvious counterargument to that one... > > > > That's fine, but if you want to operate sans-standard, then you can > > add your own END_SEGMENT. > > > > I really don't care either way here. I'm just enumerating the > > options, and noting that what is currently specified isn't > > particularly well-supported. Our responsibility is to either more > > clearly define it, or remove it. > > Agreed. > > It sounds like we're leaning towards removing it - can people live with that? > > > -- > Mark Nottingham https://www.mnot.net/ -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 15 July 2014 05:30:31 UTC