- From: Franz J. Hauck <fjh@cs.vu.nl>
- Date: Fri, 16 Feb 1996 09:12:40 +0100
- 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 UTC