Subject: RE: NO messages

From: "Martin Stecher" <[email-masked]>
Date: Tue, 1 Jul 2003 11:39:48 +0200

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

I am confused.

This seems that the processor has knowledge about the services' needs.
I knows that some services imply a particular set of parts and that other services take those parts as parameters (maybe not accepting these by closing transaction or connection).

If the processor knows already the details about needed parts it definitely knows also the profile that the service prefers.

What sense do NO/NR message negotiation for profiles have then?

I think that the OPES processor only has the service IDs that it shall apply at a given execution point.
The technical negotatiation what and how data will be exchanged with the callout server for that service should be done within OCP.

I think that NO/NR negotiation for profiles plus wanted meta data is good for that but it needs to be done per service.
All what we need is an optional service parameter for NO messages.

Martin

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 1 Jul 2003 09:52:25 -0600 (MDT)

On Tue, 1 Jul 2003, Martin Stecher wrote:

> > > > 	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?
> > >
> > 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.
> >
> > reject a Transaction Start (TS) or Create Service Group (SGC)
> > message by closing the transaction or connection.
> >
>
> I am confused.
>
> This seems that the processor has knowledge about the services'
> needs. I knows that some services imply a particular set of parts
> and that other services take those parts as parameters (maybe not
> accepting these by closing transaction or connection).
>
> If the processor knows already the details about needed parts it
> definitely knows also the profile that the service prefers.

Yes. Parts are defined in the profile. One cannot know what parts are
without the profile. The reverse is not necessarily true: it is
possible to have a profile that does not define the exact set of
required parts, only the set of possible parts, leaving the final
choice up to the services/agents.

> What sense do NO/NR message negotiation for profiles have then?

Indeed. If X is known a priory, there is no need to negotiate X! The
primary reason to have profile negotiation is to accommodate situations
when the processor or the callout server support more than one
profile. In that case, they have to agree on one profile to use. For
example, a processor may support HTTP and MIME profiles while the
server supports only MIME. They have to negotiate to find out.

The secondary reason for negotiation is to confirm assumptions. For
example, the processor may be configured to use HTTP profile and may
be told (also via a configuration file) that the callout server
supports HTTP profile. It may make sense to negotiate HTTP profile
anyway just to make sure that configuration [still] works before
exchanging any messages. This is simply to ease maintenance and
debugging.

My "services that imply a particular set of parts" phrase is
misleading because while a service may imply parts, the processor may
not be aware of that implication and may have to negotiate it. Like
you say below, the processor may only be given an opaque service ID.

> I think that the OPES processor only has the service IDs that it
> shall apply at a given execution point. The technical negotatiation
> what and how data will be exchanged with the callout server for that
> service should be done within OCP.

This is a typical scenario, yes.

> I think that NO/NR negotiation for profiles plus wanted meta data is
> good for that but it needs to be done per service. All what we need
> is an optional service parameter for NO messages.

Let's assume that "application profile" defines OCP extensions,
including a set of valid message parts and data encodings.

Are you saying that an application profile (e.g., HTTP) should be
per-service rather than per-connection? If so, it would be difficult
to introduce profile-specific OCP messages outside of the OCP
transaction boundary (because outside of a transaction, the "current"
service is not known).

Which combination of options do you prefer:

	1) Application profile is negotiated for connection
	2) Application profile is negotiated for transaction
    x
	a) Exchanged message parts are negotiated for connection
	b) Exchanged message parts are negotiated for transaction

Transaction above is synonymous with "service" or "service group". If
we select (1b) or (2b), we would need to adjust the specs so that
negotiations can be tied to a transaction/service.

(1a) does not allow for service-dependent parts
(2a) is not a valid combination
(1b) is my preference
(2b) makes OCP extensions that do not depend on a service difficult

Do you prefer (1b)?

Thanks,

Alex.