Registries in need of new protocols...

[Patrick <patrick@gandi.net>]

On Fri, Jan 19, 2001 at 02:22:03PM +0100, Jaap Akkerhuis took time to write:
>     The VeriSign gTLD registry is one.  While we're functioning
>     with the existing NSI RRP, there are needed improvements and
>     additional capabilities that require use of a new protocol.
>
> Yes of course. But I was wondering wether there are more. This to

As far as I understand most of the Registries of the new 7 gTLD, in
their presentation[1] said they are thinking of other protocols
(besides using RRP at least for the beginning to start the pump).

.NAME for one will support RRP and their own SRRP (Stateless RRP)

Maybe it can be useful to see what they have in mind (they plan to go
for a RFC to have it as a standard, AFAIK).

Some of these new Registries plan to go online on Q2 2001.

.EU is also slowly taking shape. We are not at the stage of knowing
who will be the Registry and how it will work, but it will need a
protocol for reservation, that is for sure, without needing past
compatibility, since it will be a brand new Registry and TLD.

> Registrars which deal with different TLD's have
> questioned why there is not a standard way to register domains and
> that it is a lot of work to figure out the different procedures
> etc.  Although, when they have figured it out they loose interest.
> (Because now this knowledge gives them an advantage over competitor,
> as one told me).

I'm working in an ICANN Registrar. It is true it's hard to support many TLD,
no two are doing the same. Some ccTLD are doing registrations by
email for example (.be or .uk come in mind).

In our case, we are now developing an abstract registry interface[2],
able to cope with different registries and different protocols, in a
transparent way for the application.

We are still very much interested to have a standard well designed
way for registering all TLDs ;-)

Patrick, lurker on this list but very interested/concerned by this WG

[1] http://www.ec-pop.org/20010111/index.htm
[2] in the same vein as DBI/DBD under Perl, or ODBC for example.