Re: [ietf-provreg] registries, XML & EPP (again)

[Klaus Malorny <Klaus.Malorny@knipp.de>]

Andrew Sullivan wrote:
> On Wed, Oct 19, 2005 at 06:08:31PM +0200, Klaus Malorny wrote:
>> the clear disadvantage that every single XML element added as an extension 
>> of EPP diminishes the benefit of EPP, namely to have a generic interface 
>> that can be used with a generic toolkit and a generic registrar software. 
> 
> I hear this all the time, and it troubles me.  The point of the
> extension mechanism is that it should be fairly trivial for an
> extension to be prepared and made available.  Since servers can
> announce their capabilities when negotiating connection, what is the
> overwhelming barrier?  It it just a namespace problem, or are people
> discovering that extensible servers or clients are really that tough
> to build?
> 
> If it's the _former_ problem, all we need is a namespace registry,
> right?  If it's the latter, what would make the problem less
> difficult to solve?  A number of changes were recently proposed by
> Scott.  Where were the people reporting all these problems when we
> were trying to gather reports of experience?  (Once again, I'm
> probably overlooking something self-evident to everyone else, but
> maybe you folks could hit me with the clue stick.)
> 
> A
> 

Hi Andrew,

this is a misunderstanding. It is not a problem how EPP negotiates the 
extensions. Also, _implementing_ extensions on server or client side on the 
protocol level is no rocket science, rather code monkey work (though the 
definition of extensions not).

It is more a philosophical question. If two registries belief there is a need to 
add a "language" field to the contacts, this will likely result in two different 
extensions. Why? Well, the one registry also adds a field for favourite colour 
to the contact, the other one also adds a field for the favourite car brand. 
Both won't separate the language field into a common extension that just takes 
care about the contact's language, which would, on the other hand, be the only 
correct way from a protocol's perspective. The uncontrolled extensibility of a 
protocol is the protocol's death. Take, for example, the Whois protocol aka RFC 
3912, which has its roots in 1982. This protocol is extremely extensible, but 
the value of it is negligible. There are likely no two implementations of the 
protocol by two unrelated entities that are compatible. Those registrars who 
have implemented ICANN's Registrar Transfer Policy for thin registries know what 
this means. So from a protocol's perspective, it is the best to nail down 
everything, and if any extensions are required, to have a standardization body 
to define them. However, from a broader view, the registry-registrar protocol is 
only a minor, although not unimportant, part of the registry. Here it looks like 
that the mountain has to come to the prophet, and not vice versa. Some 
registries do the move the mountain, some only partially, and others not at all.

regards,

Klaus


___________________________________________________________________________
      |       |
      | knipp |                   Knipp  Medien und Kommunikation GmbH
       -------                           Technologiepark
                                         Martin-Schmeißer-Weg 9
      Dipl. Inf. Klaus Malorny           44227 Dortmund
      Klaus.Malorny@knipp.de             Tel. +49 231 9703 0