Re: clTRID element clarification
Theo Kramer <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
On 01 Mar 2012, at 1:57 PM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Aaron Roberts >> Sent: Wednesday, February 29, 2012 10:24 AM >> 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. > > 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 _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg