W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

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>
Message-ID: <c1e90f44-2729-805b-010f-778805116d7a@gmx.de>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 November 2016 07:25:47 UTC