OTS — ots 1.1 client to 1.2 server interworking

This is a re-summarising of the interworking problem that came out in the
discussion of 3916. It is definitely NOT intended to destabilise the 3425
result, but to clarify a corner condition. I've tried to be precise rather
than brief, though I've undoubtedly misused some terms somewhere.

—
To identify some text that needs changing: the first sentence of the
following paragraph (middle of page 10-72 of 00-09-04) is not consistent
with the rest of the text:

OTS 1.1 clients may not interoperate with OTS 1.2 servers unless they
unconditionally
propagate the transaction context. (TF) The OTS 1.2 server determines the
proper
OTSPolicy from the TAG_OTS_POLICY component in the IOR.

—

And the situation in general, for 1.1 client, 1.2 server, for a target
object that is transaction-naive, with client in an active transaction

First, if both sides were 1.1, target would not inherit from TO
On most 1.1 implementations, client invocation-path would
drop/suspend the context.
Some implementations ("promiscuous") would send context.

1.1 server - some implementations would drop/not apply/suspend a
received context; some would just apply the received context (or an
interposed context derived from it) to the thread - this was assumed not to
matter for 1.1 [the 3425 discussion said this was a bug or close to a bug];
some would fault a received context with an exception. (configuration
options could switch between these in some implmentations (ours, at least))

With 1.2 server as we are now (00-09-04)
target's POA will have OTSPolicy of FORBIDS (often by default)

1.1 non-promiscuous will not send context as before - no problem
1.1 promiscuous will send context

1.2 server is required to fault the receipt of a propagation context
on the FORBIDS POA - it MUST throw an exception (INVALID_TRANSACTION).

This would mean a client ap within an active transaction on a promiscuous
1.1-ots platform cannot invoke a non-transactional object on a 1.2-ots.

There is no problem with transaction-using objects, provided the IDL
continues to inherit from TO, even on the 1.2 server. Promiscuous 1.1
clients will send anyway; non-promiscuous will narrow to TO and send the
context.

So - the TransactionalObject inheritance mechanism works for non-promiscous
1.1 clients, but not for promiscuous.

One possible solution would be to allow a setting on the server side
equivalent in effect to the NonTxTargetPolicy PREVENT/PERMIT - if set to
"lenient", it would silently remove the received context. Under no
circumstances would the context remain associated with the thread. (Note
this would be a quite different policy from the existing NonTxTargetPolicy
which affects only client-side behaviour and is for the benefit of client
application writers - this would be server-side only, mostly for the benefit
of interworking). This server-side setting could be a private configuration
switch, but that would be effectively have values "conformant" and
"useful" - which I think it is agreed is really, really bad. Making it yet
another policy would seem better.

Another "solution" would be to confirm that promiscuous 1.1 won't interwork
with 1.2.

—
In any case, the paragraph in 10-72 needs changing.

If we choose to reject the interworking, just change "unless" in the first
sentence of the paragraph to "if" (i.e. reverse the sense)

If we add a server-side policy, the 10-72 the paragraph might become
something like:

OTS 1.1 clients can interoperate with OTS 1.2 servers in the following
circumstances:

a) if the client propagates the context only if the target derives
from TO, then interoperation for both t and non-t target objects will be
possible, provided the target object's idl inherit from TO;

b) if the client always propagates the context (if in a T),
interoperation will be possible for t objects regardless of inheritance;

c) if the client always propagates the context, interoperation for
non-t objects will only be possible if the the server setting
UnwantedCtxPolicy is MAKERIGHT. Interworking in this case is not possible if
the UnwantedCtxPolicy is REJECT.

(deliberately choosing a slightly derogatory name for the moment !)

Of course, if UnwantedCtxPolicy is set to MAKERIGHT, it becomes possible
(i.e. it would work) to have the OTSPolicy checking at the client be
optional. But that would mean that contexts were also being sent to
OTS-unaware ORBs, which has been held to be undesirable, though for reasons
that are obscure.

see above