Re: clTRID element clarification

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Aaron Roberts
> Sent: 29 February 2012 15:24
> To: [email protected]
> 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
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg