Subject: Re: draft-reschke-http-cice vs discussions in Toronto @ IETF 90: use as response header field

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 Feb 2015 17:39:27 +1100

> On 31 Jan 2015, at 10:02 pm, Julian Reschke <[email-masked]> wrote:
> 
> Hi there,
> 
> the minutes (<http://tools.ietf.org/wg/httpbis/minutes?item=minutes-90-httpbis.html>) say:
> 
>> MarK: Different meaning in the request vs. response, makes him twitchy
> 
> Mark, could you elaborate on that a bit? Do you believe that changing something which currently is a request header field only to be used as response header field as well to be a problem in general? Why?

Experience with Cache-Control -- people get confused over what the pertinent directives are in each direction, and misuse it as a result.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Feb 2015 08:57:34 +0100

> Experience with Cache-Control -- people get confused over what the pertinent directives are in each direction, and misuse it as a result.

Well, we've got many other header fields where the experience seems to 
be exactly the opposite, say Content-Type or Content-Encoding. Thus I'm 
not yet convinced this is an issue...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 Feb 2015 19:07:56 +1100

Yes, but the semantics of those headers are exactly the same in both directions.

Sent from my iPhone

> On 2 Feb 2015, at 6:57 pm, Julian Reschke <[email-masked]> wrote:
> 
> Well, we've got many other header fields where the experience seems to be exactly the opposite, say Content-Type or Content-Encoding. Thus I'm not yet convinced this is an issue...
> 
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Feb 2015 09:18:13 +0100

> Yes, but the semantics of those headers are exactly the same in both directions.

I think that's the case here, too. No?

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 02 Feb 2015 23:55:06 +1300

> I think that's the case here, too. No?

Unless I am completely mis-reading it.

In both directions, and for all status codes it means "I can receive
encoding format(s) X,Y,Z". The rest of the draft is just elaboration and
specific syntax. Yes?

Amos

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Feb 2015 12:02:10 +0100

> encoding format(s) X,Y,Z". The rest of the draft is just elaboration and

Yes. If we had done this in RFC 7231, it would have been something like 
5 additional lines.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 Feb 2015 12:23:50 +1100

> I think that's the case here, too. No?

No. The existing, client-to-server semantic of Accept-Encoding is "For the response associated with this request, I will accept the following encodings..."

In the server-to-client direction, the proposed semantic is "For some unbounded set of future requests, I might accept the following encodings..."

There are a number of subtle differences there, especially about the scope of applicability -- one of the most ill-defined areas in HTTP metadata.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Feb 2015 08:11:04 +0100

> In the server-to-client direction, the proposed semantic is "For some unbounded set of future requests, I might accept the following encodings..."

I agree that there's a difference here, but I fail to see how it's 
critical. I could rephrase the definition to clarify that the 
information applies to the request it was sent with, and that future 
requests can have different behavior.

> There are a number of subtle differences there, especially about the scope of applicability -- one of the most ill-defined areas in HTTP metadata.

Anything besides the freshness issue?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Feb 2015 11:17:09 +1100

> On 9 Feb 2015, at 6:11 pm, Julian Reschke <[email-masked]> wrote:
> 
> I agree that there's a difference here, but I fail to see how it's critical. I could rephrase the definition to clarify that the information applies to the request it was sent with, and that future requests can have different behavior.

The difference in Cache-Control is likewise small, but it causes problems often IME.

> Anything besides the freshness issue?

It's also a certainty issue -- if you send Accept-Encoding as a client, the server knows it can select one of those encodings, and doesn't have to worry about failure. If the server sends it and the client uses it, the client needs to be able to recover from failure gracefully.

Let's flip it around -- what does reusing A-E buy us here? Are we trying to conserve registry space or something? :)

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Feb 2015 07:49:14 +0100

On 2015-02-10 01:17, Mark Nottingham wrote:
> ...

I think having "almost the same" functionality in two different header 
fields is confusing as well...