Re: [ietf-provreg] .BR EPP implementation and draft extensions

[Frederico A C Neves <fneves@registro.br>]

Hi Francisco,

On Mon, Feb 20, 2006 at 01:29:57PM -0400, Francisco Obispo wrote:
> Hi Frederico,
> 
> In .VE (Venezuela), we had some requests from domain holders, that wanted
> to change individual information regarding each contact of each domain.
> 
> We decided to implement a constant of 4 contacts for each domain name,
> for example, the domain name:
> 
> test.com.ve
> 
> would have:
> 
> 1) test.com.ve-dom -> Registrant
> 2) test.com.ve-adm -> Admin contact
> 3) test.com.ve-tec -> Technical contact
> 4) test.com.ve-bil -> Billing contact
> 
> 
> We can later know how many domain names an organization has, by
> grouping them by email address, or ORG name, in our
> database,..
> 
> Well, that was just our experience..

We are trying to do that using the organization object, represented by
a contact with the extension.

> 
> How do you guys implement the things that are now available in EPP
> ?,

What do you mean ? We are distributing a C++ library and in a future
version a EPP "shell-like" client.

> are you guys planning to keep extending the protocol?

As far as we don't transform this in a Frankenstein, that's the idea.

> because if that's the case, I would be interested in working together
> with you guys on it.

I don't know if we could find any thing else that could be put in the
common ground of the current EPP. One area to work together is on the
EPP core resultCodeType and how to extend it. That's something we
should comment during the current bis process.

> Right now, the functionality that is not provided by EPP, we
> implemented it by using web services, for example, if we need to
> know the list of domain names for which a particular email appears as
> contact, or to check if there are any restrictions
> on a particular name. (besides the normal domain:check)

We expect to do this and all the others registration restrictions
rules, in band, using only EPP with the extensions.

> 
> There will be probably additional modifications that we would plan to
> implement, for now we did it that way because of the short
> time we had, but in a long term it would definetly be a good idea to
> implement it in the protocol.
> 
> Keep up the good work,
> 
> Best regards
> 
> 
> Francisco Obispo

Regards,
Fred