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

From: Julian Reschke <[email-masked]>
Date: Fri, 31 Jul 2015 12:41:03 +0200

Hi Pete,

thanks for the feedback. I'm ccing the WG....

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. It seems simpler to leave that alone
> and make the following change:

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.

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

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.

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

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.

Best regards, Julian

---

From: Pete Resnick <[email-masked]>
Date: Fri, 31 Jul 2015 07:22:28 -0500

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

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

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

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

> Yep; yet another good improvement.

Thanks. Glad they helped.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Julian Reschke <[email-masked]>
Date: Fri, 31 Jul 2015 14:40:17 +0200

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

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

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

No, it means I forgot to reply.

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

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 1 Aug 2015 07:24:39 +1200

> saying "MAY" here would be contrary to that goal.

And the other reason behind that change is that cice compliant clients
not getting 415 are likely to re-try the request including the broken
encoding again and again and ... as they try every other possible reason
for it to be rejected.

Amos

---

From: Barry Leiba <[email-masked]>
Date: Sat, 1 Aug 2015 03:59:11 +0200

> To define them, but also to have a way to find the current definition of

Right.  The best way to handle this particular situation isn't to make
this "update" 7231, but to add this to [RFC7231] in the reference
field for status code 415 in the registry.

On the other hand, let me probe Pete's point a bit:
Someone reads 7231 and sees the definition for 415.  That someone
doesn't read this, perhaps because she doesn't know about it.  She
also doesn't look at the registry entry, and thus doesn't see the
reference, because, after all, it's clear that 7231 defines 415, so
why would one need to look at the registry entry for 415?

In a case such as that, "updates" could be useful.  I'm ambivalent
about whether we should do that, though -- we are trying to avoid
using "updates" for optional extensions.

Barry

---

From: Julian Reschke <[email-masked]>
Date: Sat, 1 Aug 2015 08:06:11 +0200

> why would one need to look at the registry entry for 415?

That is true. But would that person actually *find* the document 
updating RFC 7231 in the first place? It's not like we're changing the 
RFC 7231, we'd just be changing the RFC database.

(And yes, if the user would read 7231 through tools.ietf.com or 
greenbytes.de, that information would actually appear on the RFC; but 
how good does this scale once we have 10 documents "updating" 7231?)

> using "updates" for optional extensions.

Agreed.

Best regards, Julian