John Cowan wrote:

Chris Newman wrote:

...

Excellent idea, but I'd suggest choosing a magic number based on the principles outlined in RFC 2083 section 12.11. I propose:

\211 T Z \r \n ^Z \n

as a magic number.

Thanks for the reference to RFC 2083. I have two problems:

1) 7 bytes is a "peculiar" length. I suggest adding a NUL (\0) byte just after the Z, if we go with this scheme. In which case "strncpy" will have to be replaced with "memcpy".

2) There are only 20 available bytes. I am a little reluctant to consume 8 of them, leaving at most 3 new 32-bit length quantities. Consuming only 4 is less risky.

I agree that seven bytes is a bit long. PNG format files suffer indignities that I don't think the TZ records need to defend against. I don't know why "^T ^Z" would be insufficient. In addition, though, I'd like to see a version sequence number too, so that if the less-than-20 bytes of slop remaining prove insufficient, we have a recourse. I maintain that advisory timestamps: - when the information was entered - when the information was last known to be current - when the information will no longer be officially trustworthy (24 hours later, by default) - when the local installation will no longer consider the information current (perhaps longer, perhaps shorter, by preference) would be a useful addition to the format, in support of incremental network caching. Of course, we should also move to a 64-bit external time representation as soon as possible, which would also be the first increment of the version sequence number. Nathan Myers ncm@cantrip.org