Mark,
thanks for the comments, remarks inline.
* Abstract - a cache isn't an intermediary, it's a local message store;
'proxy' or 'gateway' would be a better example.
What the abstract meant to say is that an 'OPES intermediary' can -
for example - be implemented on a cache. We can surely include 'proxy'
and 'gateway' as well.
* Section 2 - 'Web' is always capitalised.
Yup, this should be changed.
'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 callout protocol.
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 explore why
executing services that aren't colocated with the intermediary is necessary,
and what scenarios it's appropriate/not appropriate for.
Well, scalability might not be specific to a callout protocol (i.e.
there are many ways to improve scalability), but a callout mechanisms
is one way to improve scalability. For example, if you run ALL
processing intensive tasks on an in-path intermediary, this might soon
become a bottleneck when the number of user requests increases. If you
now have a callout mechanism, you can "outsource" those
processing-intensive tasks to remote callout servers to scale to an
increasd number of users.
However, I agree with you that we need to do a better job in
motivating this, and, in particular, we need to provide some guidance
explaining in which scenarios this is appropriate and in which not. I
had thought the "Scenarios Document" might be a good place to do that.
* Section 3.1 - Suggest removing 'request/response'; OPES isn't tied to a
particular message exchange pattern.
Agreed, and this is also mentioned in the last paragraph of Section
3.1.4 (although the current focus of OPES is on content-path protocols
the define a request/response 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.
Yup.
Also, you specify it as a URI, and then refer to it in the last sentence as
a URL.
Yup, should be fixed.
* Section 3.1.2 - "request/reply" -> "request/response"
Yup.
This section refers to encapsulating the message; what is the motivation for
encapsulating messages? There are a number of ways one can vector the
messages to the service (e.g., just re-routing the original protocol
message, using out-of-band messaging for signaling).
Agreed, encapsulation is one method, there are others. This should be
discussed and reflected in the documents. Somebody some opinion on that?
* Section 3.1.3 - Suggest removing 'command line'.
Agreed.
* Section 3.1.5 - Could this be expressed as a requirement that the callout
protocol be asynchronous?
Yes.
* Section 3.1.6 (and elsewhere) - it may be useful to refer to, and use the
terms defined in, RFC3117.
Yes, the document needs quite some "cleaning up" and alignment with
common terminology.
* Section 3.2.1 - 'Determining which requests are identical is outside of
the scope of a callout protocol'; how is caching accomplished, then? Some
means of indexing the cache is required.
Sure, but the mechanism to determine whether two (user) requests are
identical is a local implementation decision and has nothing to do
with the callout protocol itself. The callout protocol just needs to
provide the means to indicate cachability of a response.
* Section 3.2.2. - Could this be expressed in terms of connection
management?
I think so, might be a good way to do.
* Section 3.2.3 - I *think* this should read "An intermediary MAY keep a
local copy..." -> "An intermediary MAY be required to keep a local copy..."
Hm, we thought that the callout should always work, even if the OPES
intermediary does not have enough buffer available to keep a local
copy - simple seems to be more stable and robust. The callout server
can still ask the OPES intermediary to keep a local copy if possible,
but it should not assume the such local copy will always be made. Does
that make sense?
-Markus
-Markus