Subject: [provreg] clTRID element clarification

From: Aaron Roberts <[email-masked]>
Date: Wed, 29 Feb 2012 15:24:04 +0000

Hi all,
	I'm looking to gauge domain registries' interpretation and use of the clTRID EPP command element in their EPP server implementations.

It seems that some registry EPP servers (namely .za and .im) use a kind of "cache/lookup" mechanism, based on the clTRID and (hopefully) scoped to individual registrars.  Where a command is received from a registrar with a clTRID which has been previously used by the same registrar, the cached server response is returned to the client, instead of the command being executed a second time.  The intention is to provide idempotency at the server level, when commands are issued multiple times.

My interpretation of the RFCs is that the clTRID is just a handy identifier for debugging etc.. managed by the client end and that EPP commands are designed to be idempotent by nature so can be safely executed multiple times without any considerations given to previous executions.

I'd be very interested to know what everybody is doing in this regard?

Regards,
	Aaron

Domicilium (IOM) Limited | The Isle of Man Datacentre 
Ronaldsway Industrial Estate | Ballasalla | Isle of Man |IM9 2RS
Tel +44 (0) 1624 825278

www.domicilium.com 
www.ipv6.domicilium.com 
This e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail. Please then delete the e-mail and do not disclose its contents to any person.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 1 Mar 2012 11:57:02 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Aaron Roberts
> Sent: Wednesday, February 29, 2012 10:24 AM
> To: [email-masked]
> Subject: [provreg] clTRID element clarification
> 
> Hi all,
> 	I'm looking to gauge domain registries' interpretation and use of
> the clTRID EPP command element in their EPP server implementations.
> 
> It seems that some registry EPP servers (namely .za and .im) use a kind
> of "cache/lookup" mechanism, based on the clTRID and (hopefully) scoped
> to individual registrars.  Where a command is received from a registrar
> with a clTRID which has been previously used by the same registrar, the
> cached server response is returned to the client, instead of the
> command being executed a second time.  The intention is to provide
> idempotency at the server level, when commands are issued multiple
> times.
> 
> My interpretation of the RFCs is that the clTRID is just a handy
> identifier for debugging etc.. managed by the client end and that EPP
> commands are designed to be idempotent by nature so can be safely
> executed multiple times without any considerations given to previous
> executions.

Your interpretation is correct. Servers should not make *any* assumptions about clTRIDs.

Scott

---

From: Ulrich Wisser <[email-masked]>
Date: Thu, 01 Mar 2012 23:11:49 +0100

Hi Aaron,

at .SE the clTRID is ignored as long as it fits the standard definition 
(3-63 characters). It is returned to the client in the answer, but 
that's it.

We actually do have registrars not sending clTRID at all, sending the 
same clTRID with every command, sending the clTRID from our example code 
with every command, setting clTRID to a hash of the command, ...

Regards from Stockholm

Ulrich

> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

---

From: Theo Kramer <[email-masked]>
Date: Fri, 2 Mar 2012 10:06:38 +0200

> Your interpretation is correct. Servers should not make *any* assumptions about clTRIDs.

The .za implementation for co.za operates as follows

If no clTRID is provided the server generates a unique clTRID on behalf of the client.
If a clTRID matches a previous clTRID the server compares the message and if it matches returns the original result.
If a clTRID matches a previous clTRID the server compares the message and if it does not match returns 2308 with an appropriate message.
The server validates clTRID based on the standard EPP schema.

Perhaps idempotency may simply not be practical, eg. in cases where registrant tokens are used in updates/deletes/transfers ...

-- 
Regards
Theo

---

From: Christopher Browne <[email-masked]>
Date: Thu, 1 Mar 2012 18:43:40 -0500

On Thu, Mar 1, 2012 at 5:11 PM, Ulrich Wisser <[email-masked]> wrote:
> We actually do have registrars not sending clTRID at all, sending the same
> clTRID with every command, sending the clTRID from our example code with
> every command, setting clTRID to a hash of the command, ...

I periodically bring up the idea that we ought to consider putting a
unique constraint on clTRID on a per-registrar basis; in principle,
that ought to be someone a registry could consider imposing as a
policy.

Nobody gets terribly enthused about that idea.  They expect, and I
think they're right, that this would irritate registrars that are
using particularly lazily-constructed client trids.

Furthermore, it does not seem likely that there would be huge value to
be gained from doing a lot of work interpreting clTRID values.

It's an interesting idea to put an object cache that uses client trid
as the basis for identifying that two requests ought to be interpreted
the same way.  But that seems likely to be counterproductive, looking
at a couple of cases:

1.  To repeat a write operation seems likely to cause trouble.
Re-requesting a domain renew shouldn't be able to work, for instance,
as two separate renew requests will need to be different as they need
to include different expiry dates.

2.  Caching read operations means that registrars are getting
increasingly stale data, and if they were doing a domain check to see
if a domain has become available, there's a risk that they are getting
*wrong* information.

So, the idea is interesting, in some theoretical ways, but in the
absence of something *really* valuable to gain, I don't think it's
worth irritating registrars by imposing a bunch of logic onto the
interpretation of clTRIDs.

Making some operations a little faster doesn't seem to be worth the
potential for irritation.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 2 Mar 2012 12:21:34 +0000

> Behalf Of Theo Kramer
> Sent: Friday, March 02, 2012 3:07 AM
> To: [email-masked]
> Subject: Re: [provreg] clTRID element clarification
> 
> 
> If a clTRID matches a previous clTRID the server compares the message
> and if it matches returns the original result.
> If a clTRID matches a previous clTRID the server compares the message
> and if it does not match returns 2308 with an appropriate message.
> Perhaps idempotency may simply not be practical, eg. in cases where
> registrant tokens are used in updates/deletes/transfers ...

The server shouldn't be generating what's supposed to be a client-provided transaction identifier.

Scott

---

From: Francisco Obispo <[email-masked]>
Date: Fri, 2 Mar 2012 07:40:33 -0500

+1

The clTRID is to be used by the client to identify the transaction against the server.. this is very useful if the EPP protocol is used on asynchronous protocols such as SMTP, or if pipelining is used.

> The server shouldn't be generating what's supposed to be a client-provided transaction identifier.

Francisco Obispo 
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: "Gould, James" <[email-masked]>
Date: Fri, 2 Mar 2012 12:52:48 +0000

++1

For .com, .net, .tv, .cc, .jobs, and .name the clTRID is generated by the
client and is mirrored back in the response.  I agree that it's a
necessary feature for pipelining as an Asynchronous Completion Token
(ACT).    

--
  
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 3/2/12 7:40 AM, "Francisco Obispo" <[email-masked]> wrote:

>+1
>
>The clTRID is to be used by the client to identify the transaction
>against the server.. this is very useful if the EPP protocol is used on
>asynchronous protocols such as SMTP, or if pipelining is used.
>
>
>

---

From: Theo Kramer <[email-masked]>
Date: Fri, 2 Mar 2012 15:42:52 +0200

On 02 Mar 2012, at 2:52 PM, Gould, James wrote:

> client and is mirrored back in the response.

Yes - as for co.za when supplied by the client.

>  I agree that it's a

A null clTRID can not be used as an ACT.

and, for a next release

the server will not include a server generated clTRID in a response.
-- 
Regards
Theo

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 2 Mar 2012 14:46:42 +0100

> Yes - as for co.za when supplied by the client.

That is how I think it should be used. I.e. clTRID is something that could be of benefit for the client. Not policed by the registry. Specifically if we start getting more and more async operations (or rather, overloading of commands) from the client.

   Patrik