[AFS3-std] Re: New version of the 64-bit time I-D (-03)

[Jeffrey Hutzelman]

On Fri, 2011-09-02 at 12:06 -0500, Andrew Deason wrote:
> On Fri, 2 Sep 2011 13:39:13 +0100
> Simon Wilkinson <simon@sxw.org.uk> wrote:
> 
> > Apologies for not raising this earlier, but I have a small question
> > about naming in the 64 bit time draft. I'd really like to use these
> > times for on-the-wire values in rxgk - in particular for token times.
> > Does it seem like a layering violation for something at the RX level
> > to depend on types with AFS in their name?
> 
> Are they used in an XDR stream in rxgk? My thoughts on this are that the
> types described in afs3-type-time are XDR types and aren't really for
> use in e.g. general packet headers; so if you're just using a 64-bit
> wide field in a packet or something, these types shouldn't be used
> anyway.
> 
> But either way, I think we need to be reasonable about using the exact
> same types everywhere; we can use the same format without saying the
> same exact type name. That is, it seems pretty simple to just say
> something like field TokenTimeFoo is a 64-bit integer, and it represents
> time in exactly the same format as AFS does with AFSTimeAbs64. That's
> what we would be doing for unix time values if we were using unix time;
> we don't just say the field is a time_t, we usually just say it's an
> X-bit integer that works like time in POSIX. Similar thing here, I
> think.


I think it's entirely reasonable for a document describing rxgk to
normatively reference sections of the present document with regard to
epoch, resolution, handling of leap seconds and pre-UTC time, and so on.
That is, it's reasonable to borrow the semantics of AFS's times even if
one is not borrowing the wire representation.  And, it's reasonable to
do that even in a layer that operates "below" AFS, as long as the
relationship is reasonably clean.

-- Jeff