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