I appreciate all of the feedback I've gotten so far. Admittedly,
it wasn't a particularly well-articulated document. Here's the
points I was trying to pose as the goals of this proto-WG:
- There are clients. There are origin servers. There may exist
structure between clients and origin servers. Clients shouldn't
be manually configured to use this intermediate structure,
otherwise, things like packet hijacking and request hijacking
become the norm.
- Packet and request hijacking is A Really Evil Thing. So, one goal
is the design of protocol and mechanisms for getting clients to
discover this additional structure and use it. It can be as simple
as discovering an enterprise's egress proxy to discovering Keith's
"oracle".
- There are a lot of caching systems out there, the dominant one
appears to be Squid (and Harvest). There will be others as well
(successful PhD research notwithstanding). What kind of metadata
could or should these caching systems exchange with each other?
Do we even want caching structures to interoperate with each other?
As a personal note, I'd really like to see the Adaptive Web Caching
thesis work I'm doing become a useful caching system. But AWC will
need to interop with Squid/Harvest at some point to extend the size
of the global cache. And there's no reason why Keith's idea of a
replication and mirror oracle can't be useful to a Squid root server.
- Structure requires some kind of architecture and requirements doc to
describe the various entities and their interactions.
As Keith pointed out, "proxy" has some semantic context which is
too restrictive. This structure encompasses mirrors, caches, proxies,
tunnels, gateways, etc. RFC 2068 simply calls it 'servers' (1.3,
Terminology). We need terminology...
- One thing I tried to stay away from is the copyright issue. As Ingrid
Melve pointed out to me in a private e-mail, there is a per-copy charge
in the fine country of Norway for xeroxing documents. However, we might
incorporate some language about this in a security scenarios document.
I don't think we want the scope of wrec (for lack of a better name) to
have too large a scope. If we can at least come up with a few approaches
and possible standards-track RFC for client<>"structure" autodiscovery
I think we'd be able to declare the WG a success on that point alone.
-scooter
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:25 MST