Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http

From: Ernie Dainow <[email-masked]>
Date: Mon, 1 Apr 2013 15:07:25 -0400

On Fri, Mar 29, 2013 at 12:50 PM, John R Levine <[email-masked]> wrote:

> No.  A client that doesn't send an Accept: header is not an rdap
>>>> client, so it makes sense to return a generic format that a generic
>>>> client (e.g. a web browser) can render.
>>>>
>>>>  This generic format (probably html based) is described in an other
>>> (future) weirds document?
>>>
>>
>  It is JSON, specified in draft-ietf-weirds-json-**response.
>>
>
> Other way around.  An rdap client asks for a json response, and gets a
> json response.
>
> A non-rdap client asks for something else.  Since it's not rdap, the
> server can return whatever it wants.  This is not an interoperability
> issue, so there's no reason to define it further.
>
> The non-normative note suggests that since the non-rdap clients is likely
> to be a web browser, something a browser could render would be nice. This
> is in fact what Andy's protoype does.
>

It is very useful to be able to use a browser with an RDAP server, for
developers debugging client applications as well as end users who just want
quick access to verify something on a server. We should make a stronger
recommendation that servers SHOULD support browsers by returning a simple
content-type like "text/plain". Some of the current implementations do not
do this and you have to save/download the response and then open it with a
text editor to see the server response.

-Ernie

>
> Regards,
> John Levine, [email-masked], Taughannock Networks, Trumansburg NY
>
>

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2013 15:44:39 -0400

> text editor to see the server response.

No doubt, but we're writing a standard.  How would this affect 
interoperability among RDAP clients and servers?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

PS: I'm not saying it's a bad idea to return a web page, I'm saying it's a 
bad idea to try to specify that.

---

From: Ernie Dainow <[email-masked]>
Date: Mon, 1 Apr 2013 16:09:59 -0400

> interoperability among RDAP clients and servers?
When there is an interoperability failure between a client and server, it
really helps to have simple browser support to determine if the fault is on
the server or client. Visual inspection of the server response can
determine if it is out of spec, without having to write or use debugging
code.

-Ernie

---

From: Ernie Dainow <[email-masked]>
Date: Mon, 1 Apr 2013 16:58:59 -0400

On Mon, Apr 1, 2013 at 4:14 PM, John R. Levine <[email-masked]> wrote:

> Like I said:
> It already has a hint to developers that they return a web page to generic
> clients.  If people aren't inclined to take the hint, that's a quality of
> implementation issue.
>
> Personally, I'd prefer that it always return JSON, since if I'm debugging
> a JSON client, I want to see what the client sees.  But I realize that
> tastes can differ.
>

That's why I suggested text/plain, not text/html. It's the same content as
application/rdap+json. For text/plain results, we also indent the json
structure, which makes it easy for humans to read.
http://rdg.afilias.info/rdap/domain/dog.info

-Ernie

> R's,
> John

---

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2013 17:01:36 -0400

> http://rdg.afilias.info/rdap/domain/dog.info

Andy's prototype returns xml with a link to a stylesheet that makes it 
look nice in a browser.  I wouldn't say that was wrong, which is why I 
really REALLY do not think that further advice in this section is useful.

Regards,