- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 1 Nov 2016 08:25:03 +0100
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
On 2016-11-01 08:08, Kazuho Oku wrote: > 2016-11-01 15:32 GMT+09:00 Julian Reschke <julian.reschke@gmx.de>: >> On 2016-11-01 02:32, Kazuho Oku wrote: >>> >>> Cory, Julian, thank you for looking into the I-D. >>> >>> Thank you for looking into the existing implementations using Python. >>> Your research makes it evident that some kind of negotiation is >>> mandatory if we are going to use 103 on the public Internet. >> >> >> Having to negotiate it makes me sad. > > Thank you for the suggestion. > > I think having negotiation is a good thing for Early Data, since there > is no point in sending Early Data to a client that does not recognizes > the headers included in the informational response. So I'd expect that > if we define an Accept-EH header, a server serving to the Internet > will send Early Data only when the header has included in the request. > > OTOH, we do not need to use Accept-EH header on a deployment in which > the peer is known to support Early Data. > > Considering the two, having a clause like the following (with > non-normative text explaining the background) seems reasonable to me: > > “a server SHOULD NOT send Early Data unless the client has sent an > Accept-EH header” > > Does this look fine to you? I would avoid BCP14 keywords here. If a recipient fails because it has broken 1xx handling, I wouldn't want a statement like that support them in their view. > ... Best regards, Julian
Received on Tuesday, 1 November 2016 07:25:39 UTC