Joe Touch wrote on 11/29/99 3:53 pm:
>The architecture consists of three basic components:
>server, proxy, and client.
OK, but limited... what about gateways, transformation servers,
authentication services, etc.?
Also open to the proxy/origin confusion of the word "server".
>The conventional web architecture defines server-client interaction.
rfc 2616/2617 defines client-proxy, proxy-proxy, and proxy-origin
interaction. I'd think you'd want to characterize WREC by what it adds to
that, rather than to the HTTP 1.0 model.
>Clients connect to servers based on the URL of the request.
Clients connect to servers & proxies based on configured or discovered
autoconfiguration scripts.
>Network-level services are assumed to route requests from client to server.
>This (WREC) architecture addresses proxies, and their effect on that
architecture.
How about "...addresses inter-proxy application-level routing in order to
support more effective caching. "?
>In this new architecture, we need:
Why "new" rather than "extended"?
>- a way to include proxies in the routing of requests i.e., a way to route
requests through proxies
a more standard way? More effective? More consistent? More broadly
applicable?
>- a way to maintain the proxies e.g., to keep them consistent (do we need
anything else?)
I don't think it will be possible to go far without an analysis of static
vs. dynamic web data, customization and content negotiation, authentication
and authorization delegation.
Proxy-proxy communication usually consists of effectively stale data; is the
caching/ETag model in HTTP/1.1 good enough? And unless you address
hit-metering, copyright and related issues, your work may be moot.
>I'll propose secondary architectural components as follows:
>- proxy inclusion
> a way to include proxies in a conventional proxy-less deployment
A better way? Is this an architectural or protocol issue or a configuration/
discovery/ deployment issue?
The rest of your note characterizes the problem as first a routing problem
and then a database replication problem, but I don't see the connection
between the tuo.
>- request forwarding
> a way to direct a request towards an appropriate proxy, e.g., via policy,
observation of availability, etc. (i.e., like IP forwarding)
I assume you're going to investigate the current state of deployment here,
which is quite sophisticated.
>- request routing (like IP routing)
>- request route computation
>a way to generate appropriate routes according to some metric (i.e., like
IP route computation)
>- request route exchange
>a way to configure the routes of proxies, clients, and other network
elements (i.e., like IP route exchange)
>
>There is the issue of bootstrapping this configuration; ala BOOTP, DHCP -
i.e., how does one start route exchange with nothing configured a-priori?
>There are standard mechanisms:
>manual (set a single location) and well-known address (e.g., fixed port,
broadcast message).
(?? is it possible that responses will equivalently be forwarded? is there
utility to that? I.e., to force where things are cached? should the
architecture include that, even if not yet developed?)
There are products that do these things. The issue is whether it makes
sense to try to coordinate caches across trust boundaries, and how to do so.
>- cache consistency
>a way to unify the view of what is cached between sets of proxies
>- cache group discovery
>a way to determine the association of sets of caches
>
>- cache content exchange
>a way to see what is in the others' caches
>
>- cache unification
>a way to unify or update the content of a cache
>??
-- mailto:lmm@acm.org http://purl.org/NET/masinter
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST