From: Mark Nottingham [mailto:mnot(_at_)mnot(_dot_)net]
Sent: Thursday, February 28, 2002 10:05 PM
To: OPES list
Subject: comments on draft-dracinschi-opes-callout-requirements-00
* Abstract - a cache isn't an intermediary, it's a local message store;
'proxy' or 'gateway' would be a better example.
* Section 2 - 'Web' is always capitalised.
'Remote callout servers are usually employed in an OPES
framework to either
offload the OPES intermediary for better scalability or to provide
value-added services not available oneither the origin server
or the OPES
intermediary'; scalability isn't specific to the use of a
Overall, though, this is the only motivation I can find for
using a callout
protocol in the current OPES documents; it would be useful to
executing services that aren't colocated with the intermediary
and what scenarios it's appropriate/not appropriate for.
I agree with expanding on the reasons, altough some of them are already laid
of in front of us...
IMO you have an external callout server for the some of the same reason we
have caches in the first places: offload processing, reliability issues,
technologic specialization issues, etc...
In the technologic specialization front, for instance, if you want Virus
Scanning you will need to process periodic updates, port somebody's else
code in to your box, etc, etc. Are you going to put this on the OPES box per
se or let somebody that knows how to do it best take care of that for you?
You can extend this to a lot of other services: content adaptation,
geographic services, Content Filtering, and so forth.
* Section 3.1 - Suggest removing 'request/response'; OPES
isn't tied to a
particular message exchange pattern.
* Section 3.1.1 - 'Such a URI MUST contain the complete
hostname and the
path identifying the service requested'; I think you mean to
say that it
should be an absolute URI, as opposed to a URI-reference.
Also, you specify it as a URI, and then refer to it in the
last sentence as