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