- From: Scott Lawrence <lawrence@agranat.com>
- Date: Thu, 18 Sep 1997 12:25:04 -0400
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>>>>> "LM" == Larry Masinter <masinter@parc.xerox.com> writes: LM> I would like to resolve a long-standing controversy in the HTTP LM> working group, by trying to assess the group consensus. LM> draft-fielding-http-age-00.txt LM> Roy Fielding, "Age Header Field in HTTP/1.1" LM> draft-mogul-http-age-00.txt LM> Jeff Mogul, "Generation of the Age header field in HTTP/1.1" I prefer the spec changes suggested by draft-fielding-http-age-00; admittedly they leave open some problems in the presence of badly unsyncronized clocks, but I think that the resulting specification is simpler to understand and implement correctly. Jeff has done a good job documenting just how bad the current situation with respect to clocks on the net is; I think that this suggests a few things: - Server and proxy vendors should (as Jim Gettys I believe it was, recently suggested) emphasize the importance of syncronizing clocks in thier documentation. - Clients, and possibly proxies, should include some mechanisms for providing users the ability to detect unsyncronized clocks either in the local system or in an upstream proxy. Neither of the above need to be in the protocol specification, I hasten to add. It seems to me that the main problems will be experienced by users within large intranets who must use proxies the users do not control and cannot bypass. If these proxies have unsyncronized clocks the users will experience a variety of cache-related problems. I don't think that the protocol or the rules followed by conforming implementations should be more complex in an attempt to work around these situations - instead, we should just ensure that there is sufficient information available within the protocol for a reasonably knowlegable user to detect the problem and determine where the time skew is occuring. I think that we've done that. -- Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com> Agranat Systems, Inc. Engineering http://www.agranat.com/
Received on Thursday, 18 September 1997 09:28:07 UTC