Re: Informal Last Call for HTTP Preference Header

I have only one real problem with the document as it stands.

Though the document requires that new preferences describe security
considerations, security considerations for the preferences included
are non-existent.  At a minimum, something needs to be said about the
security properties of the included preferences.

I suspect that the story is, in general:

A server could incur greater costs in attempting to comply with a
particular preference (for instance, the cost of providing a
representation in a response that would not ordinarily contain one; or
the commitment of resources necessary to track state for an
asynchronous response).  Unconditional compliance from a server could
allow the use of preferences for denial of service.  A server can
ignore an expressed preference to avoid expending resources that it
does not wish to commit.

--Martin

On 31 January 2012 13:28, James Snell <jasnell@gmail.com> wrote:
> I just posted an update for the HTTP Prefer Header altering the
> intended status from "Informational" to "Standards Track". No
> additional changes were made. As I have not received any further
> technical input on the specification, I am issuing an *Informal* Last
> Call for comments before I request that it be kicked up the chain for
> review.
>
> Mark Nottingham has agreed to serve as the document shepherd for
> helping to move it forward.
>
> Current Draft: http://www.ietf.org/id/draft-snell-http-prefer-11.txt
>
> - James
>