(Illustration by Gaich Muramatsu)
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 -- IvanReceived on 2005-05-27 16:05:10