W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

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

From: Pete Resnick <presnick@qti.qualcomm.com>
Date: Fri, 31 Jul 2015 07:22:28 -0500
To: Julian Reschke <julian.reschke@gmx.de>
CC: <apps-discuss@ietf.org>, <draft-ietf-httpbis-cice.all@ietf.org>, <iesg@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <F54E1BE2-2F61-45DF-8182-2584673B982E@qti.qualcomm.com>
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
>> 3.1.2.2 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.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
Received on Friday, 31 July 2015 12:23:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC