OTS11 — TRANSACTION_UNAVAILABLE standard exception

In its updates to the Transaction Service and the CORBA Core, the Messaging
final submission (orbos/98-05-06) defines a new standard exception,
TRANSACTION_UNAVAILABLE [orbos/98-05-06, 9.2.2]

It also defines a single situation where this new standard exception is raised:
when the receiving ORB is in the OTS_NOT_CONNECTED state and the request
carries a transaction context.

It is not clear if an ORB that has never heard of OTS is considered to be
always in this OTS_NOT_CONNECTED state, and hence has to check that the
requests it receives do not carry a transaction context.

If yes, then this checking requirement belongs to the CORBA core, not the
OTS spec. And since a compliant OTS 1.1 implementation can propagate tx
contexts whenever it can, a positive answer would probably break a
number of applications.

The messaging final submission defines TRANSACTION_UNAVAILABLE as follows
[orbos/98-05-06, 9.5.1.3]:
! TRANSACTION_UNAVAILABLE Exception
! The CosTransactions module adds the TRANSACTION_UNAVAILABLE exception
! that can be raised by the ORB when it cannot process a transaction service
! context because its connection to the Transaction Service has been
! abnormally terminated. This exception is to be defined in Chapter 3 of the
! Common Object Request Broker Architecture and Specification.

(Note that in this paragraph the TRANSACTION_UNAVAILABLE is described as
a user exception in the CosTransactions – I consider this a typo!)

The strange thing is that the OTS spec specifies (or almost specifies –
see issue #2935) how an OTS implementation registers itself with an
ORB (using the TSIdentification interface), but there is no deregister
or disconnect operation. How can the ORB find out that the connection
to the transaction service has been terminated?