Re: Prefer Draft Feedback

On 2011-12-05 20:55, James Snell wrote:
> Julian, again, thank you for feedback.. a few clarifying questions
> below however...
>
> On Sun, Dec 4, 2011 at 11:06 AM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> [snip]
>>      return-content = "return-content"
>>
>> Maybe this should be called "return-representation".
>>
>
> I'm thinking "return-content" is going to be a bit more consistent
> with other bits... such as "Content-Location".. but I'm not adverse to
> renaming it.

Well, at least the prose needs to make clear what it means :-)

>> 5.  The "return-status" Preference
>>
>>    The "return-status" preference indicates that the user-agent prefers
>>    the server to include an entity describing the status of the request
>>    in the response as opposed to returning a representation of the
>>    current state of the resource.
>>
>>      return-status = "return-status"
>>
>>    When honoring the "return-status" preference, the server SHOULD NOT
>>    include a Content-Location header in the response.
>>
>> Why not?
>>
>
> I've gone back and forth on this particular point... essentially tho,
> there really isn't any clear means of identifying when a particular
> response is a representation of the resource or a representation of
> the request status... there's absolutely nothing in the response that
> I can key off of to make that determination reliably... The idea,
> then, is to use the presence or lack of a Content-Location header as
> that key. If I send return-content and get back a response with a
> Content-Location header, then I assume it's a representation of the
> resource and can assume the preference was applied, if I receive back
> a response without a Content-Location, then I assume it's a status
> response and have to handle it accordingly. I'm definitely open to a
> better suggestion.

Well, a status message could have a content-location as well. Think a 
monitor resource after 202.

I think the current language restricts servers from doing what's allowed 
today.

Wouldn't (have Content-Location) AND (Content-Location == effective 
Request URI) work?

> ...
>> 7.  The "wait" Preference
>>
>>    The "wait" preference can be used to establish an upper bound on the
>>    length of time, in seconds, the user-agent is willing to wait for a
>>    response, after which the user-agent may choose to abandon the
>>    request.  In the case generating a response will take longer than the
>>    time specified, the server, or proxy, can choose to either return a
>>    202 Accepted response, cancel processing, or continue attempting to
>>    complete the request.
>>
>>      wait = "wait" "=" delta-seconds
>>
>> Potential overlap with other work?
>>
>
> I've considered that also but I'm not sure. I haven't really seen much
> that specifically deals with wait times, especially in an optional
> arrangement such as this. I think for now, I'll leave this in and if
> it becomes clear that there's overlap in other areas, I can revisit
> it.

There was talk about this in the context of making long polling work better.

>> [snip]
>> 11.  Registered Preferences
>>
>>    Well-defined preferences can be registered for convenience and/or to
>>    promote reuse by other applications.  This specification establishes
>>    an IANA registry of such relation types see Section Section 12.1.
>>
>>    Registered preference names MUST conform to the token rule, and MUST
>>    be compared character-by-character in a case-insensitive fashion.
>>
>> No, this is inconsistent with the use in similar header fields (like
>> Cache-Control)
>>
>
> Not sure what exactly you're objecting to here. Is it the registry or
> the comparison rule?

The comparison rule.

> ...

Best regards, Julian

Received on Monday, 5 December 2011 20:12:51 UTC