HTTP Usage in the Registration Data Access Protocol (RDAP)

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

Barry Leiba Discuss

Discuss (2013-08-15 for -07)
I am satisfied with the response about the 404 status code, so I'm removing that from my DISCUSS position.

1. This point still has no response:

The registration of the application/rdap+json media type was removed in version -07, presumably to move it to the json-response document (which makes sense).  But there are examples here in Appendix A that still use that media type, with no definition in sight.  I'm not happy with that.

I would be happy with an informative reference to the document where that media type is defined, and, of course, and update to that draft, including it (the latest posted version, json-response-04, predates this change).  (An informative reference is OK, I think, because this is in an example.)

2. And discussion has highlighted that there's a serious issue with *not* having a normative reference from this document to the rdap-query document.  I can't see how it's possible for this document to make any sense at all and to have any use at all without rdap-query, and I don't see how we can reasonably evaluate this piece of the solution without understanding that piece along with it.

(Ted Lemon) Discuss

Discuss (2013-08-14 for -07)
This document doesn't talk about security, which sort of makes sense considering the other weirds document we're reviewing in the same telechat.   However, I am concerned that there is a gap between the two documents that leaves open the possibility of password leakage.

Suppose I go to an RDAP server wanting some information that is confidential, and requires authentication.   Further suppose my request is to an http URL, not an https URL.

Presumably the RDAP server would tell me I need to authenticate, by sending an HTTP 401 response.   Suppose basic authentication is being used.   The server must first redirect me to an https server, which _then_ would send the 401 response.   If the response to the http query is 401, the client may send the password over the network in the clear, since this is allowed by the HTTP protocol.

In practice, I would expect that anything that needs to be authenticated is going to have to go over TLS anyway, so this should be straightforward to specify.

Possible responses to clear this DISCUSS would be (a) to point out that I am an idiot and this isn't a problem because I don't understand HTTP authentication properly (I know only enough to be dangerous, so this is a real possibility); (b) to argue that this needs to be fixed but should be addressed in the weirds-rdap-sec document and not in this document, or (c) to add some text to this document specifying how this should be done.   Currently neither document explicitly discusses the 401 response code.

(Sean Turner) (was No Objection, Discuss) Discuss

Discuss (2013-08-14 for -07)
updated ...

On .well-known point raised by Stephen ....  when EST came through the authors were told  by the appsdir reviewer that:

IETF standards should not define URIs or patterns of URIs, because servers may wish to provide other services (implying the possibility of collision), or deploy resources in an alternate way, for implementation or operational reasons. 

This is a fundamental concept in the Web architecture; see <>. 

Possible remedies include:

1) Specifying a "home document" format that links (in the RFC5988 sense) to the various resources as appropriate. 
2) Specifying a well-known URI to root the interaction. Note that this is suboptimal; while it avoids collisions, it does not allow alternate deployments, or multiple deployments on the same host.

Why doesn't the same recommendation apply here?
Comment (2013-08-14 for -07)
No email
send info
Just checking but does a policy reason include unauthorized access?  draft-ietf-weirds-rdap-sec talks about anonymous access as well as authenticated access so I just want to make sure that's covered in all the Ifs in s1.

please expand: SSAC

(Richard Barnes) Yes

Comment (2013-08-14 for -07)
No email
send info
(1) It seems like Section 4.1 could be made bit tighter.  There's not really a reason for clients not to send the specific RDAP JSON type in their Accept header.  So you could say that clients must send the RDAP-specific type (when requesting RDAP JSON); servers MAY accept others (e.g., application/json).

(2) In Section 5.2, do you want to recommend that the targets of redirects conform to the query syntax?  If not, it might be helpful to warn implementations that redirect targets might not have the standard query format.

(3) In Section 5.6, it would be helpful to provide some guidance on how the Access-Control-Allow-Origin header should be set.  It seems like most RDAP servers are going to be public resources, so the value "*" would be appropriate, at least as an example.

(4) The Security Considerations should point to draft-ietf-weirds-rdap-sec, since that provides the security mechanism for RDAP

(Pete Resnick) Yes

(Jari Arkko) No Objection

(Spencer Dawkins) No Objection

Comment (2013-08-10 for -07)
No email
send info
I'm not completely comfortable about the use of 404 flagged in Larry Masinter's Applications Area Directorate review, but whatever you do to resolve Larry's comment will work for me, too.

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-08-14 for -07)
No email
send info
- The abstract and 1st two sentences (particularly the
2nd which I just don't get) of the intro are pretty
thoroughly confusing. I was so puzzled that I read the
abstracts of all 6 wg drafts and they are uniformly
uninformative. That doesn't seem like a useful feature
for abstracts. Sorry to be negative but its quite easy to
slip into "we all know what this is about" mode, and
forget that most readers will not have been active wg
participants, which may be the case here. I think 
putting a bit of effort into improving the abstracts of the
weirds drafts would be a fine thing to do generally.
(The 2nd para of the intro however is just fine and does
tell me weirds is about.)

- intro: I wondered why you're not using ".well-known/ip"
in the first example but yet you don't say that a client
has to known the base URL from which to start.  How is a
client supposed to know to use a path of "/ip/"
or "/weirds/ip/"?

- Section 2: "Described in other documents" seems to
scream for references.

- 5.6: I don't get why CORS is needed here? Can you
explain? (Not sure if that needs to be in the doc, but
its not obvious to me.)

- section 7: Are there any security properties that ought
be checked in the event of a 3xx response? For example,
if https is used for the initial query, should it also be
used for the subsequent one?  

- overall: I was left wondering if this would not have
been better as a part of some other document with more
normative text, but I guess as long as the full set of
RFCs do the job that's ok.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Comment (2013-08-12 for -07)
No email
send info
I read the apsdir/review comments with interest, I have  no  serious objections.