Subject: [weirds] features impinged by RFC 7320

From: Andy Newton <[email-masked]>
Date: Sun, 20 Jul 2014 14:14:41 +0000

In reviewing my RDAP software and the features impacted by the latest specifications, I have hit upon two features that are impacted by the newly minted IETF ideology chiseled into RFC 7320 and the bending of the RDAP specifications to make them conform.

The Issues:

1) My CLI client, NicInfo, has a feature whereby you can hand it an RDAP conforming URL and it can determine the object type to be returned by a server. This is no longer possible because there is no standard way of knowing which RDAP URLs map to which RDAP objects.

2) My bootstrap server, which takes queries from constrained clients, determines where to lookup information based on URLs handed to it by the client. However, since we can no longer determine what type of information the client is seeking, the bootstrap server can no longer determine where to redirect the queries.

The solutions:

A) Put an “objectType” attribute or something similar in the JSON response. This allows a client to know the object type being returned without the need to jump through heuristic hoops. However, this only solves problem #1 and not problem #2.

B) Create an RDAP URI scheme. Eck!

C) Create separate media types to be used in the Accept header for each object type. Ewwww!!

D) Create an RDAP registry for .well-known. I believe this is the lightest weight thing to do, and the easiest for implementers of both clients and servers. Also, I do not believe this impacts any of our current specs. The bootstrap can still contain whatever URLs registries desire, and the rdap-query draft does not need to change as well.  The .well-known registry will just be used for services that do not have a defined bootstrap.

Comments? Questions?

-andy

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2014 03:00:42 -0000

>1) My CLI client, NicInfo, has a feature whereby you can hand it an RDAP conforming URL and it
>can determine the object type to be returned by a server. This is no longer possible because
>there is no standard way of knowing which RDAP URLs map to which RDAP objects.

The current bootstrap provides a per-whatever prefix to which the
client is supposed to append the appropriate URL suffix from
rdap-query for the type of query.  I would think you could easily look
at the tail of the URL to figure out what kind of object it is.

Plan B: all the answers are JSON objects, so have the object include a
"responsetype" field saying what it is.

Note that since servers are allowed to do 302 redirects to arbitrary URLs, even
with the current bootstrap scheme, someone could give you a redirected URL that
bears no resemblance to anything, yet returns a normal RDAP JSON response.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Mon, 21 Jul 2014 13:28:15 +0000

> at the tail of the URL to figure out what kind of object it is.

My reading of RFC 7320 says that we aren’t allowed to do this. However, since the author of that RFC has told us that everything looks good, I guess I am mistaken. Sorry for sending up the flare.

> "responsetype" field saying what it is.

This is probably a good idea anyway.

> bears no resemblance to anything, yet returns a normal RDAP JSON response.

True, but most HTTP client libraries handle the redirects behind the scenes. And it is also easy enough to hold on to the first URL even if programmatically plowing throwing redirects.

-andy