Subject: RE: format of contents of <domain:curExpDate>

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 14 Nov 2002 08:56:16 -0500

> I'm not seeing how this would increase opportunities for error, 
> although it's 8am here (I'm in Ontario now, but I'm still a 
> Kiwi :) and 
> the caffeine has yet to seep into the veins. If I'm missing 
> something, 
> please let me know.

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.  It can be retrieved in UTC directly from
the registry with an <info> command, parsed, and copied into the parameters
list for the <renew> command with no explicit need to translate the value
into local time.  I offered that adding the time values is possible, but
it's not necessary to ensure that the command is idempotent -- the date
alone provides enough granularity for that.  Acquiring and exchanging
information that isn't necessary to complete an operation is where I see the
increased opportunity for error.

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

-Scott-

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Nov 2002 11:13:02 -0500

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

> 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.

> 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

---

From: Joe Abley <[email-masked]>
Date: Tue, 26 Nov 2002 23:30:18 -0500

On Thursday, Nov 14, 2002, at 11:13 Canada/Eastern, Joe Abley wrote:

> [blah blah]
> return a <domain:exDate> must be consistent when sending responses to 
> a single registrar.

I had completely missed the paragraph near the beginning of the 
domain-mapping, host-mapping and contact-mapping drafts which specifies 
that all dates and times exchanged between server and client MUST be in 
UTC. My bad. That would seem to take care of (b) above.

I still think it would be more consistent to use a dateTime type in 
<domain:curExpDate>, but I can no longer think of an operational reason 
to demand it. I hereby withdraw my previous long-winded and tedious 
request :)

Joe