Subject: [weirds] FW: I-D Action: draft-hollenbeck-dnrd-ap-query-01.txt

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 7 May 2012 17:12:03 +0000

I've updated this draft to address comments received last week.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, May 07, 2012 1:10 PM
To: [email-masked]
Subject: I-D Action: draft-hollenbeck-dnrd-ap-query-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Domain Name Registration Data Access Protocol Query Format
	Author(s)       : Scott Hollenbeck
                          Steve Sheng
                          Francisco Arias
	Filename        : draft-hollenbeck-dnrd-ap-query-01.txt
	Pages           : 14
	Date            : 2012-05-07

   This document describes a RESTful query format proposal for the
   Domain Name Registration Data Access Protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hollenbeck-dnrd-ap-query-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-hollenbeck-dnrd-ap-query-01.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-hollenbeck-dnrd-ap-query/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Alex Sergeyev <[email-masked]>
Date: Mon, 7 May 2012 17:43:01 -0400

Hi,

I did not have chance to participate in list earlier and really hope
to not repeat things that were said before.

So far, based on this draft I really would like to ask if there are
serious plans to keep text/html and text/plain in the spec.

In my opinion it looks like step backwards to battle with old whois
without proper data formatting.

Having HTML in API seems like mix of presentation and data which also
would be best to avoid. I'm also wondering if having too much freedom
would make some providers to not go crazy and add things like
application/pdf to their list of formats.

Would you mind clarifying reasons to have more than JSON + XML and how
such reasons help RESTful WHOIS future?

-- 
Alex Sergeyev
Sr. Engineer of Dyn Labs

On Mon, May 7, 2012 at 1:12 PM, Hollenbeck, Scott
<[email-masked]> wrote:
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Gavin Brown <[email-masked]>
Date: Tue, 08 May 2012 11:31:43 +0100

> such reasons help RESTful WHOIS future?

Supporting text/plain provides a migration path in the early stages of
deployment: clients can be updated to use the new transport protocol
without also having to also support the new format.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 8 May 2012 09:57:52 -0400

> without also having to also support the new format.

The early arguments in favour of XML, however, were that many browsers
could render it easily.  And anyway, that still seems like a weak
reason.

If you need to support legacy clients, then you'll need to have a
straight whois server because the legacy clients won't know about the
new transport.   Who will go to the work of updating their client to
use the new transport without doing the additional work to get the
benefits of a structured format?  The new transport provides zero
benefit to the client.  It's only the structured data that provides
benefit to the client, so if they're going to update that's what
they're going to want, it seems to me.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andy Newton <[email-masked]>
Date: Tue, 8 May 2012 14:14:56 +0000

> serious plans to keep text/html and text/plain in the spec.

I don't know if it needs to be in the spec, but there is nothing wrong with supporting other formats such as plain text and HTML. If somebody points a browser at a RESTful URL, passing them back pure JSON or XML is not doing them any favors.

Again, there doesn't need to be a specified result set for text or HTML, but allowing a server to respond with such when the client wants it seem perfectly reasonable.

-andy

---

From: Francisco Arias <[email-masked]>
Date: Tue, 8 May 2012 07:17:20 -0700

Hi Alex,

See below.

>serious plans to keep text/html and text/plain in the spec.

Good question, I think the text currently in the draft was copied from the
previous draft that Steve and I wrote describing the testbed
implementation we did.

>such reasons help RESTful WHOIS future?

We had text/html thinking that would be the output given to "the common"
user that is querying using her/his browser.

We had text/plain to provide the old-WHOIS look alike output that we
provided through a proxy. Since the RESTful server was already outputting
text data in the required format, the proxy limited itself to translate
the query and provide back the answer.

I don't have a strong feeling about whether it should stay or not.

Thoughts?

__

Francisco.

---

From: "John Levine" <[email-masked]>
Date: 8 May 2012 20:50:38 -0000

>without also having to also support the new format.

As I understand it, the goal of WEIRDS is to create a spec that
computers can use to query in a reliable way for the data that is
currently served through WHOIS, and to get back responses that can
be parsed mechanically.

I'm having a great deal of trouble imagining an application where I'd
implent the restful queries, but then try and grep the answers out of
a text response rather than spending 10 minutes to call a JSON library
and get a data structure I can use directly.

R's,
John

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 May 2012 17:06:43 -0400

> without also having to also support the new format.

Could such a client convert XML to plain text itself using e.g. an XSLT 
style sheet? An example style sheet could be provided in a non-normative 
appendix...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Sascha E. Pollok" <[email-masked]>
Date: Wed, 9 May 2012 01:44:20 +0200 (CEST)

Gentlemen,

I am the new one.

> and get a data structure I can use directly.

+1 for John's opinion. I would rather ask applications to migrate to
the new transport/XML+JSON instead of doing half of a migration and
using a new protocol with an old text-format. Of course we all know
that also the text-format can be parsed but I would object to
enabling a transition mechanism that could stay for longer^Hever.
JSON/XML parsers are too easy to implement to justify a text-output.

And as Simon wrote later, people can still convert the new structured
output (from XML in his suggestion) or JSON to text if required.

$0.02
-Sascha

---

From: Francisco Arias <[email-masked]>
Date: Wed, 9 May 2012 05:04:03 -0700

>style sheet? An example style sheet could be provided in a non-normative

That's is precisely what we did in our testbed implementation.

Note that I'm not vouching to keep it, just explaining why it is there.

__

Francisco.