Issue 7224: paragraph limits use of BiDirOfferContext (firewall-traversal-ftf) Source: (Ms. Rebecca Bergersen, becky(at)bergersen.org) Nature: Uncategorized Issue Severity: Summary: 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). Resolution: Revised Text: Actions taken: April 6, 2004: received issue Discussion: End of Annotations:===== ubject: FW: Firewall Issue - paragraph limits use of BiDirOfferContext, contradicting rest of specification Date: Tue, 6 Apr 2004 17:22:13 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue - paragraph limits use of BiDirOfferContext, contradicting rest of specification Thread-Index: AcQRvyHo8A+XpksYShafuYObIZOrewKXkATA From: "Bergersen, Rebecca" To: , Forward this on since it isn't displayed in FTF issues listing. --Rebecca -----Original Message----- From: Bergersen, Rebecca Sent: Wednesday, March 24, 2004 11:41 AM To: 'firewall-traversal-ftf@omg.org' Cc: Juergen Boldt (E-mail) Subject: Firewall Issue - paragraph limits use of BiDirOfferContext, contradicting rest of specification 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). Respectfully, Rebecca Rebecca Bergersen PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS rebecca.bergersen@iona.com ------------------------------------------------------- IONA Technologies 200 West Street Waltham, MA 02451 USA Tel: (781) 902-8265 Fax: (781) 902-8001 ------------------------------------------------------- Making Software Work Together TM