Subject: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-13

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 16 Oct 2014 03:35:11 +0000

Document: draft-ietf-weirds-using-http-13
Title: HTTP usage in the Registration Data Access Protocol (RDAP)
Reviewer: Bert Greevenbosch
Review Date: 15 October 2014
IETF Last Call Date: 24 October 2014
IESG Telechat Date: 30 October 2014
Summary: Needs edits and maybe removals.

Major Issues:

(M1) Section 5 is written in an extremely optional way. In addition, it doesn't use RFC 2119 conventions. Since section 5 seems to be the main reason of the draft, I suggest to make it more formal by using RFC 2119 conventions. This also holds for other parts of the draft.

(M2) Section 5.5: "When a server declines to answer a query due to rate limits, it returns a 429 response code as described in [RFC6585]." If the client is really annoying the server with sending many requests, the server should be allowed to not respond at all.

(M3) Section 6: "ABNF for JSON names" Why is this in the "RDAP over HTTP" draft? It seems more suitable to go into the "RDAP JSON response" draft, the "Query" draft or maybe the "Bootstrap" draft.

(M4) Appendix C "In some cases, particularly sub-delegations made between RIRs known as "ERX space" and transfers of networks, multiple HTTP redirects will be issued.". In addition, section 5.2 states that "If a server wishes to inform a client that the answer to a given query can be found elsewhere, it returns either a 301 response code ... and it includes an HTTP(S) URL in the Location: header field. The client is expected to issue a subsequent request to satisfy the original query using the given URL without any processing of the URL...". This seems to cater for interesting infinite loops, when e.g. one server points at another and that other server points at the first. Maybe something for the security considerations section?

Minor Issues:

(m1) Section 3: "clients are not expected to fork multiple paths of execution to satisfy a query." What does this mean? Please clarify.

(m2) Section 5: Maybe add textual descriptions of HTTP errors 302, 303 and 307, as well as a reference to RFC 7231.

(m3) Section 5.4: "If a server receives a query which it cannot interpret as an RDAP query, it returns a 400 response code." This makes sense, as long as the server only supports RDAP. Otherwise, it should be allowed to handle non-RDAP requests in another way.

(m4) Section 8.1, "RDAP extensions registry". Does this belong in the HTTP document, or would another RDAP document be more suitable? See also comment M3.

Nits:

(n1) In the abstract: "describe" -> "describes".

---

From: Pete Resnick <[email-masked]>
Date: Wed, 15 Oct 2014 23:41:05 -0500

I'll leave it to the authors to answer the other comments, but just on 
this one.

> (M1) Section 5 is written in an extremely optional way. In addition, it doesn't use RFC 2119 conventions. Since section 5 seems to be the main reason of the draft, I suggest to make it more formal…

In general, I disagree with this. If there are places where you see 
there will be a failure to interoperate, please do point that out and a 
MUST or MUST NOT can be put in. But if you're talking about things like 
5.4 where it says:

    If a server receives a query which it cannot interpret as an RDAP
    query, it returns a 400 response code.

and you instead want:

    If a server receives a query which it cannot interpret as an RDAP
    query, it MUST return a 400 response code.

then I disagree completely. There is no interoperability problem with 
returning a different response code if the server determines that it is 
doing something special or different. These are describing what *is* 
done in particular circumstances, defining the circumstances in which 
some return codes are used, not what is "required for interoperation or 
to limit behavior which has potential for causing harm".

pr

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

---

From: Pete Resnick <[email-masked]>
Date: Wed, 15 Oct 2014 23:48:23 -0500

[Resending to the proper draft address; I'll forward the original as well.]

and you instead want:

pr

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 16 Oct 2014 06:53:59 +0000

Hi Pete,

Thank you for your feedback.

I am not a dogmatic RFC 2119 follower, but I think using the keywords from that RFC has some value. It gives a nice and clean interpretation of used statements. But I admit that there is a certain matter of taste in their usage.

In your example, without reading the introduction of section 5, I wouldn't know whether to rephrase

>     query, it returns a 400 response code.

to

>     query, it MUST return a 400 response code.

or to

>     query, it SHOULD return a 400 response code.

So when we implement an RDAP server, we wouldn't know for certain what we should do in this case. Does the server have to respond with a 400 response code? Or can it do something else as well, for example sending another error code or not responding at all? If the sentence had a SHOULD, we know we can deviate. If it was a MUST, we know we can't. But since the sentence doesn't say either, we can only guess which it is. Safest for client would indeed be interpreting the sentence as a SHOULD.

However, the introduction of section 5 says: "This section describes the various types of responses a server may send to a client. While no standard HTTP response code is forbidden in usage, this section defines the minimal set of response codes in common use by servers that a client will need to understand." So the alert reader can now that the client needs to be able to handle at least the rest of section 5, but that the server can deviate from it when it wishes. In other words, most sentences about the server imply SHOULDs and MAYs.

As I said, I am not dogmatic about this. But I see value in being precise and explicit where we can. :-)

Best regards,
Bert

> -----Original Message-----
> From: Pete Resnick [mailto:[email-masked]]
> Sent: 16 October 2014 12:48
> To: Bert Greevenbosch
> Cc: [email-masked]; [email-masked]; apps-
> [email-masked]
> Subject: Re: Applications Area Directorate Review of draft-ietf-weirds-
> using-http-13
> 
> > (M1) Section 5 is written in an extremely optional way. In addition,
> it doesn't use RFC 2119 conventions. Since section 5 seems to be the
> main reason of the draft, I suggest to make it more formal by using RFC
> 2119 conventions. This also holds for other parts of the draft.
> >
>

---

From: Pete Resnick <[email-masked]>
Date: Thu, 16 Oct 2014 02:37:24 -0500

On 10/16/14 1:53 AM, Bert Greevenbosch wrote:
> In your example, without reading the introduction of section 5,

Well, that's an interesting premise. :-)

> I wouldn't know whether to rephrase
>
>    

So, "MUST return a 400" means that if you don't return 400, something 
bad will happen.
"SHOULD return a 400" means that if you don't return 400, something bad 
will probably happen, but if you understand the ramifications and have 
good reasons to not return a 400, you might get away with it.
"MAY return a 400" means that 400 is one choice (among other unspecified 
choices) that you can feel free to send.

I'd argue that none of those are right. Because of the intro to section 
5, we know that nothing bad is going to happen if you send other than 
400. The client has to be prepared for anything anyway. So MUST and 
SHOULD are clearly wrong; no interoperability problem here. But MAY also 
seems wrong. We're not saying that 400 is as good a choice as anything 
else you might choose. We're saying that, if you want to be nice and 
convey a useful message, one that means "I can't interpret the query as 
an RDAP query", 400 is the right choice. So we say, "If you can't 
interpret the query, send back a 400." No interoperability requirement 
there; just telling you what 400 is intended to mean.

See section 6 of RFC 7231. It doesn't specify that the server MUST or 
SHOULD respond with a particular status code; it defines what the codes 
mean.

> So when we implement an RDAP server, we wouldn't know for certain what we should do in this case.

Why not? Did you get a query that you couldn't interpret? Send a 400.

> Does the server have to respond with a 400 response code?

No, of course not. That's why there's no requirement language there.

> Or can it do something else as well, for example sending another error code

Of course.

> or not responding at all?

That's probably a violation of HTTP.

> If the sentence had a SHOULD, we know we can deviate.

No you don't. You only know you can deviate if you have outside 
knowledge that allows you to deviate. If the spec says SHOULD, it means 
"that there may exist valid reasons in particular circumstances to 
ignore" the instruction, but you're doing so at your own peril, and 
something might blow up if you ignore it. MAY means you can deviate.

> If it was a MUST, we know we can't.

Right, that there's going to be an interoperability problem or some sort 
of harm if you don't.

> But since the sentence doesn't say either, we can only guess which it is.

It's neither. It's simply saying, "If you want to express 'couldn't 
interpret', send back a 400".

> Safest for client would indeed be interpreting the sentence as a SHOULD.
>    

No, the client should be interpreting this as, "If he says 400, he means 
'couldn't interpret'".

> However, the introduction of section 5 says: "This section describes the various types of responses a server may send to a client. While no standard HTTP response code is forbidden in usage, this section defines the minimal set of response codes in common use by servers that a client will need to understand." So the alert reader can now that the client needs to be able to handle at least the rest of section 5, but that the server can deviate from it when it wishes.

Yep. And that's standard behavior for HTTP clients.

> In other words, most sentences about the server imply SHOULDs and MAYs.
>    

I disagree.

> As I said, I am not dogmatic about this. But I see value in being precise and explicit where we can. :-)

I may or may not be dogmatic about this. :-) But I see value in being 
precise and explicit where we need to. We are not the protocol police.

pr