Issues for Firewall Traversal Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 4115: BiDir GIOP Policy Clarification
Issue 4155: MAIN_THREAD_MODEL questions
Issue 6284: Negotiate Session Message Orientation
Issue 6311: Negotiation Session message is unwieldy
Issue 6312: Server Authentication
Issue 6313: Bidirectional Policy insufficient for persistent objects
Issue 7167: Discrepancy in the changes proposed to CSIIOP and CSI modules
Issue 7168: GIOP version 2.0 issue
Issue 7197: CodeSet issue (01)
Issue 7198: CodeSet issue (02)
Issue 7199: CodeSet issue (03)
Issue 7200: CodeSet issue (04)
Issue 7201: CodeSet issue (05)
Issue 7202: Negotiate Session Message Issues
Issue 7224: paragraph limits use of BiDirOfferContext
Issue 7225: Implications about BiDirIds
Issue 7307: Firewall issue - Number of BiDirIds in a BiDirOffer
Issue 7308: Firewall Issue: Response to failed BiDir challenge is unclear
Issue 7309: Firewall Issue: Connection over which BiDir offers are sent is unspecified
Issue 7310: Firewall Issue: Random BiDirIds can't be used for persistent POAs
Issue 7311: Interplay of Contexts allowed in NegotiateSession messages too ill-defined
Issue 7312: What BiDirIds shall be sent over what bidirectional connections?
Issue 7313: Firewall FTF Issue: No ene-to-end security for firewall traversal
Issue 7314: Processing of NegotiateSession messages at various stages of connection set
Issue 7315: Targets of Export and Offer Policies incompletely specified
Issue 7316: Expected behavior of a non-conformant implementation
Issue 7317: connection_complete field of the FirewallPathRespContext is under specified
Issue 7318: How many BI_DIR_GIOP_OFFER service contexts are allowed
Issue 7332: GIOP and IIOP versioning must be clearly and consistently specified
Issue 7351: Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY
Issue 7352: Bi-directional connections considered volatile at connection acceptor side
Issue 7353: use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous
Issue 7356: when is a connection a "bi-directional connection"?

Issue 4115: BiDir GIOP Policy Clarification (firewall-traversal-ftf)

I am a little confused as to the scope of the BiDirPolicy in the 2.4.1
specification.  Is the BiDirPolicy a POA policy, an ORB policy, or both?  In
section 15.8 paragraph 5 on page 15-55, the specification states: 

"If the client ORB policy permits bi-directional use
of a connection, a Request message should contain an IOP::ServiceContext
structure in its Request header, which indicates that this GIOP connection
is bi-directional."

but then in section 15.9 paragraph 4 on page 15-59, the specification
states:

"In the absence of a BidirectionalPolicy being passed in the
PortableServer::POA::create_POA operation, a POA will assume a policy value
of
NORMAL." 

but then again in the next sentence the specification states:

"A client and a server ORB must each have a BidirectionalPolicy with a value
of
BOTH for bi-directional communication to take place."

Could someone clarify for me what the intent for the scope of the policy was
here, and what the rationale behind that decision was?  We are currently
reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP,
and I would like to understand the issues regarding the scope of the BiDir
policy.  

This territory is covered by the new Firewall spec. Transfer this issue to the Firewall FTF

i have a few questions about the POA ThreadPolicy type
MAIN_THREAD_MODEL.

first, the 2.4.1 spec (00-11-03),  sec 4.2.3.2 , 'perform_work' states,
    "If called by the main thread, this operation performs an
implementation-defined unit of work; otherwise it does nothing."

how is a distinguished main thread supposed to be reliably determined?
i'm not sure we really need to define this. i'd think what we're trying
to say is that the thread that calls perform_work() is the thread that
will be used to do the work, and it is up to the application to make
sure this happens. in section 4.2.3.3, the spec states,
    "For maximum portability an application should call either run or
perform_work on its main thread."

to me it seems the intent is to let the application determine what the
'main thread' is.

second, what happens if an application calls both run & perform_work?
and what happens if the application calls run from multiple threads? it
isn't really clear what the difference in request handling with regard
to the thread used is between run() & perform_work().

right now the spec seems to imply through the use of the message loop
example in section 4.2.3.2 that perform_work is really intended to be
used to handle situations where a single thread must be used for _all_
application activity. now add to that the note on pg 11-12 about using
the main thread model:
    "Note - Not all environments have such a special requirement. If
not, while requests will be processessed sequentially, they may not all
be processed on the same thread."

my interpretation is that ORB::run would be used in cases where you
simply want the POAs to be accessed sequentially, but the application
doesn't care about which thread the implementation uses, but you would
need to call perform_work to specifically hand the application defined
main thread to process requests.

my suggestion (finally ;^) is that we should state perform_work should
be called, on whichever thread the application likes, if it wants to
hand a specific thread to the ORB to do work. otherwise, calling
ORB::run from any thread simply means the implementation is free to
handle requests for servants associated with main thread model POAs on
whatever thread the implementation may choose (including a new one), in
keeping
with the requirement that the requests be processed on each POA's
servants sequentially..

one more question: does it make sense to state that a callback type of
architecture won't work when using this threading model?

Resolution: The discussion in the archive suggests that it is not possible to arrive at a consensus on making any of these changes that do not break at least some deployed systems and the gains from making the change don't appear to justify the making of the change. Close no change. 

The NegotiateSession message is a single typed GIOP message that is sent
between both Client and Server to negotiation service contexts, and
further to initiate and negotiate bidirectional GIOP.


Having a single message is problematic in that a connection, once
negotiated bidirectional may have different requirements for such things
like Codesets, etc. Getting a NegotiateSession message after a
bidrectional set up, the endpoints will have difficulty discerning the
orientation of the NegotiateSession message.


At the very least NegotateSession messages should have an orientation,
much like the GIOP Request and Reply messages do.


I'm not so sure they must be correlated with a "request id", but different
message types would help. I would suggest two messages,
NegotiateSessionRequest and NegotiateSessionReply to maintain the
client-server orientation, respectively.

The Negotiate Session message is unwieldy in that if it is used to send
service contexts, there are no general ways to govern its use other than
by special rules, all of which special cases are not accounted for in the
specification.


For example, when do you sent Bidirectional service contexts as ooposed to
firewall contexts? Can you send transaction contexts? Codesets? Codebase?
CSIv2? Can you send BiDir service contexts while firewall contexts are
being processed?

As I understood it, the Firewall Traversal specification was to use new
CSIv2 Compound Identity types to give the target server the complex
principal composed of the client and the authenticating firewall traversal
path. The server was to be authenticated to the client in much the same
way. This functionality appears to be missing in the specification. It is
easily fixed by returning a CSIv2 IdentityTokenSeq from a successful
firewall negotiation, specifying the backwards firewall authentication
trail from the server to the client.

The BidirectionalPolicy insufficient for persistent objects.


The BidirectinoalExport Policy is a POA policy and it only has two values
of ALLOW and DENY. If it is ALLOW, then a TAG_BI_DIR_GIOP componenet
should be placed in the IOR. It is stated that the ORB must generate a
random identifier when the POA is created. However, that will not work for
persistent objects in which the BiDirectional Offer must remain constant.


Also, there is no default specified if this policy is not placed on a POA,
and no default for the RootPOA.

There seems to be a discrepancy in the changes proposed to CSIIOP and CSI modules.  The draft document has identical changes to both. I think the intent of the Errata was to have only one, just switch them from CSIIOP to CSI. However, Brian's convience document doesn't show the change. Now, the draft document ptc/2004-01-01 that we are voting on has both. What to do? Should that be represented by another document, namely CSI, with it's changes, just like 2004-01-02 is? Cheers, -Polar   


Yeah, I see the problem. Yet another consequence of the adopted spec changing existing spec without calling out the change in the section meant to identify changes to existing specs. So it looks like the fix involves: 1. Section 1.9.2 and 1.9.3 in ptc/04-01-01 [henceforth referred to as document A] should disappear. 2. The first half of section of document A starting from the second para of the section and upto and including the last but one paragraph on page 1-20, should be appended to Section 24.2.5 "Identity Token Format" of Chapter 24 of Core with the title (that is the CSIv2 Chapter)[henceforth referred to as document B]. Also append a row to table 24-2 with info about ITTCompundToken. 3. The IDL in section 1.9.3 of document A should be merged properly into the IDL for the CSI module that appears in section 24.9.2 document B. 4. The addition to CSIIOP IDL as it appears in Section 1.5.2 of document A should be merged appropriately into the IDL for CSIIOP in section 24.9.3 of document B. 5. In document B insert a section 24.5.1.6 "TAG_IIOP_SEC_TRANS" with a two liner explanation of what this tag is together with the IDL for it from section 1.5.2 of document A. I'd suggest that we file this as an issue and resolve it in the FTF roughly along the lines suggested above. 

The following paragraph raises an interesting issue. If we follow this to the letter
- since it says that the new version of GIOP is not backward compatible with the
earlier versions of GIOP, it implicitly appears to make this new GIOP version a
new "major" version of GIOP. Clearly we need to figure out a way to avoid doing
this, since creating GIOP version 2.0 in this way raises all sorts of other issues.
 
From the second paragraph on  page 1-30 of the Firewall Final Adopted Spec (ptc/04-04-01):
 
This document supercedes the previously adopted CORBA firewall specification. In
addition, the changes to bi-directional GIOP, specified in Chapter 15, supercede the
adopted specification for bi-directional GIOP. These specifications are not backwards
compatible with the previous specifications and they are intended to make it possible
to create a functional protocol for the interoperation of ORBs and firewalls.

 Does the CodeSet get negotiated in Negotiate Session?
If so, does Codeset continue to get negotiated in Requests?

Does Codeset get negotiated in only the other direction?
If so, will that happen in Negotiate Session meesages orRequest Messages?

On a connection in which BiDir is negotiated, but no Codeset
   is negotiated, will the reverse direction be able to negotiate
   code set?

Can Codeset come before/with Firewall Traversal in Negotiate Session
   meesages?

Does Codeset come before/with/after BiDir negotiation?

If a service context negotiation fails by way of the NegotiateSession
message in either direction. how does the sender (client or servers side)
get an indication back to the sender?

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).

I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know.


Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client.


In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation.


obj = ...;    // target
obj.invoke_target(...);


In order for the above scenario to work, I derive the following implications from the spec.


1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on *all* of its POAs that have EXPORT policy ALLOW must be available at the server side.


This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on *each* bi-directional connection will also have to transmit the BiDirId for this new POA to the server side.


2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request.


If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on *every* bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that *allows* efficient implementation, though efficiency is not always a concern for everyone.

PROBLEM: 
The BiDir GIOP document does not specify which BiDirIds and how many of them are sent in a BI_DIR_GIOP_OFFER.
 
RECOMMENDATION:
All unoffered BiDirIds are supplied in a BI_DIR_GIOP_OFFER.

PROBLEM:
The actions that result from the failure of a BiDir challenge are unclear.
 
RECOMMENDATION:
The client has proven itself untrustworthy.  A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed.

PROBLEM:
The BiDir GIOP document does not specify the connections over which a BI_DIR_GIOP_OFFER should be sent.
 
RECOMMENDATION:
A BI_DIR_GIOP_OFFER will be sent over all existing bi-directional connections.  If there are none, then a new connection will be established and its bidirectionality initiated.

PROBLEM:
The BiDir GIOP document specifies that all BiDirIds must be randomly generated.  However, persistent POAs must use the same BiDirId across sessions since they are stored in the IOR.
 
RECOMMENDATION:
A new policy is created (BiDirIdGenerationPolicy) that contains two fields:
   field 1, the ID generation method, will take the value 'RANDOM' or the value 'REPEATABLE'
   field 2, the ID type, will take the value 'STRONG' or the value 'WEAK'
 
The random generation method is adequately documented.  The repeatable method will always generate the same BiDirId for a given POA.  This effectively makes the ID a constant, but without the concern for storage.  It also results in the end-user not having to deal with BiDirIds - they are handled entirely by the infrastructure.
 
The values for the ID type indicate whether the type of BiDirId generated is strong or weak.
 
This policy is placed on the client ORB and/or the POA in question.

PROBLEM:
The BiDir GIOP document allows all of the contexts that can be found in a GIOP query or response message to be also allowed in a NegotiateSession message.  However, the interplay among these contexts is undefined.  An example is the use in NegotiateSession messages of both CodeSet negotiation and BiDir connection setup.  What can be used in what order is not defined.
 
RECOMMENDATION:
Only bi-directional GIOP and firewall contexts may be used in a NegotiateSession message in this version of GIOP.  The contexts are the following:
 
·        BI_DIR_GIOP_OFFER
·        BI_DIR_GIOP_CHALLENGE
·        BI_DIR_GIOP_RESPONSE
·        BI_DIR_GIOP_ACCEPT
·        FIREWALL_PATH
·        FIREWALL_PATH_RESP
 
Further contexts may be added to new versions of the BiDir GIOP spec as their interplay with the existing set and the order of their use is carefully analyzed and documented.  This effectively limits the scope of the problem to the bidir protocol and use by the firewall.  The order and stage of processing the above contexts is discussed in another Firewall issue.

 The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send *all* BiDirIds on an ORB to *every* connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of *every* existing bi-directional connections (before or in the next request).


The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted.


Proposed resolution:
 1. Extend the choices of the value field of the BidirectionalOfferPolicy:
     ALLOW_ALL  -- same as ALLOW now, but the implication shall be explicitely stated in the spec
     ALLOW_LISTED  -- a list of POAs being provided in the policy
     DENY  --  same as it now
 2. Add a field to the policy to allow a sequence of POAs being specified.

The title of Section 1.7, End-to-End Secure Connection, is misleading. There is no end-to-end security in the firewall traversal spec. All security mechanisms described in this spec are essentially mechanisms between a client, firewalls, and a server, not end-to-end. Thus, it is susceptible to the man-in-the-middle attack.


I'm saying we should fix the problem, but the title of this section and the caption of Figure 1-4 is certainly misleading. Besids, if the firewall traversal scheme described in the spec is actually susceptible to the man-in-the-middle attack, we may want to consider stating it somewhere in the spec rather than making people have a wrong impression that it is secure

PROBLEM:
The BiDir GIOP Document discusses three stages of connection setup, but it is unclear when each stage begins and when it ends.  It is also unclear what NegotiateSession or Firewall activity can take place in each stage and what the order of processing may be.
 
RECOMMENDATION:
Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup):
 
"...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE.  After the connection is setup, there is a period before the first request or locate request where we can do session setup items.  I think that in that period, only Bidir contexts can be sent, NOTHING ELSE.  The first request or locate request indicates the connection_established period.  Again, during that period I think only the Bidir contexts should be legal.  This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message."  

PROBLEM:
The target (ORB, POA, object, thread) of the Export and Offer policies and the side of the connection involved is incompletely specified.
 
RECOMMENDATION:
Define the two sides of a connection as the connection 'Initiator' and connection 'Acceptor'.  The usual terms of 'client' (Initiator) and 'server' (Acceptor) become confusing in a bi-directional situation.  Given those terms for each side, specify that the Export and Offer policies are used on the Initiator side.  Specify that the Export policy may be applied to the ORB, the POA and/or to the thread.  Specify that the Offer policy can be applied to the Initiator ORB, to a reference in the Initiator for an object in the Acceptor, or to a thread in the Initiator ORB.

PROBLEM:
It is not defined what happens if a non-conformant implementation receives a BiDir offer.
 
RECOMMENDATION:
State that a non-conformant implementation need not do anything - it may simply ignore the offer.

The connection_complete field of the FirewallPathRespContext is under specified.


The fourth paragraph (including IDL) from the end of Section 1.5.4, Firewall Service Context, says,


“Once the connection has been established, the last intelligent firewall in the FirewallPath sends a FIREWALL_PATH_RESP service context in another NegotiateSession message.”


However, the last paragraph of this section says that, when the connection is not completely established, a FIREWALL_PATH_RESP service context with the connection_complete field of false is sent.


Furthermore, when the connection_complete field is false, the spec does not explain what are the situations that may cause incomplete connection establishment and what the client shall do for “further processing”. Shall the FIREWALL_PATH_RESP service context also contains information indicating what the client shall do?

The Bidirectional GIOP spec does not specify how many BI_DIR_GIOP_OFFER service contexts are allowed in a NegotiateSession or Request.


If only one such service context is allowed, it shall be stated clearly. Besides, because each BI_DIR_GIOP_OFFER service context can contain only either strong or weak BiDirIds (but not both), if there are both strong and weak BiDirIds on the ORB, the ORB has to use at least two GIOP messages to send them all.


If we allow multiple BI_DIR_GIOP_OFFER service contexts in one message, we'll have a problem in matching BI_DIR_GIOP_ACCEPT service contexts to these offers because there is no sequencing on offers and accepts.

GIOP and IIOP versioning must be clearly and consistently specified. There are numerous places within the Firewall Traversal FTF report's version of CORBA chapter 15 where certain specific GIOP or IIOP versions are explicitly cited, but the newly introduced versions are not mentioned. For example, the definition of the GIOP_version field of the GIOP Message Header in section 15.4.1 says "The major GIOP version number of this specification is one (1); the minor versions are zero(0), one (1), and two (2)." GIOP versions 1.3, 1.4, and 1.5 are not addressed. Similarly, table 15-3 does not even show messages such as Request and Reply applying to GIOP versions 1.4 and 1.5. There are other occurances where the intent may not be so obvious. I recommend revisiting every reference to a particular GIOP or IIOP version in chapter 15 to make sure that the new versions (including 1.3) are correctly addressed. Where possible, I recommend replacing lists of versions with text such as "version 1.2 and up" that does not need to be revised every time a new version is introduced. 

Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue.


The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional
connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around.


For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection.


There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference.


On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and *effective* BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction?

This issue was mentioned by Dave Stringer. I now file it as an issue.


When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available.


This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection.


On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down.


If this issue is a limitation that cannot be solved easily, we should spell it out in the spec.

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?

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).