Re: [dhcwg] new forthcoming dhc timezone draft

[Ted Lemon <Ted.Lemon at nominum.com>]

On Tuesday 28 March 2006 03:22, Shane Kerr wrote:
> Case 1:
> - client requests TZ
> - server replies with TZ (and maybe POSIX timezone?)
>
> Case 2:
> - client requests POSIX timezone
> - server replies with POSIX timezone (and maybe TZ?)
>
> Case 3:
> - client requests MS Time
> - server replies with ?
>
> Case 4:
> - client does not request any time information
> - server replies with ?
>
> AIUI, in Case 1 or Case 2, the server *could* include an unsolicited
> option, right?
>
> In Case 3 or Case 4, should the server reply with the TZ, or the POSIX
> timezone, or both, or nothing?
>
> Is it wrong to make any recommendations for these cases? (Developers &
> administators will have to figure something out anyway.)

It is absolutely wrong, yes.   The way clients request options is in the 
parameter request list.   The way servers decide what options to send is to 
look at the parameter request list.   If you place any additional 
requirements on the server here, you are needlessly requiring special-case 
code in a situation where no special-case code is needed.

In case 1, if you reply with TZ, it's going to work.   If you reply with TZ 
and POSIX, what do you think is going to happen?   If you reply only with 
POSIX, what do you think is going to happen?

I'll tell you what I think is going to happen - I think it's going to get 
ignored.   My implementation will either ignore it, or possibly use it as way 
to *guess* the timezone by looking up timezones in the TZ database that have 
the same offset as that specified in the POSIX timezone information.   My 
client definitely isn't going to do anything more than that with the POSIX 
information, because it's incomplete, and there's no way in Linux or NetBSD 
(which are the two cases I particularly care about) to configure the timezone 
using something other than the TZ database.   Since POSIX doesn't specify the 
TZ value unambiguously, it's not very useful, other than for sorting the list 
of timezones to ask about in a pulldown menu somewhere.

In case 2, it's going to work fine, because you're giving the client what it 
asked for and, therefore, what it expects.

In case 3, I suspect you get the same result as in case 1 - if you send the 
POSIX timezone, it will be ignored, because there is no API in Windows for 
setting the timezone that way, and furthermore the POSIX timezone information 
doesn't specify the timezone unambiguously.

In case 4, there's no point in sending the option - if the client didn't ask 
for it, it's not going to do anything with it when it gets it.

Again, please let me call your attention back to the fact that we can't assume 
that we have lots of payload space to burn.   I don't know of a single 
example of a time when sending the POSIX option when it hasn't been requested 
is going to work.   So you are essentially just decreasing the available 
space in the DHCP packet by 40 bytes for no purpose at all.

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg