Re: Issue List: CACHEDATE

Shel Kaphan wrote:

> Franz J. Hauck writes:
>  >
>  > > I didn't think I was suggesting invalidating existing implementations
>  > > (they can take care of that for themselves!), [...]
>  >
>  > The proposal on the issue list does exactly this.
>  >
>  > > The kind of case that seems likely to break is a client with a clock
>  > > that's relatively out of whack (say, 5 minutes off, like the Mac I'm
>  > > writing this on), an application that depends for correctness on
>  > > clients always validating documents, and client software that
>  > > (for some reason) is doing unspeakable things to construct I-M-S dates
>  > > based on its own clock, thereby causing the application to appear to
>  > > be broken.
>  >
>  > I think, I have shown that this is *not* true.
> You've shown that by being sufficiently conservative with the I-M-S date
> you can avoid some problems in the compound document case you mentioned.

I have shown that there is no need to change the spec about it. Except that we may
want to add a warning to section 10.23 for clients to be aware that I-M-S times are
interpreted with the server's local understanding of time. This is rather obvious
--every CS student knows that there are no completely synchronized clocks in
distributed systems--, but we may want to add it anyway.

> Let's just think about one client and one server. [...]

If you read my previous mail carefully you know I already mentioned exactly this
problem. For me, this thread is closed.


Received on Friday, 16 February 1996 00:15:26 UTC