Subject: RE: [ietf-provreg] Implementation Report Update

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 20 Jun 2006 08:48:08 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Patrick Mevzek
> Sent: Monday, June 19, 2006 12:32 PM
> To: [email-masked]
> Subject: Re: [ietf-provreg] Implementation Report Update
> 
> Hollenbeck, Scott <[email-masked]> 2006-06-19 16:50
> > I've been intermittently working on an EPP implementation 
> report (see
> > section 4.1.2 of RFC 2026) for the last few months.  The 
> good news is
> > that the people I've been working with have described 
> implementations
> > that cover most of the required and optional features in 
> the core EPP
> > specifications.
> 
> I would be very much interested in participating in any way possible.
> I'm the author of a GPL-licensed software called Net::DRI, which is
> a toolkit implementing RRP, EPP, and other registries protocols
> (namely, at least, RFCs
> 2832,3632,3730,3731,3732,3733,3734,3735,3915,4114, and 4310).
> 
> All information is there :
> http://www.dotandco.com/services/software/Net-DRI/index.en
> (also in French for those prefering French).
> It is used in live operations by various registrars in various
> TLD.
> 
> >  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.

> > 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.  The protocol
spec doesn't describe how the actual offline review works since that's
something that should be done according to registry practices that are
outside the protocol.  If something else isn't clear we have a chance to
add text when the -bis documents are updated again.

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

-Scott-

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 23 Jun 2006 00:33:36 +0200

Hollenbeck, Scott <[email-masked]> 2006-06-20 14:54
> 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).

> 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

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/>