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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 14 Nov 2002 07:24:57 -0500

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

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.

-Scott-

---

From: Asbjorn Steira <[email-masked]>
Date: Thu, 14 Nov 2002 13:57:34 +0000

Hollenbeck, Scott wrote:

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

I think we should just leave it as it is.

Asbjorn

-- 
Asbjorn Steira
The Global Name Registry, Limited

Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Nov 2002 08:41:16 -0500

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

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

> thinks

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