- 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