Re: Appdir Review of draft-ietf-httpbis-cice-01

Hi Pete,

thanks for the feedback. I'm ccing the WG....

On 2015-07-30 22:08, Pete Resnick wrote:
> ...
> Comments:
>
> No major issues at all in this document, but a couple of things to
> consider.
>
> Minor Issues:
>
> Section 3 of this document seems to change the MAY in RFC 7231 section
> 3.1.2.2 regarding the 415 response to a SHOULD. I don't see any
> particular justification for that. It seems simpler to leave that alone
> and make the following change:

I'd say that this is intentional. We really *want* people conforming to 
this spec to sue 415 in this cases, so a SHOULD seems to be justified.

> OLD
>     Servers that fail a request due to an unsupported content coding
>     SHOULD respond with a 415 status and SHOULD include an "Accept-
>     Encoding" header field in that response, allowing clients to
>     distinguish between content coding related issues and media type
>     related issues.
> NEW
>     Servers that fail a request due to an unsupported content coding and
>     respond with a 415 status SHOULD include an "Accept-Encoding" header
>     field in that response, allowing clients to distinguish between
>     content coding related issues and media type related issues.
>
> If you are going to change the MAY to a SHOULD, I’m guessing this
> document would end up updating 7231. Again, I don’t suggest you do that.

IMHO we should avoid using the "updates" hammer for minor changes like 
these; we have the IANA registries for a reason.

This spec already updates the entry for "Content-Encoding"; one could 
argue we need to update the one for 415 as well. Feedback appreciated.

> Section 6: This may be completely off the wall, but is there any way
> that a server could convince a client to do something stupid and/or
> dangerous by asking it for a different suggested encoding? Unlike using
> it for requests, putting an Accept-Encoding in a response is telling the
> client, "Please try again, this time using encoding X". If it blindly
> does so, could a client get itself in trouble? Like I said, this might
> be completely silly, but someone who knows HTTP better than I should
> probably say, "No, this isn't going to cause a problem."
>
>
> Nits:
>
> In the Abstract and in section 1:
>
>     to indicate that content codings are supported in requests.
>
> Don't you mean "to indicate the content codings that are supported in
> requests" or "to indicate which content codings are supported in requests"?

The first proposal sounds good to me.

> Section 5:
>
> OLD
>     6.5.13 of [RFC7231] recommends using the status code 415 (Unsupported
>     Media Type)
> NEW
>     6.5.13 of [RFC7231] defines the status code 415 (Unsupported Media
>     Type) for this purpose
>
> No other issues that I can find or invent; looking generally fine.

Yep; yet another good improvement.


Best regards, Julian

Received on Friday, 31 July 2015 10:41:43 UTC