HTTP Usage in the Registration Data Access Protocol (RDAP)
RFC 7480

Note: This ballot was opened for revision 13 and is now closed.

(Pete Resnick; former steering group member) Yes

Yes ( for -14)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -13)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ( for -13)
No email
send info

(Alissa Cooper; former steering group member) (was Discuss) No Objection

No Objection (2014-12-01)
No email
send info
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.

(Barry Leiba; former steering group member) No Objection

No Objection (2014-10-28 for -14)
No email
send info
-- 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.

(Benoît Claise; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -13)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2014-10-30 for -14)
No email
send info
It looks like the SecDir review was considered when provided last year, thanks.
http://www.ietf.org/mail-archive/web/secdir/current/msg04151.html

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Richard Barnes; former steering group member) No Objection

No Objection (2014-10-29 for -14)
No email
send info
Might be worth noting in Section 3 that this protocol should be forward compatible with HTTP/2.0.

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2014-10-30 for -14)
No email
send info
- 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.

(Ted Lemon; former steering group member) No Objection

No Objection ( for -14)
No email
send info