- From: Koen Holtman <koen@win.tue.nl>
- Date: Tue, 17 Jun 1997 23:04:16 +0200 (MET DST)
- To: Scott Lawrence <lawrence@agranat.com>
- Cc: hardie@thornhill.arc.nasa.gov, http-wg@cuckoo.hpl.hp.com
Scott Lawrence: > > > As one of 'those contributing to that discussion', I'd like to start > by thanking you, Ted; very well done. Aside from the couple of > comments below, I believe this sums up the requirements nicely. Me too. Thanks for writing this Ted. I like the requirements: I think they sum up the basic things nicely without being slanted to any particular solution. Some comments on sections 3 and 5.2.1: Section 3 start of last paragraph: |Content negotiation based on User-agent strings also creates |difficulties for caching proxies, The same problems also exist for negotiation based on Accept headers. Section 5.2.1 end of first paragraph: | [TCN] describes a standard method for delineating |the axes along which a resource varies and a set of methods by which |caches can participate in the negotiation process. I assume that you mean that remote variant selection algorithms are in this set of methods. In that case, it would be better to write `a set of methods by which origin servers and proxy caches can optimize the negotiation process.' Section 5.2.1 last sentence: |Many times, however, this process [elective negotiation] requires a |user to actively select among the resources provided, which reduces |perceived efficiency and increases perceived latency. I am not sure what you mean by `many times'. Do you mean `for many methods of elective negotiation'? You would always select by hand with the `click here for...' negotiation method you describe first. But for TCN, selection is automatic. A list of variants for the user to select would only appear if the user asks for it, or in an error message if the user agent detects that every variant is completely unacceptable according to its configuration database. Koen.
Received on Tuesday, 17 June 1997 14:06:10 UTC