CORBA34 — use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous

ptc/04-04-06 section 15.9.1 (top of page 15-67) states:
When the server receives a BI_DIR_GIOP_OFFER context it must send back a
BI_DIR_GIOP_ACCEPT context in both the strong and weak identification cases.

What happens if an ACCEPT service context is not returned? Either immediately
or ever?

Can a connection initiator, having sent an OFFER SC, send any further GIOP
messages over that connection prior to receiving the ACCEPT SC?

Should a connection initiator, having sent an OFFER SC but not having received
an ACCEPT SC, accept a Request (i.e in the reverse direction) on that connection?
a) for an object whose POA's BiDirId has been offered and accepted?
b) for an object whose POA's BiDirId has been offered but a corresponding
ACCEPT has not yet been received?
c) for an object whose POA's BiDirId has been offered and accepted only over a
different connection (to that over which the Request arrives)?
d) for an object whose POA has a BiDirId but it hasn't yet been offered?
e) for any object (e.g. one whose POA doesn't have a BiDirId)?

If an OFFER SC is sent on a Request message, can the corresponding ACCEPT
SC be carried on any GIOP message from the connection acceptor?
a) the associated Response
b) a Response not associated with the Request
c) a NegotiateSession message
d) a Request message for an object whose POA's BiDirId has already been
negotiated

If an OFFER SC is sent on a NegotiateSession message, can the corresponding
ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or
must it come over a NegotiateSession message?

If two POAs (with EXPORT policy) are created and their BiDirIds are sent separately
in OFFER SCs on separate messages over a given connection, is a subsequently
received ACCEPT SC deemed to relate to one or to both of the offered BiDirIds?

Since I assume that a connection is effectively promoted to BiDir once the first
ACCEPT SC (indicating no error) is received. What is the point of insisting that
the connection acceptor "must" send additional ACCEPT SC?

In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a GIOP Request
message from the connection acceptor would imply that the connection acceptor
has accepted the BiDirId. It would seem that the ACCEPT(no error variant) SC is
completely superfluous.

Given the ambiguities in the protocol, it seems likely that an implementation may
find the real-world interactions to have broken its model of the protocol. What should
a GIOP protocol machine do in such a situation?

If the connection initiator deems that the OFFER-ACCEPT protocol has gone wrong
should it be required to close the connection?

As there is no correlation between OFFER SCs and ACCEPT SCs, on a given
connection, does an ACCEPT (indicating an error) imply that the connection is
in an indeterminate state and should be closed?

If a connection is to be closed due to an error in the OFFER-ACCEPT protocol do
the normal rules regarding outstanding invocations apply? Do they apply for both
directions?

Deferred

This proposal was generated automatically by request of the Task Force Chair Adam Mitz.