Issue 6311: Negotiation Session message is unwieldy (firewall-traversal-ftf) Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: 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? Resolution: Revised Text: Actions taken: October 7, 2003: received issue Discussion: End of Annotations:===== uthentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Tue, 7 Oct 2003 10:17:14 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: issues@omg.org, firewall-traversal-ftf@omg.org Subject: Negotiation Session message is unwieldy 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? Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: re: resolution for issue 6311 - NegotiateSession unwieldy Date: Fri, 9 Apr 2004 14:28:25 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: resolution for issue 6311 - NegotiateSession unwieldy Thread-Index: AcQeMDoQvFgCIZyfRl2kg/qpyTW6ZQAQzI1A From: "Dave Stringer" To: "Bergersen, Rebecca" , "Joncheng Kuo" , "Tom Rutt" , "Jishnu Mukerji" , "Polar Humenn" Cc: X-OriginalArrivalTime: 09 Apr 2004 21:28:25.0788 (UTC) FILETIME=[97AE5FC0:01C41E79] I'm worried about a resolution that states "special cases of interaction with other protocols are not addressed in this spec." I think this is insufficient for a specification of **interoperability**. For each interaction that is not considered and properly specified there will be a number of interoperability problems down-stream because implementors will have taken different decisions. This will be a grave disservice to ORB users when their applications fail due to an underlying ORB non-interoperability. For example, putting a SendingContextRuntime service context into a NegotiateSession message would mean what? For various reasons this context goes along with every Request message anyway, so what if one ORB implementation tried to use it whilst another just threw it away? Or the TransactionContext: it makes no sense to send this in a NegotiateSession ... unless the ORB itself uses transactional resources and it intended to enroll its own internal state into a transaction. Then we could imagine rolling back the creation of a POA !!!!! Or perhaps, one implementation might take a TransactionContext in NegotiateSession message to be a shorthand for including that context in every subsequent Request on that connection (i.e. in that "session"). But if other implementations don't do this then there is no interoperability. And if its not specified who knows what they'll do. It is pointless to allow ORB implementors the freedom to use interoperability mechanisms in completely undocumented ways. It would be much better to state that ONLY those service contexts where the interaction had been properly specified be allowed. Since we're writing a firewall traversal spec here we should only allow those contexts pertinent to firewall traversal to be placed in NegotiateSession messages. I would include CodeSets in this proscription. Dave Subject: RE: resolution for issue 6311 - NegotiateSession unwieldy Date: Fri, 9 Apr 2004 17:45:02 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: resolution for issue 6311 - NegotiateSession unwieldy Thread-Index: AcQeMDoQvFgCIZyfRl2kg/qpyTW6ZQAQzI1AAAHLRZA= From: "Bergersen, Rebecca" To: "Dave Stringer" , "Joncheng Kuo" , "Tom Rutt" , "Jishnu Mukerji" , "Polar Humenn" Cc: I'm also worried, but none of the special issues have been posted as issues, with a statement of the issue, some discussion and a suggested resolution. There has been no discussion of even the very general examples that Polar provided, though Polar did post half a dozen questions about code sets. No one replied. These and the other examples are special cases and the solutions will probably have to be specially designed for the cases. If we're lucky we might see some general pattern that we can address with an integrated solution. But we haven't had that discussion, we haven't explored the impacts and we haven't seen any proposed resolutions. The FTF is at its final deadline. I don't see anything else to do at this stage but to state that the issue was too general to resolve and there was no discussion of any of the special cases. These cases will have to be brought up and dealt with in the RTF. --Rebecca -----Original Message----- From: Dave Stringer [mailto:Dave.Stringer@borland.com] Sent: Friday, April 09, 2004 5:28 PM To: Bergersen, Rebecca; Joncheng Kuo; Tom Rutt; Jishnu Mukerji; Polar Humenn Cc: firewall-traversal-ftf@omg.org Subject: re: resolution for issue 6311 - NegotiateSession unwieldy I'm worried about a resolution that states "special cases of interaction with other protocols are not addressed in this spec." I think this is insufficient for a specification of **interoperability**. For each interaction that is not considered and properly specified there will be a number of interoperability problems down-stream because implementors will have taken different decisions. This will be a grave disservice to ORB users when their applications fail due to an underlying ORB non-interoperability. For example, putting a SendingContextRuntime service context into a NegotiateSession message would mean what? For various reasons this context goes along with every Request message anyway, so what if one ORB implementation tried to use it whilst another just threw it away? Or the TransactionContext: it makes no sense to send this in a NegotiateSession ... unless the ORB itself uses transactional resources and it intended to enroll its own internal state into a transaction. Then we could imagine rolling back the creation of a POA !!!!! Or perhaps, one implementation might take a TransactionContext in NegotiateSession message to be a shorthand for including that context in every subsequent Request on that connection (i.e. in that "session"). But if other implementations don't do this then there is no interoperability. And if its not specified who knows what they'll do. It is pointless to allow ORB implementors the freedom to use interoperability mechanisms in completely undocumented ways. It would be much better to state that ONLY those service contexts where the interaction had been properly specified be allowed. Since we're writing a firewall traversal spec here we should only allow those contexts pertinent to firewall traversal to be placed in NegotiateSession messages. I would include CodeSets in this proscription. Dave Date: Fri, 09 Apr 2004 18:04:42 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: Dave Stringer , Joncheng Kuo , Jishnu Mukerji , Polar Humenn , firewall-traversal-ftf@omg.org Subject: Re: resolution for issue 6311 - NegotiateSession unwieldy Make this an issue for RTF to deal with Tom Rutt Bergersen, Rebecca wrote: I'm also worried, but none of the special issues have been posted as issues, with a statement of the issue, some discussion and a suggested resolution. There has been no discussion of even the very general examples that Polar provided, though Polar did post half a dozen questions about code sets. No one replied. These and the other examples are special cases and the solutions will probably have to be specially designed for the cases. If we're lucky we might see some general pattern that we can address with an integrated solution. But we haven't had that discussion, we haven't explored the impacts and we haven't seen any proposed resolutions. The FTF is at its final deadline. I don't see anything else to do at this stage but to state that the issue was too general to resolve and there was no discussion of any of the special cases. These cases will have to be brought up and dealt with in the RTF. --Rebecca -----Original Message----- *From:* Dave Stringer [mailto:Dave.Stringer@borland.com] *Sent:* Friday, April 09, 2004 5:28 PM *To:* Bergersen, Rebecca; Joncheng Kuo; Tom Rutt; Jishnu Mukerji; Polar Humenn *Cc:* firewall-traversal-ftf@omg.org *Subject:* re: resolution for issue 6311 - NegotiateSession unwieldy I'm worried about a resolution that states "special cases of interaction with other protocols are not addressed in this spec." I think this is insufficient for a specification of **interoperability**. For each interaction that is not considered and properly specified there will be a number of interoperability problems down-stream because implementors will have taken different decisions. This will be a grave disservice to ORB users when their applications fail due to an underlying ORB non-interoperability. For example, putting a SendingContextRuntime service context into a NegotiateSession message would mean what? For various reasons this context goes along with every Request message anyway, so what if one ORB implementation tried to use it whilst another just threw it away? Or the TransactionContext: it makes no sense to send this in a NegotiateSession ... unless the ORB itself uses transactional resources and it intended to enroll its own internal state into a transaction. Then we could imagine rolling back the creation of a POA !!!!! Or perhaps, one implementation might take a TransactionContext in NegotiateSession message to be a shorthand for including that context in every subsequent Request on that connection (i.e. in that "session"). But if other implementations don't do this then there is no interoperability. And if its not specified who knows what they'll do. It is pointless to allow ORB implementors the freedom to use interoperability mechanisms in completely undocumented ways. It would be much better to state that ONLY those service contexts where the interaction had been properly specified be allowed. Since we're writing a firewall traversal spec here we should only allow those contexts pertinent to firewall traversal to be placed in NegotiateSession messages. I would include CodeSets in this proscription. Dave -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Mon, 12 Apr 2004 14:14:22 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: ckuo01@syr.edu, "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 The Resolution for issue 6311 states: 2. Add a final sentence to the sixth paragraph (including the IDL) of section 15.4.10: NegotiateSession messages are not allowed during the connection setup period. Hmmm, I thought NegotiationSession messages facilitiated the Connection Setup period! Doesn't the NegotiationSession message transport the Firewall Traversal Service Context? -Polar On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > The second and final vote for the Firewall Traversal FTF has been posted at > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversal_FTF_Vote_2.htm. > > The resolutions are based on comments received from Tom, Jishnu, Dave, Joncheng, Polar and myself. > The vote will open at 12:00 PM (EDT) Monday 12 April and close at 17:00 PM (EDT) Wednesday 14 April, since the final report has a hard deadline of Thursday, 15 April. > > Vote Early! > > Regards, > 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 > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Date: Mon, 12 Apr 2004 15:49:10 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Thread-Index: AcQgun0BvGjoZ/BfRZO38HEqBxUoHAADNE7Q From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , , "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3CJpona001049 Connection setup is the period before any GIOP messages have been sent. It deals at a lower level than GIOP. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Monday, April 12, 2004 2:14 PM > To: Bergersen, Rebecca > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > Stringer (E-mail); firewall-traversal-ftf@omg.org > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > > > > The Resolution for issue 6311 states: > > 2. Add a final sentence to the sixth paragraph (including > the IDL) of > section 15.4.10: NegotiateSession messages are not allowed during the > connection setup period. > > Hmmm, I thought NegotiationSession messages facilitiated the > Connection > Setup period! Doesn't the NegotiationSession message transport the > Firewall Traversal Service Context? > > -Polar > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > The second and final vote for the Firewall Traversal FTF > has been posted at > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa l_FTF_Vote_2.htm. > > The resolutions are based on comments received from Tom, Jishnu, Dave, Joncheng, Polar and myself. > The vote will open at 12:00 PM (EDT) Monday 12 April and close at 17:00 PM (EDT) Wednesday 14 April, since the final report has a hard deadline of Thursday, 15 April. > > Vote Early! > > Regards, > 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 > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 12 Apr 2004 16:53:51 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: ckuo01@syr.edu, "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > Connection setup is the period before any GIOP messages have been sent. No it is not. Section 1.5.1 of the Firewall Traversal Specification states: In order to set up a connection to the target server, the client must first send a connection setup message to the target. This connection setup message is a NegotiateSession message discussed in section 15.4.10 and it contains a FIREWALL_PATH service context entry. > It deals at a lower level than GIOP. NegotiationSession message is a GIOP message. -Polar > > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Monday, April 12, 2004 2:14 PM > > To: Bergersen, Rebecca > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > > > > > > > > The Resolution for issue 6311 states: > > > > 2. Add a final sentence to the sixth paragraph (including > > the IDL) of > > section 15.4.10: NegotiateSession messages are not allowed during the > > connection setup period. > > > > Hmmm, I thought NegotiationSession messages facilitiated the > > Connection > > Setup period! Doesn't the NegotiationSession message transport the > > Firewall Traversal Service Context? > > > > -Polar > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > The second and final vote for the Firewall Traversal FTF > > has been posted at > > > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > l_FTF_Vote_2.htm. > > > > The resolutions are based on comments received from Tom, Jishnu, Dave, Joncheng, Polar and myself. > > The vote will open at 12:00 PM (EDT) Monday 12 April and close at 17:00 PM (EDT) Wednesday 14 April, since the final report has a hard deadline of Thursday, 15 April. > > > > Vote Early! > > > > Regards, > > 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 > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Date: Mon, 12 Apr 2004 14:05:12 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Thread-Index: AcQgun0BvGjoZ/BfRZO38HEqBxUoHAADNE7QAAKDFfA= From: "Dave Stringer" To: "Bergersen, Rebecca" , "Polar Humenn" Cc: , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , X-OriginalArrivalTime: 12 Apr 2004 21:05:13.0817 (UTC) FILETIME=[D93DB490:01C420D1] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3CL9mna002054 Section 15.4.10 of the 7168 fix document states: " The connection setup period occurs while a client is attempting to setup a logical connection to the server. This period only occurs when the GIOP connection consists of a sequence of transport-level connections (when firewalls or bridges are in use). Only service contexts that are used for connection setup may be sent during this period." These service contexts are presumably carried on a GIOP message. I think its an omission to not list the contexts allowed during connection setup by name rather than rely on an informal characterization. Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 12:49 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Connection setup is the period before any GIOP messages have been sent. It deals at a lower level than GIOP. --Rebecca Date: Tue, 13 Apr 2004 13:15:39 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: Dave Stringer , Polar Humenn , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 X-Virus-Scanned: Symantec AntiVirus Scan Engine Comments by Joncheng below: Section 15.4.10 of the 7168 fix document states: " The connection setup period occurs while a client is attempting to setup a logical connection to the server. This period only occurs when the GIOP connection consists of a sequence of transport-level connections (when firewalls or bridges are in use). Only service contexts that are used for connection setup may be sent during this period." Resolution for Issue 6311 says, 2. Add a final sentence to the sixth paragraph (including the IDL) of section 15.4.10: .NegotiateSession messages are not allowed during the connection setup period.. If NegotiateSession messages are not allowed in the connection setup period, how can service contexts being delivered? What does a session really mean? Joncheng Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 12:49 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Connection setup is the period before any GIOP messages have been sent. It deals at a lower level than GIOP. --Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Date: Tue, 13 Apr 2004 14:51:10 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Thread-Index: AcQhevd+BU8fggi2Tg2xVoTKmo2ZKQADNPyg From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: "Dave Stringer" , "Polar Humenn" , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , This is what we were discussing yesterday. I said at the time that I goofed and forgot about firewall_path and firewall_path_resp service contexts which certainly are used at connection setup time. I was concentrating on the bi_dir_giop_* contexts which are only used after connection setup has occurred, thinking that was the entire set of service contexts that a NegotiateSession message would carry. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, April 13, 2004 1:16 PM To: Bergersen, Rebecca Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Comments by Joncheng below: Section 15.4.10 of the 7168 fix document states: " The connection setup period occurs while a client is attempting to setup a logical connection to the server. This period only occurs when the GIOP connection consists of a sequence of transport-level connections (when firewalls or bridges are in use). Only service contexts that are used for connection setup may be sent during this period." Resolution for Issue 6311 says, 2. Add a final sentence to the sixth paragraph (including the IDL) of section 15.4.10: .NegotiateSession messages are not allowed during the connection setup period.. If NegotiateSession messages are not allowed in the connection setup period, how can service contexts being delivered? What does a session really mean? Joncheng Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 12:49 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Connection setup is the period before any GIOP messages have been sent. It deals at a lower level than GIOP. --Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Date: Tue, 13 Apr 2004 12:08:50 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Thread-Index: AcQhevd+BU8fggi2Tg2xVoTKmo2ZKQADNPygAABiEjA= From: "Dave Stringer" To: "Bergersen, Rebecca" , "Joncheng Kuo" Cc: "Polar Humenn" , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , X-OriginalArrivalTime: 13 Apr 2004 19:08:51.0665 (UTC) FILETIME=[C1F79C10:01C4218A] This "goof" illustrates my biggest concern with the whole spec: the totally unconstrained NegotiateSession message. Well - we did get to "the connection acceptor can't send CodeSet service contexts" and I vaguely remember reading that the connection acceptor can't send BI_DIR_GIOP_OFFER service contexts but those apart, unconstrained! It seems inconceivable to me that two independent ORB implementations, that made any use of this capability (except perhaps for firewall traversal and bidirectional connection contexts - and even that we are still debating!) would end up being interoperable. For this spec to progress to "available" with NegotiateSession in its current unrestricted form will be the biggest threat to real-world ORB interoperability in the last 10 years ( ... worse than value types). Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Tuesday, April 13, 2004 11:51 AM To: Joncheng Kuo Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 This is what we were discussing yesterday. I said at the time that I goofed and forgot about firewall_path and firewall_path_resp service contexts which certainly are used at connection setup time. I was concentrating on the bi_dir_giop_* contexts which are only used after connection setup has occurred, thinking that was the entire set of service contexts that a NegotiateSession message would carry. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, April 13, 2004 1:16 PM To: Bergersen, Rebecca Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Comments by Joncheng below: Section 15.4.10 of the 7168 fix document states: " The connection setup period occurs while a client is attempting to setup a logical connection to the server. This period only occurs when the GIOP connection consists of a sequence of transport-level connections (when firewalls or bridges are in use). Only service contexts that are used for connection setup may be sent during this period." Resolution for Issue 6311 says, 2. Add a final sentence to the sixth paragraph (including the IDL) of section 15.4.10: .NegotiateSession messages are not allowed during the connection setup period.. If NegotiateSession messages are not allowed in the connection setup period, how can service contexts being delivered? What does a session really mean? Joncheng Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 12:49 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Connection setup is the period before any GIOP messages have been sent. It deals at a lower level than GIOP. --Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Date: Tue, 13 Apr 2004 15:37:19 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Thread-Index: AcQhevd+BU8fggi2Tg2xVoTKmo2ZKQADNPygAABiEjAAAU+l0A== From: "Bergersen, Rebecca" To: "Dave Stringer" , "Joncheng Kuo" Cc: "Polar Humenn" , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , , "Bergersen, Rebecca" The text I wrote was meant to constrain the use of NegotiateSession messages to just those required for establishing bidirectionality over a connection. I listed the service contexts I remembered that were used in that regard and missed two. It's simple to add the two I missed to the list. Everything else, including codesets, is prohibited, effectively restricting it. Are you implying that we can't add the two service contexts I left out? --Rebecca -----Original Message----- From: Dave Stringer [mailto:Dave.Stringer@borland.com] Sent: Tuesday, April 13, 2004 3:09 PM To: Bergersen, Rebecca; Joncheng Kuo Cc: Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 This "goof" illustrates my biggest concern with the whole spec: the totally unconstrained NegotiateSession message. Well - we did get to "the connection acceptor can't send CodeSet service contexts" and I vaguely remember reading that the connection acceptor can't send BI_DIR_GIOP_OFFER service contexts but those apart, unconstrained! It seems inconceivable to me that two independent ORB implementations, that made any use of this capability (except perhaps for firewall traversal and bidirectional connection contexts - and even that we are still debating!) would end up being interoperable. For this spec to progress to "available" with NegotiateSession in its current unrestricted form will be the biggest threat to real-world ORB interoperability in the last 10 years ( ... worse than value types). Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Tuesday, April 13, 2004 11:51 AM To: Joncheng Kuo Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 This is what we were discussing yesterday. I said at the time that I goofed and forgot about firewall_path and firewall_path_resp service contexts which certainly are used at connection setup time. I was concentrating on the bi_dir_giop_* contexts which are only used after connection setup has occurred, thinking that was the entire set of service contexts that a NegotiateSession message would carry. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, April 13, 2004 1:16 PM To: Bergersen, Rebecca Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Comments by Joncheng below: Section 15.4.10 of the 7168 fix document states: " The connection setup period occurs while a client is attempting to setup a logical connection to the server. This period only occurs when the GIOP connection consists of a sequence of transport-level connections (when firewalls or bridges are in use). Only service contexts that are used for connection setup may be sent during this period." Resolution for Issue 6311 says, 2. Add a final sentence to the sixth paragraph (including the IDL) of section 15.4.10: .NegotiateSession messages are not allowed during the connection setup period.. If NegotiateSession messages are not allowed in the connection setup period, how can service contexts being delivered? What does a session really mean? Joncheng Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 12:49 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Connection setup is the period before any GIOP messages have been sent. It deals at a lower level than GIOP. --Rebecca Date: Tue, 13 Apr 2004 16:34:51 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: Dave Stringer , Polar Humenn , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Bergersen, Rebecca wrote: This is what we were discussing yesterday. I said at the time that I goofed and forgot about firewall_path and firewall_path_resp service contexts which certainly are used at connection setup time. I was concentrating on the bi_dir_giop_* contexts which are only used after connection setup has occurred, thinking that was the entire set of service contexts that a NegotiateSession message would carry. My concern was not the firewall_path service contexts that you missed. What I don't understand is that, if you can send NegotiationSession messages at the connection setup time, what would be the difference between the connection setup period and the session setup period, as it is stated in 15.4.10. "The connection setup period occurs while a client is attempting to setup a logical connection to the server. This period only occurs when the GIOP connection consists of a sequence of transport-level connections (when firewalls or bridges are in use). Only service contexts that are used for connection setup may be sent during this period. The session setup period occurs before any GIOP Request or LocateRequest messages have been sent on a connection. During this period, the client and server can send any number of NegotiateSession messages. After all session negotiation has taken place, the client sends the first GIOP Request or LocateRequest." Joncheng --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, April 13, 2004 1:16 PM To: Bergersen, Rebecca Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Comments by Joncheng below: Section 15.4.10 of the 7168 fix document states: " The connection setup period occurs while a client is attempting to setup a logical connection to the server. This period only occurs when the GIOP connection consists of a sequence of transport-level connections (when firewalls or bridges are in use). Only service contexts that are used for connection setup may be sent during this period." Resolution for Issue 6311 says, 2. Add a final sentence to the sixth paragraph (including the IDL) of section 15.4.10: .NegotiateSession messages are not allowed during the connection setup period.. If NegotiateSession messages are not allowed in the connection setup period, how can service contexts being delivered? What does a session really mean? Joncheng Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 12:49 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Connection setup is the period before any GIOP messages have been sent. It deals at a lower level than GIOP. --Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Date: Tue, 13 Apr 2004 13:59:37 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Thread-Index: AcQg0MXEHHr2gYThSei5evnJ0cmR2QACHxIwAC8MZqA= From: "Dave Stringer" To: "Bergersen, Rebecca" Cc: X-OriginalArrivalTime: 13 Apr 2004 20:59:38.0213 (UTC) FILETIME=[3B9E5950:01C4219A] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3DL4Jna013521 Yes, I think it is possible to amend the ballot - or hold a vote 3 with a revised resoltion to issue 6311. The modification, as laid out in Vote 2 of 4/12 8:21 PDT, part 1 needs amending To add the 2 Firewall service contexts and to no longer surpress the connection setup bullet. However, it needs more than this. There is still the problem with the definitions of these periods and just what is allowed in each one. For example, can the connection initiator send a 2nd NegotiateMessage(BI_DIR_GIOP_OFFER) before it receives the BI_DIR_GIOP_ACCEPT corresponding to an earlier NegMes(...OFFER) ? And if so, can it reiterate the BiDirIds from the earlier OFFER? And if it does do this and then receives an ...ACCEPT relating to the earlier OFFER only, can it progress to send a RequestMessage before completing the NegotiateMessage handshake? Since most connections are initiated because the ORB wishes to send a Request, and as in your example elsewhere the BI_DIR_GIOP_OFFER context can go on the Request message, isn't the "session setup" period vanishingly small? In fact what does session setup mean now that we may preclude all but firewall and BiDir contexts? Does a BI_DIR_GIOP_ACCEPT have to go on the Response associated with the Request That carried the corresponding BI_DIR_GIOP_OFFER? (I would assume not). Or can the Connection-acceptor ORB piggy back on the next GIOP message going the right way? How long could the c-acceptor wait before sending a dedicated NegotiateSession Message? Or should it always send NegotiateSession message? This protocol is not specified with any of the usual artefacts for a protocol: state-machine and message sequences. So I feel it was not just ambiguous with respect to the full set of Service Contexts but it is also ambiguous with respect to when the various flavours of NegotiateSession can/can't be sent. Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 3:03 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Damn! You're right. I forgot about FIREWALL_PATH and FIREWALL_PATH_RESP when I was writing that paragraph. So, what now? It would be easy to modify the paragraph to say that FIREWALL_PATH, etc., are used during setup and that the four BiDir contexts I did mention are used during session setup. Is it possible to amend a ballot? Nobody's voted yet anyway.... --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Monday, April 12, 2004 4:54 PM > To: Bergersen, Rebecca > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > Stringer (E-mail); firewall-traversal-ftf@omg.org > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > Connection setup is the period before any GIOP messages > have been sent. > > No it is not. > > Section 1.5.1 of the Firewall Traversal Specification states: > > In order to set up a connection to the target server, the client must > first send a connection setup message to the target. This > connection setup > message is a NegotiateSession message discussed in section > 15.4.10 and it > contains a FIREWALL_PATH service context entry. > > > It deals at a lower level than GIOP. > > NegotiationSession message is a GIOP message. > > -Polar > > > > > --Rebecca > > > > > -----Original Message----- > > > From: Polar Humenn [mailto:polar@adiron.com] > > > Sent: Monday, April 12, 2004 2:14 PM > > > To: Bergersen, Rebecca > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > (E-mail); Dave > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - > resolution for 6311 > > > > > > > > > > > > The Resolution for issue 6311 states: > > > > > > 2. Add a final sentence to the sixth paragraph (including > > > the IDL) of > > > section 15.4.10: NegotiateSession messages are not > allowed during the > > > connection setup period. > > > > > > Hmmm, I thought NegotiationSession messages facilitiated the > > > Connection > > > Setup period! Doesn't the NegotiationSession message transport the > > > Firewall Traversal Service Context? > > > > > > -Polar > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > The second and final vote for the Firewall Traversal FTF > > > has been posted at > > > > > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > > l_FTF_Vote_2.htm. > > > > > > The resolutions are based on comments received from Tom, > Jishnu, Dave, Joncheng, Polar and myself. > > > The vote will open at 12:00 PM (EDT) Monday 12 April and > close at 17:00 PM (EDT) Wednesday 14 April, since the final > report has a hard deadline of Thursday, 15 April. > > > > > > Vote Early! > > > > > > Regards, > > > 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 > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > Date: Tue, 13 Apr 2004 17:12:31 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Dave Stringer CC: "Bergersen, Rebecca" , Polar Humenn , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 As we can see, many of the possible interoperability issues appeared in the firewall and BiDir spec come from the use (misuse) of service contexts as a vehicle for delivering the firewall path/resp and BiDir stuff. These are things at the connection level, not service-specific information that you want to deliver with Request/Reply. Let's not continue abusing service contexts for this purpose. Pulling them out of service contexts and making them GIOP messages will save us lots of troubles. For example, we can have a simple and clear protocol like the following. C ---ConnectionSetup--> S C <--ConnectionReply--- S ... C ---BiDirOffer---> S C <--BiDirChallenge--- S C ---BiDirResponse--> S C <--BiDirAccept--- S If the FTF is not the right place to make it right, let's find a way to do it. The firewall spec is important and urgent to CORBA, but it's even more dangerous to make it a threat to CORBA. Joncheng Dave Stringer wrote: This "goof" illustrates my biggest concern with the whole spec: the totally unconstrained NegotiateSession message. Well - we did get to "the connection acceptor can't send CodeSet service contexts" and I vaguely remember reading that the connection acceptor can't send BI_DIR_GIOP_OFFER service contexts but those apart, unconstrained! It seems inconceivable to me that two independent ORB implementations, that made any use of this capability (except perhaps for firewall traversal and bidirectional connection contexts - and even that we are still debating!) would end up being interoperable. For this spec to progress to "available" with NegotiateSession in its current unrestricted form will be the biggest threat to real-world ORB interoperability in the last 10 years ( ... worse than value types). Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Tuesday, April 13, 2004 11:51 AM To: Joncheng Kuo Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 This is what we were discussing yesterday. I said at the time that I goofed and forgot about firewall_path and firewall_path_resp service contexts which certainly are used at connection setup time. I was concentrating on the bi_dir_giop_* contexts which are only used after connection setup has occurred, thinking that was the entire set of service contexts that a NegotiateSession message would carry. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, April 13, 2004 1:16 PM To: Bergersen, Rebecca Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Comments by Joncheng below: Section 15.4.10 of the 7168 fix document states: " The connection setup period occurs while a client is attempting to setup a logical connection to the server. This period only occurs when the GIOP connection consists of a sequence of transport-level connections (when firewalls or bridges are in use). Only service contexts that are used for connection setup may be sent during this period." Resolution for Issue 6311 says, 2. Add a final sentence to the sixth paragraph (including the IDL) of section 15.4.10: .NegotiateSession messages are not allowed during the connection setup period.. If NegotiateSession messages are not allowed in the connection setup period, how can service contexts being delivered? What does a session really mean? Joncheng Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 12:49 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Connection setup is the period before any GIOP messages have been sent. It deals at a lower level than GIOP. --Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Date: Tue, 13 Apr 2004 17:16:32 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Thread-Index: AcQg0MXEHHr2gYThSei5evnJ0cmR2QACHxIwAC8MZqAAAaUgAA== From: "Bergersen, Rebecca" To: "Dave Stringer" Cc: , "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3DLJDna013685 All valid questions, Dave. And, as you and others say, left unanswered by the spec. Given that, is it possible to define statements for this FTF that restrict or prohibit the undefined behaviors, that would be voted on in a third ballot? These behaviors can then be dealt with in an RTF when there is more time. Would you care to take a crack at writing such statements? We do have a bit more time than we had originally thought. --Rebecca > -----Original Message----- > From: Dave Stringer [mailto:Dave.Stringer@borland.com] > Sent: Tuesday, April 13, 2004 5:00 PM > To: Bergersen, Rebecca > Cc: firewall-traversal-ftf@omg.org > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > > > Yes, I think it is possible to amend the ballot - or hold a > vote 3 with > a revised > resoltion to issue 6311. > > The modification, as laid out in Vote 2 of 4/12 8:21 PDT, part 1 needs > amending > To add the 2 Firewall service contexts and to no longer surpress the > connection > setup bullet. > > However, it needs more than this. There is still the problem with the > definitions > of these periods and just what is allowed in each one. > > For example, can the connection initiator send a 2nd > NegotiateMessage(BI_DIR_GIOP_OFFER) > before it receives the BI_DIR_GIOP_ACCEPT corresponding to an earlier > NegMes(...OFFER) ? > And if so, can it reiterate the BiDirIds from the earlier > OFFER? And if > it does do this > and then receives an ...ACCEPT relating to the earlier OFFER only, can > it progress to > send a RequestMessage before completing the NegotiateMessage > handshake? > > Since most connections are initiated because the ORB wishes to send a > Request, and > as in your example elsewhere the BI_DIR_GIOP_OFFER context > can go on the > Request > message, isn't the "session setup" period vanishingly small? In fact > what does session > setup mean now that we may preclude all but firewall and > BiDir contexts? > > Does a BI_DIR_GIOP_ACCEPT have to go on the Response > associated with the > Request > That carried the corresponding BI_DIR_GIOP_OFFER? (I would > assume not). > Or can the > Connection-acceptor ORB piggy back on the next GIOP message going the > right way? > How long could the c-acceptor wait before sending a dedicated > NegotiateSession > Message? Or should it always send NegotiateSession message? > > This protocol is not specified with any of the usual artefacts for a > protocol: > state-machine and message sequences. So I feel it was not > just ambiguous > with respect > to the full set of Service Contexts but it is also ambiguous with > respect to when > the various flavours of NegotiateSession can/can't be sent. > > Dave > > > -----Original Message----- > From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] > Sent: Monday, April 12, 2004 3:03 PM > To: Polar Humenn > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > > > Damn! You're right. I forgot about FIREWALL_PATH and > FIREWALL_PATH_RESP when I was writing that paragraph. So, > what now? It > would be easy to modify the paragraph to say that FIREWALL_PATH, etc., > are used during setup and that the four BiDir contexts I did > mention are > used during session setup. Is it possible to amend a ballot? > Nobody's > voted yet anyway.... > > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Monday, April 12, 2004 4:54 PM > > To: Bergersen, Rebecca > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > Connection setup is the period before any GIOP messages > > have been sent. > > > > No it is not. > > > > Section 1.5.1 of the Firewall Traversal Specification states: > > > > In order to set up a connection to the target server, the > client must > > first send a connection setup message to the target. This > > connection setup > > message is a NegotiateSession message discussed in section > > 15.4.10 and it > > contains a FIREWALL_PATH service context entry. > > > > > > It deals at a lower level than GIOP. > > > > NegotiationSession message is a GIOP message. > > > > > -Polar > > > > > > > > --Rebecca > > > > > > > -----Original Message----- > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > Sent: Monday, April 12, 2004 2:14 PM > > > > To: Bergersen, Rebecca > > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > > (E-mail); Dave > > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - > > resolution for 6311 > > > > > > > > > > > > > > > > The Resolution for issue 6311 states: > > > > > > > > 2. Add a final sentence to the sixth paragraph (including > > > > the IDL) of > > > > section 15.4.10: NegotiateSession messages are not > > allowed during the > > > > connection setup period. > > > > > > > > Hmmm, I thought NegotiationSession messages facilitiated the > > > > Connection > > > > Setup period! Doesn't the NegotiationSession message > transport the > > > > Firewall Traversal Service Context? > > > > > > > > -Polar > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > The second and final vote for the Firewall Traversal FTF > > > > has been posted at > > > > > > > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > > > l_FTF_Vote_2.htm. > > > > > > > > The resolutions are based on comments received from Tom, > > Jishnu, Dave, Joncheng, Polar and myself. > > > > The vote will open at 12:00 PM (EDT) Monday 12 April and > > close at 17:00 PM (EDT) Wednesday 14 April, since the final > > report has a hard deadline of Thursday, 15 April. > > > > > > > > Vote Early! > > > > > > > > Regards, > > > > 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 > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > Date: Tue, 13 Apr 2004 17:43:22 -0400 From: Tom Rutt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Dave Stringer CC: "Bergersen, Rebecca" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 / I agree with this change. we could take this single issue out of the existing vote, and issue a new vote, with the ammended text, closing the same date as the first ballot. / Dave Stringer wrote: Yes, I think it is possible to amend the ballot - or hold a vote 3 with a revised resoltion to issue 6311. The modification, as laid out in Vote 2 of 4/12 8:21 PDT, part 1 needs amending To add the 2 Firewall service contexts and to no longer surpress the connection setup bullet. However, it needs more than this. There is still the problem with the definitions of these periods and just what is allowed in each one. For example, can the connection initiator send a 2nd NegotiateMessage(BI_DIR_GIOP_OFFER) before it receives the BI_DIR_GIOP_ACCEPT corresponding to an earlier NegMes(...OFFER) ? And if so, can it reiterate the BiDirIds from the earlier OFFER? And if it does do this and then receives an ...ACCEPT relating to the earlier OFFER only, can it progress to send a RequestMessage before completing the NegotiateMessage handshake? Since most connections are initiated because the ORB wishes to send a Request, and as in your example elsewhere the BI_DIR_GIOP_OFFER context can go on the Request message, isn't the "session setup" period vanishingly small? In fact what does session setup mean now that we may preclude all but firewall and BiDir contexts? Does a BI_DIR_GIOP_ACCEPT have to go on the Response associated with the Request That carried the corresponding BI_DIR_GIOP_OFFER? (I would assume not). Or can the Connection-acceptor ORB piggy back on the next GIOP message going the right way? How long could the c-acceptor wait before sending a dedicated NegotiateSession Message? Or should it always send NegotiateSession message? This protocol is not specified with any of the usual artefacts for a protocol: state-machine and message sequences. So I feel it was not just ambiguous with respect to the full set of Service Contexts but it is also ambiguous with respect to when the various flavours of NegotiateSession can/can't be sent. Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 3:03 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Damn! You're right. I forgot about FIREWALL_PATH and FIREWALL_PATH_RESP when I was writing that paragraph. So, what now? It would be easy to modify the paragraph to say that FIREWALL_PATH, etc., are used during setup and that the four BiDir contexts I did mention are used during session setup. Is it possible to amend a ballot? Nobody's voted yet anyway.... --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Monday, April 12, 2004 4:54 PM To: Bergersen, Rebecca Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer (E-mail); firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: Connection setup is the period before any GIOP messages have been sent. No it is not. Section 1.5.1 of the Firewall Traversal Specification states: In order to set up a connection to the target server, the client must first send a connection setup message to the target. This connection setup message is a NegotiateSession message discussed in section 15.4.10 and it contains a FIREWALL_PATH service context entry. It deals at a lower level than GIOP. NegotiationSession message is a GIOP message. -Polar --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Monday, April 12, 2004 2:14 PM To: Bergersen, Rebecca Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 The Resolution for issue 6311 states: 2. Add a final sentence to the sixth paragraph (including the IDL) of section 15.4.10: NegotiateSession messages are not allowed during the connection setup period. Hmmm, I thought NegotiationSession messages facilitiated the Connection Setup period! Doesn't the NegotiationSession message transport the Firewall Traversal Service Context? -Polar On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: The second and final vote for the Firewall Traversal FTF has been posted at ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa l_FTF_Vote_2.htm. The resolutions are based on comments received from Tom, Jishnu, Dave, Joncheng, Polar and myself. The vote will open at 12:00 PM (EDT) Monday 12 April and close at 17:00 PM (EDT) Wednesday 14 April, since the final report has a hard deadline of Thursday, 15 April. Vote Early! Regards, 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 ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Date: Tue, 13 Apr 2004 18:30:17 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Thread-Index: AcQhnCkeBqXJ8VbRRYu4QHJ1Y2FySgAAQkFg From: "Bergersen, Rebecca" To: "Joncheng Kuo" , "Dave Stringer" Cc: "Polar Humenn" , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , , "Bergersen, Rebecca" I disagree (but you already knew that, since been over and over this argument in the past). There is no functional difference between doing the work through service contexts or creating new GIOP messages. The issues raised don't result from confusing service context usage - they result from inadequate definition in the spec. The same would be true if the protocol was made up of different GIOP messages. The same holes would need to be plugged. The advantage to keeping the use of service contexts is that the weak BiDir protocol, which can be sent over both NegotiateSession and Request/Reply messages, is implementable in GIOP 1.2. Since most (maybe all) ORBs support 1.2 and few will support 1.4 or 1.5 for a long time, this is an important concern. Finally, it's not the job of this (or any) FTF to change the programming model that the submitters designed and the AB and TC approved. A new RFP or RFC is the only way to do that. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, April 13, 2004 5:13 PM To: Dave Stringer Cc: Bergersen, Rebecca; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 As we can see, many of the possible interoperability issues appeared in the firewall and BiDir spec come from the use (misuse) of service contexts as a vehicle for delivering the firewall path/resp and BiDir stuff. These are things at the connection level, not service-specific information that you want to deliver with Request/Reply. Let's not continue abusing service contexts for this purpose. Pulling them out of service contexts and making them GIOP messages will save us lots of troubles. For example, we can have a simple and clear protocol like the following. C ---ConnectionSetup--> S C <--ConnectionReply--- S ... C ---BiDirOffer---> S C <--BiDirChallenge--- S C ---BiDirResponse--> S C <--BiDirAccept--- S If the FTF is not the right place to make it right, let's find a way to do it. The firewall spec is important and urgent to CORBA, but it's even more dangerous to make it a threat to CORBA. Joncheng Dave Stringer wrote: This "goof" illustrates my biggest concern with the whole spec: the totally unconstrained NegotiateSession message. Well - we did get to "the connection acceptor can't send CodeSet service contexts" and I vaguely remember reading that the connection acceptor can't send BI_DIR_GIOP_OFFER service contexts but those apart, unconstrained! It seems inconceivable to me that two independent ORB implementations, that made any use of this capability (except perhaps for firewall traversal and bidirectional connection contexts - and even that we are still debating!) would end up being interoperable. For this spec to progress to "available" with NegotiateSession in its current unrestricted form will be the biggest threat to real-world ORB interoperability in the last 10 years ( ... worse than value types). Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Tuesday, April 13, 2004 11:51 AM To: Joncheng Kuo Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 This is what we were discussing yesterday. I said at the time that I goofed and forgot about firewall_path and firewall_path_resp service contexts which certainly are used at connection setup time. I was concentrating on the bi_dir_giop_* contexts which are only used after connection setup has occurred, thinking that was the entire set of service contexts that a NegotiateSession message would carry. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, April 13, 2004 1:16 PM To: Bergersen, Rebecca Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Comments by Joncheng below: Section 15.4.10 of the 7168 fix document states: " The connection setup period occurs while a client is attempting to setup a logical connection to the server. This period only occurs when the GIOP connection consists of a sequence of transport-level connections (when firewalls or bridges are in use). Only service contexts that are used for connection setup may be sent during this period." Resolution for Issue 6311 says, 2. Add a final sentence to the sixth paragraph (including the IDL) of section 15.4.10: .NegotiateSession messages are not allowed during the connection setup period.. If NegotiateSession messages are not allowed in the connection setup period, how can service contexts being delivered? What does a session really mean? Joncheng Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 12:49 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Connection setup is the period before any GIOP messages have been sent. It deals at a lower level than GIOP. --Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Date: Tue, 13 Apr 2004 19:00:14 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Thread-Index: AcQhoGiOAyxfCDtfR8WG6JroUJbeSgACfz/Q From: "Bergersen, Rebecca" To: "Tom Rutt" , "Dave Stringer" , "Joncheng Kuo" , "Jishnu Mukerji (E-mail)" , "Polar Humenn (E-mail)" Cc: , "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3DN2vna014468 Okay, but does the suggestion I made in the issue 7225 discussion help even more? I said "All right, I agree that offers must be sent out over all legitimate connections - that is, ones that allow an offer. I agree that all unoffered BiDirIds must be sent when an offer is made. Where does that leave us? If we state the above and shut down all special cases that could use NegotiateSession messages (codeset, et al) do we a viable spec?" Will those compromises, when worded properly into a ballot, and the change that Dave suggests below, allow us to have a viable spec to offer the OMG? --Rebecca > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Tuesday, April 13, 2004 5:43 PM > To: Dave Stringer > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > > > / I agree with this change. > > we could take this single issue out of the existing vote, and issue a > new vote, with the ammended text, closing the same date as > the first ballot. > / > Dave Stringer wrote: > > >Yes, I think it is possible to amend the ballot - or hold a > vote 3 with > >a revised > >resoltion to issue 6311. > > > >The modification, as laid out in Vote 2 of 4/12 8:21 PDT, > part 1 needs > >amending > >To add the 2 Firewall service contexts and to no longer surpress the > >connection > >setup bullet. > > > >However, it needs more than this. There is still the problem with the > >definitions > >of these periods and just what is allowed in each one. > > > >For example, can the connection initiator send a 2nd > >NegotiateMessage(BI_DIR_GIOP_OFFER) > >before it receives the BI_DIR_GIOP_ACCEPT corresponding to an earlier > >NegMes(...OFFER) ? > >And if so, can it reiterate the BiDirIds from the earlier > OFFER? And if > >it does do this > >and then receives an ...ACCEPT relating to the earlier OFFER > only, can > >it progress to > >send a RequestMessage before completing the NegotiateMessage > handshake? > > > >Since most connections are initiated because the ORB wishes to send a > >Request, and > >as in your example elsewhere the BI_DIR_GIOP_OFFER context > can go on the > >Request > >message, isn't the "session setup" period vanishingly small? In fact > >what does session > >setup mean now that we may preclude all but firewall and > BiDir contexts? > > > >Does a BI_DIR_GIOP_ACCEPT have to go on the Response > associated with the > >Request > >That carried the corresponding BI_DIR_GIOP_OFFER? (I would > assume not). > >Or can the > >Connection-acceptor ORB piggy back on the next GIOP message going the > >right way? > >How long could the c-acceptor wait before sending a dedicated > >NegotiateSession > >Message? Or should it always send NegotiateSession message? > > > >This protocol is not specified with any of the usual artefacts for a > >protocol: > >state-machine and message sequences. So I feel it was not > just ambiguous > >with respect > >to the full set of Service Contexts but it is also ambiguous with > >respect to when > >the various flavours of NegotiateSession can/can't be sent. > > > >Dave > > > > > >-----Original Message----- > >From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] > >Sent: Monday, April 12, 2004 3:03 PM > >To: Polar Humenn > >Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > >Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca > >Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > > > > > >Damn! You're right. I forgot about FIREWALL_PATH and > >FIREWALL_PATH_RESP when I was writing that paragraph. So, > what now? It > >would be easy to modify the paragraph to say that > FIREWALL_PATH, etc., > >are used during setup and that the four BiDir contexts I did > mention are > >used during session setup. Is it possible to amend a > ballot? Nobody's > >voted yet anyway.... > > > > --Rebecca > > > > > > > >>-----Original Message----- > >>From: Polar Humenn [mailto:polar@adiron.com] > >>Sent: Monday, April 12, 2004 4:54 PM > >>To: Bergersen, Rebecca > >>Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > >>Stringer (E-mail); firewall-traversal-ftf@omg.org > >>Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > >> > >> > >> > >> > >>On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > >> > >> > >> > >>>Connection setup is the period before any GIOP messages > >>> > >>> > >>have been sent. > >> > >>No it is not. > >> > >>Section 1.5.1 of the Firewall Traversal Specification states: > >> > >>In order to set up a connection to the target server, the > client must > >>first send a connection setup message to the target. This > >>connection setup > >>message is a NegotiateSession message discussed in section > >>15.4.10 and it > >>contains a FIREWALL_PATH service context entry. > >> > >> > > > > > > > >>>It deals at a lower level than GIOP. > >>> > >>> > >>NegotiationSession message is a GIOP message. > >> > >> > > > > > > > >>-Polar > >> > >> > >> > >>> --Rebecca > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Polar Humenn [mailto:polar@adiron.com] > >>>>Sent: Monday, April 12, 2004 2:14 PM > >>>>To: Bergersen, Rebecca > >>>>Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > >>>> > >>>> > >>(E-mail); Dave > >> > >> > >>>>Stringer (E-mail); firewall-traversal-ftf@omg.org > >>>>Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - > >>>> > >>>> > >>resolution for 6311 > >> > >> > >>>> > >>>>The Resolution for issue 6311 states: > >>>> > >>>>2. Add a final sentence to the sixth paragraph (including > >>>>the IDL) of > >>>>section 15.4.10: NegotiateSession messages are not > >>>> > >>>> > >>allowed during the > >> > >> > >>>>connection setup period. > >>>> > >>>>Hmmm, I thought NegotiationSession messages facilitiated the > >>>>Connection > >>>>Setup period! Doesn't the NegotiationSession message transport the > >>>>Firewall Traversal Service Context? > >>>> > >>>>-Polar > >>>> > >>>>On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > >>>> > >>>> > >>>> > >>>>>The second and final vote for the Firewall Traversal FTF > >>>>> > >>>>> > >>>>has been posted at > >>>> > >>>> > >>>>ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > >>>> > >>>> > >>>l_FTF_Vote_2.htm. > >>> > >>> > >>>>The resolutions are based on comments received from Tom, > >>>> > >>>> > >>Jishnu, Dave, Joncheng, Polar and myself. > >> > >> > >>>>The vote will open at 12:00 PM (EDT) Monday 12 April and > >>>> > >>>> > >>close at 17:00 PM (EDT) Wednesday 14 April, since the final > >>report has a hard deadline of Thursday, 15 April. > >> > >> > >>>>Vote Early! > >>>> > >>>>Regards, > >>>>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 > >>>> > >>>> > >>>> > >>>> > >>>------------------------------------------------------------------- > >>>Polar Humenn Adiron, LLC > >>>mailto:polar@adiron.com 2-212 CST > >>>Phone: 315-443-3171 Syracuse, NY 13244-4100 > >>>Fax: 315-443-4745 http://www.adiron.com > >>> > >>> > >>> > >>------------------------------------------------------------------- > >>Polar Humenn Adiron, LLC > >>mailto:polar@adiron.com 2-212 CST > >>Phone: 315-443-3171 Syracuse, NY 13244-4100 > >>Fax: 315-443-4745 http://www.adiron.com > >> > >> > >> > > > > > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > > Date: Tue, 13 Apr 2004 20:00:46 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: Dave Stringer , Polar Humenn , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: I disagree (but you already knew that, since been over and over this argument in the past). There is no functional difference between doing the work through service contexts or creating new GIOP messages. I agree with you that they are functionally equivalent, but you have more situations to deal with when you use service contexts. For example, you have to exclude what other service contexts are not allowed. Even with only firewall path and BiDir allowed, you still have to deal with the interaction between the two and the interaction between the BiDir service context and the Request that carries this BiDir service context. The issues raised don't result from confusing service context usage - they result from inadequate definition in the spec. The same would be true if the protocol was made up of different GIOP messages. The same holes would need to be plugged. I agree too, but a clear protocol makes inadequate definition less likely to occur. At least, there is a clear distinction between when BiDirIds are offered and when "callback" object references are passed. Besides, mixing offers and accepts can be achieved easily if they are paired up with sequence IDs. Moreover, we can handle a STRONG_FAILURE BiDirId easily without shutting down the whole connection. The advantage to keeping the use of service contexts is that the weak BiDir protocol, which can be sent over both NegotiateSession and Request/Reply messages, is implementable in GIOP 1.2. You're right, but if that's important, a new BiDir spec can still make a special case for that. Joncheng Since most (maybe all) ORBs support 1.2 and few will support 1.4 or 1.5 for a long time, this is an important concern. Finally, it's not the job of this (or any) FTF to change the programming model that the submitters designed and the AB and TC approved. A new RFP or RFC is the only way to do that. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, April 13, 2004 5:13 PM To: Dave Stringer Cc: Bergersen, Rebecca; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 As we can see, many of the possible interoperability issues appeared in the firewall and BiDir spec come from the use (misuse) of service contexts as a vehicle for delivering the firewall path/resp and BiDir stuff. These are things at the connection level, not service-specific information that you want to deliver with Request/Reply. Let's not continue abusing service contexts for this purpose. Pulling them out of service contexts and making them GIOP messages will save us lots of troubles. For example, we can have a simple and clear protocol like the following. C ---ConnectionSetup--> S C <--ConnectionReply--- S ... C ---BiDirOffer---> S C <--BiDirChallenge--- S C ---BiDirResponse--> S C <--BiDirAccept--- S If the FTF is not the right place to make it right, let's find a way to do it. The firewall spec is important and urgent to CORBA, but it's even more dangerous to make it a threat to CORBA. Joncheng Dave Stringer wrote: This "goof" illustrates my biggest concern with the whole spec: the totally unconstrained NegotiateSession message. Well - we did get to "the connection acceptor can't send CodeSet service contexts" and I vaguely remember reading that the connection acceptor can't send BI_DIR_GIOP_OFFER service contexts but those apart, unconstrained! It seems inconceivable to me that two independent ORB implementations, that made any use of this capability (except perhaps for firewall traversal and bidirectional connection contexts - and even that we are still debating!) would end up being interoperable. For this spec to progress to "available" with NegotiateSession in its current unrestricted form will be the biggest threat to real-world ORB interoperability in the last 10 years ( ... worse than value types). Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Tuesday, April 13, 2004 11:51 AM To: Joncheng Kuo Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 This is what we were discussing yesterday. I said at the time that I goofed and forgot about firewall_path and firewall_path_resp service contexts which certainly are used at connection setup time. I was concentrating on the bi_dir_giop_* contexts which are only used after connection setup has occurred, thinking that was the entire set of service contexts that a NegotiateSession message would carry. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, April 13, 2004 1:16 PM To: Bergersen, Rebecca Cc: Dave Stringer; Polar Humenn; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Comments by Joncheng below: Section 15.4.10 of the 7168 fix document states: " The connection setup period occurs while a client is attempting to setup a logical connection to the server. This period only occurs when the GIOP connection consists of a sequence of transport-level connections (when firewalls or bridges are in use). Only service contexts that are used for connection setup may be sent during this period." Resolution for Issue 6311 says, 2. Add a final sentence to the sixth paragraph (including the IDL) of section 15.4.10: .NegotiateSession messages are not allowed during the connection setup period.. If NegotiateSession messages are not allowed in the connection setup period, how can service contexts being delivered? What does a session really mean? Joncheng Dave -----Original Message----- From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] Sent: Monday, April 12, 2004 12:49 PM To: Polar Humenn Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Connection setup is the period before any GIOP messages have been sent. It deals at a lower level than GIOP. --Rebecca Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Date: Wed, 14 Apr 2004 11:03:06 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 Thread-Index: AcQhoGiOAyxfCDtfR8WG6JroUJbeSgAkTllQ From: "Bergersen, Rebecca" To: "Tom Rutt" , "Dave Stringer" , "Bergersen, Rebecca" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3EF5una020266 The resolution for 6311 is hereby removed from ballot 2. It will be reworded as indicated below and issued on a new ballot later today and closing tomorrow. PLEASE VOTE ON BALLOT 2 (except for resolution 6311). Regards, Rebecca > -----Original Message----- > From: Tom Rutt [mailto:tom@coastin.com] > Sent: Tuesday, April 13, 2004 5:43 PM > To: Dave Stringer > Cc: Bergersen, Rebecca; firewall-traversal-ftf@omg.org > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > > > / I agree with this change. > > we could take this single issue out of the existing vote, and issue a > new vote, with the ammended text, closing the same date as > the first ballot. > / > Dave Stringer wrote: > > >Yes, I think it is possible to amend the ballot - or hold a > vote 3 with > >a revised > >resoltion to issue 6311. > > > >The modification, as laid out in Vote 2 of 4/12 8:21 PDT, > part 1 needs > >amending > >To add the 2 Firewall service contexts and to no longer surpress the > >connection > >setup bullet. > > > >However, it needs more than this. There is still the problem with the > >definitions > >of these periods and just what is allowed in each one. > > > >For example, can the connection initiator send a 2nd > >NegotiateMessage(BI_DIR_GIOP_OFFER) > >before it receives the BI_DIR_GIOP_ACCEPT corresponding to an earlier > >NegMes(...OFFER) ? > >And if so, can it reiterate the BiDirIds from the earlier > OFFER? And if > >it does do this > >and then receives an ...ACCEPT relating to the earlier OFFER > only, can > >it progress to > >send a RequestMessage before completing the NegotiateMessage > handshake? > > > >Since most connections are initiated because the ORB wishes to send a > >Request, and > >as in your example elsewhere the BI_DIR_GIOP_OFFER context > can go on the > >Request > >message, isn't the "session setup" period vanishingly small? In fact > >what does session > >setup mean now that we may preclude all but firewall and > BiDir contexts? > > > >Does a BI_DIR_GIOP_ACCEPT have to go on the Response > associated with the > >Request > >That carried the corresponding BI_DIR_GIOP_OFFER? (I would > assume not). > >Or can the > >Connection-acceptor ORB piggy back on the next GIOP message going the > >right way? > >How long could the c-acceptor wait before sending a dedicated > >NegotiateSession > >Message? Or should it always send NegotiateSession message? > > > >This protocol is not specified with any of the usual artefacts for a > >protocol: > >state-machine and message sequences. So I feel it was not > just ambiguous > >with respect > >to the full set of Service Contexts but it is also ambiguous with > >respect to when > >the various flavours of NegotiateSession can/can't be sent. > > > >Dave > > > > > >-----Original Message----- > >From: Bergersen, Rebecca [mailto:Rebecca.Bergersen@iona.com] > >Sent: Monday, April 12, 2004 3:03 PM > >To: Polar Humenn > >Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > >Stringer; firewall-traversal-ftf@omg.org; Bergersen, Rebecca > >Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > > > > > >Damn! You're right. I forgot about FIREWALL_PATH and > >FIREWALL_PATH_RESP when I was writing that paragraph. So, > what now? It > >would be easy to modify the paragraph to say that > FIREWALL_PATH, etc., > >are used during setup and that the four BiDir contexts I did > mention are > >used during session setup. Is it possible to amend a > ballot? Nobody's > >voted yet anyway.... > > > > --Rebecca > > > > > > > >>-----Original Message----- > >>From: Polar Humenn [mailto:polar@adiron.com] > >>Sent: Monday, April 12, 2004 4:54 PM > >>To: Bergersen, Rebecca > >>Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > >>Stringer (E-mail); firewall-traversal-ftf@omg.org > >>Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution for 6311 > >> > >> > >> > >> > >>On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > >> > >> > >> > >>>Connection setup is the period before any GIOP messages > >>> > >>> > >>have been sent. > >> > >>No it is not. > >> > >>Section 1.5.1 of the Firewall Traversal Specification states: > >> > >>In order to set up a connection to the target server, the > client must > >>first send a connection setup message to the target. This > >>connection setup > >>message is a NegotiateSession message discussed in section > >>15.4.10 and it > >>contains a FIREWALL_PATH service context entry. > >> > >> > > > > > > > >>>It deals at a lower level than GIOP. > >>> > >>> > >>NegotiationSession message is a GIOP message. > >> > >> > > > > > > > >>-Polar > >> > >> > >> > >>> --Rebecca > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Polar Humenn [mailto:polar@adiron.com] > >>>>Sent: Monday, April 12, 2004 2:14 PM > >>>>To: Bergersen, Rebecca > >>>>Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > >>>> > >>>> > >>(E-mail); Dave > >> > >> > >>>>Stringer (E-mail); firewall-traversal-ftf@omg.org > >>>>Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - > >>>> > >>>> > >>resolution for 6311 > >> > >> > >>>> > >>>>The Resolution for issue 6311 states: > >>>> > >>>>2. Add a final sentence to the sixth paragraph (including > >>>>the IDL) of > >>>>section 15.4.10: NegotiateSession messages are not > >>>> > >>>> > >>allowed during the > >> > >> > >>>>connection setup period. > >>>> > >>>>Hmmm, I thought NegotiationSession messages facilitiated the > >>>>Connection > >>>>Setup period! Doesn't the NegotiationSession message transport the > >>>>Firewall Traversal Service Context? > >>>> > >>>>-Polar > >>>> > >>>>On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > >>>> > >>>> > >>>> > >>>>>The second and final vote for the Firewall Traversal FTF > >>>>> > >>>>> > >>>>has been posted at > >>>> > >>>> > >>>>ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > >>>> > >>>> > >>>l_FTF_Vote_2.htm. > >>> > >>> > >>>>The resolutions are based on comments received from Tom, > >>>> > >>>> > >>Jishnu, Dave, Joncheng, Polar and myself. > >> > >> > >>>>The vote will open at 12:00 PM (EDT) Monday 12 April and > >>>> > >>>> > >>close at 17:00 PM (EDT) Wednesday 14 April, since the final > >>report has a hard deadline of Thursday, 15 April. > >> > >> > >>>>Vote Early! > >>>> > >>>>Regards, > >>>>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 > >>>> > >>>> > >>>> > >>>> > >>>------------------------------------------------------------------- > >>>Polar Humenn Adiron, LLC > >>>mailto:polar@adiron.com 2-212 CST > >>>Phone: 315-443-3171 Syracuse, NY 13244-4100 > >>>Fax: 315-443-4745 http://www.adiron.com > >>> > >>> > >>> > >>------------------------------------------------------------------- > >>Polar Humenn Adiron, LLC > >>mailto:polar@adiron.com 2-212 CST > >>Phone: 315-443-3171 Syracuse, NY 13244-4100 > >>Fax: 315-443-4745 http://www.adiron.com > >> > >> > >> > > > > > > > > -- > ---------------------------------------------------- > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com > Tel: +1 732 801 5744 Fax: +1 732 774 5133 > > > Subject: RE: PLEASE VOTE - Firewall Traversal FTF - Ballot 3 Date: Wed, 14 Apr 2004 14:08:53 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall Traversal FTF - Ballot 3 Thread-Index: AcQiU/weP9L9RZ0lQr+8FuBcblaZAwAD5meg From: "Dave Stringer" To: "Bergersen, Rebecca" , , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" Cc: X-OriginalArrivalTime: 14 Apr 2004 21:08:52.0823 (UTC) FILETIME=[B09ADE70:01C42264] Borland votes Issue 6311: NO the proposed text change is certainly necessary but it only addresses half the problem with NegotiateSession. The other half being the total lack of sequencing constraints between the flavours of NegotiateSession and between NegotiateSession and the other GIOP messages. The loose hints on connection periods just highlight the problem. After some thought I opt to vote against this as any new issue raised to focus on the remaining gaps would not have the distinction of having been raised before the comment deadline ... for what that might be worth. Date: Thu, 15 Apr 2004 11:59:14 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall Traversal FTF - Ballot 3 Syracuse University votes No on the resolution on Issue 6311. First of all, I would rather like to restrict the service contexts allowed in NegotiateSessions for firewall and bidir only. Secondly, I don't see a point to bring up sessions in the bi-dir spec. Joncheng Kuo -----Original Message----- From: Bergersen, Rebecca Sent: Wednesday, April 14, 2004 3:06 PM To: Bergersen, Rebecca; ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer (E-mail) Cc: firewall-traversal-ftf@omg.org Subject: PLEASE VOTE - Firewall Traversal FTF - Ballot 3 This is ballot 3 for the Firewall FTF. It contains the revised resolution text for issue 6311. The ballot opens at 3:00 PM DT Wednesday, April 14th, and closes at 12:00 PM EDT Wednesday, April 15th. ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversal_FTF_Vote_3.htm Regards, 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 Date: Thu, 15 Apr 2004 23:42:05 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall Traversal FTF - Ballot 3 X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: I'm confused, Joncheng. I thought this resolution did restrict the use of NegotiateSession to firewall and BiDir only. Why do you think it doesn't? I'm sorry that I was in a hurry and misunderstood some of your resolution, but there are still problems with the resolution. The revised text says, "... Additionally, those service contexts are restricted such that they can only be sent at certain times in the connection lifetime. Those periods are: · connection setup period · session setup period · session established period" In other words, I can send FIREWALL_PATH and FIREWALL_PATH_RESP in the session setup and session established periods. Is that right? The other problems, not covered by this issue but made clear through this issue, are 1) the sequencing issue as stated by Dave, and 2) the lack of the capability of controlling what BiDirIds to be sent. For example, because each OFFER service context has either strong or weak BiDirIds, if the client ORB has both strong and weak BiDirIds, what would the client ORB do? Send a Request with two OFFER service contexts? Or sending one NegotiateSession for weak OFFER, waiting for ACCEPT, sending another NegotiateSession, waiting for ACCEPT, and then sending the actual Request? Can I send multiple OFFER service contexts in one Request or NegotiateSession message? If so, how do you match them up with the replied ACCEPT service contexts? Another concern raised by Dave is the fact that connections are transient. If a server ORB (connection acceptor) is able to call back to the client ORB (connection initiator) only through bi-directional connections, there is no guarantee that the call back could always succeed, assuming that there is no problem at the network. The connection established by the client ORB may come and go any time, possible being reconnected (or even rebind) due to an invocation on an object reference that has OfferPolicy DENY. There are actually two cases here: Case 1: Like your ticker example, a client registers to a server and receives callback from time to time. Case 2: a server ORB calls back to objects at the client ORB only during an invocation from the client. I haven't found a solution for the first case. The server object implementation has to take care of that. The second case has a little more hope in that, if this connection is lost, the client ORB (or application) may choose to retry, causing another Request sent to the server. However, this situation may be complicated by the fact that this bi-directional connection may become uni-directional if we allow a STRONG_FAIL to shutdown the whole bi-directional capability. Joncheng --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Thursday, April 15, 2004 11:59 AM To: Bergersen, Rebecca Cc: Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall Traversal FTF - Ballot 3 Syracuse University votes No on the resolution on Issue 6311. First of all, I would rather like to restrict the service contexts allowed in NegotiateSessions for firewall and bidir only. Secondly, I don't see a point to bring up sessions in the bi-dir spec. Joncheng Kuo -----Original Message----- From: Bergersen, Rebecca Sent: Wednesday, April 14, 2004 3:06 PM To: Bergersen, Rebecca; ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer (E-mail) Cc: firewall-traversal-ftf@omg.org Subject: PLEASE VOTE - Firewall Traversal FTF - Ballot 3 This is ballot 3 for the Firewall FTF. It contains the revised resolution text for issue 6311. The ballot opens at 3:00 PM DT Wednesday, April 14th, and closes at 12:00 PM EDT Wednesday, April 15th. ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversal_FTF_Vote_3.htm Regards, 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 Dave Stringer>