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

On 31 Jul 2015, at 5:41, Julian Reschke wrote:

> 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
>> regarding the 415 response to a SHOULD. I don't see any
>> particular justification for that.
> 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.

Well, “want” is not a reason to make a protocol requirement :-) , 
but I think I get your meaning: It *is* important for better 
interoperability for people to use this.

>> 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.

Barry should weigh in on this, but here’s my take: IANA registries are 
not meant to impose protocol requirements; IANA registry entries are 
just meant to define code points. If there’s a requirement that the 
implementer needs to know about, that belongs in the spec. And in this 
case, you *are* really saying, “We had this optional thing in 7231, 
but we’ve found that there’s good interoperability reason for 
implementers to do this in a particular way, so we’re letting you know 
that we’ve made a change.” I don’t think “Updates” is a big 
hammer; it’s a document reference mechanism. (Yes, I wish we had a 
more surgical tool for this kind of thing, but I think “Updates” is 
OK for this.)

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

Should I take your silence on the above to mean, “Pete, you’re a 
goofball” or simply “No comment”? ;-)

>> 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.

Thanks. Glad they helped.

Pete Resnick <>
Qualcomm Technologies, Inc. - +1 (858)651-4478

Received on Friday, 31 July 2015 12:23:11 UTC