Re: Prefer Draft Feedback

On Wed, Dec 7, 2011 at 7:33 AM, Moore, Jonathan (CIM)
<Jonathan_Moore@comcast.com> wrote:
> [snip]
> 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?
>

The distinction between SHOULD and MAY is critical for Prefer, yes.

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

Possibly yes, but there are other possible solutions. For instance, we
could -- in theory -- leverage the Content-Disposition header using an
extension parameter... e.g.

Content-Disposition: inline; nature=representation
Content-Disposition: inline: nature=status

This would address the issue just fine, I think.  What I'm wondering,
however, is whether this is really all that much different than using
Preference-Applied, tho, and whether Just Using Something Else really
addresses Mark's concern.

- James

> Jon
> ........
> Jon Moore
> Comcast Interactive Media
>
>
>
> From: James Snell <jasnell@gmail.com>
> Date: Wed, 7 Dec 2011 06:34:02 -0800
> To: Jonathan Moore <Jonathan_Moore@Comcast.com>
> Cc: Alex Rousskov <rousskov@measurement-factory.com>, Martin Thomson
> <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Mark
> Nottingham <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>
> 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
>>
>>
>>
>>
>>
>

Received on Wednesday, 7 December 2011 15:57:09 UTC