Hi Jan,

On Fri, May 27, 2005 at 12:51:42PM -0400, Jan Harkes wrote:
>     http://www-2.cs.cmu.edu/afs/cs/project/coda-www/ResearchWebPages/docdir/sec89.pdf
> 
> And although it briefly mentions the begin timestamp, it provides no
> argument _why_ is exists. Looking at Kerberos 'history' shows that they
> have the same thing which is probably where it came from. However

most probably inspired by Kerberos, but

> kerberos seems to need it because their lifetime seems to be defined as
> 5 minute increments from the begin timestamp, while the end timestamp
> in Coda is self-sufficient, i.e. a UNIX timestamp in seconds since the
> epoch.

possibly not because of that.

A scenario - a customer who will need to fetch a bunch of data a certain
day a month later.

You do not want to give him a password (or account for that matter)
but instead provide him with a token usable only that day.
It limits his possibilities to do harm, and also his liability,
so both you and him are happy.

Then you can reuse some special account for such occations,
making sure the tokens' validity times do not overlap.

I can imagine (given my speculations about "streaming" from Coda
coming true in some form) booking payed-per-time viewing in advance
and storing the corresponding token in the customer "player" -
instead of making/proving your payment and fetching a token at the exact time.

(do not confuse that with DRM, any information a client has fetched may stay
in its disposition forever, still it may be important to get new access at
certain times, for new time-dependent information)

Those were artificial scenarios, but may be there are real life ones looking
for that feature?.. I think I'd like to add the lacking begin-time option to

"clog -method generate" ... :)

My 2c
--
Ivan