Subject: RE: NO messages

From: "Martin Stecher" <[email-masked]>
Date: Mon, 30 Jun 2003 22:44:09 +0200

> 	I feel like the current design is too rigid. You are saying
> that it is common for one callout server to support multiple HTTP
> adaptations services. And different adaptation services require
> different messages or message parts to be exchanged via OCP. Our
> current design ties message parts that can be exchanged to one of the
> two HTTP profiles. Thus, with the current scheme the only way to
> support multiple services that require different parts is to have at
> least one OCP connection for each service.

I had no problem if distinct connections per service worked.
But if at the beginning of a connection a NO message offers alternatives, the callout server does not know which services will be selected later on and so cannot make a decision.

> 
> 	A possible solution would be to have a single HTTP profile
> (that defines what HTTP message parts _can_ be exchanged) and
> separately negotiate what services need what parts. Often a service ID
> would define the list of parts and no extra negotiation would be
> required. Would that work better from your point of view?

That could work. Can you make a suggestion how this separate negotiation will look like?

Martin

> 
> Alex.
> 
> 
> On Mon, 30 Jun 2003, Martin Stecher wrote:
> 
> > If a callout server supports different services, for example URL
> > blocking and virus checking and if it allows the OPES processor to
> > select the service(s) for the OCP transactions, then it also needs
> > exchange this information in the profile negotiation.
> >
> > For URL blocking the server is interested in the
> > http://iana.org/opes/ocp/HTTP/request profile and for virus checking
> > it will select the http://iana.org/opes/ocp/HTTP/response profile.
> >
> > That implies that the NO message needs a services or sg-id
> > parameter, I think.
> >
> > What do you think?
> >
> > Regards
> > Martin
> >
> >
>

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 30 Jun 2003 15:16:37 -0600 (MDT)

On Mon, 30 Jun 2003, Martin Stecher wrote:

> > separately negotiate what services need what parts. Often a
> > service ID would define the list of parts and no extra negotiation
> > would be required. Would that work better from your point of view?
>

It could be the same as service "negotiation" now. For services that
imply a particular set of parts, the service ID is sufficient. For
other services, the part names will be listed as service parameters,
just like they are listed as profile parameters now.

OCP does not have a mechanism to negotiate services, but one can
reject a Transaction Start (TS) or Create Service Group (SGC) message
by closing the transaction or connection.

Alex.