W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Issue List: CACHEDATE

From: Franz J. Hauck <fjh@cs.vu.nl>
Date: Fri, 16 Feb 1996 09:12:40 +0100
Message-Id: <31243C78.6023@cs.vu.nl>
To: Shel Kaphan <sjk@amazon.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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.

--Franz
Received on Friday, 16 February 1996 00:15:26 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:45 EDT