CORBA35 — when is a connection a "bi-directional connection"?

The discussion on when to send BiDirIds over connections is floundering.
In part, I think this is due to a lack of precision in our thinking (and more
importantly in the adopted firewall spec we are working from).

When does a GIOP connection become bi-directional? The implementation
of the connection-initiator protocol engine must know this. Before this
event it has to treat a GIOP Request message as a protocol error and after
the event it has to dispatch the request.

There seems to be an assumption (or more than one) that there is a
relationship between an Object Reference (i.e. the programming language
artefact representing CORBA::Object) and a GIOP connection.

Whilst it is true that an implementation of the CORBA spec will provide a
relationship (else an invocation cannot result in a GIOP Request message)
the particular relationship was left to ORB implementers to provide for
flexibility of implementation. Specifically, such a relationship is not prescribed
in the CORBA specification (nor should it be).

I suggest it would be dangerous to define a GIOP connection to change state
when an Object Reference that (in some ill-defined way) "points to" a server
that is the target of that connection, undergoes a policy change (i.e. its BiDir
Offer policy is set to Allow).

Instead, a GIOP connection presumably becomes bi-directional when an
invocation on an Object Reference, with an effective Offer Policy of Allow, results
in a Request message being sent over that connection.

The specification must be explicit over which event causes the connection to
become bi-directional.

Also, can a connection cease to be bi-directional? For example if either the
Object Reference invoked above or the POA with "Export = Allow" are destroyed.
Again this would appear to be fraught with problems, leading to the assumption
that the GIOP connection, once bi-directional, remains bi-directional until it is
closed.

Lastly, the closing of idle connections and the subsequent re-connection has
hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
withstanding). This is unfortunate as an application won't be aware of the ORB
having conserved resources in this way and the ORB should not be expected to
provide session semantics that span multiple tcp connections (this is currently
stated in the description of NegotiateSession).