RE: Command Recovery

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: Thomas Corte [mailto:Thomas.Corte@knipp.de]
> Sent: Friday, September 21, 2001 6:41 AM
> To: Daniel Manley
> Cc: Hollenbeck, Scott; ietf-provreg@cafax.se
> Subject: Re: Command Recovery
> 
> Using the transmission date would require client and server to
> agree on the *exact date* for a later status query match. Afaik,
> EPP currently does not include transmission of the current date,
> neither by the client nor by the server. Therefore, usage of the
> date might be not feasible here.
> Using the operation type (in addition to the registrar id)
> to reduce the client trid namespace seems reasonable.

Thomas,

Given that all dates are exchanged in UTC it shouldn't be a problem for the
client (who knows when the command was allegedly sent) and server to be in
synch, but if they're not, yes, this might be an issue.  I can also see
where it might be an issue if a date boundary is crossed due to normal
network latency, so I don't mind leaving it out if folks think it introduces
a point of potential confusion.

> However, I still don't consider it a big problem to require unique
> trids from the client. After all, the mechanism we are discussing
> facilitates the client's recovery issues, so it shouldn't burden
> the client too much to put trid uniqueness into it's responsibility.

I wouldn't mind adding text to the specs to RECOMMEND that clients enforce
TRID uniqueness on their end, but I don't want such text to imply that the
server MUST enforce uniqueness if the client makes mistakes.  That's where
the burden can get ugly.

<Scott/>