Issue 7316: Expected behavior of a non-conformant implementation (firewall-traversal-ftf) Source: (Ms. Rebecca Bergersen, becky(at)bergersen.org) Nature: Uncategorized Issue Severity: Summary: PROBLEM: It is not defined what happens if a non-conformant implementation receives a BiDir offer. RECOMMENDATION: State that a non-conformant implementation need not do anything - it may simply ignore the offer. Resolution: Revised Text: Actions taken: May 6, 2004: received issue Discussion: End of Annotations:===== ubject: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Date: Thu, 6 May 2004 18:20:15 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Thread-Index: AcQzuGVbs51v/mQLTU6+7ZYCUd03Jg== From: "Bergersen, Rebecca" To: , Cc: "Bergersen, Rebecca" PROBLEM: It is not defined what happens if a non-conformant implementation receives a BiDir offer. RECOMMENDATION: State that a non-conformant implementation need not do anything - it may simply ignore the offer. Merely formalizing an issue brought up by Jishnu Mukerji, Respectfully, 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, 6 May 2004 19:14:14 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: issues@omg.org, firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined What happens when you send a "non-conformant" implemenation a NegotiateSession message? -Polar On Thu, 6 May 2004, Bergersen, Rebecca wrote: > PROBLEM: > It is not defined what happens if a non-conformant implementation receives a BiDir offer. > > RECOMMENDATION: > State that a non-conformant implementation need not do anything - it may simply ignore the offer. > > Merely formalizing an issue brought up by Jishnu Mukerji, > Respectfully, > 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: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Date: Fri, 7 May 2004 10:04:46 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Thread-Index: AcQzv98ywJ5GKIzcR/G+PZ4hv9YlVwAfGS/g From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i47E5hFh012144 It would seem to follow that nothing happens - it is ignored. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, May 06, 2004 7:14 PM > To: Bergersen, Rebecca > Cc: issues@omg.org; firewall-traversal-ftf@omg.org > Subject: Re: Firewall Issue: Expected behavior of a non-conformant > implementation which receives a BiDir offer is undefined > > > > What happens when you send a "non-conformant" implemenation a > NegotiateSession message? > > -Polar > > On Thu, 6 May 2004, Bergersen, Rebecca wrote: > > > PROBLEM: > > It is not defined what happens if a non-conformant > implementation receives a BiDir offer. > > > > RECOMMENDATION: > > State that a non-conformant implementation need not do > anything - it may simply ignore the offer. > > > > Merely formalizing an issue brought up by Jishnu Mukerji, > > Respectfully, > > 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: Fri, 7 May 2004 10:21:29 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: issues@omg.org, firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined On Fri, 7 May 2004, Bergersen, Rebecca wrote: > It would seem to follow that nothing happens - it is ignored. Now, if you send a message to and endpoint that only understands it's going to receive GIOP Requests, LocateRequests, and CloseConnection message, I very seriously think it would be ignored. What would ORBIX do if I sent it a Negotiate Session message? -Polar > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Thursday, May 06, 2004 7:14 PM > > To: Bergersen, Rebecca > > Cc: issues@omg.org; firewall-traversal-ftf@omg.org > > Subject: Re: Firewall Issue: Expected behavior of a non-conformant > > implementation which receives a BiDir offer is undefined > > > > > > > > What happens when you send a "non-conformant" implemenation a > > NegotiateSession message? > > > > -Polar > > > > On Thu, 6 May 2004, Bergersen, Rebecca wrote: > > > > > PROBLEM: > > > It is not defined what happens if a non-conformant > > implementation receives a BiDir offer. > > > > > > RECOMMENDATION: > > > State that a non-conformant implementation need not do > > anything - it may simply ignore the offer. > > > > > > Merely formalizing an issue brought up by Jishnu Mukerji, > > > Respectfully, > > > 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: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Date: Fri, 7 May 2004 10:36:15 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Thread-Index: AcQ0Pp5bKxHKRZ0bSrWPoLSRM41uPwAAeXDQ From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i47EgRFh013192 Since the NegotiateSession message type is not yet fully implemented in Orbix, it would respond with a MessageError. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Friday, May 07, 2004 10:21 AM > To: Bergersen, Rebecca > Cc: issues@omg.org; firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: Expected behavior of a non-conformant > implementation which receives a BiDir offer is undefined > > > On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > > It would seem to follow that nothing happens - it is ignored. > > Now, if you send a message to and endpoint that only understands it's > going to receive GIOP Requests, LocateRequests, and CloseConnection > message, I very seriously think it would be ignored. > > What would ORBIX do if I sent it a Negotiate Session message? > > -Polar > > > --Rebecca > > > > > -----Original Message----- > > > From: Polar Humenn [mailto:polar@adiron.com] > > > Sent: Thursday, May 06, 2004 7:14 PM > > > To: Bergersen, Rebecca > > > Cc: issues@omg.org; firewall-traversal-ftf@omg.org > > > Subject: Re: Firewall Issue: Expected behavior of a non-conformant > > > implementation which receives a BiDir offer is undefined > > > > > > > > > > > > What happens when you send a "non-conformant" implemenation a > > > NegotiateSession message? > > > > > > -Polar > > > > > > On Thu, 6 May 2004, Bergersen, Rebecca wrote: > > > > > > > PROBLEM: > > > > It is not defined what happens if a non-conformant > > > implementation receives a BiDir offer. > > > > > > > > RECOMMENDATION: > > > > State that a non-conformant implementation need not do > > > anything - it may simply ignore the offer. > > > > > > > > Merely formalizing an issue brought up by Jishnu Mukerji, > > > > Respectfully, > > > > 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: Fri, 7 May 2004 10:46:55 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: issues@omg.org, firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined On Fri, 7 May 2004, Bergersen, Rebecca wrote: > Since the NegotiateSession message type is not yet fully implemented in > Orbix, it would respond with a MessageError. And then the connection goes kaput, right? Jishnu, I doubt very much that this sould like the optional "feature" you were getting at? -Polar > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Friday, May 07, 2004 10:21 AM > > To: Bergersen, Rebecca > > Cc: issues@omg.org; firewall-traversal-ftf@omg.org > > Subject: RE: Firewall Issue: Expected behavior of a non-conformant > > implementation which receives a BiDir offer is undefined > > > > > > On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > > > > It would seem to follow that nothing happens - it is ignored. > > > > Now, if you send a message to and endpoint that only understands it's > > going to receive GIOP Requests, LocateRequests, and CloseConnection > > message, I very seriously think it would be ignored. > > > > What would ORBIX do if I sent it a Negotiate Session message? > > > > -Polar > > > > > --Rebecca > > > > > > > -----Original Message----- > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > Sent: Thursday, May 06, 2004 7:14 PM > > > > To: Bergersen, Rebecca > > > > Cc: issues@omg.org; firewall-traversal-ftf@omg.org > > > > Subject: Re: Firewall Issue: Expected behavior of a non-conformant > > > > implementation which receives a BiDir offer is undefined > > > > > > > > > > > > > > > > What happens when you send a "non-conformant" implemenation a > > > > NegotiateSession message? > > > > > > > > -Polar > > > > > > > > On Thu, 6 May 2004, Bergersen, Rebecca wrote: > > > > > > > > > PROBLEM: > > > > > It is not defined what happens if a non-conformant > > > > implementation receives a BiDir offer. > > > > > > > > > > RECOMMENDATION: > > > > > State that a non-conformant implementation need not do > > > > anything - it may simply ignore the offer. > > > > > > > > > > Merely formalizing an issue brought up by Jishnu Mukerji, > > > > > Respectfully, > > > > > 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 > > > ------------------------------------------------------------------- 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: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Date: Fri, 7 May 2004 11:01:58 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Thread-Index: AcQ0QitpPKS6lpJhRn+3ONACpHCh9AAALvIw From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i47F4lFh013752 You asked about what Orbix would do right now. It would have been an illegal message in the first place, since the current implementation is GIOP 1.2 compliant and NegotiateSession is a 1.3 or 1.4 message type. However, the proper behavior in an non-conformant GIOP 1.3 or 1.4 implementation should be to just ignore it and not send an error. Of course, if a non-conformant implementation started getting BiDir challenges or something, it might think there was a security implication, return an error and shut down the connection even if the standard says to ignore the NegotiateSession message. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Friday, May 07, 2004 10:47 AM > To: Bergersen, Rebecca > Cc: issues@omg.org; firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: Expected behavior of a non-conformant > implementation which receives a BiDir offer is undefined > > > On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > > Since the NegotiateSession message type is not yet fully > implemented in > > Orbix, it would respond with a MessageError. > > And then the connection goes kaput, right? > > Jishnu, I doubt very much that this sould like the optional > "feature" you > were getting at? > > -Polar > > > --Rebecca > > > > > -----Original Message----- > > > From: Polar Humenn [mailto:polar@adiron.com] > > > Sent: Friday, May 07, 2004 10:21 AM > > > To: Bergersen, Rebecca > > > Cc: issues@omg.org; firewall-traversal-ftf@omg.org > > > Subject: RE: Firewall Issue: Expected behavior of a non-conformant > > > implementation which receives a BiDir offer is undefined > > > > > > > > > On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > > > > > > It would seem to follow that nothing happens - it is ignored. > > > > > > Now, if you send a message to and endpoint that only > understands it's > > > going to receive GIOP Requests, LocateRequests, and > CloseConnection > > > message, I very seriously think it would be ignored. > > > > > > What would ORBIX do if I sent it a Negotiate Session message? > > > > > > -Polar > > > > > > > --Rebecca > > > > > > > > > -----Original Message----- > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > Sent: Thursday, May 06, 2004 7:14 PM > > > > > To: Bergersen, Rebecca > > > > > Cc: issues@omg.org; firewall-traversal-ftf@omg.org > > > > > Subject: Re: Firewall Issue: Expected behavior of a > non-conformant > > > > > implementation which receives a BiDir offer is undefined > > > > > > > > > > > > > > > > > > > > What happens when you send a "non-conformant" implemenation a > > > > > NegotiateSession message? > > > > > > > > > > -Polar > > > > > > > > > > On Thu, 6 May 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > PROBLEM: > > > > > > It is not defined what happens if a non-conformant > > > > > implementation receives a BiDir offer. > > > > > > > > > > > > RECOMMENDATION: > > > > > > State that a non-conformant implementation need not do > > > > > anything - it may simply ignore the offer. > > > > > > > > > > > > Merely formalizing an issue brought up by Jishnu Mukerji, > > > > > > Respectfully, > > > > > > 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 > > > > > > > ------------------------------------------------------------------- > 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: Fri, 7 May 2004 13:01:54 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined On Fri, 7 May 2004, Jishnu Mukerji wrote: > Not quite. I think I covered the correct behavior specification in my > previous message. > > >If I'm a GIOP 1.3/4 state machine, I have to accept and gobble any BOGUS > >message that conforms to a GIOP header? > > No, I don't think you have to accept any old message. However, it is > reasonable to require acceptance of all legitimate GIOP messages that > are specified for that minor version of GIOP, and then be free to ignore > those that are of concern only for the optional conformance point that > is presumably not conformed to by the implementation. > Using this rule, and assuming that the NegotiateSession message becomes > a valid GIOP message in GIOP 1,.4, it would be OK for a GIOP 1.3 > implementation to return a MessageError if it happens to receive a > NegotiateSession message. But it would not be OK for a GIOP 1.4 > implementation to send a Message Error message upon receiving a > NegotateSession message. It's hard to test conformance on that point from a protocol point of view, since you can send a Message Error message at any time for any reason. > However, if the implementation does not conform > to the BiDir optional conformance point, it would be OK for it to simply > ignore that message. > > >What, are we trying to make GIOP into a friggin web server? > > Hopefully not ;-) Getting there. :) > >What if the magic isn't "GIOP"? > > Rhetorically speaking, the sender should be run up a flagpole and shot > ;-) Nah just send back a MessageError. Okay, that makes more sense, I must have misinterpreted some remarks. > >What if the header ups the version number? > > That would be an interesting instance of an "active header" :-) Such > headers would be very difficult to deal with, since they are able change > their own version numbers at any random point 8-} More seriously, I > don't understand how a header ups its own version number. Until now I > had been under the impression that a header is a static data structure > the contents of which are set by the protocol engine that originates the > message and once the contents are set they remain unchanged through the > life of the header (unless some other active agent changes the contents). Well, GIOP 1.3/4 has to accept GIOP 1.0 messages, Does it not? Then you have to send back 1.0 messages. Once you see a GIOP 1.1 message header, then the channel ups to that, and you no longer send back 1.0 messages. My question, predicated on that previous implication that ignoring of any bogus message that doesn't cause a framing problem, was do bogus messages factor into that version scheme? Furthermore, if I accept a NegotiationSession message and ignore it, do I now have to send back GIOP 1.4 messages? None of this stuff is fully thought out. This specification so incomplete. -Polar > Jishnu. > > > > > > > > >>Of course, if a non-conformant implementation started getting BiDir > >>challenges or something, it might think there was a security > >>implication, return an error and shut down the connection even if the > >>standard says to ignore the NegotiateSession message. > >> > >> > > > >Okay, so why send replies to bad BiDirOffers? Why not just drop the > >connection? Since that's all it's going to buy you anyway, just one > >crapped up connection you can no longer use. > > > >-Polar > > > > > > > >> --Rebecca > >> > >> > >> > >> > >> > >>>-----Original Message----- > >>>From: Polar Humenn [mailto:polar@adiron.com] > >>>Sent: Friday, May 07, 2004 10:47 AM > >>>To: Bergersen, Rebecca > >>>Cc: issues@omg.org; firewall-traversal-ftf@omg.org > >>>Subject: RE: Firewall Issue: Expected behavior of a non-conformant > >>>implementation which receives a BiDir offer is undefined > >>> > >>> > >>>On Fri, 7 May 2004, Bergersen, Rebecca wrote: > >>> > >>> > >>> > >>>>Since the NegotiateSession message type is not yet fully > >>>> > >>>> > >>>implemented in > >>> > >>> > >>>>Orbix, it would respond with a MessageError. > >>>> > >>>> > >>>And then the connection goes kaput, right? > >>> > >>>Jishnu, I doubt very much that this sould like the optional > >>>"feature" you > >>>were getting at? > >>> > >>>-Polar > >>> > >>> > >>> > >>>> --Rebecca > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Polar Humenn [mailto:polar@adiron.com] > >>>>>Sent: Friday, May 07, 2004 10:21 AM > >>>>>To: Bergersen, Rebecca > >>>>>Cc: issues@omg.org; firewall-traversal-ftf@omg.org > >>>>>Subject: RE: Firewall Issue: Expected behavior of a non-conformant > >>>>>implementation which receives a BiDir offer is undefined > >>>>> > >>>>> > >>>>>On Fri, 7 May 2004, Bergersen, Rebecca wrote: > >>>>> > >>>>> > >>>>> > >>>>>>It would seem to follow that nothing happens - it is ignored. > >>>>>> > >>>>>> > >>>>>Now, if you send a message to and endpoint that only > >>>>> > >>>>> > >>>understands it's > >>> > >>> > >>>>>going to receive GIOP Requests, LocateRequests, and > >>>>> > >>>>> > >>>CloseConnection > >>> > >>> > >>>>>message, I very seriously think it would be ignored. > >>>>> > >>>>>What would ORBIX do if I sent it a Negotiate Session message? > >>>>> > >>>>>-Polar > >>>>> > >>>>> > >>>>> > >>>>>>--Rebecca > >>>>>> > >>>>>> > >>>>>> > >>>>>>>-----Original Message----- > >>>>>>>From: Polar Humenn [mailto:polar@adiron.com] > >>>>>>>Sent: Thursday, May 06, 2004 7:14 PM > >>>>>>>To: Bergersen, Rebecca > >>>>>>>Cc: issues@omg.org; firewall-traversal-ftf@omg.org > >>>>>>>Subject: Re: Firewall Issue: Expected behavior of a > >>>>>>> > >>>>>>> > >>>non-conformant > >>> > >>> > >>>>>>>implementation which receives a BiDir offer is undefined > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>What happens when you send a "non-conformant" implemenation a > >>>>>>>NegotiateSession message? > >>>>>>> > >>>>>>>-Polar > >>>>>>> > >>>>>>>On Thu, 6 May 2004, Bergersen, Rebecca wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>PROBLEM: > >>>>>>>>It is not defined what happens if a non-conformant > >>>>>>>> > >>>>>>>> > >>>>>>>implementation receives a BiDir offer. > >>>>>>> > >>>>>>> > >>>>>>>>RECOMMENDATION: > >>>>>>>>State that a non-conformant implementation need not do > >>>>>>>> > >>>>>>>> > >>>>>>>anything - it may simply ignore the offer. > >>>>>>> > >>>>>>> > >>>>>>>>Merely formalizing an issue brought up by Jishnu Mukerji, > >>>>>>>>Respectfully, > >>>>>>>>Rebecca Bergersen > >>>>>>>> > >>>>>>>> > ------------------------------------------------------------------- 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: Fri, 07 May 2004 11:53:24 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: firewall-traversal-ftf@omg.org Cc: Polar Humenn , "Bergersen, Rebecca" Subject: Re: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Polar Humenn wrote: On Fri, 7 May 2004, Bergersen, Rebecca wrote: Since the NegotiateSession message type is not yet fully implemented in Orbix, it would respond with a MessageError. And then the connection goes kaput, right? Jishnu, I doubt very much that this sould like the optional "feature" you were getting at? -Polar Right. The expected behavior from an implementation of GIOP 1.4 (which is where this new BiDir is likely to land up) that does not claim compliance to the optional BiDir compliance point should be that that NegotiateSession message is simply swallowed and no response is sent beck - not even an error response. The fact that the implementation is of 1.4 implies it is aware of the existence of this new message type. The fact that the implementation does not implement this optional conformance point means that it is free to ignore that message. We need to add clarification text at the appropriate place(s) to state this, if a majority of the FTF agrees of course. Naturally, for any ORB that claims to be GIOP 1.x (x < 4) conformant, it can fully expect never to receive a NegotiateSession message, and in case it does receive one, it would be fully within its rights to throw a tantrum about it, i.e. respond with a MessageError, which would seem to be the situation that Orbix is in at present. --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Friday, May 07, 2004 10:21 AM To: Bergersen, Rebecca Cc: issues@omg.org; firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined On Fri, 7 May 2004, Bergersen, Rebecca wrote: It would seem to follow that nothing happens - it is ignored. Now, if you send a message to and endpoint that only understands it's going to receive GIOP Requests, LocateRequests, and CloseConnection message, I very seriously think it would be ignored. What would ORBIX do if I sent it a Negotiate Session message? -Polar --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Thursday, May 06, 2004 7:14 PM To: Bergersen, Rebecca Cc: issues@omg.org; firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined What happens when you send a "non-conformant" implemenation a NegotiateSession message? -Polar On Thu, 6 May 2004, Bergersen, Rebecca wrote: PROBLEM: It is not defined what happens if a non-conformant implementation receives a BiDir offer. RECOMMENDATION: State that a non-conformant implementation need not do anything - it may simply ignore the offer. Merely formalizing an issue brought up by Jishnu Mukerji, Respectfully, 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 ------------------------------------------------------------------- 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 -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Management Software Organization Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Date: Fri, 07 May 2004 12:07:30 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: firewall-traversal-ftf@omg.org Cc: Polar Humenn , "Bergersen, Rebecca" Subject: Re: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Polar Humenn wrote: On Fri, 7 May 2004, Bergersen, Rebecca wrote: You asked about what Orbix would do right now. It would have been an illegal message in the first place, since the current implementation is GIOP 1.2 compliant and NegotiateSession is a 1.3 or 1.4 message type. However, the proper behavior in an non-conformant GIOP 1.3 or 1.4 implementation should be to just ignore it and not send an error. You've got to be kidding me! Jishnu is this correct? Not quite. I think I covered the correct behavior specification in my previous message. If I'm a GIOP 1.3/4 state machine, I have to accept and gobble any BOGUS message that conforms to a GIOP header? No, I don't think you have to accept any old message. However, it is reasonable to require acceptance of all legitimate GIOP messages that are specified for that minor version of GIOP, and then be free to ignore those that are of concern only for the optional conformance point that is presumably not conformed to by the implementation. Using this rule, and assuming that the NegotiateSession message becomes a valid GIOP message in GIOP 1,.4, it would be OK for a GIOP 1.3 implementation to return a MessageError if it happens to receive a NegotiateSession message. But it would not be OK for a GIOP 1.4 implementation to send a Message Error message upon receiving a NegotateSession message. However, if the implementation does not conform to the BiDir optional conformance point, it would be OK for it to simply ignore that message. What, are we trying to make GIOP into a friggin web server? Hopefully not ;-) What if the magic isn't "GIOP"? Rhetorically speaking, the sender should be run up a flagpole and shot ;-) Nah just send back a MessageError. What if the header ups the version number? That would be an interesting instance of an "active header" :-) Such headers would be very difficult to deal with, since they are able change their own version numbers at any random point 8-} More seriously, I don't understand how a header ups its own version number. Until now I had been under the impression that a header is a static data structure the contents of which are set by the protocol engine that originates the message and once the contents are set they remain unchanged through the life of the header (unless some other active agent changes the contents). Jishnu. Of course, if a non-conformant implementation started getting BiDir challenges or something, it might think there was a security implication, return an error and shut down the connection even if the standard says to ignore the NegotiateSession message. Okay, so why send replies to bad BiDirOffers? Why not just drop the connection? Since that's all it's going to buy you anyway, just one crapped up connection you can no longer use. -Polar --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Friday, May 07, 2004 10:47 AM To: Bergersen, Rebecca Cc: issues@omg.org; firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined On Fri, 7 May 2004, Bergersen, Rebecca wrote: Since the NegotiateSession message type is not yet fully implemented in Orbix, it would respond with a MessageError. And then the connection goes kaput, right? Jishnu, I doubt very much that this sould like the optional "feature" you were getting at? -Polar --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Friday, May 07, 2004 10:21 AM To: Bergersen, Rebecca Cc: issues@omg.org; firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined On Fri, 7 May 2004, Bergersen, Rebecca wrote: It would seem to follow that nothing happens - it is ignored. Now, if you send a message to and endpoint that only understands it's going to receive GIOP Requests, LocateRequests, and CloseConnection message, I very seriously think it would be ignored. What would ORBIX do if I sent it a Negotiate Session message? -Polar --Rebecca -----Original Message----- From: Polar Humenn [mailto:polar@adiron.com] Sent: Thursday, May 06, 2004 7:14 PM To: Bergersen, Rebecca Cc: issues@omg.org; firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined What happens when you send a "non-conformant" implemenation a NegotiateSession message? -Polar On Thu, 6 May 2004, Bergersen, Rebecca wrote: PROBLEM: It is not defined what happens if a non-conformant implementation receives a BiDir offer. RECOMMENDATION: State that a non-conformant implementation need not do anything - it may simply ignore the offer. Merely formalizing an issue brought up by Jishnu Mukerji, Respectfully, Rebecca Bergersen Date: Fri, 7 May 2004 13:01:54 -0400 (EDT) From: Polar Humenn To: firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined On Fri, 7 May 2004, Jishnu Mukerji wrote: > Not quite. I think I covered the correct behavior specification in my > previous message. > > >If I'm a GIOP 1.3/4 state machine, I have to accept and gobble any BOGUS > >message that conforms to a GIOP header? > > No, I don't think you have to accept any old message. However, it is > reasonable to require acceptance of all legitimate GIOP messages that > are specified for that minor version of GIOP, and then be free to ignore > those that are of concern only for the optional conformance point that > is presumably not conformed to by the implementation. > Using this rule, and assuming that the NegotiateSession message becomes > a valid GIOP message in GIOP 1,.4, it would be OK for a GIOP 1.3 > implementation to return a MessageError if it happens to receive a > NegotiateSession message. But it would not be OK for a GIOP 1.4 > implementation to send a Message Error message upon receiving a > NegotateSession message. It's hard to test conformance on that point from a protocol point of view, since you can send a Message Error message at any time for any reason. > However, if the implementation does not conform > to the BiDir optional conformance point, it would be OK for it to simply > ignore that message. > > >What, are we trying to make GIOP into a friggin web server? > > Hopefully not ;-) Getting there. :) > >What if the magic isn't "GIOP"? > > Rhetorically speaking, the sender should be run up a flagpole and shot > ;-) Nah just send back a MessageError. Okay, that makes more sense, I must have misinterpreted some remarks. > >What if the header ups the version number? > > That would be an interesting instance of an "active header" :-) Such > headers would be very difficult to deal with, since they are able change > their own version numbers at any random point 8-} More seriously, I > don't understand how a header ups its own version number. Until now I > had been under the impression that a header is a static data structure > the contents of which are set by the protocol engine that originates the > message and once the contents are set they remain unchanged through the > life of the header (unless some other active agent changes the contents). Well, GIOP 1.3/4 has to accept GIOP 1.0 messages, Does it not? Then you have to send back 1.0 messages. Once you see a GIOP 1.1 message header, then the channel ups to that, and you no longer send back 1.0 messages. My question, predicated on that previous implication that ignoring of any bogus message that doesn't cause a framing problem, was do bogus messages factor into that version scheme? Furthermore, if I accept a NegotiationSession message and ignore it, do I now have to send back GIOP 1.4 messages? None of this stuff is fully thought out. This specification so incomplete. -Polar > Jishnu. > > > > > > > > >>Of course, if a non-conformant implementation started getting BiDir > >>challenges or something, it might think there was a security > >>implication, return an error and shut down the connection even if the > >>standard says to ignore the NegotiateSession message. > >> > >> > > > >Okay, so why send replies to bad BiDirOffers? Why not just drop the > >connection? Since that's all it's going to buy you anyway, just one > >crapped up connection you can no longer use. > > > >-Polar > > > > > > > >> --Rebecca > >> > >> > >> > >> > >> > >>>-----Original Message----- > >>>From: Polar Humenn [mailto:polar@adiron.com] > >>>Sent: Friday, May 07, 2004 10:47 AM > >>>To: Bergersen, Rebecca > >>>Cc: issues@omg.org; firewall-traversal-ftf@omg.org > >>>Subject: RE: Firewall Issue: Expected behavior of a non-conformant > >>>implementation which receives a BiDir offer is undefined > >>> > >>> > >>>On Fri, 7 May 2004, Bergersen, Rebecca wrote: > >>> > >>> > >>> > >>>>Since the NegotiateSession message type is not yet fully > >>>> > >>>> > >>>implemented in > >>> > >>> > >>>>Orbix, it would respond with a MessageError. > >>>> > >>>> > >>>And then the connection goes kaput, right? > >>> > >>>Jishnu, I doubt very much that this sould like the optional > >>>"feature" you > >>>were getting at? > >>> > >>>-Polar > >>> > >>> > >>> > >>>> --Rebecca > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Polar Humenn [mailto:polar@adiron.com] > >>>>>Sent: Friday, May 07, 2004 10:21 AM > >>>>>To: Bergersen, Rebecca > >>>>>Cc: issues@omg.org; firewall-traversal-ftf@omg.org > >>>>>Subject: RE: Firewall Issue: Expected behavior of a non-conformant > >>>>>implementation which receives a BiDir offer is undefined > >>>>> > >>>>> > >>>>>On Fri, 7 May 2004, Bergersen, Rebecca wrote: > >>>>> > >>>>> > >>>>> > >>>>>>It would seem to follow that nothing happens - it is ignored. > >>>>>> > >>>>>> > >>>>>Now, if you send a message to and endpoint that only > >>>>> > >>>>> > >>>understands it's > >>> > >>> > >>>>>going to receive GIOP Requests, LocateRequests, and > >>>>> > >>>>> > >>>CloseConnection > >>> > >>> > >>>>>message, I very seriously think it would be ignored. > >>>>> > >>>>>What would ORBIX do if I sent it a Negotiate Session message? > >>>>> > >>>>>-Polar > >>>>> > >>>>> > >>>>> > >>>>>>--Rebecca > >>>>>> > >>>>>> > >>>>>> > >>>>>>>-----Original Message----- > >>>>>>>From: Polar Humenn [mailto:polar@adiron.com] > >>>>>>>Sent: Thursday, May 06, 2004 7:14 PM > >>>>>>>To: Bergersen, Rebecca > >>>>>>>Cc: issues@omg.org; firewall-traversal-ftf@omg.org > >>>>>>>Subject: Re: Firewall Issue: Expected behavior of a > >>>>>>> > >>>>>>> > >>>non-conformant > >>> > >>> > >>>>>>>implementation which receives a BiDir offer is undefined > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>What happens when you send a "non-conformant" implemenation a > >>>>>>>NegotiateSession message? > >>>>>>> > >>>>>>>-Polar > >>>>>>> > >>>>>>>On Thu, 6 May 2004, Bergersen, Rebecca wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>PROBLEM: > >>>>>>>>It is not defined what happens if a non-conformant > >>>>>>>> > >>>>>>>> > >>>>>>>implementation receives a BiDir offer. > >>>>>>> > >>>>>>> > >>>>>>>>RECOMMENDATION: > >>>>>>>>State that a non-conformant implementation need not do > >>>>>>>> > >>>>>>>> > >>>>>>>anything - it may simply ignore the offer. > >>>>>>> > >>>>>>> > >>>>>>>>Merely formalizing an issue brought up by Jishnu Mukerji, > >>>>>>>>Respectfully, > >>>>>>>>Rebecca Bergersen > >>>>>>>> > >>>>>>>> > ------------------------------------------------------------------- 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: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Date: Fri, 7 May 2004 10:40:51 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Thread-Index: AcQ0Vmidi9dEQ+cKSUqCgPBz40634gAAIsQw From: "Dave Stringer" To: "Jishnu Mukerji" , Cc: "Polar Humenn" , "Bergersen, Rebecca" X-OriginalArrivalTime: 07 May 2004 17:40:50.0884 (UTC) FILETIME=[704A6040:01C4345A] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i47HhAFh017422 Jishnu wrote: > Right. The expected behavior from an implementation of GIOP 1.4 (which > is where this new BiDir is likely to land up) that does not claim > compliance to the optional BiDir compliance point should be that that > NegotiateSession message is simply swallowed and no response is sent > beck - not even an error response. The fact that the implementation is > of 1.4 implies it is aware of the existence of this new message type. > The fact that the implementation does not implement this optional > conformance point means that it is free to ignore that message. We need > to add clarification text at the appropriate place(s) to state this, if > a majority of the FTF agrees of course. Another subtle distinction in terminology! CORBA specifications have "compliance" sections in which we see a description of one or more "compliance points", in terms of subsections of the specification. But what is a "conformance" point as used above? RM-ODP (doesn't matter what this was) defines "conformance" points as denoted "reference" points. There are two kinds of reference points pertinent to this discussion "programmatic" and "protocol". That is the "API for the policies" and a (poorly defined - IMHO) "subset of a future GIOP minor version" respectively. So what is an optional conformance point? Jishnu has defined the interactions at the protocol reference point for "non-compliant implementations" and so this, in itself, is no longer optional. The optionality arises with the programmatic reference point. In particular with the policy API, e.g. does a compliant ORB have to provide the API to create and/or apply an ...Accept policy and if it does provide such APIs is it allowed to return INVALID_POLICY exceptions if the value is ALLOW? Talk of "optionality" in a protocol is a bad idea. Optionailty is here used at the level of "feature compliance". It refers to the linkage between the API and the protocol. It should be manifested at the API. Dave Date: Fri, 07 May 2004 14:07:09 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Polar Humenn Cc: firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Expected behavior of a non-conformant implementation which receives a BiDir offer is undefined Polar Humenn wrote: On Fri, 7 May 2004, Jishnu Mukerji wrote: Not quite. I think I covered the correct behavior specification in my previous message. If I'm a GIOP 1.3/4 state machine, I have to accept and gobble any BOGUS message that conforms to a GIOP header? No, I don't think you have to accept any old message. However, it is reasonable to require acceptance of all legitimate GIOP messages that are specified for that minor version of GIOP, and then be free to ignore those that are of concern only for the optional conformance point that is presumably not conformed to by the implementation. Using this rule, and assuming that the NegotiateSession message becomes a valid GIOP message in GIOP 1,.4, it would be OK for a GIOP 1.3 implementation to return a MessageError if it happens to receive a NegotiateSession message. But it would not be OK for a GIOP 1.4 implementation to send a Message Error message upon receiving a NegotateSession message. It's hard to test conformance on that point from a protocol point of view, since you can send a Message Error message at any time for any reason. I was just trying to state what would be reasonable behavior. I would tend to agree that GIOP is not specified tightly enough for us to be able to test some of this meaningfully - thr problem being the wishy-washiness (apparently) of the prescription of circumstances under which ErrorMessage can be sent. Also, it is hard to test in general, the absence of an act of sending message from the other end of an unreliable connection.. However, if the implementation does not conform to the BiDir optional conformance point, it would be OK for it to simply ignore that message. What, are we trying to make GIOP into a friggin web server? Hopefully not ;-) Getting there. :) What if the magic isn't "GIOP"? Rhetorically speaking, the sender should be run up a flagpole and shot ;-) Nah just send back a MessageError. Okay, that makes more sense, I must have misinterpreted some remarks. What if the header ups the version number? That would be an interesting instance of an "active header" :-) Such headers would be very difficult to deal with, since they are able change their own version numbers at any random point 8-} More seriously, I don't understand how a header ups its own version number. Until now I had been under the impression that a header is a static data structure the contents of which are set by the protocol engine that originates the message and once the contents are set they remain unchanged through the life of the header (unless some other active agent changes the contents). Well, GIOP 1.3/4 has to accept GIOP 1.0 messages, Does it not? Then you have to send back 1.0 messages. Once you see a GIOP 1.1 message header, then the channel ups to that, and you no longer send back 1.0 messages. My question, predicated on that previous implication that ignoring of any bogus message that doesn't cause a framing problem, was do bogus messages factor into that version scheme? By bogus message do you mean a message that actually has a valid GIOP header but is bogus otherwise for whatever reason? Or do you mean something else? Furthermore, if I accept a NegotiationSession message and ignore it, do I now have to send back GIOP 1.4 messages? That is a good question. My first blush answer is that the only point where you could send a GIOP 1.4 message would be at the point where you can be absolutely sure that the NegtiateSession message was accepted and ignored. Figuring out the exact circumstances under which you can be sure of this may or may not be easy to characterize. So a safe course might be to say that you do not send back a 1.4 message until you have a positive proof that the other side is accepting and responding to 1.4 messages, say in the form of a reply message of the 1.4 type. Basically follow the rule paraphrased as you stated above .... "Once you "see" a 1.4 header send back 1.4" ..... since in not receiving a response you do not see any header don't do anything. This is just my "off the top of my head" response. It bears some further thought and discussion before stating something definitive. Jishnu. None of this stuff is fully thought out. This specification so incomplete. -Polar Date: Mon, 10 May 2004 12:40:12 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: firewall-traversal-ftf@omg.org Cc: Juergen Boldt Subject: Re: issues 7316 -- Firewall Traversal FTF issues Juergen Boldt wrote: This is issue # 7316 Expected behavior of a non-conformant implementation PROBLEM: It is not defined what happens if a non-conformant implementation receives a BiDir offer. RECOMMENDATION: State that a non-conformant implementation need not do anything - it may simply ignore the offer. As I stated it the issue is more specific. It is not just any non-conformant implementation that I am worried about. It is those implementations that are GIOP 1.4 compliant but do not implement the optional BiDir compliance point. Also you need to say a bit more than "need not do anything". I think a GIOP 1.4 compliant implementation should recognize that a NegotiateSession message is a valid GIOP message and hence not send back a MessageError message. Other than that it should be able to ignore everything that has to do with BiDir i.e. ServiceContexts etc. as per the email discussion late last week. Jishnu.