Ed Davies said:
> know how you'd portably get TXT records unless you coded up the
> whole process of communicating with the DNS server using UDP or
> TCP which would be:
This ought to be a feature of standard libraries (though I'll admit I
haven't checked).
> As to getting the dates of leap seconds: the question arises as
> to why one would want these dates, as such.
I don't know, but it seems an obvious thing to make available.
> Returning multiple addresses with different second bytes is a neat idea
> I hadn't thought of.
Thanks.
> However, I don't much like the idea of putting in too much information
> in one go. The idea is to make things as lightweight as possible so
> proper TAI and UTC handling can be done by any internet connected
> system.
Adding a second address isn't going to make it much heavier. And it is
*far* better to have it clear *NOW* that there could be more than one
address, than try to retrofit the feature at a later date when people have
deployed broken code.
> It might be good practice, though, to write code which can accept
> multiple addresses and select out the one(s) with understood second
> bytes.
Exactly. But if you don't produce such data, experience tells me that code
won't get written.
> A small disadvantage of your suggestion is that the domains for all
> months after the latest scheduled leap second (e.g., all months in
> 2003) would have to have a shorter TTL, because ultimately, they'll
> be replaced with a link to the next leap second when it is scheduled.
Any TTL greater than a week is going to mean there's so much caching and so
little load on the base server that it won't be a problem.
> If your scheme was adopted then maybe values of N in the range
> [200..253] could be used to mean that the next leap second has not
> been scheduled yet but it is at least N-200 months ahead.
Could do.
>> (4) To be future-proof you need to deal with IPv6. IPv6 only has one
>> loopback address. However, it also has two ways of embedding IPv4
>> addresses into IPv6 addresses. I suggest that you use:
>>
>> ::FFFF:7Faa:bbcc aka ::FF:127.aaa.bbb.ccc
>>
>> (that is, the equivalent IPv4 address with 80 zeros and 16 ones prefixed).
>
> Good point. I'm not confident enough of my knowledge of IPv6 to
> have included this but you are right, it should go in a complete
> version of this proposal. The only thing I have about IPv6 is
> IPv6 The New Internet Protocol by Christian Huitema, 1996 (which
> makes it pretty old for a "future" protocol :-) ). It says IPv4
> addresses are embedded by prefixing them with 96 zeros.
> Presumably that's the other way of embedding them which you don't
> suggest?
Yes. That's used for IPv4 addresses reachable through IPv6 tunnels. While
you could use either, the "unreachable" version looks better to me.
--
Clive D.W. Feather | Work: <clive_at_demon.net> | Tel: +44 20 8495 6138
Internet Expert | Home: <clive_at_davros.org> | *** NOTE CHANGE ***
Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937
Thus plc | | Mobile: +44 7973 377646
Received on Tue May 06 2003 - 08:40:09 PDT