HTTP Usage in the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-using-http-15

Thanks for addressing my DISCUSS.

I am curious if someone went through this doc to make sure everything it says is consistent with the change to MUST use TLS in rdap-sec.

-- Section 1 --

   2.  A client issues an HTTP (or HTTPS) query using GET [RFC7231].  As
       an example, a query for the network registration 192.0.2.0 might
       be

          http://example.com/rdap/ip/192.0.2.0

A small point, but, strictly speaking, that is not a query: it's a query URL.  The query is the full HTTP GET protocol.  So either put in the HTTP query, or make it "As an example, a query URL for...".  (The rdap-query document actually is careful to call them URLs every time.)

Another small point: in bullet 4 you expand the abbreviation "URL".  Good, but you've used "URL" twice, earlier in the document.  You should expand it the first time it's used.

-- Section 2 --
Yet another small point: I see that someone asked you to expand "SSAC".  Cool, but that now screams out for noting that it's a committee of ICANN (which then raises the question of whether ICANN should be expanded).  I'm going to duck and cover now, and just let you do what you think best here.

-- Section 3 --

   First, each query is meant to require only one path of execution to
   obtain an answer.  A response may contain an answer, no answer, or a
   redirect, and clients are not expected to fork multiple paths of
   execution to satisfy a query.

Do clients "satisfy" queries?  I thought that clients make them, and servers satisfy them.

-- Section 5.2 --

   For example, if the client sends

      http://serv1.example.com/weirds/domain/example.com

Again: strictly speaking, the client doesn't "send" that.  You could say, "if the client uses".

-- Section 5.3 --

   Clients
   MAY retry the query based on the respective response code.

What you probably want to say here is

NEW
   A client
   MAY retry the query if that is appropriate for the
   respective response code.
END

-- Section 9.1 --
Thank you!  It's always been my contention that IRIs are not part of wire protocol, and should never be sent around as IRIs.

It looks like the SecDir review was considered when provided last year, thanks.
http://www.ietf.org/mail-archive/web/secdir/current/msg04151.html

Might be worth noting in Section 3 that this protocol should be forward compatible with HTTP/2.0.

- As I said on the sec draft, I see no reason why RDAP could
not only be defined for use with https URIs. 

- 5.5 seems to conflict a bit with one of the notices defined
in the json-response draft where you say to do the same thing
in the payload. I don't think it's a big problem but could be
better to say which to use when.

- I'm also not sure the CORS thing is quite right if cookies
might get sent to the wrong places.