ietf-openproxy
[Top] [All Lists]

RE: NO messages

2003-07-02 08:39:33


On Wed, 2 Jul 2003, Martin Stecher wrote:

    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

(1b) makes much sense in many scenarios.
Let me describe a scenario that might be typical. But I also have an
example where it does not work. It will not be the normal case, so
please have a look whether support of that example is important.

0. My previous example of an earlier message was not so good. An
OPES processor will usually not offer HTTP/reqzest and HTTP/response
profile at the same time. Makes not much sense on a certain decision
point.

OK. This probably depends on the processor implementation and how it
is integrated with the proxy.

1. A typical example would be a callout server with two services
that work on HTTP-responses. Service-1 needs the original HTTP
request as meta data, Service-2 does not. Selecting HTTP profile for
the connection and needed message parts for the transaction
(combination 1b) works well here.

2. A not-so-typical example would be a callout server that works as
a wrapping engine and home for other 3rd party service plugins. That
means that the services are very different and support different OCP
extensions (profiles). Without knowing which service(s) will be
selected within a connection, the server cannot select the correct
profile for the connection.

If example 2 is not important, we can choose combination (1b).

Example #2 is how some web services work today, I guess. So it may be
wise to support it. OPES adaptation is, by some definitions, a web
service.


Else we may need to change something and I would start here:
 > Transaction above is synonymous with "service" or "service group"

Actually service groups are created and destroyed outside of
transactions and a single service ID can exist at any time.

I know, that is why I mentioned that some modifications to the
current negotiation and scoping mechanism would be required to tie
profiles and services.

Currently, playing a NO/NR dialog implies that the selected profile
in the NR message is selected and available featuer set switches
(from OCP core to selected OCP extension). If we change this in a
way that the agents negotiate the profile for a service or service
group (outside of a transaction) without switching to that profile
at the same time?

For example:
  P: NO ({profile1},{profile1 featureX},{profile2})
     Service: serviceA;
  S: NR {profile2};
  P: NO ({profile1},{profile1 featureX},{profile2})
     Service: serviceB;
  S: NR {profile1 featureX};
  P: NO ({profile1},{profile1 featureX},{profile2})
     Service-Group: 42;
  S: NR {profile1 featureX};
  P: SwitchProfile {profile1 featureX};
  P: TS 1 42; // start with transaction for service group 42

How do you think about that?

There are two ways to support what you want: better profile scope
management (your proposal above) and profile variables (similar to
current service group variables). The scope approach means that you
cannot have two concurrent transactions on the same connection using
different profiles (or, at least, it would look awkward if
SwitchProfile applies to the immediate TS only). The variable approach
allows for concurrent transactions with different profiles at the
increased risk of leaking variables and creating a DoS (allocating and
not destroying "a lot of" variables as a result of a bug or on
purpose).

I suggest that we use the "variable" approach:

        P: NO ( service-feature1, service-feature2, ... );
        S: NR service-feature2;
        P: TS 1 service-group-id2;

Where "service-feature" is the following structure:

        { service-group-id service profile }

Where "service-group-id" is an "sg-id:" UNI that can be used in TS
messages if negotiation is successful. "Service" and "profile" are
structures describing callout service and profile information (they
are already defined in OCP).

If you accept the above, I would also suggest that sg-id parameter of
the Transaction Start (TS) message is made mandatory. This will allow
agents to negotiate acceptable services before they are used in any
transaction.

As you can see, both proposals are similar. The only big difference is
that the variable approach lacks the SwitchProfile message.

Note that the variable approach does not allow to select a particular
profile outside of the transaction scope. However, since OCP Core
requires that unknown messages are ignored, it is still possible to
customize exchange outside of transaction boundaries without losing
interoperability.

Will this approach work well, in your opinion?

Alex.


<Prev in Thread] Current Thread [Next in Thread>