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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 7 Jul 2006 09:22:47 -0400

> -----Original Message-----
> From: Klaus Malorny [mailto:[email-masked]] 
> Sent: Friday, July 07, 2006 9:08 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> 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-

---

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

> fixed.  It will be in the next iteration of the document.  Thanks for

See, I do this despite my opinion regarding EPP ;-)

> in response to a client action.

Maybe "unsolicited" is the wrong term, but not as a response to a <hello> 
message, but to the connect. So a <hello> message is not consumed by this.

> financial consequences for transactions repeatedly sent in error.

Ah, come on. The registry is not responsible for the errors that are done by the 
registrar. If a registrar accidentally deletes a domain and has to restore it 
for big money, you are happy about this, aren't you?

> -Scott-

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Jul 2006 13:32:45 -0400

On Fri, Jul 07, 2006 at 03:51:06PM +0200, Klaus Malorny wrote:

> Ah, come on. The registry is not responsible for the errors that are done 
> by the registrar. 

You've not been on the end of a complaint call about this, I take it? 
Because I can tell you right now that, irrespective of who does what,
there are at least some people who regard any unexpected happenings
as the fault of the registry, irrespective of who issued what
commands.  (This is not to paint everyone with the same brush, note:
there are pleny of people who do look at their own error messages. 
But of course, those people tend to test their clients completely,
too, so that they don't accidentally send the same command multiple
times.)

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110