Re: format of contents of <domain:curExpDate>

[Joe Abley <jabley@isc.org>]

On Thursday, Nov 14, 2002, at 07:24 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> I can see how that would be the case if everybody in the
>> world lived in
>> the same time zone. It seems like it might cause friction otherwise,
>> however.
>
> This field isn't used for local interpretation purposes -- it's used 
> _only_
> to match the date as currently archived by the server.  We could 
> instead
> force a match on date, hours, minutes, seconds, and time zone, but that
> would seem to increase opportunities for error.

 From an implementation perspective it would be nice to have a single 
date format for use throughout the protocol, that we called regardless 
of which element we were parsing. That was my original reason for 
bringing it up.

> This is such a nit that I really don't care, though.  If anyone else 
> thinks
> that it would be better to use a full date-time value in this field, 
> please
> speak up.

This field *does* have a local interpretation, regardless of whether 
the protocol requires an interpretation to be made at the registrar.

Consider a registrar in New Zealand (UTC+12, UTC+13 in the southern 
summer) and a registry on the west coast of the US (UTC-8, UTC-7 in the 
northern summer). The date in New Zealand is usually (but not always) 
one day in advance of the date in California.

The NZ registrar will presumably have a local market of registrants, 
and it will communicate expiry dates to those registrants in a way that 
makes sense for New Zealanders.

Because of the requirement to interpret the renewal date in two 
timezones, complexity arises. The date has to be converted either from 
a locally-held value when talking to the registry, or from a 
registry-held value when talking to a registrant.

You could argue that the exact moment at which the expiry occurs is not 
relevant, since the registry probably operates a grace period which 
gives the required 1 day of flexibility, but that is an assumption 
about policy and would seem to be out-of-scope for a provisioning 
protocol document.

It seems to me that this is indeed an irritating nit as viewed from the 
perspective of one who rarely has to deal with other organisations in a 
different timezone where the date is different. However, having lived 
in New Zealand and worked with a lot of people in California while I 
was there, this kind of ambiguity arises all the time and usually 
requires annoying kludge-coding to attempt to approximate real-life 
practice when functional specifications don't specify what MUST happen. 
I would be very surprised if this is a problem that is unique to New 
Zealand, although given its time zone it is probably more of a problem 
there than elsewhere.

Specifying a full time instead of a date seems to me like it would 
avoid a problem, and would make implementation easier.

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.


Joe