Dates vs. Deltas [was: An alternative to explicit revocation? ]

In message <9601030037.AA29004@acetes.pa.dec.com>, Jeffrey Mogul writes:
>
>   Date parsing: Just Say No!
>
>Actually, I spent part of the weekend mulling this over, and I
>think the use of absolute expiration dates (as opposed to "seconds 
>remaining") is a mistake.

(1) I disagree, and (2) that's not what I was talking about. I
was talking about the zillions of date formats: Tue, 02 Jan 1996 ...
as opposed to nice sortable ISO format: 19960102163724Z.

But you raise an interesting point.

>Consider the problem of dealing with clock skew.

I'd rather not. I'd rather

	(1) have as few mechanisms as possible depend on
	global synchronization (e.g. compare IMS dates
	for equality _only_, and never order)

	(2) in the few cases where we need global synchronization,
	just count on everybody having good clocks, and live
	with the resulting level of reliability.


>Think about how you would handle this case:
>
>	The origin server has a correct clock.  On Monday,
>	it generates a response which is cachable until Friday.

ew... I hate the term "cachable." I much prefer "fresh." But
anyway...


>	The first cache has a clock that is a day slow

If their clock is off by a day, then stale HTTP pages are
the least of their worries. They're Seriously Broken.
Trying to deal with their brokennes is just going to complicate
things to the point where the net reliability will suffer,
I predict.

>One have the caches rewrite the expiration dates, or include
>more mechanisms for clock-deskewing.  But it seems much simpler
>and safer to express expiration as a number of seconds remaining,
>which works as long as the inaccuracy in clock rates is reasonably
>small.

Exactly what do you mean by "works"? How exactly does it "work"?

With global clocks, the test for fressness is:

	Given t1, the fresh-until date given in the Cache: header of
	the response, and t2, the local current time,
	is t2 < t1?

I'd like to use a simple lexicographic test on ISO format dates,
though I suppose integral seconds will do. ISO dates are convenient
if, for example, you only want to be precise to the month:

	Cache: fresh-until=199605

What exactly is the test for freshness using deltas, and what are the
input parameters? Does the number of parameters increase with the
number of parties involved in an HTTP transaction?  I'm playing
devil's advocate (read: I'm too lazy to think it through myself.)

Consider a client, an origin server, and three caching proxies
in between. The server writes:

	Cache: max-age=3600

The first caching proxy sees that at 1pm, so it thinks the response is
fresh until 2pm (note the book-keeping above and beyond the headers
themselves). The second caching proxy requests this resource at
1:15. Does the first proxy re-write the Cache: header? Yuk.  What
about latency?

Dan

Received on Wednesday, 3 January 1996 06:26:48 UTC