<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] thick RRP client
> 2. Why ICANN does not step in and request the Registries to standardize on
> the RRP protocol? It appears now that each and every Registry will be
using
> different protocol (or at least different flavor of the same protocol )
> making the life of the Registrars miserable? We have had hard time
managing
> just one single relation with Verisign (numerous problems). Can you
imagine
> this multiplied 5x times. Also the new registries will be definitely less
> experienced (at least in the beginning ). Any input on this?
My current information is that the new registries have standardized on a new
protocol (EPP) that allows for a thick registry model while minimizing on
the headaches associated with the RRP. The unfortunate part of RRP is that
it is inherently thin which makes it unsuited for most current
(ie -non-legacy) implementations.
RRP is essentially the equivalent of an IP based teletype protocol and can
only be pushed so far. With EPP in play, the various registries can support
a common protocol with minimal proprietary extensions.
Tucows is currently one of the sponsors of an open-source development effort
called the Universal Registry/Registrar Toolkit. The chief goal of this
community initiative is to develop a comprehensive multi-platform,
multi-language, multi-registry toolkit that registrars can use to talk to
the various registries. More information on this effort can be found at
http://epp-rtk.sourceforge.net. Both C++ and Java version have been released
that are interoperable with both the .name and .info registries. Presumably
it will interoperate with .pro and .biz as well because of the common
protocol (EPP) heritage.
It is my understanding that the registrars concerns as voiced last November
were well heard and that the ICANN staff were very conscious of ensuring
ease of integration and standardization of protocols and tools when they
were negotiating with the new registries.
-rwr
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|