On Fri, 15 Jul 2011 13:11:18 -0500 "Douglas E. Engert" <[email protected]> wrote:
> http://datatracker.ietf.org/doc/draft-deason-afs3-type-time/ Based on the threads in afs3-stds, and on discussions I've had with others, I propose the following going forward. This is what I'm working on for an -03 draft, and it's what will appear unless I hear objections. The epoch will be changed to the Unix epoch. Absolute time will be signed so we can still represent the windows stuff. The language will also be changed a bit according to Russ's suggestions ("number of seconds since 1970 excluding leap seconds" or whatever it turns out to be, see this sub-thread: <http://thread.gmane.org/gmane.comp.file-systems.afs.standardization/1148/focus=1184>). The granularity in this draft will not be changed. However, additional types will be proposed to be used for higher efficiency and higher granularity. That is, the current types will be AFSAbsTime64 which corresponds to 64-bit 100-ns time, but we will also have types such as AFSAbsTime32 (32-bit 1-s time) and AFSAbsTime96 (64-bit 1-s time plus 32-bit 1-ns). RPCs for which this matters will use some way of accomodating and specifying these other types, but how they do so is outside the scope of this draft (in theory this could be unions, extended unions, separate RPCs etc; in practice right now we expect extended unions). In the interest of getting this i-d done as quickly as we can, the other time types will not be added to this draft, but will be proposed in separate i-ds and if we need to we can argue about them then. So, the only change for draft-deason-afs3-type-time is that the type names will be changed to AFSAbsTime64 etc, and I will include a paragraph discussing the rationale and the future use of other time types for interoperability and efficiency. I feel this will satisfy everyone's concerns, as this approach should allow us to interoperate well with other systems, but the common case should be kept nearly as efficient as the current draft. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
