Re: [ietf-provreg] Implementation Report Update

[Patrick Mevzek <provreg@contact.dotandco.com>]

Hollenbeck, Scott <shollenbeck@verisign.com> 2006-06-20 14:54
> > >  The bad news is that there are a few optional features
> > > that no one has yet described as "implemented".  These include:
> > > 
> > > 1. Domain transfer authorization using the "roid" attribute.
> > 
> > Implemented in my software.
> 
> Do you know of any registrars that are using this feature, Patrick?  We
> need two independently developed implementations to meet the
> proposed-to-draft requirements.

I do not understand, sorry (still new at all this).
Is the problem : have it been implemented, or is it used ?
If that changes anything, almost (I believe all but I will not say
all, in fear of having forgotten a case) all EPP operations are
covered in my software by a test suite of 1416 tests, meaning that
at least I have proof, based on examples given in RFCs, that my
software behaves like in the RFC, including for domain transfer with
roid attribute.
You can see it line 159 of the test file living at :
http://search.cpan.org/src/PMEVZEK/Net-DRI-0.30/t/601vnds_epp.t
showing a transfer of example5.com with roid value JD1234-REP

Of course this does not replace on the field tests.

There are other parts of the RFC, seldom used if not at all forbidden
by some registries, like contact transfers.
I have implemented it also since it is in the RFC, but the fact that
it may not be used does not eliminate it from testing
interoperability and including it, does it ?

Otherwise I do not have direct feedback of anyone using it, but I
even do not know exactly who uses the toolkit at all, even if I know
it is used (bugreports :-)).
As for domain transfer with roid, maybe starting with registries
allowing it would be easier (I'm not a gTLD registrar, I do not know
which ones do, which ones do not).

> > > 2. Offline review of domain, host, and contact transform 
> > operations.  In
> > > truth, one registrar has reported that they have successfully tested
> > > this feature with domains and hosts, but I want to confirm 
> > that before
> > > reporting success.
> > 
> > Partially (until I understand better) implemented in my software.
> > The latest version implements parsing of panData result.
> > It was not clear from my reading of the RFC how things should
> > operate in other cases.
> 
> I'd like to understand what you don't understand, too. 

Nothing wrong with the RFC, I think.
The core part gives a very general example, after which the
domain/contact/host mappings give only one example, with panData.
The core part let me believe many types of messages can be retrieved
that way. However the mapping parts all say :
In addition, the EPP
   <resData> element MUST contain a child <domain:panData>
and so on, which makes me believe nothing else than panData can
appear in such resData messages, so no other type of information.

However registries are using it in various purposes it seems and since not all
registries are willing to share documents about their EPP extensions,
I have trouble doing something that make sense, because in my case I do not
want my software to be only for one registry, it should work with
multiple registries doing multiple type of poll responses.

So it's probably just an implementor problem not coming from the
protocol itself.

> Same question as above: do you know of any registrars that are using
> this feature?

I'm not sure to follow. You mean with my software ?
From direct report, at least a .COM registrar. But I do not have
details, just an enhancement patch about parsing transfer data in poll
response.

So in short, not sure if I'm helpful, but I'll try if someone tells
me where I'm wrong or clueless.

-- 
Patrick Mevzek 
Dot and Co <http://www.dotandco.com/>