RE: [ietf-provreg] EPP Implementation Test Matrix

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] 
> Sent: Friday, July 07, 2006 9:08 AM
> To: Hollenbeck, Scott
> Cc: ietf-provreg@cafax.se
> Subject: Re: [ietf-provreg] EPP Implementation Test Matrix
> 
> Hollenbeck, Scott wrote:
> 
> > 
> > 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.
> > 
> 
> 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.

Not a contradiction, an error.  The state machine diagram should be
fixed.  It will be in the next iteration of the document.  Thanks for
pointing out the error.

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

Correct about 3730, though the <greeting> isn't unsolicited.  It's sent
in response to a client action.

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

There's another party to consider: the server operator.  It's important
for them -- and I can guarantee that registrars WILL care if there are
financial consequences for transactions repeatedly sent in error.

-Scott-