Re: clTRID element clarification

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Theo Kramer
> Sent: Friday, March 02, 2012 3:07 AM
> To: [email protected]
> Subject: Re: [provreg] clTRID element clarification
> 
> 
> 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 ...

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

Scott
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg