RE: interpretation of 'EPP idempotency'

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

<Scott/> 

> -----Original Message-----
> From: Thomas Corte [mailto:Thomas.Corte@knipp.de]
> Sent: Tuesday, September 18, 2001 4:36 PM
> To: Hollenbeck, Scott
> Cc: 'Klaus Malorny'; ietf-provreg@cafax.se
> Subject: RE: interpretation of 'EPP idempotency'

[snip]

> For example, the .info EPP server currently operates in a mode where
> multiple domains with the same name may be submitted using 
> EPP commands.
> If the same registrar resubmits a domain already submitted, 
> this succeeds
> and increases the entry count for this domain. Different 
> registrars may
> submit the same domain name, too. Furthermore, domain names submitted
> in this mode can not be inquired.
> Now, if I want to submit a domain name exactly once, what 
> should I do if
> for some reason I do not get the EPP server's response to my 
> submission? I
> can't inquire, I can't resubmit without risking a duplicate 
> entry, and I
> can't leave it alone if I want to be sure to have an entry in the
> repostory.
> 
> Admittedly, this is an exceptional situation. But all the 
> registries to
> come may have special cases like this, and I think EPP should 
> be able to
> handle it.

Thomas,

Now I see where your issues are coming from...

I can't speak directly to .info's implementation, but it sounds a little
kludgy as you describe it.  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/>