Re: Prefer Draft Feedback

My point is that existing negotiation schemes (Accept, Accept-Encoding, Accept-Language, Accept-Charset) are all basically preferences—a (conditionally) compliant server may simply ignore them. Even conditional GETs simply express a preference to get a 304 if possible—but a 200 is still a valid response.

So I guess I'll ask: how are preferences as you see them different from existing server-side negotiations? Is the difference that an unconditionally compliant server SHOULD honor requested negotiations but MAY choose to honor preferences or not, as it chooses?

On the topic of return-status v. return-representation, couldn't the server set a Link header to make this unambiguous?

Jon
........
Jon Moore
Comcast Interactive Media



From: James Snell <jasnell@gmail.com<mailto:jasnell@gmail.com>>
Date: Wed, 7 Dec 2011 06:34:02 -0800
To: Jonathan Moore <Jonathan_Moore@Comcast.com<mailto:Jonathan_Moore@Comcast.com>>
Cc: Alex Rousskov <rousskov@measurement-factory.com<mailto:rousskov@measurement-factory.com>>, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>, HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>>
Subject: RE: Prefer Draft Feedback


For me, it's not so much about coming up with an über negotiation mechanism... In fact, that's rather frightening to think about... I just need it to be unambiguous as to whether or not particular preferences were applied or not. For most preferences, I suspect, as Mark has argued in previous feedback, application is going to be readily apparent and detectable via context, however there will be some that aren't easily detectable. The return-representation v. return-status tokens, for example. In most cases, I suspect the use of content-location as a signal would be sufficient, or some heuristic based on comparing request uri, to content-location, and possibly the location field, etc but such heuristics are certainly not infalible. I fear that the cases where it doesn't hold up will undermine their utility and increase the complexity of the mechanism. So let's focus on just that one use case and see if we can reach s reasonable solution... Given return-representation and return-status, how can I reliably, consistently and simply know which type of response the server has provided?

On Dec 7, 2011 3:46 AM, "Moore, Jonathan (CIM)" <Jonathan_Moore@comcast.com<mailto:Jonathan_Moore@comcast.com>> wrote:
On Wednesday, December 07, 2011 1:36 AM, Mark Nottingham wrote:
> > - brought Preference-Applied back
>
> This needs to be discussed. I'm very uneasy about turning this into Yet Another HTTP Negotiation Mechanism.

Can you explain your unease? It seems like all the pre-existing server-side negotiation mechanisms (Accept, Accept-Language, etc.) all basically have an "express your desire but check the response anyway" semantic. For example, servers are explicitly not required to send a 406 if they can't honor an Accept header. However, there are (optional) protocol-level means that servers can use to provide more context to clients--Content-Language being a good example. Therefore, in some sense, they are all client "preferences" one way or another. Perhaps we're just defining "the last negotiation mechanism you'll ever need"?

Or are you suggesting server-side negotiation was a Bad Idea, and hence we shouldn't be pursuing other means for it?

Curiously yours,
Jon