Re: Revision of p2 2.2.1 / who can generate a status code?

On 3/07/2012 2:00 p.m., Mark Nottingham wrote:
> <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#considerations.for.new.methods> currently has:
>
>> When it is necessary to express new semantics for a HTTP request that aren't specific to a single application or media type, and currently defined methods are inadequate, it might be appropriate to register a new method.
>>
>> HTTP methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, "type" of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't specific to a single application, so that this is clear.
>>
>> Due to the parsing rules defined in Section 3.3 of [Part1], definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
>>
>> New method definitions need to indicate whether they are safe (Section 2.1.1), what semantics (if any) the request body has, and whether they are idempotent (Section 2.1.2). They also need to state whether they can be cached ([Part6]); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used to satisfy a subsequent request.
> Based on discussion, I suggest it be replaced with:
>
> """
> When it is necessary to express new semantics for a HTTP request that aren't specific to a single application or media type, and currently defined methods are inadequate, it might be appropriate to register a new method.
>
> HTTP methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, "type" of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't specific to a single application, so that this is clear.
>
> Due to the parsing rules defined in Section 3.3 of [Part1], definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
>
> Definitions of new methods need to indicate:
>
> * whether they are safe (Section 2.1.1),
> * whether they are idempotent (Section 2.1.2),
> * what semantics (if any) the request body has,
> * whether proxies, origin servers (including gateways), intermediaries (proxy or gateway) or all servers can generate this status code,

Clarity: "this status code"? this list context is about methods so far.

> * whether they can be cached ([Part6]); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used to satisfy a subsequent request.

Clarity: is "they" talking about the method? request entity? or response 
entity?

> """
>

AYJ

Received on Wednesday, 4 July 2012 07:17:36 UTC