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

On 2015-07-31 14:22, Pete Resnick wrote:
> 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.

The whole point of this protocol is to expose this information, so 
saying "MAY" here would be contrary to that goal.

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

To define them, but also to have a way to find the current definition of 
that protocol point.

So the main question here really is whether this is an optional protocol 
extension or not. The intent was to make this optional (we don't want to 
break existing servers that do not do this), but also to encourage 
people to implement this.

> 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”? ;-)

No, it means I forgot to reply.

And no, I don't think there's a problem here.

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

Best regards, Julian

Received on Friday, 31 July 2015 12:40:54 UTC