Subject: Re: [provreg] clTRID element clarification

From: Aaron Roberts <[email-masked]>
Date: Wed, 7 Mar 2012 15:42:20 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Aaron Roberts
> Sent: 29 February 2012 15:24
> 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.
> 
> I'd be very interested to know what everybody is doing in this regard?
> 

Thanks to everyone for your responses.
The consensus from the responses that I received are that an EPP server should not be doing anything with the clTRID, (except returning it to the client in responses, as RFC5730 section 2.6 states).  Does anybody feel that section 2.5 of RFC5730 ("command format") should include some extra text to explicitly prohibit servers from making assumptions about the clTRID element (or something similar)?

Thanks,
Aaron

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 7 Mar 2012 17:08:22 +0000

> Sent: Wednesday, March 07, 2012 10:42 AM
> To: [email-masked]
> Subject: Re: [provreg] clTRID element clarification
> 
> The consensus from the responses that I received are that an EPP server
> should not be doing anything with the clTRID, (except returning it to
> the client in responses, as RFC5730 section 2.6 states).  Does anybody
> feel that section 2.5 of RFC5730 ("command format") should include some
> extra text to explicitly prohibit servers from making assumptions about
> the clTRID element (or something similar)?

Given that RFC 5730 is part of Standard 69 there's not much chance of a near-term amendment, but our process allows us to collect errata. I'm not convinced that there's anything here to correct, though. Section 2.5 currently says this:

"MAY be used to uniquely identify the command *to the client*"

(emphasis mine), and

"Clients are responsible for maintaining their own transaction identifier space to ensure uniqueness."

This doesn't seem ambiguous to me.

Scott

---

From: Luis Muñoz <[email-masked]>
Date: Wed, 7 Mar 2012 12:11:20 -0500

> This doesn't seem ambiguous to me.

That language does not directly contradicts a server using it to provide a cached response to a command with the same (command, clTRID, arguments...) n-tuple, right?

-lem

---

From: Aaron Roberts <[email-masked]>
Date: Wed, 7 Mar 2012 17:32:37 +0000

> From: Luis Muñoz [mailto:[email-masked]]
> Sent: 07 March 2012 17:11
> To: Hollenbeck, Scott
> Cc: Aaron Roberts; [email-masked]
> That language does not directly contradicts a server using it to provide a
> cached response to a command with the same (command, clTRID,
> arguments...) n-tuple, right?
> 

It is pretty clear that the cached response server behaviour is miles outside the definition of the clTRID.  However, all the stuff which should not be done with the clTRID, at the server end, is only covered by the implication of the statement that the clTRID "MAY be used to uniquely identify the command to the client".  One of the other registries, in their responses, said that they had seriously considered this sort of server behaviour, at points in their development.  If registries are making the decision to implement this cached response behaviour (or even thinking about it), a statement like "The server shouldn't make any assumptions about the clTRID" could stop the discussion, before it even started?

Aaron

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 7 Mar 2012 18:07:27 +0000

> Sent: Wednesday, March 07, 2012 12:11 PM
> To: Hollenbeck, Scott
> That language does not directly contradicts a server using it to
> provide a cached response to a command with the same (command, clTRID,

No, it doesn't. It also doesn't include restrictions for any number of other behaviors. It describes who owns the item and what may do with it. One shouldn't assume that something is allowable unless it's expressly prohibited.

Scott

---

From: Theo Kramer <[email-masked]>
Date: Thu, 8 Mar 2012 22:32:33 -0600

> "MAY be used to uniquely identify the command *to the client*"

Is that not perhaps something that slipped through the cracks? Ie. should it not read

"MAY be used to uniquely identify the command from the client" ?

-- 
Regards
Theo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 9 Mar 2012 12:04:13 +0000

> Behalf Of Theo Kramer
> Sent: Thursday, March 08, 2012 11:33 PM
> > Given that RFC 5730 is part of Standard 69 there's not much chance of
> a near-term amendment, but our process allows us to collect errata. I'm
> not convinced that there's anything here to correct, though. Section
> 2.5 currently says this:
> >

No, the intention is for the clTRID to have meaning only in the client's context. That's not a typo about sending commands to clients.

Scott