Subject: RE: Taxonomy Term closure needed

From: LOVRIC Ivan CNET/DSE/CAE <[email-masked]>
Date: Mon, 6 Sep 1999 11:29:07 +0200

Here are my definitions; in fact, I consider that caches and mirrors aim at
reaching the same goals...

Cache :
An intermediary equipment or program between the client and the server
aiming at reducing network bandwidth and improving the quality of service
from the user point of view by storing web objects closer to the end-user. 
The user requests not satisfied by the cache MUST be forwarded to the server
or upper level cache in a cache mesh.
The cache MUST freshen the stored data according to server information.
It SHOULD contain its own internal algorithms to freshen the data if no
particular server information is given.

Mirror :
A copy of a Web server aiming at reducing network bandwidth and improving
the quality of service from the user point of view by storing all or part of
the content of the origin server closer to the end-user. 
The user requests not satisfied by the mirror MUST result in the sending of
the appropriate HTTP error code.
A complemental system, either installed on the origin server or on the
mirror, SHOULD freshen the copied data when necessary.  

> From [email-masked] Fri Aug 27 15:02 EDT 1999
> 
> Hello WREC'ers.
> 
> We've had a great deal of discussion these past two weeks concerning
caching and replication.  I propose that we work on getting our core
definitions completed now.  From these, we can move onto finishing up the
taxonomic implementation and deployments based  upon these definitions.
> 
> First I suggest we break the defintions up into a small base set that are
the most fundamental.  From the base set come the first and second
derivatives that form all the core terms necessary to describe repliacation
and caching implementations.   Included are a starting point for discussion.

> 
> As we move from the terminology to the taxonimc discussions, please keep
in mind the following:
> 
> Implementation and deployment that is broadly (or hopelessly depended
upon) in the Internet today belongs in the taxonomy draft.
> 
> Current research and needed research belongs in the research draft. (Joe
Touch Editor)
> 
> Known problems and implementation shortcomings of current
implementation/deployment belong in the known issues draft (John Dilley
Editor)
> 
> Here are the core terms as they stand today.  Feel free to add/subtract
the core set.
> 
> 
> Base Terms:
> Client 
>   Exactly adopted from RFC2616. Editors View - Consensus 
>   "A program that establishes connections for the purpose of sending
requests." 
> 
> Proxy
>  A derived definition for RFC2616. Editors View - Consensus
>  Editors Note: The term has been heavily debated within the WG.  Consensus
>  is to override the definition in RFC2616.
>  "An intermediary system which acts as both a server and a
>   client for the purpose of making requests on behalf of
>   other clients. Requests are serviced internally or by
>   passing them on, with possible translation, to other
>   servers. A proxy MUST implement both the client and server
>   requirements of this specification. A "transparent proxy"
>   is a proxy that does not modify the request or response
>   beyond what is required for proxy authentication and
>   identification. A "non-transparent proxy" is a proxy that
>   modifies the request or response in order to provide some
>   added service to the user agent, such as group annotation
>   services, media type transformation, protocol reduction,
>   or anonymity filtering. Except where either transparent or
>   non-transparent behavior is explicitly stated, the HTTP
>   proxy requirements apply to both types of proxies.
> 
>       Note:  The term "transparent proxy" given in [6] has different
>              meaning within the Web caching community.  Further
>              unspecified references in this document (including the
>              following paragraph) are to the Web caching community
>              definition, which is given later.
> 
>              The condition requiring implementation of both server and
>              client requirements of HTTP/1.1 is only appropriate for a
>              non-transparent proxy."
> 
> Replication
>   Not defined.  Editors View - Open Disucssion
>   Editors Note:  Amazingly enough, we can't find any definition for
replication
>   in any on-line RFC or draft.  Is it really intuitive.  We think not,
since 
>   there so much debate in the working group surrounding what is
replication.
> 
> Server
>   Exactly adopted from RFC2616. Editors View - Consensus
>   "An application program that accepts connections in order to
>    service requests by sending back responses. Any given program may
>    be capable of being both a client and a server; our use of these
>    terms refers only to the role being performed by the program for a
>    particular connection, rather than to the program's capabilities
>    in general. Likewise, any server may act as an origin server,
>    proxy, gateway, or tunnel, switching behavior based on the nature
>    of each request."
> 
> Surrogate
>   Not defined  Editors View - Open Discussion
>   Editors-Note: A fundemental concept to the web.  Surrogates act in
behalf of 
>   content publishers.  Examples of surrogates within the taxonomy are:
Mirrors
>   and accelerators.
> 
> First Derivative Terms: (Build upon base terms)
> Cache
>   A derived definition for RFC2616. Editors View - Open Disuccsion
>   Editor-Notes: The most controversial term in the taxonomy. Is it
dervived 
>   from replication or is it a base term? 3 variants proposed need 
>   rationalization.  There has been so many comments on each of the variant
>   definitions, we would like the individuals to supply thier current
concise
>   definitions for dicussion.
>   Current taxonomy definition
>   "A program's local store of response messages and the
>    subsystem that controls its message storage, retrieval, and
>    deletion. A cache stores cacheable responses in order to
>    reduce the response time, server load and network
>    bandwidth consumption on future, equivalent requests. Any
>    client or server may include a cache, though a cache
>    cannot be used by a server while it is acting as a tunnel."
> 
>    Joe Touch's definition
>      Joe can you supply your current definition?
> 
>    Wojtek Sylwestrzak's definition
>      Wojtek can you supply your current definition?
> 
>    Misha Rabinovich's definition
>       Misha can you supply your current definition?
> 
>    Ivan Lovric's definition
>       Ivan can you supply your current definition?
> 
> 
> Mirror
>   Not defined. Editors View - Nees Discussion
>   Editors-Note: An attempt at taxonomy has been made.  It is clear
>   from discussion that a definition is in order.  The taxonomic variants
>   can then be defined from it.
> 
> Origin Server
>   Exactly adopted from RFC2616. Editors View - Consensus
>   "The server on which a given resource resides or is to be created."
> 
> Reverse Proxy
>   A new defintion.  Editors View - Open Discussion
>   Editors-Note:  Differentiation from proxy is needed.
>   "An intermediary system which acts as both a server and a
>   client for the purpose of serving requests on behalf of
>   origin servers. Requests are serviced internally or by
>   passing them on to the origin server they are representing.
>   A reverse proxy must interpret and, if necessary, rewrite a
>   request message before forwarding it. Reverse proxies are
>   often used as server-side portals through network firewalls
>   and as helper applications for off loading requests from
>   origin servers."
> 
> Second Derivative Terms: (Build upon first derivative terms)
> Caching Proxy
>   A new defintion.  Editors View - Consensus
>   "A proxy with a cache, acting as server to clients, and
>    a client to servers"
> 
> Caching Reverse Proxy (Accelerator)
>   Not Defined.  Editors View - Needs Discussion
>   Editors-Note: Do we need it?  Suggested definition
>   "A reverse proxy with a cache, acting as server to clients, and
>    a client to servers"
> 
> Replica Origin Server
>   New definition. Editors View - Open Disussion
>   Editors-Note:  In light of the recent disuccsion, the authoritative
>   attribute is quiestionable.
>   "origin server storing a persistent replica of a data set
>    stored at the authoritative reference"
> 
> Surrogate Cache
>   Not Defined.  Editors View - Needs Discussion
>   Editors-Node:  Do we need it, or is it a role that is provided by
proxies,
>   reverse proxies and replica origin servers?
> 
> - Gary
> 
> 
>

---

From: <[email-masked]>
Date: Mon, 6 Sep 1999 12:51:00 +0200

A reverse cache is not by definition "controlled by a content provider".

In most cases this will be the case. But it does not need to be. Everyone can set up an accelerator everywhere. Just as an example, we usually set up an accelerator (reverse cache) for www.novell.com in technical trainings. Or, yet another example, internally I've setup accelerators for various popular sites on a test server. By using a reverse cache internally Ican improve performance dramatically. All I need to do is "hack" the dns entry, so with my browser I access the reverse cache instead of the origin server on the internet (or I simply access the reverse cache by ip address). I'm doing it for example with my own website, which is hosted at an outside internet service provider, who doesn't even know that the site is reverse cached.

The point is, a reverse cache MAY (and will most likely be), but definitely MUST NOT be under the same administrative control than the origin server that it accelerates. I would define a "reverse cache" as a device that acts on behalf of the origin server. The dns record for the server is modified so that it points to the reverse cache instead of the origin server. The reverse cache will fill the cache from the origin server for any requests coming in. It is using the same algorithms than the forward cache to control object freshness.

Frank 

>>> michael rabinovich <[email-masked]> 05.09.99 4.11 >>>
Here are my definition drafts.  Apologies if wording is sloppy in some
places - this can be corrected at a later time.

Misha Rabinovich.

A cache - a device on the request path from a client to a server
^^^^^^^
such that (1) requests arrive to this device regardless of its state;
and (2) it can store some responses and use them to 
satisfy future requests for the same resources.  

A typical property of a cache, which distinguishes it from a 
mirror or replica, is that it sees both hit and missed requests.
Examples: browser main memory and disk cache; a proxy cache, 
an origin server main memory cache.

Note: there is a distinction between a cache and its storage.
One might say that the browser disk cache is not a cache according to 
the above definition since missed requests do not touch disk.  However,
this cache includes also the code for checking if the requested 
object is stored in the disk cache.  Thus, missed requests do get
processed by the disk cache.

A forward cache is the cache that is outside the control of any
^^^^^^^^^^^^^^^
content provider.  It is the responsibility of the client or 
network operators to deliver requests to the forward cache.
Origin servers are typically oblivious to the existence of 
forward caches - a forward cache looks just like another client
to them, with the exception of a special HTTP request header that 
some forward caches insert.

A reverse cache is the cache that is controlled by a content provider.
^^^^^^^^^^^^^^^
It is the responsibility of the content provider to deliver requests
to the reverse cache.  Clients are oblivious to the existence of 
reverse caches.  

A replica of a Web object is a copy of the object on a
^^^^^^^^^^^^^^^^^^^^^^^^^
server that is not on the request path from a client to 
the server where the primary object copy resides.  

A mirror is a server that hosts replicas of Web objects.
^^^^^^^
While caches process requests as they fly through, the delivery of 
requests to mirrors is done based on the knowledge by the
delivery mechanism that particular mirrors have particular replicas of
particular objects.  Thus, mirrors normally do not see missed requests
unless the delivery mechanism uses imperfect or obsolete replica
location information. 

There is a variety of mechanisms for delivering requests to mirrors.
Examples include user-based (when a replica receives a separate URL), 
DNS-based (where mirrors store replicas of entire sites and the site 
DNS server rotates among the mirrors when answering DNS queries for the
site), HTTP-based (when the primary server redirects requests to 
a mirror).

> We've had a great deal of discussion these past two weeks concerning caching and replication.  I propose that we work on getting our core definitions completed now.  From these, we can move onto finishing up the taxonomic implementation and deployments based  upon these definitions.
> 
> First I suggest we break the defintions up into a small base set that are the most fundamental.  From the base set come the first and second derivatives that form all the core terms necessary to describe repliacation and caching implementations.   Included are a starting point for discussion. 
> 
> As we move from the terminology to the taxonimc discussions, please keep in mind the following:
> 
> Implementation and deployment that is broadly (or hopelessly depended upon) in the Internet today belongs in the taxonomy draft.
> 
> Current research and needed research belongs in the research draft. (Joe Touch Editor)
> 
> Known problems and implementation shortcomings of current implementation/deployment belong in the known issues draft (John Dilley Editor)
> 
> Here are the core terms as they stand today.  Feel free to add/subtract the core set.
> 
> 
> Base Terms:
> Client 
>   "A program that establishes connections for the purpose of sending requests." 
> 
> Proxy
>   Editors Note:  Amazingly enough, we can't find any definition for replication
>   in any on-line RFC or draft.  Is it really intuitive.  We think not, since 
>   there so much debate in the working group surrounding what is replication.
> 
> Server
>   Editors-Note: A fundemental concept to the web.  Surrogates act in behalf of 
>   content publishers.  Examples of surrogates within the taxonomy are: Mirrors
>   and accelerators.
> 
>   Editor-Notes: The most controversial term in the taxonomy. Is it dervived 
>   definitions, we would like the individuals to supply thier current concise
>   Editors-Node:  Do we need it, or is it a role that is provided by proxies,

---

From: michael rabinovich <[email-masked]>
Date: Tue, 7 Sep 1999 09:17:51 -0400 (EDT)

> From [email-masked] Mon Sep  6 11:55 EDT 1999
> 
> Misha, Gary,
> 
> At 10:11 PM 04/09/99 -0400, michael rabinovich wrote:
> I think this is the definition of a proxy or a caching proxy, not a 
> "cache". I believe the definition of the broad term "cache" was deemed too 
> controversial / difficult at one of our previous meetings and I thought 
> that we had therefore agreed, in the context of the taxonomy document, to 
> define only the term "caching proxy" and derivatives thereof?
> 
> John
> ---------------------------------------------------------------
> Network Appliance           Direct / Voicemail: +31 654 308 275
> Kruisweg 799                               Fax: +31 23 567 9699
> NL-2132 NG Hoofddorp               Main Office: +31 23 567 9600
> ---------------------------------------------------------------
> 
> 

Sure, that's fine.  I indeed first thought of it as  a definition of
a proxy but then thought that it generalizes to other caches.  

Misha

---

From: michael rabinovich <[email-masked]>
Date: Tue, 7 Sep 1999 09:47:11 -0400 (EDT)

> From [email-masked] Mon Sep  6 06:52 EDT 1999
> 

I think we are talking about the same thing, and the misunderstanding
confirms that my wording was sloppy.  I did not mean necessarily
administrative control in a narrow sense that the origin server and
the reverse proxy share the same ISP or corporate network.  The main 
thing is that
clients or client ISPs are oblivious to the reverses proxy: it is the
responsilibity of the content provider to deliver requests to it.
Also, since content provider MUST
be aware of the reverse proxy, it can implement all sorts of things
like strong cache consistency, usage reporting, etc.  In other words, 
it can have as much *control* over the reverse proxy as it chooses.   
The fact that
the reverse proxy may reside in a different ISP does not change the
fact that the content provider has control over it.

Your examples fall right into this.  If you agree with the meat of it,
we can work together on the exact wording.

Your wording suggestion that a reverse proxy acts "on behalf of the
content server" looks too vague to me.  I'd say that the forward
proxy (esp. the transparent one) acts on behalf of the end-server as
well when sergving the object for the cache (and impersonating the 
end-server).   

Also, putting into the definition a particular mechanism (DNS-based)
for delivering requests to the reverse proxy is too narrow.  
For example, we here at AT&T were seriously considering using WCCP at
the access routers to transparently divert requests from our users to
reverse proxies.  (We currently decided in favor of DNS solution, 
but it does not change my point.) 

> places - this can be corrected at a later time.  Your examples 
> 
> Misha Rabinovich.

---

From: "Gary Tomlinson" <[email-masked]>
Date: Tue, 07 Sep 1999 16:54:55 -0600

>>> michael rabinovich <[email-masked]> 09/07/99 07:47AM >>>

>well when sergving the object for the cache (and impersonating the 

I'll argue the agency role of a reverse proxy isn't germane to the definition of what a reverse proxy is.  The  agency role is determined by the network authority hosting it and the policy assigned by that authority.  

A classic case is one of surrogacy, in which the reverse proxy (accelerator) is acting in behalf of the content provider, either in the content providers network, or as a delegate in a content distributors network.  This begs for the completion of the term SURROGATE.

>but it does not change my point.) 

And here is another case, in which the reverse proxy is under the authority of a consumer network acting in behalf of the consumers.

It looks like we are converging on a definition for reverse proxy.  Lets try and wrap this up.  Will one of you, either Misha or Frank submit a edited definition for the group to review?

We'll need to tackle the definition for SURROGATE next.  With it in place, we can then document the roles reverse proxies are commonly delpoyed in.  

The following was listed as a surrogate advantage in the BOF chaired by Ted Hardie at the 4th Web Caching Workshop.  Does anyone like this as a starting point for the definition of a surrogate?
"Surrogates work on behalf of a content provider, so a business relationship exists for traffic analysis, copyright, and authentication"

>> A reverse cache is the cache that is controlled by a content provider.

Gary

---

From: michael rabinovich <[email-masked]>
Date: Fri, 10 Sep 1999 09:40:42 -0400 (EDT)

Looks good.  

Misha

> From [email-masked] Thu Sep  9 19:50 EDT 1999
> 
> Here's a suggestion for definitions of both forward cache
> and reverse cache:
> 
> A FORWARD CACHE is a cache operating on behalf of a
> user agent. It is typically outside the control of any
> A REVERSE CACHE is the cache operating on behalf of a
> origin server. It is typically controlled by a content provider.
> reverse caches - a reverse cache looks just like the origin server
> to them, with the exception of a special HTTP response header
> that some reverse caches insert.
> 
> Frank
> 
> 
> >>> Gary Tomlinson 08.09.99 0.54 >>>
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Sep 1999 11:31:01 -0700 (PDT)

> From [email-masked]  Fri Sep 10 08:33:13 1999
> Delivery-Date: Fri, 10 Sep 1999 08:33:13 -0700
> Return-Path: [email-masked]
> From: Ian Cooper <[email-masked]>
> To: Markus Buchhorn <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Taxonomy Term closure needed
> Date: Fri, 10 Sep 1999 12:35:38 +0100
> List-Unsubscribe: <mailto:[email-masked]?Subject=unsubscribe>
> 
> On Fri, 10 Sep 1999 12:23:38 +1000, Markus Buchhorn wrote:
> 
> >
> >At 17:40 9/09/99 -0700, Joe Touch wrote:
> >>A cache is a system which stores temporary copies of response messages, 
> >>and replays them when prompted. 
> >
> > .. of successful response messages..? or somesuch - not much point caching
> >error results.
> 
> Well, there might be. It would depend on what type of error.
> 
> > And there's also the question of permission/time - being
> >allowed to cache a response (Pragma: No-Cache; Expires: Now).
> 
> Doesn't that come under the catch-all term "cacheable"?
> 
> >>> Reverse Proxy
> >>
> >>This is the one I find odd. There is nothing reverse about it.
> >>It's just a proxy cache co-located (or nearly-colocated) with the server.
> >>
> >>Why not just call it a "server-side, or server-proximal" cache?
> >
> >Agreed. A 'server-side' cache is designed to take load off the origin
> >server, but does nothing for the network or performance as seen by the
> >end-user.
> 
> Not necessarily.  By taking load off the origin server you may well
> enhance the performance as seen by the end-user.  I know what you're
> saying though.
> 

> >>And which intercepts requests that have associated responses
> >>in its cache.
> >
> >No - it "intercepts" _all_ requests, but if it can't service them will
> >forward them on on behalf of the client, and store the response while also
> >passing it on. And depending on the application it may not be an
> >"intercept" (which sounds like a hijack) it may be a deliberate direct
> >request ("have you got this? If not please get it for me").
> 
> "Intercepts" seems to hint at the wrong thing (as you say).
> "terminates" is probably too strong, although the request stream _is_
> being terminated for cached content.

Why do we have a problem with intercepts?
When that's what you want, it's a good thing. (intercepting bugs)
When it isn't, it's hijacking.

Sounds like exactly the right thing, in this case.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Sep 1999 11:29:44 -0700 (PDT)

> From: Markus Buchhorn <[email-masked]>

Sure there is. If the error is from the server, not a meta-error
about not being able to reach it. I.e., if the content isn't there,
why keep going back?

> allowed to cache a response (Pragma: No-Cache; Expires: Now).

That is a complication that isn't useful in the definition.
There's nothing about a cache that says that the cached result
is useful - it's just replayed. 

> server, but does nothing for the network or performance as seen by the

I can affect the performance seen by the end user, if
that performance is limited by the server bottleneck.
If that server-side cache pushes, uses multicast, etc,
it can also reduce network load.

> A 'network' cache is designed to speed up responses for the
> end-user and reduce network load.

s/and/or - it can be either.

> The term 'Reverse Proxy' to me sounds like a pre-populated caching proxy...
> 
> passing it on.

Define "intercept" - I was intending it to mean what you do with
messages you don't forward. You mean something different. Maybe
'responds to' is better than 'intercepts'?

> And depending on the application it may not be an

In that role the caching proxy is acting like a server (something
that is explicitly addressed). While anything we can create 
can have any combination of these capabilities, the definitions
focus on the 'pure' forms of each capability, no?

> How is this different to a mirror ? 

I think a mirror is about the entire server; a replica is about an object.
I.e., 'servers (or databases, or data sets) are mirrored;
'individual objects are replicated'.??

Joe

---

From: <[email-masked]>
Date: 12 Sep 1999 11:57:00 +0200

Hope this makes it clear what the difference is between forward and reverse proxy:

Forward Proxy:
A forward proxy listens on a proxy port to receive incoming requests from a user agent. Typically this is on port 8080 or 3128 depending on the vendor. The user agent (typically a browser) is aware talking to a proxy instead the origin server. The forward proxy uses a build-in user agent to request the object from the origin server (or another forward proxy if configured, see ICP). The forward proxy delivers it back to the user agent.

Reverse Proxy:
Different picture here. The user agent sends the request to the (what he believes) origin server. In fact the request comes in to the reverse proxy (you achieve this by modifying the dns record of the origin server so that it resolves to the reverse proxy instead of the origin server), which has a listener on port 80 (like an origin server). The reverse proxy will then use a build-in user agent to request the object from the (real) origin server. It will then send the object back to the requesting user agent.

Now you just need to add caching to these scenarios. Of course, a caching proxy will first evaluate all incoming requests to see whether the object is already in cache. It will also use http response headers if available (or defaults or other heuristics) to determine the freshness of objects. Typically the algorithms used are the same for forward and reverse caching.

Summary: A forward cache is acting as a user agent to an origin server, while a reverse cache is acting as a web server to a user agent.

Frank

>>> Joe Touch <[email-masked]> 11.09.99 18.35 >>>

Henrik Nordstrom wrote:
> 
> Henrik Nordstrom wrote:
> 
> > The most important aspect for a reverse proxy is "on behalf", which
> > implies that is is set up by and under the administrative control of the
> > content provider.
> 
> Sorry, I was a bit uncareful in the wording there. The administrative
> control is usually that of the network managers of the origin server,
> which does not neccesary imply that it is under the control of the
> content provider. It should however be included in the a service
> agreement between the content provider and management of the origin
> server, network connection or reverse proxy.

Whether a term is in wide use or not does not necessarily
require its use in the core of the taxonomy document. 

We can easily define an appropriate term and define 'reverse proxy'
in terms thereof.

What concerns me about the above is the use of "intent"
in a definition. There must be some objective metric.
Management control, service agreeements, etc. aren't
useful objective metrics.

Is there any definition of a reverse proxy that is objective?
(and can distinguish it completely from a non-reverse proxy cache?)

Joe

---

From: Markus Buchhorn <[email-masked]>
Date: Wed, 15 Sep 1999 14:26:22 +1000

>about not being able to reach it. I.e., if the content isn't there,

Because it might be there later? I don't know what the caching rules are
for error-information - is there a standard? Just because a page isn't
there now should not mean the cache keeps on just returning *that*
information - it should
(always/frequently/occassionally/when-prompted/whatever) check if the error
status has gone away.

At this stage I can really only see this as an issue on caching of
(semi-)dynamic pages, so perhaps that is a different kettle of worms anyway
:-)

>it can also reduce network load.

Yeah, alright. Although a cache that pushes content doesn't seem like a
cache to me - but perhaps that's just my gut feeling. Populating caches
downwards in a hierarchy with e.g. multicast seems to be part of a
different scheme of things somehow...

>s/and/or - it can be either.

Of course. (And I didn't want to introduce another term, it was just in
contrast to 'server-side' :-) ).

>'responds to' is better than 'intercepts'?

Yes.. 'Intercept' in almost all uses I can think of has a connotation of
something unexpected, it changes the flow of events, e.g. in sports, where
something is going one way and is suddenly taken another way. However, if
caches were truly transparent to the end-user (i.e. they are like a
"feature of the network") then intercept is probably right. But I think
'responds to' is a good choice. 

Imagine if one day we had true resource-discovery where you did a multicast
HTTP GET for some URI, then it would be the first 'box' of whatever type
that (positively) "responded to" your request that becomes your
data-provider. Yet no single box can "intercept" your request (in my use of
'intercept'). "Responding (to)" has a broader, safer, meaning perhaps...?

> While anything we can create 

For sure. I totally support the brief summaries (client for server, server
for clients) and think that is all that is needed. I was just responding to
somebody else's comment about interception being added in. I don't think it
is needed in (that part of) the definition. Elsewhere maybe.

>'individual objects are replicated'.??

Is a database an individual object or a set of objects ? Is a shareware
site? I'd vote for mirror=replica, forget about the size or number of
objects (or fraction of server) involved. Lets reduce the size of the
dictionary :-)

Cheers,
	Markus

Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2 62798810
email: [email-masked], snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602
Australian National University, Canberra 0200, Australia |Mobile: 0417 281429