[apps-discuss] Appdir Review of draft-ietf-httpbis-cice-01

[Pete Resnick <[e-mail]>]

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate 
).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.
Document: draft-ietf-httpbis-cice
Title: Hypertext Transfer Protocol (HTTP) Client-Initiated 
Content-Encoding
Reviewer: Pete Resnick
Review Date: 2015-07-30
IETF Last Call Date: 2015-07-21
IESG Telechat Date: Unknown
Summary: This draft is basically ready for publication as a Proposed 
Standard, but there are a few minor issues that might need to be 
addressed.

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:

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.

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"?

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.

pr