[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: ietf-provreg@cafax.se
From: Andrew Sullivan <andrew@ca.afilias.info>
Date: Mon, 24 Oct 2005 09:08:03 -0400
Content-Disposition: inline
In-Reply-To: <435967C9.7040807@knipp.de>
Mail-Followup-To: Andrew Sullivan <andrew@ca.afilias.info>,ietf-provreg@cafax.se
Reply-To: Andrew Sullivan <andrew@ca.afilias.info>
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mutt/1.5.9i
Subject: Re: [ietf-provreg] registries, XML & EPP (again)

On Sat, Oct 22, 2005 at 12:12:25AM +0200, Klaus Malorny wrote:
> 
> I didn't say that. People can compromise. If they believe they have a 
> benefit from it, directly or indirectly. They won't if there aren't enough 
> incentives.

Well, this is different from the position as you put it before, where
the suggestion is that the registries _can't_ compromise.  If you're
merely making the assertion that they _won't_, then it's a question
that is empirically satisfied.  But given that (for example) NeuStar,
VeriSign, and Afilias managed together to co-ordinate a response to
the ICANN redemption grace period, there's at least _prima facie_
evidence that your assertion is false.

> Hmm. Maybe you don't know. HTML is dead. HTML is the prototype of a failed 
> standard in many ways. W3C is working for many, many years now to fix that.

But it was nevertheless hugely successful, even if it's not pure. 
The point here, as I understand it, is at least partly "running
code"; and by that estimation, HTML was a wild success.  

> Well, I can send e-mails to nearly everyone connected to the Internet 
> without using X-headers. But I can't register a .us, .coop, .eu domain, for 
> example, without using the appropriate proprietary extensions. I can do 
> this only for vanilla registries, mostly gTLDs. There is a difference at 
> least to me.

First, there _are_ people who use X headers as tokens for various
things, which then extend the functionality of those systems (it
seems to me that I've had messages from a Lotus Notes user that
contained more X-headers than anything else).  I couldn't use that
functionality, because I didn't know what the headers meant.  Does
that meant that those particular X-headers are bad?  (I say, "No.")

More significantly, though, your argument above seems to be that,
because you have to use this or that extension to a base protocol to
express this or that unusual policy in a given registry, that proves
that the base protocol is not useful.  It's really a false dichotomy:
either the protocol can be used everywhere, or it's not a protocol. 
You're welcome to that view; but with respect, I think it's not one
consistent with a large portion of technical or even human
experience: "SQL" is still a useful name for something, even though
the way you express it when using Oracle, DB2, PostgreSQL, or MS SQL
Server are different.

> By the way, you are the one who wants to dictate every registry to use a 
> standard, namely EPP. I just question the value of a standard that is 
> practically incomplete for a non-negligible number of registries in the one 
> hand, and too limited for them at the same time in the other hand.

I don't want to dictate anything: use what you want.  I am
suggesting, however, that the limitations you are observing can be
solved by the creative use of the extension mechanism; and that
co-ordination on that front may be achieved through the IETF. 
Therefore, I claim it would be more helpful to suggest alterations or
extensions than it is to stand by and make sweeping claims about
disutility.  In my opinion, registries that adopt, extend, and
improve EPP have an advantage over those that stick with a different
base protocol.  This is a matter for empirical discovery, though; and
it'd be hard to test my hypothesis if we don't have any hold outs.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@ca.afilias.info>                              M2P 2A8
                                        +1 416 646 3304 x4110


Home | Date list | Subject list