Re: Re-review of draft-snell-http-prefer-15

My .02:

* Technically, the requirement for including a Vary should include the option for using Vary: *; requiring Prefer in the Vary header is too constraining.

* Vary needs to be on *every* response from a resource that evidences negotiation, not those that just happen to be influenced by the Prefer header. 

* The examples section needs to show complete request and response messages, not just examples of the header field in isolation. This spec is not just defining a header, it's defining a protocol.

* "return-async" now seems like a less functional expression of "wait". Also, saying you'd *prefer* something to return async doesn't make much sense; if the request semantics can be honoured immediately and reflected in the response representation, why not allow so? 

I can imagine some protocols that want to tunnel over HTTP wanting to do so, but can't think of any sane use of HTTP that would. return-async can be dropped.

* I still don't see the use cases for Preference-Applied (see message just now on the thread that brought it back). I'm not going to fight it, but am -0.5 on it (as I think it introduces opportunities for people to abuse the mechanism).

Cheers,



On 14/10/2012, at 1:42 AM, Barry Leiba <barryleiba@computer.org> wrote:

> After some discussion on the httpbis mailing list, James made a significant change to draft-snell-http-prefer-15, adding (back) the Preference-Applied response header field.  See:
> http://tools.ietf.org/rfcdiff?url2=draft-snell-http-prefer-15.txt
> 
> Because this happened after last call, I would like the copied communities to re-review this in parallel with IESG Evaluation, and make further comments on that particular change.
> 
> The document is on the 25 Oct telechat, so please post any comments by then.
> 
> Barry, sponsoring AD
> 

--
Mark Nottingham   http://www.mnot.net/