Subject: RE: [ietf-provreg] EPP Implementation Test Matrix

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 7 Jul 2006 08:06:14 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Klaus Malorny
> Sent: Thursday, July 06, 2006 4:19 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [ietf-provreg] EPP Implementation Test Matrix
> 
> Hollenbeck, Scott wrote:
> 
> > This is precisely why I shared the matrix.  If your results 
> differ, I
> > need to know what others have seen for test results.  If there are
> > differences of opinion we can talk about them to determine 
> what really
> > needs to be in the boxes.
> > 
> 
> Hi Scott,
> 
> It is not a question of "differences". It is a question of 
> interpretation of the 
> term "implemented and tested". What about the "<hello>" 
> message, for example? 
> Six "X". Really? Does any of the three registries work with a 
> different 
> transport layer than RFC 3734? Not that I am aware of. So how 
> could you have 
> tested the <hello> command if RFC3734 does not even mention 
> it? Comparing 
> RFC3730 and RFC3734 shows that it is at least unclear (if not 
> contradicting) 
> whether or not the client may send a "<hello>" message at the 
> beginning of the 
> communication (and cannot be tested therefore). My personal 
> interpretation of 
> your RFC3734 is, however, that the "<hello>" element is not 
> allowed in TCP-based 
> communications. Since the "<hello>" message is not a command, 
> it is also unclear 
> in RFC3730 how a server should react if it receives a 
> "<hello>" message at any 
> point in time after the server has sent the "<greeting>" 
> message. Also not testable.

Sorry, but I disagree.  Apparently other implementers do as well.
There's absolutely nothing in 3730 that says a <hello> can't be used
with a connection-oriented transport.  In fact, section 2.3 very clearly
says that "An EPP client MAY request a <greeting> from an EPP server at
any time by sending a <hello> to a server".  I don't know what's unclear
about that.

While I disagree with the specific example you described above I agree
that we need to discuss feature interpretation and testability.  That's
the whole point of producing an implementation report.

> >> Howsoever, I would be surprised if you would do anything but 
> >> to ignore my 
> >> objections -- as usual.
> > 
> > Ignore your "objections"?  Hardly.  There are multitudes of 
> responses
> > from me in the list archives (such as this one) to confirm 
> that you're
> > not being ignored when you participate in a productive dialogue.
> > However, don't expect me to respond to your opinions [1] 
> that repeat old
> > arguments.  I'm not going there.
> > 
> 
> A single word comes to my mind: Idempotency. You are probably 
> still convinced of 
> this great property of EPP (in the way you have defined it).

Another old argument.  The definition I've consistently used [1] is
described in Jim Gray and Andreas Reuter's "Transaction Processing:
Concepts and Techniques" book.  If you disagree with it, take it up with
them.

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00061.html

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 07 Jul 2006 15:07:30 +0200

> any time by sending a <hello> to a server".  I don't know what's unclear

I know the statement in 2.3, but the figure 1 on page 4, titled "EPP Server 
State Machine" does not tell anything about an exchange of a <hello> or 
<greeting> message except for the startup. Since <hello> is not a command (it is 
not described in section 2.9), the state machine does not expect a <hello> 
message if in the "Waiting for Client Authentication" or "Waiting for Command" 
states. I hope you agree that there is a contradiction.

Also, in 3734, the server sends an unsolicited <greeting>. Should the server 
send a second <greeting> in case the client sends a <hello>? According to 
3730/2.3, it has to.

> Concepts and Techniques" book.  If you disagree with it, take it up with

I own that book and I clearly do not disagree with the authors of the book in 
any way. Instead I think that you are tweaking the definition until it fits for 
EPP. Anyhow, whether this "feature" of EPP conforms to the book's definition of 
"idempotency" or not, several registrars have confirmed my point of view that it 
does not help registrars in any way, and that's the important quintessence.

Regards,

Klaus

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