W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Age calculation in HTTP: two Internet Drafts

From: Scott Lawrence <lawrence@agranat.com>
Date: Thu, 18 Sep 1997 12:25:04 -0400
Message-Id: <199709181625.MAA25509@devnix.agranat.com>
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 EDT

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