CORBA35 — paragraph limits use of BiDirOfferContext

PROBLEM:
The second paragraph on page 15-60 of the revised GIOP chapter only allows a BiDirOfferContext to be sent to a server if the ORB-level policy permits it:

"If the client ORB policy permits bi-directional use of a connection, a Request or
NegotiateSession (see MARS/04-01-01) message can be sent to the server that
contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header that
indicates that this GIOP connection is bi-directional. The BiDirOfferContext
indicates to the server that the objects with the supplied BiDirIds are available for
invocation over that connection. To determine whether an ORB may support bidirectional
GIOP, the BidirectionalOfferPolicy has been defined (see Section 15.9,
"Bi-directional GIOP policy," on page 65)."

This, however, contradicts the rest of the document, which allows the ORB-level policy to be overriden at the object level. ("A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden
for specific object references received by the client ORB." - Section 15-9, page 15-66).

Additionally, the first sentence of the above paragraph is worded in such a way that it defines a connection as bidirectional before it has accepted as such by a server.

Finally, a spurious reference to the submission document is included in the first sentence ("see MARS/04-01-01").

RECOMMENDATION:
Rephrase the paragraph as follows:

If the effective BidirectionalOfferPolicy of an object in the client is set to ALLOW, a Request or NegotiateSession message that contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header can be sent to the server, offering bi-directional use of the connection. The BiDirOfferContext indicates to the server that the objects with the supplied BiDirIds are available for invocation over that connection. To determine if bidirectional GIOP may be supported, the BidirectionalOfferPolicy has been defined (see Section 15.9, "Bi-directional GIOP policy," on page 65).