[Top] [All Lists]

Re: comments on draft-dracinschi-opes-callout-requirements-00

2002-03-01 09:21:42


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.


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"


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'.


* Section 3.1.5 - Could this be expressed as a requirement that the callout
protocol be asynchronous?


* 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

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?