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

Re: Prefer Draft Feedback

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Wed, 07 Dec 2011 08:53:15 -0700
Message-ID: <4EDF8BEB.3070402@measurement-factory.com>
To: Mark Nottingham <mnot@mnot.net>
CC: James Snell <jasnell@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 12/06/2011 11:36 PM, Mark Nottingham wrote:
> On 07/12/2011, at 11:57 AM, James Snell wrote:
>> Current iterations based on today's feedback...
>> http://www.ietf.org/id/draft-snell-http-prefer-06.txt
>> Change summary:
>> - replaced user-agent with client
> What's the reasoning here? Do you expect intermediaries to have preferences?

IMO, the general reasoning should be "we do not want to exclude
intermediaries without a specific reason because some of them might find
the new mechanism useful". This is especially true when the mechanism
can be extended.

In this specific case, we have already come up with at least one
possible use: wait=10 preference set by a proxy in a poorly connected
environment when validating a cached response. See this thread for more

>> - brought Preference-Applied back

> This needs to be discussed. I'm very uneasy about turning this into
> Yet Another HTTP Negotiation Mechanism.

If there is an existing mechanism that can be reused to acknowledge
which preference was honored, we should reuse it. Otherwise, a "yet
another" acknowledgement mechanism seems justified.

I am not an expert on this, but my understanding of the arguments
presented so far is that reusing Content-Location to indicate whether
the status preference was applied is not going to cover all possible use

I also find the Preference-Applied acknowledgement mechanism useful for

[ N.B. If "Preference-Applied" stays, please consider renaming it to
"Preferred" to save a few bytes and to remove the implication that all
preferences can be "applied" rather than honored, etc. ]

Thank you,

Received on Wednesday, 7 December 2011 15:54:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:54 UTC