Re: interpretation of 'EPP idempotency'

[Daniel Manley <dmanley@tucows.com>]

Hollenbeck, Scott wrote:

>I can't speak directly to .info's implementation, but it sounds a little kludgy as you describe it.
>
Yes, that does break the idempotency of the protocol, doesn't it?  I 
can't specifically speak for the reasons of using EPP for sunrise and 
landrush registrations of .info domains, but the side effects were 
great.  We were able to test our implementation of an EPP server and see 
its performance in a live environment under high loads.  It also helped 
us avoid the situation where the registrars had to develop two different 
interfaces to the .info registry (i.e. batch file processing and then 
real-time EPP).

I can't truly speak for Liberty/Afilias but I think their support team 
is trying to be as accomodating as possible, given that everyone is 
learning from this process.  If you encountered problems in registration 
of domains, you should give their tech support team a call and they 
might be able to check up on transactions for you to verify the number 
of times a domain has been submitted by your registrar.

I believe that they are closing the landrush queue by the end of this 
week, so this "un-idempotent" period will be over soon.

>
>As things are written in the specs, you should
>NOT be able to <create> an object more than once and receive a "success"
>response.  If you do a <create>, get back "success", do another <create>,
>and then get back another "success", the <create> command isn't idempotent.
>Executing the command multiple times doesn't produce the same state as
>executing the command once.
>
>EPP _is_ designed to handle special needs via the extension mechanism; it
>could be that .info was under time pressure to go ahead with an earlier
>version of the specs in which some of the extension possibilities weren't
>fully developed, or maybe the method as you described it was just seen as
>the easiest way to solve an immediate problem, even if it means <create> is
>no longer idempotent.  As you noted, when the command isn't idempotent there
>are issues to be dealt with -- and I'll be the first to admit that the
>protocol wasn't designed to deal with commands that aren't idempotent.
>
>>Why shouldn't EPP get an idempotency mechanism which is independent of
>>specific object or command semantics?
>>
>
>Because idempotency isn't a mechanism, it's a property -- it's an integral
>part of the way commands or transactions are structured to provide the
>property of being idempotent.
>
><Scott/>
>