Rob Seaman <[email protected]> wrote: > Obviously we would be forced to adapt. We can't all be a "one-man > micronation" like Michael :-) More power to him, but that isn't a > "coordinated" plan either.
My "one-man micronation" is connected to the Internet with its own public, static, world-reachable IPv4 address block and a few domains. My UTR time server will have a public, world-reachable IPv4 address (IPv6 connectively will probably be added soon too), and all of you will be more than welcome to get time from it. So it *is* a viable solution for more than just me. Furthermore, although my preference is to implement my UTR time server with custom PowerPC hardware rather than mere software hacks on a garden variety x86 box, I will publish all of my hardware schematics, PCB and gerber files etc (as in release all that into the public domain), so anyone else would be able to build his/her own UTR server identical to mine. I will also offer actual hardware units for the cost of what I have to pay for the PCBs, parts and assembly, i.e., zero profit margin for me. And if someone else finds a way to implement a functionally equivalent UTR server using only software instead of custom hardware, more power to them. As for my plan not being "coordinated", I beg to disagree as well. I have already posted a draft of the formal technical specification for the UTR timescale, which includes a mechanism for having all UTR users agree on exactly the same rubberizations. Brief summary: * An open-participation mailing list needs to be created on which all UTR users could gather, although I would prefer it to be a little more inclusive to *all* forms of Mean Solar Time in a post-UTC world, hence the proposed name MST Users. You, Rob, are personally invited to join, as are Michael Cook and Markus Kuhn. * The UTR specification does not stipulate any specific set of rubberizations, although for the sake of ease of implementation it requires the duration of each rubber second to be an integral number of SI milliseconds. But there are many possible rubberizations which would meet this constraint, and my vision is to have some community consensus rather than fiat drive that choice. Even if our Mean Solar Time Users mailing list has only 3 members initially (e.g., me, you and Michael Cook), our UTR timescale can be fully coordinated between the 3 of us. The official UTR timescale is defined by the utrdef.txt file, an ASCII text file whose format/syntax is defined by the UTR specification, but the consensus at to exactly when should rubberizations occur and what shape they should take should be reached on the mailing list first. My vision is that we would reach consensus on our mailing list, then the maintainer of the actual utrdef.txt on the official server would merely encode the consensus decision in the standard file format/syntax. All actual UTR time server implementations, whether it's my preferred PowerPC hardware implementation or someone else's functionally equivalent software implementation, would periodically poll the server holding the master copy of the official utrdef.txt, and automatically pull down any updates well advance of each rubberization. As a result all UTR users will independently regenerate exactly the same UTR time scale, with rubberizations occurring at exactly the same agreed-upon times, regardless of which actual hw/sw implementation they choose to use. No worse than the current UTC, i.e., no less coordinated. MS _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
