The current description of NonTxTargetPolicy processing states that the behavior of FORBIDS OTSPolicy is modified based on the NonTxTargetPolicy setting (PERMIT or FORBIDS). This leads to loose transactional semantics and compromises integrity. The NonTxTargetPolicy client policy should instead be modified to apply ONLY to the case where the IOR does not have an OTSPolicy and should NOT be applied to modify FORBDS OTSPolicy behavior.

when a target object explicitly indicates its unwillingness to participate in a
transaction (ie., FORBIDS), and if a transactional client happens to invoke such
a target, the transactional client must get an exception ie., it is incorrect to
drop the tx context silently. But i am fine dropping the transaction context
silently when interoperating with OTS 1.1 servers.

To explain more on why it is incorrect to modify the FORBIDS behavior when it is
stated explicitly in the IOR:

site A (PREVENT) ---> site B (PERMIT) --> site C (holds an Object with FORBIDS)

In the above case, the client app at site A does not get its required behavior
ie., it is not notified by an exception when a non-transactional target is
invoked, since site B silently drops the tx context on it own accord. This
compromises the expected transaction semantics ! and data integrity. After all
we build our systems only to serve the needs of the applications.

On the other hand, i am fine with using the NonTxTargetPolicy with the default
set to PERMIT while interoperating with OTS 1.1 servers only. Since there is an
inherent risk while interoperating with OTS 1.1 servers because of the weak OTS
1.1 tx semantics.

In order to preserve the transaction semantics of applications, i propose that
the NonTxTargetPolicy with a default (PERMIT) be applied only in the case where
the IOR does not have an OTSPolicy. If an IOR has an explicit FORBIDS policy,
NonTxTargetPolicy has no effect.

It is important for us to fix this behavior in this revision.

See issue 4030 resolution

With respect to the OTSPolicy setting for OTS objects like Coordinator,
Resource, etc: the OTS specification needs to clearly specify the OTSPolicy for
such objects.

Given the choice of OTSPolicies currently available

: ADAPTS seems the most appropriate OTSPolicy for OTS objects.

see above