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>
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
>
>
>
>
>
>