Le dimanche 09 mars 2014 à 08:28 +0000, Patrik Fältström a écrit :
>
> On 2014-03-08 09:00, Mark Andrews wrote:
> > They have failed to invent / document a common standard way for
> > machine updates to work. They could have quite easily got together
> > anytime in the last decade and done a standardised update protocol.
> >
> > But they haven't.
>
> As long as the registries have _NOT_ unified their extensions of
> whatever fluffy things they want, so that I as a registrar _really_ can
> use the same EPP implementation to more than one (backend) registry,
> then registrars have to spend energy and real $$ to implement those
> incompatibilities.
These are not incompatibilities. It is by design, sort of.
While I can agree with you on many aspects of the sad current state of
EPP (having both implemented multiple client/server EPP stuff, and
having done presentations on EPP in various venues), the fact is that
trying to achieve 100% uniformity will never happen.
Registries, and specifically ccTLD registries, have distinct local
rules. They will never be exactly the same. You can find many voices
claiming that the current new batch of gTLDs make them all the same
because ICANN forces so many technical details in contractual terms.
Those voices see that as a downside, reducing differences means reducing
interest and differentiation biases.
It would be great if registries standardized parts that are needed the
same way in more than one of them, for example the case of change of
registrant ("trade").
Speaking for my own choir, having an EPP implementation able to speak
with 60+ TLDs shows that you _can_ have the same piece of code talking
into account the differences, which of course you need to hide in some
level of indirection (standard law of computer science).
There will always be some differences. Trying to squeeze them will not
work. Trying to find redundant extensions and merge them may work but
not without a lot of (non technical) work. Convincing registries to
document their EPP extension and even publish them as ID or RFC would be
great but not a simple task. We will see how EPPEXT goes along.
--
Patrick Mevzek
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
