Subject: [weirds] Text media type

From: Chris Wright <[email-masked]>
Date: Tue, 18 Sep 2012 09:41:16 +1000

Would people be against including a plain text media type in WEIRDS?

I would like to do this, so that if a client wants they can specify a plain text media type and I could send them a UTF8 encoded text stream that is essentially my current WhoIs response (so the fields are prefixed with a descriptive label).

This would make transition easier, and a really simple WERIDS client (eg a command line wget or curl) could just get the plain text version and send it to console.

Of course the WERIDS server would also have to support the JSON media type as well to allow the ‘machine to machine’ style interaction we are intending.

Any one see any issues with this?

Thanks

c.

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 17 Sep 2012 16:52:47 -0700

I guess the plan is to have a p43 whois to RDAP proxy for those cases where legacy support is needed.

On Sep 17, 2012, at 4:41 PM, Chris Wright <[email-masked]> wrote:

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Carlos Martinez <[email-masked]>
Date: Mon, 17 Sep 2012 20:56:27 -0300

We are for it. In fact we were planing to add it to our prototype. 

Regards

Carlos

Sent from a mobile device

---

From: Andy Newton <[email-masked]>
Date: Tue, 18 Sep 2012 00:09:30 +0000

>I would like to do this, so that if a client wants they can specify a
>plain text media type and I could send them a UTF8 encoded text stream
>that is essentially my current WhoIs response (so the fields are prefixed
>with a descriptive label).
> 
>This would make transition easier, and a really simple WERIDS client (eg
>a command line wget or curl) could just get the plain text version and
>send it to console.
> 
>Of course the WERIDS server would also have to support the JSON media
>type as well to allow the Œmachine to machine¹ style interaction we are
>intending.
> 

We support plain text and xhtml depending on the Accept header, and plan
to do so going forward. Perhaps this type of behavior ought to be
explicitly called out in the Using HTTP draft even if there will be no
specification for those formats.

-andy

---

From: "John Levine" <[email-masked]>
Date: 18 Sep 2012 03:39:58 -0000

>Would people be against including a plain text media type in WEIRDS?

It's a perfectly reasonable thing to do, but I would have reservations
about putting it into WEIRDS, because history tells us that once
something is in the spec, it'll never, ever go away.

Would you want it to say that the text/plain response is an entirely
implementation dependent stream of UTF-8 text, or more than that?  As
soon as there is any sort of spec for what's in that stream, we've
effectively doubled our work, since now we have to define the text
version as well as the JSON version for everything.

Remember that a standard describes what you have to do in order to
interoperate.  You're always allowed to have your software do things
beyond what the standard says, so long as it doesn't interfere with
the standard compliant operation.  It'd be fine to leave text/plain
out of the standard, but implement it anyway as a non-standard
transition hack.

R's,
John

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 17 Sep 2012 20:47:28 -0700

John,

I have to say that perhaps for the first time in the last week, I deeply agree with you ;-)

Francisco Obispo

---

From: Alan Maitland <[email-masked]>
Date: Tue, 18 Sep 2012 00:18:58 -0600

> Would people be against including a plain text media type in WEIRDS?

This approach could be expressed as transitional gateway for operators 
and consumers of their data to ease over to WIERDS from WHOIS.

> that is essentially my current WhoIs response (so the fields are
> prefixed with a descriptive label).

While that seems to make sense, does it really encourage good behavior? 
  In other words, will it make the task of transitioning or migrating to 
a full implementation of a more RESTful environment less desirable for 
consumers of data and the registries?

> a command line wget or curl) could just get the plain text version and

Agreed.  Another question to ask... would such a solution be able to as 
easily implement the same kinds of security measures as has been 
proposed by some on this list?

> type as well to allow the ‘machine to machine’ style interaction we are
> intending.
>

While there might be some questions to think about, offering a plain 
text media type seems a valid idea in approaching transitional migration 
from WHOIS to WIERDS.

Perhaps the approach in describing this could be expressed in a "MAY 
choose to implement a plain text option to assist in transition or 
encourage early adoption" approach.

> c.

Best,

Alan M.

---

From: Dave Piscitello <[email-masked]>
Date: Mon, 17 Sep 2012 23:48:15 -0700

So you are suggesting a plain text response to a structured query that presumably returns the current blob of whatever data the provider serves up. Doesn't this leave all the burden on the client and consumer of data (I.e, all the variability across whois responses must be normalized still)?

Sent from my iPhone

---

From: Alan Maitland <[email-masked]>
Date: Tue, 18 Sep 2012 01:26:10 -0600

Hi Dave,

> So you are suggesting a plain text response to a structured query that presumably returns the current blob of whatever data the provider serves up. Doesn't this leave all the burden on the client a…

Actually, I was responding to Chris Wright at ausregistry.com.au who 
started the thread.

 From a transitional perspective, his idea might at least offer a common 
request point and mechanism for both the plain text and the new response 
formats.

As the issues with having to work in plain text already exist today, one 
might expect that dealing with the plain text from a consumer/client 
basis will really not be that much different then is the case for 
current WHOIS responses.

Of course, the alternate view might well be to simply say if you wish to 
support the WHOIS responses as they exist today, why not just do that?

But then if there are client consumers who would prefer to have the 
WHOIS style responses live on and those registries who would opt to 
continue to provide such responses and WHOIS gets retired, there might 
be some WEIRDS "buyers" (implementers?) remorse.

Then again, that view might presume the WEIRDS text response would be a 
long term solution, which may not be the choice of the majority of those 
sculpting and implementing the WEIRDS protocol.

Best,

Alan M.

> On Sep 18, 2012, at 7:19 AM, "Alan Maitland"<[email-masked]>  wrote:
>

---

From: Wolfgang Nagele <[email-masked]>
Date: Tue, 18 Sep 2012 17:57:51 +1000

Hi,

If we were to use a text/plain content-type I would suggest not to infer any sort of structure of that data. For that response the client would have to serve the answer "as-is".

Given that, I would rather define a content-type for RPSL - application/rpsl for instance so it is clear which format is being returned/requested.

Regards,

--
Wolfgang Nagele
Senior Systems and Network Administrator
AusRegistry Pty Ltd
Level 8, 10 Queens Road
Melbourne, Victoria, Australia, 3004
Phone +61 3 9090 1756
Email: [email-masked]
Web: www.ausregistry.com.au

The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately.

---

From: Dave Piscitello <[email-masked]>
Date: Tue, 18 Sep 2012 04:04:17 -0700

Tx for the clarification.

I share John Levine's confer that this would Never go away and thus many of the benefits would not be realized.

Sent from my iPhone

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 18 Sep 2012 11:04:30 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Levine
> Sent: Monday, September 17, 2012 11:40 PM
> To: [email-masked]
> Subject: Re: [weirds] Text media type
> 
> beyond what the standard says, so long as it doesn't interfere with the
> standard compliant operation.  It'd be fine to leave text/plain out of
> the standard, but implement it anyway as a non-standard transition
> hack.

I concur. We already have some text in the unified query draft that sort-of describes this scenario:

"It is envisioned that each registry will continue to maintain NICNAME/WHOIS and/or RESTful web services specific to their needs and those of their constituencies, and the information retrieved through the patterns described here may reference such services."

I also agree that it doesn't need to be described in the specs.

Scott

---

From: Arturo Servin <[email-masked]>
Date: Tue, 18 Sep 2012 09:49:57 -0300

Same as many I prefer not to standardise this, otherwise it will never go away.

Regards,
as

---

From: Carlos Martinez <[email-masked]>
Date: Tue, 18 Sep 2012 09:54:24 -0300

Agreed. What is currently written should suffice.