RE: draft-ietf-opes-protocol-reqs-01

[<bindignavile.srinivas@xxxxxxxxx>]

Hi,
I forgot to CC the list in my response! Here it is.

Thanks,
-Srinivas

-----Original Message-----
From: Srinivas Bindignavile (NRC/Boston) 
Sent: Wednesday, June 19, 2002 2:41 PM
To: 'ext Andre Beck'
Subject: RE: draft-ietf-opes-protocol-reqs-01


Hi Andre,
Thanks for your responses to my comments!

> Hi Srinivas,
> 
> Thanks for your comments.
> 
> bindignavile.srinivas@xxxxxxxxx wrote:
>   >> A callout transaction is defined as a message exchange between an
>   >> OPES processor and a callout server consisting of a 
> callout request
>   >>  and a callout response.  Both, the callout request as 
> well as the
>   >> callout response, MAY each consist of one or more protocol
>   >> messages, i.e.  a series of protocol messages.
>   >
>   > What did you mean when you referred to one or more "protocol"
>   > messages? Are you implying that multiple "OCP" messages can be
>   > packaged in each request or response? What is the 
> justification for
>   > possibly packaging multiple protocol messages in a single callout
>   > request or response? Except if you feel that this might 
> cause a great
>   > increase in overhead! If not, why not restrict each request and
>   > response to have only one protocol message (as is usually done in
>   > other request-response protocols).
> 
> Section 3.13 of the draft talks about the need for application message
> segmentation, i.e. an OPES processor may have to forward an 
> application
> message to a callout server in a series of fragments. If this is the
> case, then the OCP may choose to encapsulate application message
> fragments into separate OCP messages (which would all be part of the
> same OCP request). The same applies to OCP responses. So I don't think
> we should restrict each OCP request and response to only one 
> OCP message.

I see your point here! However, I think that you might want to reword this statement to indicate that, if the original application message is not too large (meaning not segmented), then each application message SHOULD be sent in a separate OCP message rather than sending multiple application messages in the same OCP message (possibly to reduce overhead).
 
>   > Why do you call this termination of the callout service 
> "premature"?
>   > Isnt the fact that the content analysis task, for example, has
>   > outputted a result re. what the content is the expected 
> result of the
>   > callout task and the normal completion of the same? So, I dont see
>   > why the example you have referred to is a case of premature
>   > termination of the callout transaction. Please clarify.
> 
> I see your point, but we did not mean to imply that a "premature
> termination" represents an error condition of any kind. It's simply
> something that occurs when an OPES processor terminates a callout
> transaction before the completion of a callout request. This usually
> happens when an OPES service terminates before the entire OCP request
> was sent. As you pointed out, this may be the normal operation of the
> OPES service. If the term "premature termination" is confusing, then
> maybe we should call it something else. Any suggestions?

Could we call it "service completion" instead? After all, for the example of Content Analysis, the successful determination of the content type (of the data stream) does represent the completion of the required service.

Thanks,
-Srinivas