Subject: [weirds] Why did IRIS fail?

From: Edward Lewis <[email-masked]>
Date: Tue, 13 Mar 2012 10:54:04 -0600

In the sense that we want to avoid the fate of IRIS, it would be good 
to enumerate why IRIS went no where.

I'm just throwing these out there for discussion:

   I've heard that the transport was not a good choice.

   I see a beginning debate over the use of XML.

What aspects of IRIS are the reasons we are now starting another WG 
on essentially the same topic?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 13 Mar 2012 14:16:20 -0300

>    I see a beginning debate over the use of XML.

I'll add another one, the need to deploy clients. This is well
addressed by the current proposition.

Fred

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Tue, 13 Mar 2012 14:58:33 -0300

I wasn't in this line of work at the time of IRIS, but I am quite sure
that any effort that ties the WHOIS replacement to a specific client
that needs to be developed will fail.

This is IMO, as Fred says, a strong point in the current line of
deploying REST services.

regards

Carlos

On 3/13/12 2:16 PM, Frederico A C Neves wrote:
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Andy Newton <[email-masked]>
Date: Tue, 13 Mar 2012 16:38:05 -0400

> addressed by the current proposition.

These could possibly be intertwined. IRIS certainly makes copious use of XML. Not that an XML representation is a bad thing, but the starting assumption that we need validation, namespaces, etc… is. No, we don't need them. And most REST services use JSON and seem to get along just fine without those things.

Been there. Got the t-shirt:
http://www.zazzle.com/xml_is_like_violence_if_it_doesnt_solve_your_tshirt-235860791926916918

-andy

---

From: Patrik Wallstrom <[email-masked]>
Date: Tue, 13 Mar 2012 23:17:23 +0100

> These could possibly be intertwined. IRIS certainly makes copious use of XML. Not that an XML representation is a bad thing, but the starting assumption that we need validation, namespaces, etc… is…

Isn't this because most JSON based RESTful services only is provided by only one service or implementation? If you don't have the need to standardize or to be interoperable, JSON is probably wonderful. On the standardization side we have Atom which is XML, although I don't pretend to have a complete overview of HTTP based APIs out there.

On the downside of XML I think most "PHP based" implementors give up when we present them with things like namespaces - extended namespaces!, XML Schema and XPath. Add BEEP on top of that, I think that is where any junior developer gives up.

So to avoid the pitfalls of XML I'd vote we skip any namespace extensions and instead use the RESTful names for things like extensions. Need a new version of a weirds based protocol? Add a new path in the URL.

Just to summarize, if the choice is XML, go for the simplest possible representation of the data just as we would for any JSON based API.

---

From: Andy Newton <[email-masked]>
Date: Tue, 13 Mar 2012 20:45:53 -0400

On Mar 13, 2012, at 6:17 PM, Patrik Wallstrom wrote:

> Isn't this because most JSON based RESTful services only is provided by only one service or implementation? If you don't have the need to standardize or to be interoperable, JSON is probably wonderful.

There are JSON based standards. The IETF's ALTO working group has one. And the J in the JOSE working group stands for JSON. They are redoing CMS type work previously done in ASN.1. Certainly our problem isn't as thorny as theirs.

> On the downside of XML I think most "PHP based" implementors give up when we present them with things like namespaces - extended namespaces!, XML Schema and XPath. Add BEEP on top of that, I think…

It's not just PHP programmers. It's really most programmers. While they may understand plain and simple XML, most don't understand XML namespaces or schemas. And it isn't because they are stupid or we are super smart. It's because they simply don't run across it that much. And when it comes to experience with REST systems, more have used JSON than have used XML.

Another reason programmers prefer JSON over XML tends to be the APIs. The XML apis tend to be more complex because XML is more complex. JSON on the other hand, is almost always represented as simple arrays and hashes. Just take a look at the difference in PHP:
http://us2.php.net/manual/en/ref.domxml.php
http://us.php.net/manual/en/ref.json.php

> So to avoid the pitfalls of XML I'd vote we skip any namespace extensions and instead use the RESTful names for things like extensions. Need a new version of a weirds based protocol? Add a new path…

Yup. That is the idea of the RIR drafts.

Also one of the changes made to the latest revision of the RIR JSON draft is to restrict JSON names to be compatible with XML tags for the possibility of having a straightforward mapping of a JSON representation to XML. There's nothing wrong with a simple XML representation, and if JSON is used as the basis then it will stay simple.

-andy

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 13 Mar 2012 18:15:25 -0700

It just feels like we've had this discussion before ;-)

JSON is great when you have control of both the sender and receiver. In care of ALTO, there is a limited number of components interacting with each other, so JSON is a great solution.

Most programmers just fear XML, it is very unfortunate that there are just so many sub topics associated to it, that makes it very difficult to learn, but those who understand it very well, get to use its full power.

Like I said in my previous email, validation is just usually 1 line of code, validating JSON data at this point, involves processing the received data structure, which is indeed more complex than doing the same with XML.

XML is more suitable for data exchanges between unknown parties, it offers a language and tools to define/validate its data structures, and wide support not only in existing browsers, but in almost any computer language out there.

Francisco

> Also one of the changes made to the latest revision of the RIR JSON draft is to restrict JSON names to be compatible with XML tags for the possibility of having a straightforward mapping of a JSON…

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

---

From: Andy Newton <[email-masked]>
Date: Tue, 13 Mar 2012 22:04:55 -0400

> Most programmers just fear XML, it is very unfortunate that there are just so many sub topics associated to it, that makes it very difficult to learn, but those who understand it very well, get to…

There's a t-shirt for that too:
http://www.zazzle.com/the_beatings_will_continue_until_morale_improves_tshirt-235894388228818297

-andy

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 Mar 2012 13:51:11 +0100

On 14/Mar/12 01:45, Andy Newton wrote:
> 
> Also one of the changes made to the latest revision of the RIR JSON
> draft is to restrict JSON names to be compatible with XML tags for
> the possibility of having a straightforward mapping of a JSON
> representation to XML. There's nothing wrong with a simple XML
> representation, and if JSON is used as the basis then it will stay
> simple.

I like the idea of representation mappings.

I'd note that both XSLT and JavaScript are Turing-complete, hence
equivalent, languages.  But our common denominator (should we name it
"weirds data representation"?) is bound to be much simpler.

An explicit formalization of the straightforward mappings between JSON
and XML may be easier than manually writing other documents that
describe responses in other formats to the same URL queries.  There
are lots of XML<->JSON converter scripts: we may pick up one and adapt
it to our needs.  I mean, to automatically generate the alternative
representation(s) in the relevant appendix(es).

---

From: Stephen van Egmond <[email-masked]>
Date: Thu, 15 Mar 2012 00:06:05 -0400

Beyond technical details, are there business reasons anyone is aware of that may have led IRIS to fail?

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 15 Mar 2012 11:19:22 -0400

> Beyond technical details, are there business reasons anyone is aware of that may have led IRIS to fail?

Sure: the people who are contractually required to operate WHOIS for
names already have a WHOIS service and therefore need to do zero work
to set it up.  Setting up IRIS (or anything else) requires effort
(which means money).  And there is no revenue at all associated with
running a domain name registration data service: it's all cost.  

That very problem is one of the premises in the scepticism some have
expressed about the viability of the names work in WEIRDS.  People
have said that all the (possibly contentious) work needed will not
result in anything, because all the financial incentives in the DNS
names registration community are in favour of not making any change.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andy Newton <[email-masked]>
Date: Thu, 15 Mar 2012 12:10:40 -0400

> names registration community are in favour of not making any change.

Just theorizing, but maybe this isn't a black and white issue. Since 
IRIS did a lot of stuff, the investment to get it up and running was 
non-trivial; non-trivial in the sense that a DNS registry had to make a 
commitment to it instead of investing a small amount of money just to 
see what came of such a service.

It would be best for us to think about doing only what is needed so that 
the cost to implement is as low as possible. That way organizations that 
can't justify a large budget on this can hopefully still try it with 
little expense.

-andy

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Thu, 15 Mar 2012 13:14:04 -0300

And, IMO, the need for specialized clients cannot be ignored either.
Developing such clients also implies 'cost' (even if they are open
source, someone has to develop them).

regards

Carlos

On 3/15/12 1:10 PM, Andy Newton wrote:
> non-trivial; non-trivial in the sense that a DNS registry had to make
> a commitment to it instead of investing a small amount of money just
> to see what came of such a service.
>
> It would be best for us to think about doing only what is needed so
> that the cost to implement is as low as possible. That way
> organizations that can't justify a large budget on this can hopefully
> still try it with little expense.
>
> -andy

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 15 Mar 2012 12:19:53 -0400

On Thu, Mar 15, 2012 at 12:10:40PM -0400, Andy Newton wrote:
> organizations that can't justify a large budget on this can
> hopefully still try it with little expense.

I think this is right, and might be a suggestion for changes to any of
the proposed charters.  They all start from the principle that any WG
would be broadly aligned with the CRISP requirements, but they don't
explicitly say that any resulting WG would always err on the side of
simplicity instead of in favour of desired features.  To put this
another way, we might want to propose that a charter require a base
protocol with no optional features.  Interoperability is most promoted
when everyone can be sure that they MUST do the same thing.

The problem with such an approach, of course, is that it's going to
increase the contentiousness.  But if we were successful, it should
reduce the cost of implementation, because a simple and minimal
protocol is, all else being equal, less costly to implement than one
with a lot of options.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 15 Mar 2012 12:32:02 -0400

+1 to andrew sullivan's note.

a point i've tried to make to the provreg side of the house is that
from the registry perspective, it is an island (regardless of how many
properties the rsp hosts), and claims for benefit which are
registry-plural (the usual form of registrar interest advocacy) or
gtld-universal (the usual form of icann policy advocacy,
indistinguishable from vgrs-incumbency interest preference), or
contract-external claims of benefit (the usual form of leo and
trademark interest advocacy), don't mean spit to the registry operator
looking (rationally) out for just itself and its supply chain, if
meaningfully distinct from vgrs.

it doesn't cost much to maintain the :43 nonsense, and for those
registries that price out or policy out the ppc {typo & keyword} squat
domainers and policy out or time out (no rapid update) the
use-and-burn illegals, the utility of any post-43 is inobvious.

so, yes, there were business reasons why iris was not adopted in the
blink of an eye, and these were not continuations of the uwho errors
of vgrs, or the nih response of its competitors prior to the iris
moment in protocol specification time.

cost is externalized by some parties, some are registries, some are
registrars, and one is icann itself -- all of whom are, to use the
phrase of the ipc -- willfully blind to systemic misconduct -- as is
of course the ipc insisting that all uses of marks by parties other
than the marks holders are indistinguishable, and the leo's with all
of their foibles, and the rational economically motivated registrants.

none of these parties is putting a nickle on the table, or their very
expensive-to-others pseudo-requirements, to see if they meet the sniff
test for necessity and utility.

so yeah, it's all cost.

-e

---

From: Andy Newton <[email-masked]>
Date: Thu, 15 Mar 2012 12:32:11 -0400

> when everyone can be sure that they MUST do the same thing.

So, maybe we need to start from a subset of the CRISP requirements. And 
I like the idea of charter explicitly calling out the need for simplicity.

> protocol is, all else being equal, less costly to implement than one

I think we can get burned with nothing but MUSTs and extension points 
would be hard to codify.

-andy