Re: format of contents of <domain:curExpDate>

[Joe Abley <jabley@isc.org>]

On Thursday, Nov 14, 2002, at 08:56 Canada/Eastern, Hollenbeck, Scott 
wrote:

> You seem to be thinking that the value for this particular field is 
> one that
> needs to be either given to or retrieved from the registrant as part 
> of a
> renewal operation -- it doesn't.

Actually, I wasn't. I was thinking that it's a value that needs to be 
interpreted in precisely the same way by both registrar and registry, 
and was making the observation that the way in which the field should 
be interpreted is not currently communicated between client and server. 
Mention of the registrant was purely to illustrate that there are 
reasons for a registrar to interpret the data concerned in a localised 
fashion, in contexts other than <domain:renew>.

If the procedure you suggested (rip the date part out of a 
<domain:curExpDate>, in whatever timezone was specified in that data) 
is what you intended, then the draft needs to specify:

  (a) that procedure, and

  (b) that the time zone used in all situations where a server can 
return a <domain:exDate> must be consistent when sending responses to a 
single registrar.

Consider the following, in support of (b). Suppose a registry had EPP 
servers distributed geographically, in different time zones (one in 
Europe somewhere, one in the US maybe), and client connections to EPP 
servers were load-balanced in some fashion (round-robin DNS, anycast) 
or there was a capability of fail-over between sites. Suppose servers 
in each site returned date objects encoded in the local time zone, as 
is common practice in other protocols (SMTP "Received" headers, for 
example), and as is permitted by the EPP protocol.

It might be easily possible in that scenario for a client to receive a 
date specified in UTC-5 in response to one <domain:info> request, and 
to receive a date specified in UTC+2 in response to a subsequent one. 
Which timezone should be used when encoding a <domain:curExpDate>, in 
the case that you don't know which EPP server is going to handle the 
transaction?

This may sound like a wildly contrived example, but I seem to remember 
several of the ORG redelegation proposals specifying widely-flung 
geographic diversity in registry infrastructure. It doesn't seem like 
an unreasonable thing for a registry to do.

> That's why I said it was a nit.  It's got nothing to do with being
> insensitive to time zone differences.

It is certainly a minor point in the grand scheme of things, but I 
think it's more relevant than a nit.


Joe