Issue 3303: An ORB should not accept an IOR with no usable profiles (interop) Source: Xerox (Mr. William C. Janssen, Jr., janssen(at)parc.xerox.com) Nature: Uncategorized Issue Severity: Summary: ORBs should be required to reject IORs that do not contain any profile that the ORB can use Resolution: accomodated by proposed change from Issue 3234. Revised Text: Actions taken: February 9, 2000: received issue October 4, 2000: closed issue Discussion: End of Annotations:===== To: Michi Henning cc: Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: Your message of "Tue, 08 Feb 2000 20:39:40 PST." From: Bill Janssen Message-Id: <00Feb9.122709pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 12:27:18 PST Content-Type: text X-UIDL: GSC!!0KH!!OY;!!#ZJ!! > Given that, the requirement not to drop profiles is entirely consistent > with the CORBA architecture and can be implemented without pain by > commercial ORBs. Further, imposing the requirement will improve > interoperability and make it easy to add new protocols without breaking > existing implementations. Sorry, Michi, this isn't about dropping profiles -- that's another discussion. This is about whether an ORB should accept object references that contain no profiles it recognizes. Bill From: "Carlos O'Ryan" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: <14497.56852.54807.647295@kelvar.ece.uci.edu> Date: Wed, 9 Feb 2000 13:37:24 -0800 (PST) To: Bill Janssen Cc: Michi Henning , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: <00Feb9.122709pst."3647"@watson.parc.xerox.com> References: <00Feb9.122709pst."3647"@watson.parc.xerox.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Sender: "Carlos O'Ryan" Content-Type: text/plain; charset=us-ascii X-UIDL: o6\!!PW"!!]]_d9+X6!! Hi, Bill Janssen writes: > > Sorry, Michi, this isn't about dropping profiles -- that's another > discussion. This is about whether an ORB should accept object > references that contain no profiles it recognizes. So why should the ORB drop that IOR? It can certainly store it, and pass it along to someplace else. And there are good use-cases for that behavior: Naming, Trading or other lookup services. It just doesn't make sense to me to prohibit something that: 1) It is useful 2) It is (relatively) easy to implement. -- Carlos O'Ryan (coryan@uci.edu) #include #include // "Speak softly and carry a megawatt laser" 1024D/46936992 33B3 C4ED AA90 FA0F E8D1 D509 FE5E 8F79 4693 6992 Date: Thu, 10 Feb 2000 07:49:02 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: <00Feb9.122709pst."3647"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: mFld9H&'e9AZe!!9,f!! On Wed, 9 Feb 2000, Bill Janssen wrote: > > Given that, the requirement not to drop profiles is entirely consistent > > with the CORBA architecture and can be implemented without pain by > > commercial ORBs. Further, imposing the requirement will improve > > interoperability and make it easy to add new protocols without breaking > > existing implementations. > > Sorry, Michi, this isn't about dropping profiles -- that's another > discussion. This is about whether an ORB should accept object > references that contain no profiles it recognizes. I see no reason for an ORB to reject an IOR that contains no profiles it recognizes as long as the IOR isn't used to make an invocation. The IOR should be rejected at the point at which an invocation is made, not at the point at which it is received by the ORB. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <38A1E266.F12F7160@floorboard.com> Date: Wed, 09 Feb 2000 13:55:50 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Michi Henning , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) References: <00Feb9.122709pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: H;?e9DJG!!]i0!!>P>e9 Bill Janssen wrote: > > > Given that, the requirement not to drop profiles is entirely > consistent > > with the CORBA architecture and can be implemented without pain by > > commercial ORBs. Further, imposing the requirement will improve > > interoperability and make it easy to add new protocols without > breaking > > existing implementations. > > Sorry, Michi, this isn't about dropping profiles -- that's another > discussion. This is about whether an ORB should accept object > references that contain no profiles it recognizes. But you haven't demonstrated any harm done by an ORB that accepts an object reference containing only unknown profiles. This seems to violate the "liberal in what you accept" principle. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 09 Feb 2000 18:19:46 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Boldt Subject: Re: Issue 2457 redux References: <00Feb9.123041pst."3647"@watson.parc.xerox.com> <4.1.20000209180646.009b97e0@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii X-UIDL: N6p!!6A'e9S3"e9?9Ae9 It is more like 3234 than 3235. Better still do the following. Make a new issue with the following summary: ORBs should be required to reject IORs that do not contain any profile that the ORB can use. make Bill Janssen the originator of the issue, and add this thread to it, starting from Bill Janssen's message to Michi saying that the discussion was not about dropping profiles but about rejecting IORs as they are received. Thanks, Jishnu. Juergen Boldt wrote: Jishnu, you guys lost me here...this is either issue 3234 or 3235 -Juergen At 05:17 PM 2/9/2000 -0500, you wrote: >Bill Janssen wrote: > >> > Do interoperable ORBs have the right to reject >> > 3'rd party Objects which ought to be reprocessed >> > and which do not need to be invoked (like beeing >> > stored in a 3'rd party Naming- or Trader Service)? >> >> Karsten, that's exactly the point I've been trying to make. I think >> that we should explicitly say in the Interoperability spec that an ORB >> *must* reject any object reference which does not contain any profiles >> usable by that ORB. The particular application code involved is >> immaterial. > >If we say that, then it would imply that any ORB that provides name services >can >store only such IORs that contains at least one profile usable by that ORB. Why >would that be desirable? > >I can understand an ORB raising an exception when an attempt is made to invoke >an operation through an IOR that does not contain any profiles that are usable, >but I am somewhat dubious about an requirement for rejection of an IOR that >contains no profile that the ORB can use at the point it receives the IOR. > >Seems like the issue is one of whether an eager binding regime is being used or >a lazy binding regime is being used. it seems that the rejection at receipt of >an IOR is an issue only if an eager binding regime is used. > >This seems to preclude reception of IORs that the ORB could use in the future >due to addition of protocol facilities, and it also seems to make the ORB less >than useful as a host for a general naming or trading service. Unless I hear >some extremely persuasive argument to convince me otherwise, my tendency would >be to vote against such a rejection requirement. I would like to see a >clarification made about what exception raising action the ORB should take at >the point of invocation of an operation if it finds no usable profile at that >point. > >Comments? > >Jishnu. >-- >Jishnu Mukerji >Systems Architect > >Email: jis@fpk.hp.com Hewlett-Packard EIAL, >Tel: +1 973 443 7528 300 Campus Drive, 2E-62, >Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > > ================================================================ Juergen Boldt Senior Member of Technical Staff Object Management Group Tel. +1-781 444 0404 ext. 132 250 First Avenue, Suite 201 Fax: +1-781 444 0320 Needham, MA 02494, USA Email: juergen@omg.org ================================================================ -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jbiggar@corvette.floorboard.com Message-ID: <38A1F45C.2253F3A9@floorboard.com> Date: Wed, 09 Feb 2000 15:12:28 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: Bill Janssen , Michi Henning , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) References: <00Feb9.122709pst."3647"@watson.parc.xerox.com> <38A1E918.379CBD75@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: N:>e9;DR!!%p$e9+ > Bill Janssen wrote: > > > > Given that, the requirement not to drop profiles is entirely > consistent > > > with the CORBA architecture and can be implemented without pain > by > > > commercial ORBs. Further, imposing the requirement will improve > > > interoperability and make it easy to add new protocols without > breaking > > > existing implementations. > > > > Sorry, Michi, this isn't about dropping profiles -- that's another > > discussion. This is about whether an ORB should accept object > > references that contain no profiles it recognizes. > > Ahh, I see. So you would like to see us disallow even acceptance of > IORs that > for some reason the ORB is unable to find a usable profile in, at > the time that > it receives the IOR. This seems to relate more to part b of 2457, > than to part > a. > > Just to come up with a contrived example to try to understand this a > bit better, > suppose the ORB receives an IOR which contains a single secure IIOP > profile that > contains a time based validity restrictions such that an invocation > can be made > using it only between 9am and 5pm local time. Suppose this is > received at 8pm > local time. Would the ORB be required to reject this because the IOR > contains no > profile that is usable at the time it is received? In all fairness, Bill was arguing against IORs with unrecognized profiles, not ones that have profiles that are currently unusable due to policy. Even so, I don't agree with the argument. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org To: "Carlos O'Ryan" cc: Michi Henning , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: Your message of "Wed, 09 Feb 2000 13:38:27 PST." <14497.56852.54807.647295@kelvar.ece.uci.edu> From: Bill Janssen Message-Id: <00Feb9.153510pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 15:35:19 PST Content-Type: text X-UIDL: V8h!!b=H!!\22e9f>_!! > It just doesn't make sense to me to prohibit something that: > > 1) It is useful > 2) It is (relatively) easy to implement. I realize that the OMG isn't big on architectural integrity, but: you don't do this because it violates the architecture you've developed. What interoperability gave us was the guarantee that if an ORB accepted an object reference from another ORB, that object reference would be `live'; that is, the application code written against that accepting ORB could use that object. This thing you seem to like violates that principle. Bill To: Stefan Wengi cc: karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Wed, 09 Feb 2000 13:47:03 PST." <38A1E049.229D4855@adnovum.com> From: Bill Janssen Message-Id: <00Feb9.153649pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 15:36:59 PST Content-Type: text X-UIDL: I?!e9>I6e9Am@!!fPKe9 > I totally agree with Karsten on this one. > E.g. it should be possible for one ORB to use another ORBs > NamingService > even when object references do not contain an IIOP profile. I might even agree with you on this. But to do that we need to re-specify the naming service so that it's not just another application, but has some special magic features. Bill Date: Wed, 09 Feb 2000 18:35:47 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar Cc: Bill Janssen , Michi Henning , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) References: <00Feb9.122709pst."3647"@watson.parc.xerox.com> <38A1E918.379CBD75@fpk.hp.com> <38A1F45C.2253F3A9@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2*/!!h*=e9c`Wd9TMY!! Jonathan Biggar wrote: > Jishnu Mukerji wrote: > > Just to come up with a contrived example to try to understand this > a bit better, > > suppose the ORB receives an IOR which contains a single secure > IIOP profile that > > contains a time based validity restrictions such that an > invocation can be made > > using it only between 9am and 5pm local time. Suppose this is > received at 8pm > > local time. Would the ORB be required to reject this because the > IOR contains no > > profile that is usable at the time it is received? > > In all fairness, Bill was arguing against IORs with unrecognized > profiles, not ones that have profiles that are currently unusable > due to > policy. Ah I missed that part. So the claim is if the IOR contains no profile that the ORB "understands". Unfortunately the wording used was "an ORB *must* reject any object reference which does not contain any profiles ->usable<- by that ORB" > Even so, I don't agree with the argument. I agree with you. I guess to carry Bill's line of argument to its logical conclusion would also require string_to_object to carefully check whether the generated object reference contains at least one profile that the ORB understands at the point that string_to_object is invoked? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. To: Michi Henning cc: Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: Your message of "Wed, 09 Feb 2000 13:49:51 PST." From: Bill Janssen Message-Id: <00Feb9.154505pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 15:45:08 PST Content-Type: text X-UIDL: Z% The IOR > should be rejected at the point at which an invocation is made, not > at > the point at which it is received by the ORB. This is a very important point to consider. I've done so, and came up with this line of thought: What interoperability originally gave us was the ability for one ORB to accept objects from another ORB and pass them to application code, with an assurance that the application code could use the object as if it had come from the 'native' ORB for that application code. You're proposing we throw that assurance out. You're proposing to pass objects into the application space that can't be narrowed, that won't support even the basic operations on CORBA::Object. You're proposing we do that with no guidelines from the application. We already have one stupid feature of CORBA objects -- that any reference might be nil, so that application code has to check every reference before using it. Now you're suggesting another similar user trap -- that any object reference can be unusable. But this one's worse, because there's no way for the application code to test for it. Please consider the consequences of this decision on the larger architecture. Also consider that the so-called interoperability issue here is really the consequence of an ORB *not* using the CORBA Interoperability architecture. Bill Date: Thu, 10 Feb 2000 09:51:50 +1000 (EST) From: Michi Henning To: Bill Janssen cc: "Carlos O'Ryan" , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: <00Feb9.153510pst."3647"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 8[ld9*, > It just doesn't make sense to me to prohibit something that: > > > > 1) It is useful > > 2) It is (relatively) easy to implement. > > I realize that the OMG isn't big on architectural integrity, but: > you > don't do this because it violates the architecture you've developed. > What interoperability gave us was the guarantee that if an ORB > accepted an object reference from another ORB, that object reference > would be `live'; that is, the application code written against that > accepting ORB could use that object. This thing you seem to like > violates that principle. I have never seen any such guarantee anywhere. The object reference may not be live for any number of other reasons, such as connectivity being lost or the object having been deleted, or the caller not having the right credentials, or the caller not being in a transaction, or the caller not having the right codeset, or the caller... IIOP provides a guarantee that ORBs can exchange data values. It doesn't guarantee (and was never meant to guarantee) that the receiving ORB can make sense of all the data it has received. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 10 Feb 2000 10:19:15 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Stefan Wengi , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: <00Feb9.153649pst."3647"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: -pQ!!`]O!!;V(!!U?F!! On Wed, 9 Feb 2000, Bill Janssen wrote: > > I totally agree with Karsten on this one. > > E.g. it should be possible for one ORB to use another ORBs > NamingService > > even when object references do not contain an IIOP profile. > > I might even agree with you on this. But to do that we need to > re-specify the naming service so that it's not just another > application, but has some special magic features. I don't see how we need to re-specify anything. The naming services is like a parrot: it hears something and plays it back again without any understanding whatsoever of what it is playing back. I see neither why the naming service should reject an IOR just because it contains no profiles understood by the service, nor why we would need to re-specify anything. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <38A206AB.D0691FEC@floorboard.com> Date: Wed, 09 Feb 2000 16:30:35 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Michi Henning , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) References: <00Feb9.154505pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 7]!!!M,T!!i@U!!6'id9 Bill Janssen wrote: > This is a very important point to consider. I've done so, and came > up > with this line of thought: > > What interoperability originally gave us was the ability for one ORB > to accept objects from another ORB and pass them to application > code, > with an assurance that the application code could use the object as > if > it had come from the 'native' ORB for that application code. > > You're proposing we throw that assurance out. > > You're proposing to pass objects into the application space that > can't > be narrowed, that won't support even the basic operations on > CORBA::Object. You're proposing we do that with no guidelines from > the application. > > We already have one stupid feature of CORBA objects -- that any > reference might be nil, so that application code has to check every > reference before using it. Now you're suggesting another similar > user > trap -- that any object reference can be unusable. But this one's > worse, because there's no way for the application code to test for > it. > Please consider the consequences of this decision on the larger > architecture. Also consider that the so-called interoperability > issue > here is really the consequence of an ORB *not* using the CORBA > Interoperability architecture. Bill, this is fundamentally no different than an ORB that receives an IOR for an object whose server is currently unavailable. The only difference is the timespan of the unavailability. :-) Applications already have to be able to deal with references that raise COM_FAILURE because the server is down, so if we define a new minor code for COM_FAILURE that specifies that no usable profiles were found, we have added no additional requirements for the application. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 10 Feb 2000 10:29:46 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: <00Feb9.154505pst."3647"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 0^:!!SQpd9ME%e9X^2e9 On Wed, 9 Feb 2000, Bill Janssen wrote: > > The IOR > > should be rejected at the point at which an invocation is made, > not at > > the point at which it is received by the ORB. > > This is a very important point to consider. I've done so, and came > up > with this line of thought: > > What interoperability originally gave us was the ability for one ORB > to accept objects from another ORB and pass them to application > code, > with an assurance that the application code could use the object as > if > it had come from the 'native' ORB for that application code. There has never been any such assurance. As I said earlier, connectivity may be lost, the object may not exist, there may be no matching codesets, the credentials may be missing, etc, etc. > You're proposing we throw that assurance out. > > You're proposing to pass objects into the application space that > can't > be narrowed, that won't support even the basic operations on > CORBA::Object. You're proposing we do that with no guidelines from > the application. If an object doesn't exist, even a narrow won't work. Nothing changes if you allow an ORB to accept an IOR that contains no profile understood by that ORB. > We already have one stupid feature of CORBA objects -- that any > reference might be nil, so that application code has to check every > reference before using it. Yes, I agree with that. Nil was a bad idea. If you admit nil at all, it should be visible in the type system. Too late to do anything about this, I'm afraid... > Now you're suggesting another similar user > trap -- that any object reference can be unusable. Any object reference can be unusable already. And, as Bob pointed out, what constitutes "understanding" of a profile can become a very fluid notion indeed, if an ORB is designed to dynamically acquire support for new protocols. Heck, for all I know, an ORB could download the byte code for a new protocol engine from the web on the fly. > But this one's > worse, because there's no way for the application code to test for > it. There is no way to test for loss of connectivity either, other than to try and reach the object. > Please consider the consequences of this decision on the larger > architecture. Also consider that the so-called interoperability > issue > here is really the consequence of an ORB *not* using the CORBA > Interoperability architecture. I still disagree. The only thing I think we could consider is adding a new system exception to indicate "no protocol support". It's not essential, but would improve error reporting. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 09 Feb 2000 19:29:10 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen Cc: Michi Henning , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) References: <00Feb9.154505pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pJ,e9l:4!!BQ,e94i(e9 Bill Janssen wrote: > > The IOR > > should be rejected at the point at which an invocation is made, > not at > > the point at which it is received by the ORB. > > This is a very important point to consider. I've done so, and came > up > with this line of thought: > > What interoperability originally gave us was the ability for one ORB > to accept objects from another ORB and pass them to application > code, > with an assurance that the application code could use the object as > if > it had come from the 'native' ORB for that application code. .... only if the entire connectivity infrastructure was operational at the point at which an invocation was made. > You're proposing we throw that assurance out. > > You're proposing to pass objects into the application space that can't > be narrowed, that won't support even the basic operations on > CORBA::Object. You're proposing we do that with no guidelines from > the application. I guess, what I am missing is, in what way is this situation different from a disconnected network situation caused by a network failure. What additional assurance does an application have if the IOR contained a profile that the ORB understood in that case, as opposed to an IOR that did not contain any profile that the ORB understood. If the network interface card is gone, there is no getting to the target object either way. > We already have one stupid feature of CORBA objects -- that any > reference might be nil, so that application code has to check every > reference before using it. Hey people did not want to miss the old null pointer dereferencing malarchy, what can I say?:-) > Now you're suggesting another similar user > trap -- that any object reference can be unusable. But this one's > worse, because there's no way for the application code to test for > it. Why is this any worse than an application faced with a network outage, which any ORB with all rthe knowledge of all profiles in the world can do nothing to get around? > Please consider the consequences of this decision on the larger > architecture. Also consider that the so-called interoperability > issue > here is really the consequence of an ORB *not* using the CORBA > Interoperability architecture. I don't follow.... but I guess I have had a looooong day.:-( Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: Jeffrey Mischkinsky Message-Id: <200002100032.QAA14990@wheel.dcn.davis.ca.us> Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) To: janssen@parc.xerox.com (Bill Janssen) Date: Wed, 9 Feb 2000 16:32:36 -0800 (PST) Cc: coryan@uci.edu (Carlos O'Ryan), michi@ooc.com.au (Michi Henning), owen_rees@hp.com (Owen Rees), ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org In-Reply-To: <00Feb9.153510pst."3647"@watson.parc.xerox.com> from "Bill Janssen" at Feb 09, 2000 03:35:19 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3^C!!QaQ!!W-Ge9"%Fe9 'Bill Janssen' writes: > > > It just doesn't make sense to me to prohibit something that: > > > > 1) It is useful > > 2) It is (relatively) easy to implement. > > I realize that the OMG isn't big on architectural integrity, but: > you > don't do this because it violates the architecture you've developed. > What interoperability gave us was the guarantee that if an ORB > accepted an object reference from another ORB, that object reference > would be `live'; that is, the application code written against that > accepting ORB could use that object. This thing you seem to like > violates that principle. I find myself agreeing with both sides here. I think Bill has a key point here, and we ignore it at our own peril. OTOH, the use cases that are being used to justify the oppposite point of view are certainly quite compelling. One thing that strikes me is that the use cases, naming, trading, etc. are all cases where the objref is being used as data. The "service" isn't planning to make an invocations, just hold something and give it back to someone. The guarantee that we have today, is that (assuming the orb's involved claim to support interoperabilty) everything they give out is guaranteed to be "useful" i.e. they have at least one profile (the IIOP one) which everyone has said they will be able to handle. This is quite a strong guarantee. Obviously at some point, someone will try to make an invocation (or else why bother). The question is whether we want to allow them to fail at that point, or whether the failure should happen earlier. (Jishnu referred to this as eager vs lazy binding) jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: Jeffrey Mischkinsky Message-Id: <200002100038.QAA15739@wheel.dcn.davis.ca.us> Subject: Re: An ORB should not accept an IOR with no usable profiles (was: To: michi@ooc.com.au (Michi Henning) Date: Wed, 9 Feb 2000 16:38:13 -0800 (PST) Cc: janssen@parc.xerox.com (Bill Janssen), coryan@uci.edu (Carlos O'Ryan), owen_rees@hp.com (Owen Rees), ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org In-Reply-To: from "Michi Henning" at Feb 10, 2000 09:51:50 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pgJe9^n-!!c(=!!!4g!! 'Michi Henning' writes: > > On Wed, 9 Feb 2000, Bill Janssen wrote: > > > > It just doesn't make sense to me to prohibit something that: > > > > > > 1) It is useful > > > 2) It is (relatively) easy to implement. > > > > I realize that the OMG isn't big on architectural integrity, but: > you > > don't do this because it violates the architecture you've > developed. > > What interoperability gave us was the guarantee that if an ORB > > accepted an object reference from another ORB, that object > reference > > would be `live'; that is, the application code written against > that > > accepting ORB could use that object. This thing you seem to like > > violates that principle. > > I have never seen any such guarantee anywhere. The object reference > may > not be live for any number of other reasons, such as connectivity > being > lost or the object having been deleted, or the caller not having the > right credentials, or the caller not being in a transaction, or the > caller > not having the right codeset, or the caller... > > IIOP provides a guarantee that ORBs can exchange data values. It > doesn't > guarantee (and was never meant to guarantee) that the receiving ORB > can make sense of all the data it has received. (ok, now i've been sucked in too, but when you start making these kind of "unprovable" claims, it's hard not to.) I think the idea behind IORs plus having IIOP be mandatory, was that the ORB was guaranteed to be able to make sense of object references it received. (Note: I'm not saying anything about "liveness". You're correct, you never know until you try if an invocation will succeed. But i would maintain that IOR plus IIOP were designed to allow to always be able to make the invocation, and not throw up your hands because you didn't understand how to make the invocation.) jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Thu, 10 Feb 2000 10:45:58 +1000 (EST) From: Michi Henning To: Jeffrey Mischkinsky cc: Bill Janssen , "Carlos O'Ryan" , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: In-Reply-To: <200002100038.QAA15739@wheel.dcn.davis.ca.us> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: V\H!!U7kd9SNV!!="]!! On Wed, 9 Feb 2000, Jeffrey Mischkinsky wrote: > I think the idea behind IORs plus having IIOP be mandatory, was that the > ORB was guaranteed to be able to make sense of object references it > received. > > (Note: I'm not saying anything about "liveness". You're correct, you never > know until you try if an invocation will succeed. But i would maintain > that IOR plus IIOP were designed to allow to always be able to make > the invocation, and not throw up your hands because you didn't understand > how to make the invocation.) An IOR that contains only proprietary profiles is, by definition, not interoperable. I can't expect to be able to use that IOR to talk to another vendor's ORB. However, that does not imply that I have the right to reject the IOR out of hand, especially when I never need to use it. Consider a special-purpose environment with custom profiles, maybe real-time embedded or some such. Almost every system has a need for naming of some kind. If I can't use another vendor's naming service to store my IORs, then I am forced to duplicate the naming service for my special-purpose environment as well, even though I'm giving a standard naming servcie all the information that's necessary to store my IORs and return them to me again. As I said in my earlier post, the notion of what profiles are "understood" by an ORB can become so fluid as to be just about meaningless anyway. The ultimate and only test I have for whether a profile is "understood" is whether I can successfully invoke an operation via that profile. Until I try to do that, I simply can't know. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Paul Kyzivat To: "Interop RTF (E-mail)" Subject: RE: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) Date: Wed, 9 Feb 2000 20:07:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: n0B!!+o2!!P[:!!g(f!! I suppose this could be viewed as a quality-of-implementation issue. But if so, it ought to be a separate compliance point so that customers know what they are, and are not, getting. Paul > -----Original Message----- > From: Bill Janssen [mailto:janssen@parc.xerox.com] > Sent: Wednesday, February 09, 2000 3:27 PM > To: Michi Henning > Cc: Owen Rees; ObjectManagementGroup-Interest.All_Areas@xerox.com; > interop@omg.org > Subject: An ORB should not accept an IOR with no usable profiles > (was: > Re: Issue 2457 redux) > > > > Given that, the requirement not to drop profiles is > entirely consistent > > with the CORBA architecture and can be implemented without pain by > > commercial ORBs. Further, imposing the requirement will improve > > interoperability and make it easy to add new protocols > without breaking > > existing implementations. > > Sorry, Michi, this isn't about dropping profiles -- that's another > discussion. This is about whether an ORB should accept object > references that contain no profiles it recognizes. > > Bill > From: Paul Kyzivat To: interop@omg.org Subject: RE: An ORB should not accept an IOR with no usable profiles > (was: Re: Issue 2457 redux) Date: Wed, 9 Feb 2000 20:34:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: d')e9kZ1e9hp/!!?7,e9 Bill, We also accept the possibility of holding a reference to a non-existent object. It may not be appealing, but is there really a practical alternative? By your argument, a reference to a non-existent object should also never be permitted to be given to an application. And even if that were possible, what should happen if it should become non-existent after the application gets the reference? (One possibility is to prevent an object from becoming non-existent while references to it exist, but that is yet another rat hole.) I don't think there is any way to get CORBA there, nor does it seem like a good idea even if it were possible. Paul > -----Original Message----- > From: Bill Janssen [mailto:janssen@parc.xerox.com] > Sent: Wednesday, February 09, 2000 6:45 PM > To: Michi Henning > Cc: Owen Rees; ObjectManagementGroup-Interest.All_Areas@xerox.com; > interop@omg.org > Subject: Re: An ORB should not accept an IOR with no usable profiles > (was: Re: Issue 2457 redux) > > > > The IOR > > should be rejected at the point at which an invocation is > made, not at > > the point at which it is received by the ORB. > > This is a very important point to consider. I've done so, and came > up > with this line of thought: > > What interoperability originally gave us was the ability for one ORB > to accept objects from another ORB and pass them to application > code, > with an assurance that the application code could use the object as > if > it had come from the 'native' ORB for that application code. > > You're proposing we throw that assurance out. > > You're proposing to pass objects into the application space that > can't > be narrowed, that won't support even the basic operations on > CORBA::Object. You're proposing we do that with no guidelines from > the application. > > We already have one stupid feature of CORBA objects -- that any > reference might be nil, so that application code has to check every > reference before using it. Now you're suggesting another similar > user > trap -- that any object reference can be unusable. But this one's > worse, because there's no way for the application code to test for > it. > Please consider the consequences of this decision on the larger > architecture. Also consider that the so-called interoperability > issue > here is really the consequence of an ORB *not* using the CORBA > Interoperability architecture. > > Bill > To: Jonathan Biggar cc: Paul Kyzivat , interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Wed, 09 Feb 2000 13:55:16 PST." <38A1E22A.39853B1F@floorboard.com> From: Bill Janssen Message-Id: <00Feb9.180231pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 18:02:43 PST Content-Type: text X-UIDL: *_6@!!>Oa!! > Yes, but most of the other ORB vendors (or at least several) are > rejecting your position. Actually, I'm not sure I've heard from many ORB vendors. And I'm not sure they've really thought through the impact of this on their customers. Bill To: jis@fpk.hp.com cc: Michi Henning , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: Your message of "Wed, 09 Feb 2000 14:25:09 PST." <38A1E918.379CBD75@fpk.hp.com> From: Bill Janssen Message-Id: <00Feb9.180700pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 18:07:12 PST Content-Type: text X-UIDL: /eRd9#/md9a8E!!MZgd9 > Just to come up with a contrived example to try to understand this a bit better, > suppose the ORB receives an IOR which contains a single secure IIOP profile that > contains a time based validity restrictions such that an invocation can be made > using it only between 9am and 5pm local time. Suppose this is received at 8pm > local time. Would the ORB be required to reject this because the IOR contains no > profile that is usable at the time it is received? I've got no problem with restrictions such as these, but I really worry about when the ORB should give the reference to the application code. Would such a security restriction also prevent built in operations such as is_a or get_interface? Bill To: Michi Henning cc: "Carlos O'Ryan" , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: Your message of "Wed, 09 Feb 2000 15:52:07 PST." From: Bill Janssen Message-Id: <00Feb9.180924pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 18:09:33 PST Content-Type: text X-UIDL: h#Qe9\/2!!)";!!VNTd9 > I have never seen any such guarantee anywhere. The object reference may > not be live for any number of other reasons, such as connectivity being > lost or the object having been deleted, or the caller not having the > right credentials, or the caller not being in a transaction, or the caller > not having the right codeset, or the caller... These liveness issues are server-side problems that can arise, sure. They're things the recieving ORB can't really do anything about. Bill To: jis@fpk.hp.com cc: karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Wed, 09 Feb 2000 14:17:36 PST." <38A1E779.98A4C5AA@fpk.hp.com> From: Bill Janssen Message-Id: <00Feb9.180426pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 18:04:42 PST Content-Type: text X-UIDL: 3SV!!S2`!!SFjd9V:,e9 > If we say that, then it would imply that any ORB that provides name services can > store only such IORs that contains at least one profile usable by that ORB. Why > would that be desirable? It's not, for name services, but it's a side-effect of a more generally desirable principle. Perhaps name services shouldn't be implemented as simple applications. Bill To: Michi Henning cc: Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: Your message of "Wed, 09 Feb 2000 16:30:21 PST." From: Bill Janssen Message-Id: <00Feb9.181149pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 18:11:53 PST Content-Type: text X-UIDL: WJD!!Z!L!! Any object reference can be unusable already. And, as Bob pointed out, > what constitutes "understanding" of a profile can become a very fluid > notion indeed, if an ORB is designed to dynamically acquire support for > new protocols. Heck, for all I know, an ORB could download the byte code > for a new protocol engine from the web on the fly. I've got no problem with that, as long as it's done before the object reference is passed to the application code. Bill To: Michi Henning cc: karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Wed, 09 Feb 2000 13:54:19 PST." From: Bill Janssen Message-Id: <00Feb9.180132pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 18:01:41 PST Content-Type: text X-UIDL: JI[!!?9#e9XQ5!!H=;!! > That's like saying that an English database should reject all Japanese > strings that are sent to it, even though the database never needs to > understand those strings... I think I'd agree with that position. > If I'm implementing a naming service, which never uses the IORs it stores, > I see no reason to reject an IOR just because it contains no profile I > understand. After all, I'm never using the IOR and, if I don't reject it, > everything works just fine. So, there is no reason to reject it. That would be fine, if there was some way to tell the ORB that the application had that peculiarity. Bill To: jis@fpk.hp.com cc: Jonathan Biggar , Michi Henning , Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: Your message of "Wed, 09 Feb 2000 15:36:00 PST." <38A1F9D3.E7E05AAC@fpk.hp.com> From: Bill Janssen Message-Id: <00Feb9.180759pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 18:08:02 PST Content-Type: text X-UIDL: Xf7!!USSd9&^O!!YY?!! > I guess to carry Bill's line of argument to its logical conclusion would also require > string_to_object to carefully check whether the generated object reference contains at > least one profile that the ORB understands at the point that string_to_object is > invoked? Indeed. Bill To: Jeffrey Mischkinsky cc: michi@ooc.com.au (Michi Henning), coryan@uci.edu (Carlos O'Ryan), owen_rees@hp.com (Owen Rees), ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: In-Reply-To: Your message of "Wed, 09 Feb 2000 16:39:11 PST." <200002100038.QAA15739@wheel.dcn.davis.ca.us> From: Bill Janssen Message-Id: <00Feb9.181415pst."3647"@watson.parc.xerox.com> Date: Wed, 9 Feb 2000 18:14:22 PST Content-Type: text X-UIDL: %^U!!([cd9+T%!!Fm&e9 > I think the idea behind IORs plus having IIOP be mandatory, was that the > ORB was guaranteed to be able to make sense of object references it > received. > > (Note: I'm not saying anything about "liveness". You're correct, you never > know until you try if an invocation will succeed. But i would maintain > that IOR plus IIOP were designed to allow to always be able to make > the invocation, and not throw up your hands because you didn't understand > how to make the invocation.) Maybe I've just been in this group too long :-). All that useless memory of what the intention of something was :-). Bill Date: Thu, 10 Feb 2000 12:26:54 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: "Interop RTF (E-mail)" Subject: RE: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA9140352@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: $A%e9-#id9jF;e9O1+e9 On Wed, 9 Feb 2000, Paul Kyzivat wrote: > I suppose this could be viewed as a quality-of-implementation issue. > But if so, it ought to be a separate compliance point so that > customers know > what they are, and are not, getting. I don't think I agree: > > From: Bill Janssen [mailto:janssen@parc.xerox.com] > > > > Sorry, Michi, this isn't about dropping profiles -- that's another > > discussion. This is about whether an ORB should accept object > > references that contain no profiles it recognizes. OK Bill, I'll make ILU happy: I have my normal IORs which each contain three proprietary and special-purpose profiles. But, to keep ILU happy, I shall add a dummy IIOP profile to each of my IORs. That profile will contain the address 10.1.1.1, port 1024, and a single-byte object key with value 0. Now, my IOR is perfectly OK as far as ILU is concerned, isn't it? What has ILU gained by me giving it that IOR? I hope you are not suggesting that ILU still won't be happy just because the IIOP profile can't possibly work... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 10 Feb 2000 12:36:20 +1000 (EST) From: Michi Henning To: Bill Janssen cc: jis@fpk.hp.com, Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: <00Feb9.180700pst."3647"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: "-Nd9kE4!!mW6e9E-Be9 On Wed, 9 Feb 2000, Bill Janssen wrote: > I've got no problem with restrictions such as these, but I really > worry about when the ORB should give the reference to the > application > code. Would such a security restriction also prevent built in > operations such as is_a or get_interface? One security revision coming up... :-) And, of course, we have to worry about covert channels. By invoking is_a operations on a secure reference in morse code, I can funnel information... Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <38A2251B.297F7343@floorboard.com> Date: Wed, 09 Feb 2000 18:40:27 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Michi Henning , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux References: <00Feb9.180132pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ajEe9i35!!CK3!!eK/!! Bill Janssen wrote: > > > That's like saying that an English database should reject all > Japanese > > strings that are sent to it, even though the database never needs > to > > understand those strings... > > I think I'd agree with that position. > > > If I'm implementing a naming service, which never uses the IORs it > stores, > > I see no reason to reject an IOR just because it contains no > profile I > > understand. After all, I'm never using the IOR and, if I don't > reject it, > > everything works just fine. So, there is no reason to reject it. > > That would be fine, if there was some way to tell the ORB that the > application had that peculiarity. Bill, you still haven't answered the fundamental question, which is to tell us what harm it does for an ORB to accept an uninvocable profile, given that applications already have to deal with objects that suddenly don't exist or have unreachable servers? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@corvette.floorboard.com Message-ID: <38A22422.4770C477@floorboard.com> Date: Wed, 09 Feb 2000 18:36:18 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: jis@fpk.hp.com, karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux References: <00Feb9.180426pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^KE!!ihO!!?Z3e9a71e9 Bill Janssen wrote: > > > If we say that, then it would imply that any ORB that provides > name services can > > store only such IORs that contains at least one profile usable by > that ORB. Why > > would that be desirable? > > It's not, for name services, but it's a side-effect of a more > generally desirable principle. Perhaps name services shouldn't be > implemented as simple applications. And why in the world would we want to complicate the CORBA model by requiring name services to be magic? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@corvette.floorboard.com Message-ID: <38A22FDE.ECACD900@floorboard.com> Date: Wed, 09 Feb 2000 19:26:22 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Bill Janssen , jis@fpk.hp.com, Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was:Re: Issue 2457 redux) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &-[!!Cc-!!Z+L!!KB0!! Michi Henning wrote: > > On Wed, 9 Feb 2000, Bill Janssen wrote: > > > I've got no problem with restrictions such as these, but I really > > worry about when the ORB should give the reference to the > application > > code. Would such a security restriction also prevent built in > > operations such as is_a or get_interface? > > One security revision coming up... :-) And, of course, we have to > worry > about covert channels. By invoking is_a operations on a secure > reference > in morse code, I can funnel information... Not really. It requires the secure object implementation to cooperate by using timing delays or varying the boolean response of the is_a operation. Besides, I don't expect the bandwidth of the covert channel to be high enough to get security folks too worked up. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 10 Feb 2000 14:23:04 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Bill Janssen , jis@fpk.hp.com, Owen Rees , ObjectManagementGroup-Interest.All_Areas@xerox.com, interop@omg.org Subject: Re: An ORB should not accept an IOR with no usable profiles (was:Re: Issue 2457 redux) In-Reply-To: <38A22FDE.ECACD900@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: IF=!!X/pd9@BLe9Pc_d9 On Wed, 9 Feb 2000, Jonathan Biggar wrote: > > One security revision coming up... :-) And, of course, we have to worry > > about covert channels. By invoking is_a operations on a secure reference > > in morse code, I can funnel information... > > Not really. It requires the secure object implementation to cooperate > by using timing delays or varying the boolean response of the is_a > operation. Besides, I don't expect the bandwidth of the covert channel > to be high enough to get security folks too worked up. I wasn't serious -- I was being sarcastic. (I should have added another smiley, really). Cheers, Michi. Date: Thu, 10 Feb 2000 00:08:04 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Jonathan Biggar , Paul Kyzivat , interop@omg.org Subject: Re: Issue 2457 redux References: <00Feb9.180231pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 8Zkd9e31e9)DKe9!*[!! I've worked at three ORB vendors (I think HP sold a few copies of ORBplus) and on at least two different multi-protocol interop-architecture-based ORBs. The idea of rejecting an object reference passed as a parameter because of it not advertizing a recognized protocol never came up in any design discusion I've been involved in, nor have any customers that I'm aware of ever asked for such a "feature". I think my strongest argument against adding such a restriction is that it would completely tie our hands for the further evolution of CORBA itself. I envision that someday we really will have a shiny new IIOP 2.0 (or HTTPng, SOAP, or whatever), and that there will be some ORBs that support IIOP 2.0 and IIOP 1.x, some that only support IIOP 1.x, and eventually some that only support IIOP 2.x. Customers will expect these to work together as much as possible. Should two ORBs that support both IIOP 2.x and 1.x not be able to use a naming service that only supports IIOP 1.x to exchange an object reference that only advertizes IIOP 2.x? Should a trader that only supports IIOP 2.x not be able to supply a legacy object that only supports IIOP 1.x to a client that speaks IIOP 1.x and IIOP 2.x? I'd hate to see a restriction like this prevent us from ever breaking with the old trusty TAG_INTERNET_IOP profile and its implication that at IIOP 1.0 is supported. -Bob Bill Janssen wrote: > > > Yes, but most of the other ORB vendors (or at least several) are > > rejecting your position. > > Actually, I'm not sure I've heard from many ORB vendors. And I'm > not > sure they've really thought through the impact of this on their > customers. > > Bill From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interop@omg.org Message-ID: <85256881.004CB190.00@d54mta08.raleigh.ibm.com> Date: Thu, 10 Feb 2000 07:51:08 -0600 Subject: Re: Issue 2457 redux Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: FH[d9X%nd9k:gd9NMi!! My sentiments follow Bob's fairly closely. The issue of rejecting object references has never come up here. And adding such a requirement will potentially hobble us in the future. And to echo Jon's question: what harm is there for an ORB to accept an uninvocable profile? Russell Butek butek@us.ibm.com Bob Kukura on 02/09/2000 11:08:04 PM To: Bill Janssen cc: Jonathan Biggar , Paul Kyzivat , interop@omg.org Subject: Re: Issue 2457 redux I've worked at three ORB vendors (I think HP sold a few copies of ORBplus) and on at least two different multi-protocol interop-architecture-based ORBs. The idea of rejecting an object reference passed as a parameter because of it not advertizing a recognized protocol never came up in any design discusion I've been involved in, nor have any customers that I'm aware of ever asked for such a "feature". I think my strongest argument against adding such a restriction is that it would completely tie our hands for the further evolution of CORBA itself. I envision that someday we really will have a shiny new IIOP 2.0 (or HTTPng, SOAP, or whatever), and that there will be some ORBs that support IIOP 2.0 and IIOP 1.x, some that only support IIOP 1.x, and eventually some that only support IIOP 2.x. Customers will expect these to work together as much as possible. Should two ORBs that support both IIOP 2.x and 1.x not be able to use a naming service that only supports IIOP 1.x to exchange an object reference that only advertizes IIOP 2.x? Should a trader that only supports IIOP 2.x not be able to supply a legacy object that only supports IIOP 1.x to a client that speaks IIOP 1.x and IIOP 2.x? I'd hate to see a restriction like this prevent us from ever breaking with the old trusty TAG_INTERNET_IOP profile and its implication that at IIOP 1.0 is supported. -Bob Bill Janssen wrote: > > > Yes, but most of the other ORB vendors (or at least several) are > > rejecting your position. > > Actually, I'm not sure I've heard from many ORB vendors. And I'm not > sure they've really thought through the impact of this on their > customers. > > Bill From: "Rutt, T E (Tom)" To: "'interop@omg.org'" Subject: RE: Issue 2457 redux Date: Thu, 10 Feb 2000 11:02:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: lFJe9/N[!!A!n!!Y7pd9 I keep hearing two sides of this conversation. Maybe we need to have a new conformance point for Interoperable ORBS, 1) IOR presering ORBS - don't drop info from IORs received in operation parameters Orbs which do not conform to this will work fine in well engineered "islands" involving the TCP based IIOP (quite a large island, say "island earth" minus the proprietary bits) > -- > Tom Rutt > Lucent Technologies - Bell Labs > Rm 4L-336 Tel: +1(732)949-7862 > 101 Crawford Corner Rd Fax: +1(732)949-1196 > Holmdel NJ, 07733 USA email: terutt@lucent.com > Date: Thu, 10 Feb 2000 11:23:03 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rutt, T E (Tom)" CC: "'interop@omg.org'" Subject: Re: Issue 2457 redux References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ih#!!OY+!!V6#e9Y"/!! "Rutt, T E (Tom)" wrote: > > I keep hearing two sides of this conversation. > > Maybe we need to have a new conformance point for Interoperable > ORBS, > 1) IOR presering ORBS - don't drop info from IORs received in > operation > parameters > > Orbs which do not conform to this will work fine in well engineered > "islands" involving > the TCP based IIOP (quite a large island, say "island earth" minus > the > proprietary bits) I'd amend that slightly to "island earth as of the end of the 20th century". Future OMG standards are basically indistinguishable from current proprietary bits. -Bob > > > -- > > Tom Rutt > > Lucent Technologies - Bell Labs > > Rm 4L-336 Tel: +1(732)949-7862 > > 101 Crawford Corner Rd Fax: +1(732)949-1196 > > Holmdel NJ, 07733 USA email: terutt@lucent.com > > To: Bob Kukura cc: Jonathan Biggar , Paul Kyzivat , interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Wed, 09 Feb 2000 21:12:00 PST." <38A247B4.BCE0D7DF@iona.com> From: Bill Janssen Message-Id: <00Feb10.151237pst."3656"@watson.parc.xerox.com> Date: Thu, 10 Feb 2000 15:12:58 PST Content-Type: text X-UIDL: pD2e93ihd9]b2e9dP>!! > I think my strongest argument against adding such a restriction is that > it would completely tie our hands for the further evolution of CORBA > itself. I envision that someday we really will have a shiny new IIOP > 2.0 (or HTTPng, SOAP, or whatever), and that there will be some ORBs > that support IIOP 2.0 and IIOP 1.x, some that only support IIOP 1.x, and > eventually some that only support IIOP 2.x. Customers will expect these > to work together as much as possible. Should two ORBs that support both > IIOP 2.x and 1.x not be able to use a naming service that only supports > IIOP 1.x to exchange an object reference that only advertizes IIOP 2.x? > Should a trader that only supports IIOP 2.x not be able to supply a > legacy object that only supports IIOP 1.x to a client that speaks IIOP > 1.x and IIOP 2.x? I'd hate to see a restriction like this prevent us > from ever breaking with the old trusty TAG_INTERNET_IOP profile and its > implication that at IIOP 1.0 is supported. Good points, Bob. Bill To: Michi Henning cc: Paul Kyzivat , "Interop RTF (E-mail)" Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: Your message of "Wed, 09 Feb 2000 18:28:15 PST." From: Bill Janssen Message-Id: <00Feb10.150939pst."3656"@watson.parc.xerox.com> Date: Thu, 10 Feb 2000 15:09:48 PST Content-Type: text X-UIDL: cc: Michi Henning , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Wed, 09 Feb 2000 18:49:09 PST." <38A2251B.297F7343@floorboard.com> From: Bill Janssen Message-Id: <00Feb10.151102pst."3656"@watson.parc.xerox.com> Date: Thu, 10 Feb 2000 15:11:08 PST Content-Type: text X-UIDL: lO?!!+W\d9WKo!!,Jl!! > Bill, you still haven't answered the fundamental question, which is to > tell us what harm it does for an ORB to accept an uninvocable profile, > given that applications already have to deal with objects that suddenly > don't exist or have unreachable servers? The difference is that this is harm which the ORB can reasonably detect and prevent, while the others aren't. Bill Date: Fri, 11 Feb 2000 09:13:39 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Paul Kyzivat , "Interop RTF (E-mail)" Subject: Re: An ORB should not accept an IOR with no usable profiles (was: Re: Issue 2457 redux) In-Reply-To: <00Feb10.150939pst."3656"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: CUY!!^m7e93k@!!6(/e9 On Thu, 10 Feb 2000, Bill Janssen wrote: > I'm sorry I even mentioned ILU, which is, after all, a test platform > for prototyping various distributed object experiments, not a CORBA > ORB. Let's not focus on what may or may not make ILU happy. Bill, I posted the example about the dummy IIPO profile not to rubbish ILU. I posted it because I think it illustrates the futility of insisting on having an IIOP profile in an IOR: having such a profile establishes no stronger guarantees than not having it. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 11 Feb 2000 12:30:14 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Bill Janssen , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: <38A37193.9921463F@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: W,~e92K$e9$X1!!YB8!! On Thu, 10 Feb 2000, Jonathan Biggar wrote: > Bill, you are dodging the question! You still haven't explained the > harm of an ORB postponing detection of no understood profile in an > IOR > until attempting to invoke an operation, when objects not existing > or > server crashes can cause identical in behavior exceptions at any > point > in time. We are going round in circles. Bill keeps arguing that it's bad, and pretty much everyone keeps arguing that it's good. (At least, I can't recall anyone supporting Bill's argument.) Can we put it to a vote and put an end to it? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <38A37193.9921463F@floorboard.com> Date: Thu, 10 Feb 2000 18:18:59 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Michi Henning , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux References: <00Feb10.151102pst."3656"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ?:^!!ZVLe9Y^j!!NfFe9 Bill Janssen wrote: > > > Bill, you still haven't answered the fundamental question, which > is to > > tell us what harm it does for an ORB to accept an uninvocable > profile, > > given that applications already have to deal with objects that > suddenly > > don't exist or have unreachable servers? > > The difference is that this is harm which the ORB can reasonably > detect and prevent, while the others aren't. Bill, you are dodging the question! You still haven't explained the harm of an ORB postponing detection of no understood profile in an IOR until attempting to invoke an operation, when objects not existing or server crashes can cause identical in behavior exceptions at any point in time. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org To: Jonathan Biggar cc: Michi Henning , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Thu, 10 Feb 2000 18:27:46 PST." <38A37193.9921463F@floorboard.com> From: Bill Janssen Message-Id: <00Feb10.185825pst."3656"@watson.parc.xerox.com> Date: Thu, 10 Feb 2000 18:58:47 PST Content-Type: text X-UIDL: 3C3!!>dfd9Mggd9-p'!! > Bill, you are dodging the question! You still haven't explained the > harm of an ORB postponing detection of no understood profile in an > IOR > until attempting to invoke an operation, when objects not existing > or > server crashes can cause identical in behavior exceptions at any > point > in time. Not dodging, just thought it was obvious. If you are at the wheel of a car speeding towards a child, you should attempt to not hit the child, even though the child may still be hit by other cars that you have no control over. Similarly, ORBs should attempt to minimize disruption of service to the application code by preventing those errors that they can detect, though other errors that they cannot detect may still be present. Bill To: Michi Henning cc: Jonathan Biggar , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Thu, 10 Feb 2000 18:31:59 PST." From: Bill Janssen Message-Id: <00Feb10.185920pst."3656"@watson.parc.xerox.com> Date: Thu, 10 Feb 2000 18:59:28 PST Content-Type: text X-UIDL: EB7!!5fnd9V'Be9K/@e9 Or we could consider ways to make both camps happy. For instance, perhaps if we had an ORB policy that says, "I don't touch references", that the Naming and Trading services could set, I'd be happy. Bill Date: Fri, 11 Feb 2000 13:08:51 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Jonathan Biggar , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: <00Feb10.185920pst."3656"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: fEOe94NK!!~4Be9WnW!! On Thu, 10 Feb 2000, Bill Janssen wrote: > Or we could consider ways to make both camps happy. For instance, > perhaps if we had an ORB policy that says, "I don't touch > references", > that the Naming and Trading services could set, I'd be happy. No. That would break the opacity of references. I'm dead-set against this. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 11 Feb 2000 13:08:19 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Jonathan Biggar , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: <00Feb10.185825pst."3656"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: :f3!!1!bd9a]0e9SM4e9 On Thu, 10 Feb 2000, Bill Janssen wrote: > Not dodging, just thought it was obvious. If you are at the wheel of > a car speeding towards a child, you should attempt to not hit the > child, even though the child may still be hit by other cars that you > have no control over. Similarly, ORBs should attempt to minimize > disruption of service to the application code by preventing those > errors that they can detect, though other errors that they cannot > detect may still be present. I don't think analogies will help us here. And I agree with Jon -- you keep dodging the question. As I demonstrated with the dummy IIOP profile example, the presence of an IIOP profile provides no better guarantee than its absence. The IIOP profile may be permanently non-functional, for example, because the server that created the IOR may no longer exist. (Which needn't stop a client from attempting to advertise the reference in a naming service.) Given that, I don't see what insistence on the presence of IIOP profile would achieve. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <38A37BDE.648801AA@floorboard.com> Date: Thu, 10 Feb 2000 19:02:54 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen CC: Michi Henning , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux References: <00Feb10.185825pst."3656"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: H2f!!AKhd9bODe97GCe9 Bill Janssen wrote: > > > Bill, you are dodging the question! You still haven't explained > the > > harm of an ORB postponing detection of no understood profile in an > IOR > > until attempting to invoke an operation, when objects not existing > or > > server crashes can cause identical in behavior exceptions at any > point > > in time. > > Not dodging, just thought it was obvious. If you are at the wheel > of > a car speeding towards a child, you should attempt to not hit the > child, even though the child may still be hit by other cars that you > have no control over. Similarly, ORBs should attempt to minimize > disruption of service to the application code by preventing those > errors that they can detect, though other errors that they cannot > detect may still be present. I agree that ORBs should detect problems routinely, but not at the cost of eliminating a useful feature or deployment strategy. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org To: Michi Henning cc: Jonathan Biggar , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Thu, 10 Feb 2000 19:08:32 PST." From: Bill Janssen Message-Id: <00Feb10.193626pst."3656"@watson.parc.xerox.com> Date: Thu, 10 Feb 2000 19:36:39 PST Content-Type: text X-UIDL: Gh^!!?L+e9X3p!!]g&!! > Given that, I don't see what insistence on the presence of IIOP profile > would achieve. 1. I'm not insisting on the presence of an IIOP profile, just on the presence of a usable profile, usable by that ORB. 2. The difference is between errors the ORB can detect and prevent, and errors that it cannot detect. Bill To: Michi Henning cc: Jonathan Biggar , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Thu, 10 Feb 2000 19:09:02 PST." From: Bill Janssen Message-Id: <00Feb10.193730pst."3656"@watson.parc.xerox.com> Date: Thu, 10 Feb 2000 19:37:39 PST Content-Type: text X-UIDL: cM]!!~X[!!+Ke!!>oE!! > No. That would break the opacity of references. I'm dead-set against this. Huh? How would it break the opacity? It's just giving more information to the ORB about its use of references. More information has got to be better than less, no? Bill Date: Fri, 11 Feb 2000 14:29:58 +1000 (EST) From: Michi Henning To: Bill Janssen cc: Jonathan Biggar , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux In-Reply-To: <00Feb10.193730pst."3656"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: `[M!!T%?!!aBLe9bKDe9 On Thu, 10 Feb 2000, Bill Janssen wrote: > Huh? How would it break the opacity? It's just giving more > information to the ORB about its use of references. More > information > has got to be better than less, no? The client would have to make a decision about IOR profiles and decide whether a particular trader or naming service is safe to use. That elevates the concept of profiles and protocols up to the application level, where those concepts should be invisibile. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 11 Feb 2000 01:02:00 -0500 From: Jishnu Mukerji X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning Cc: Jonathan Biggar , Bill Janssen , karsten-oliver.starr@ubs.com, interop@omg.org, kraatika@cs.helsinki.fi, paulk@roguewave.com Subject: Re: Issue 2457 redux References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: E_He9&)/!!:i4!!P[9e9 Michi Henning wrote: > On Thu, 10 Feb 2000, Jonathan Biggar wrote: > > > Bill, you are dodging the question! You still haven't explained the > > harm of an ORB postponing detection of no understood profile in an IOR > > until attempting to invoke an operation, when objects not existing or > > server crashes can cause identical in behavior exceptions at any point > > in time. > > We are going round in circles. Bill keeps arguing that it's bad, and > pretty much everyone keeps arguing that it's good. (At least, I can't > recall anyone supporting Bill's argument.) Can we put it to a vote > and put an end to it? > Heck, that is exactly why I asked Juergen to create a new issue focused on this particular matter of requiring the rejection of IORs that don't contain any *usable* profile, at the time that the IOR is received. Now if we can get Tom to do a vote, we can get this out of the way quite quickly I think. Jishnu. Date: Fri, 11 Feb 2000 11:31:17 +0000 From: Owen Rees To: interop@omg.org Subject: Re: Issue 2457 redux Message-ID: <1080904693.950268677@ews-proj-2.hpl.hp.com> In-Reply-To: <00Feb10.193626pst."3656"@watson.parc.xerox.com> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: *B#e914!e9=Ad!!>9F!! --On 10 February 2000, 19:36 +0000 Bill Janssen wrote: > > 1. I'm not insisting on the presence of an IIOP profile, just on > the > presence of a usable profile, usable by that ORB. You need a better definition of 'usable' to have such a requirement. Michi has demonstrated the workaround that lets an IOR pass at least one level of test without actually adding the ability to interact with the object. Any IOR is 'usable' as a parameter or result, even if the ORB could not perform an invocation with it. Another thing to think about here is how this affects an IOR that is usable for making an invocation only at the 'server' end of a bi-dir GIOP connection. It may look normal, but it will never work for invocations from anywhere else, and it also depends on the existence of an incoming connection. Some of the other parts of the firewall spec may depend on the ability to have IORs that are known to be not usable for invocations in places where they must exist to be passed as parameters. There are some unresolved issues in that area - and unless a new firewall RTF is chartered, these issues may have to be adopted by interop if they are to be fixed at all. > > 2. The difference is between errors the ORB can detect and prevent, > and errors that it cannot detect. The ORB may be able to detect an 'error', but it does not prevent it. In fact it forces the error to cause a fault where it might not otherwise have led to a fault. The fault does not happen earlier enough to be useful - I do not see that it makes it any easier to design or configure the system to avoid the fault. There is no obvious advantage for fault-tolerance either - in fact, it seems to be more difficult to deal with the fault. If an invocation that passes many references as both in and out parameters, a fault indicating that one or other of invoker and invokee does not like one of the references does not provide much clue about which of the references needs to be avoided/replaced. At least if the fault occurs when trying to invoke using the unusable reference, it is easier to see which reference is the problem, even if it may not be obvious what correcting action to take. Finally, and totally out of character, I shall argue against architectural purity with an analogy that is of doubtful relevance. In a hypertext system, a broken link is an error that architectural purity says must not occur. To the purists, the World Wide Web voilates the principles they hold dear by having no mechanism to detect and correct syntactically correct links that do not work when you actually try to follow them. Dropping the architectural purity, being satisfied with most links working most of the time, made it possible for WWW to escape from small-scale specialist applications and take over the Internet to the point where many people think it is the Internet. Perhaps CORBA needs to sacrifice some purity in order to succeed. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 2457 redux Date: Fri, 11 Feb 2000 08:47:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: _V-e9ADIe9[iBe9>Ohd9 Bill, I think you are being overprotective of the user, at the user's expense. You are saying this is an error because an object with no profiles understood by the orb is unusable. But that depends on your definition of "usable". An application that simply stores and returns object references *is* using them in the way it wishes. Why are you denying an application the right to use some object references in this way even if they are otherwise unusable? Paul > -----Original Message----- > From: Bill Janssen [mailto:janssen@parc.xerox.com] > Sent: Thursday, February 10, 2000 10:37 PM > To: Michi Henning > Cc: Jonathan Biggar; karsten-oliver.starr@ubs.com; interop@omg.org; > kraatika@cs.helsinki.fi; paulk@roguewave.com > Subject: Re: Issue 2457 redux > > > > Given that, I don't see what insistence on the presence of > IIOP profile > > would achieve. > > 1. I'm not insisting on the presence of an IIOP profile, just on > the > presence of a usable profile, usable by that ORB. > > 2. The difference is between errors the ORB can detect and prevent, > and errors that it cannot detect. > > Bill > Date: Tue, 15 Feb 2000 16:21:41 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: karsten-oliver.starr@ubs.com Cc: janssen@parc.xerox.com, interop@omg.org Subject: Actually Issue 3303 [was Re: Issue 3234] References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &Nmd9QM2!!2>Ae9J@0!! karsten-oliver.starr@ubs.com wrote: > > > In cases where an interoperable ORB is not intended > > > to invoke methods on a specific object it must not > > > reject the object - regardless of whether the IOR > > > contains profiles which the ORB is able to process > > > or not. > > > > There's no way to know, from the ORB's perspective, whether or not > it > > is 'not intended to invoke methods on a specific object'. > > > > Bill > > > > > Well, there is a way: IORs that are beeing passed as a > parameter (eg. 'in object') do not necessarily need > to be invoked. It's not the ORB's primary intention. > It's intention is to pass the object to another one. .... and how would the ORB know that a-priori? It is not the ORB that has the intentions, it is the applications running on top of the ORB that do, ..... well maybe they do. In effect what you are saying is that IOR received as in parameters should be accepted no matter what (which is th same as the position espoused by many). So could you identify which IOR's would then be rejected, if any?:-) Presumably the same logic would apply to any IOR received whether it be in an in paramter by itself, or inside a struct or union or valuetype? Would there then be any IORs that would be rejectable? So if there is no operational difference between this convoluted new language and the simple language that "IORs shall not be dropped because they do not contain any components or profile that the ORB supports or can make use of", why not use the simple language?:-) BTW, I think IORs that contain no identifiable valid identifiable encapsulations should be allowed to be dropped with a INV_OBJREF or some such, sicne the IOR is then ill-formed. > What about changing the statement into a more generic form: > > "Interoperable ORBS must not reject objects without > having to invoke them - regardless of whether the IOR > contains profiles which the ORB is able to process > or not." > > Any comments on that? I can't quite parse that and make any sense of it. Jishnu. To: jis@fpk.hp.com cc: karsten-oliver.starr@ubs.com, interop@omg.org Subject: Re: Actually Issue 3303 [was Re: Issue 3234] In-Reply-To: Your message of "Tue, 15 Feb 2000 13:21:57 PST." <38A9C365.DFC25349@fpk.hp.com> From: Bill Janssen Message-Id: <00Feb15.182622pst."3731"@watson.parc.xerox.com> Date: Tue, 15 Feb 2000 18:26:47 PST Content-Type: text X-UIDL: ?8G!!W*b!!?0'!!+^Ud9 > BTW, I think IORs that contain no identifiable valid identifiable encapsulations > should be allowed to be dropped with a INV_OBJREF or some such Do you really mean `encapsulation' here? Or profile, or what? Bill From: karsten-oliver.starr@ubs.com X-OpenMail-Hops: 2 Date: Wed, 16 Feb 2000 11:52:12 +0100 Message-Id: In-Reply-To: <38A9C365.DFC25349@fpk.hp.com> Subject: Issue 3303 MIME-Version: 1.0 TO: jis@fpk.hp.com CC: interop@omg.org, janssen@parc.xerox.com, karsten-oliver.starr@ubs.com Content-Disposition: inline ;Creation-Date="Wed, 16 Feb 2000 08:54:46 +0100" ;Modification-Date="Wed, 16 Feb 2000 11:52:12 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Wed, 16 Feb 2000 08:54:46 +0100" ;Modification-Date="Wed, 16 Feb 2000 11:52:12 +0100" X-UIDL: AG*!!]Vnd9n^?!!^+F!! > karsten-oliver.starr@ubs.com wrote: > > > > > In cases where an interoperable ORB is not intended > > > > to invoke methods on a specific object it must not > > > > reject the object - regardless of whether the IOR > > > > contains profiles which the ORB is able to process > > > > or not. > > > > > > There's no way to know, from the ORB's perspective, whether or > not it > > > is 'not intended to invoke methods on a specific object'. > > > > > > Bill > > > > > > > > Well, there is a way: IORs that are beeing passed as a > > parameter (eg. 'in object') do not necessarily need > > to be invoked. It's not the ORB's primary intention. > > It's intention is to pass the object to another one. > > .... and how would the ORB know that a-priori? It is not the ORB > that has the > intentions, it is the applications running on top of the ORB that > do, > ..... well maybe they do. What I am trying to say is: If the ORB receives a request or reply which contains an object as a parameter, the ORB should simply pass the request/reply to the destination object and not interpret/touch/change the parameter object. Which does not mean, that the object which is processing the request is not allowed to reject an invalid IOR (where invalid could be missing profiles, no profiles at all, corrupted IOR, ...). Example CosNaming: NamingContext->bind(in Name n, in Object obj); Neither the ORB nor the NamingContext object must reject the in-object. The purpose of a Name Server is to store object references. It may reject the in-object if the IOR is corrupt. It must not reject the in-object if it contains profiles which it does not recognize or if the TAG_INTERNET_IOP is missing. Example CosPersistence: CosPersistencePDS::PDS connect (in Object obj, in CosPersistencePID::PID p) The Persistence Service needs detailed information about the object. The ORB must not reject the in-object, but the Persistence Service can choose to reject it if the IOR is corrupt or represents an object that is not valid in the Services' ORB-domain (already addressed in issue 3235). Karsten Date: Wed, 16 Feb 2000 10:55:50 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Janssen Cc: karsten-oliver.starr@ubs.com, interop@omg.org Subject: Re: Actually Issue 3303 [was Re: Issue 3234] References: <00Feb15.182622pst."3731"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !D^!!~-1e9ig/e9f:a!! Bill Janssen wrote: > > BTW, I think IORs that contain no identifiable valid identifiable encapsulations > > should be allowed to be dropped with a INV_OBJREF or some such > > Do you really mean `encapsulation' here? Or profile, or what? I don't know what the right terminology is. What I am trying to say is that if the IOR is not recognizable as an IOR due to invalid construction of it (syntactically ill-formed), it should be rejected. It is sort of static the obvious. Jishnu. Date: Wed, 16 Feb 2000 11:02:33 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: karsten-oliver.starr@ubs.com Cc: interop@omg.org Subject: Re: Issue 3303 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6pP!!2">e9Cc^d97aQ!! karsten-oliver.starr@ubs.com wrote: > > karsten-oliver.starr@ubs.com wrote: > > > > > > > In cases where an interoperable ORB is not intended > > > > > to invoke methods on a specific object it must not > > > > > reject the object - regardless of whether the IOR > > > > > contains profiles which the ORB is able to process > > > > > or not. > > > > > > > > There's no way to know, from the ORB's perspective, whether or > not it > > > > is 'not intended to invoke methods on a specific object'. > > > > > > > > Bill > > > > > > > > > > > Well, there is a way: IORs that are beeing passed as a > > > parameter (eg. 'in object') do not necessarily need > > > to be invoked. It's not the ORB's primary intention. > > > It's intention is to pass the object to another one. > > > > .... and how would the ORB know that a-priori? It is not the ORB > that has the > > intentions, it is the applications running on top of the ORB that > do, > > ..... well maybe they do. > > What I am trying to say is: If the ORB receives a request or reply > which contains an object as a parameter, the ORB should simply pass > the > request/reply to the destination object and not > interpret/touch/change > the parameter object. > > Which does not mean, that the object which is processing the request > is not allowed to reject an invalid IOR (where invalid could be > missing > profiles, no profiles at all, corrupted IOR, ...). > > Example CosNaming: > NamingContext->bind(in Name n, in Object obj); > > Neither the ORB nor the NamingContext object must reject the > in-object. The purpose of a Name Server is to store object > references. It may reject the in-object if the IOR is corrupt. > It must not reject the in-object if it contains profiles which > it does not recognize or if the TAG_INTERNET_IOP is missing. > > Example CosPersistence: > CosPersistencePDS::PDS connect (in Object obj, in > CosPersistencePID::PID p) > > The Persistence Service needs detailed information about the object. > The ORB must not reject the in-object, but the Persistence Service > can > choose to reject it if the IOR is corrupt or represents an object > that is > not valid in the Services' ORB-domain (already addressed in issue > 3235). Ah I see. I misunderstood. As far as the Core standard is concerned, it only deals with what the ORB is allowed to do and what the ORB is supposed to do. What an application running on top of the ORB (and that includes Object Services) does with an object reference that it receives is entirely its business. It can do whatever it likes without running afoul of the first 15 chapters of the Core and Interop specification. So, what the Naming Context object can or cannot do is not the concern of the Core standard. So I think you and I agree on the portion that is relevant to issue 3303, that is that the ORB should not reject IORs that are well formed, but the contents of which are incomprehensible to the ORB. Regards, Jishnu. To: karsten-oliver.starr@ubs.com cc: jis@fpk.hp.com, interop@omg.org Subject: Re: Issue 3303 In-Reply-To: Your message of "Wed, 16 Feb 2000 03:02:54 PST." From: Bill Janssen Message-Id: <00Feb16.095344pst."3773"@watson.parc.xerox.com> Date: Wed, 16 Feb 2000 09:53:56 PST Content-Type: text X-UIDL: O7Ee9Ci:!!T4]!!@/+e9 > What I am trying to say is: If the ORB receives a request or reply > which contains an object as a parameter, the ORB should simply pass > the > request/reply to the destination object and not > interpret/touch/change > the parameter object. > > Which does not mean, that the object which is processing the request > is not allowed to reject an invalid IOR (where invalid could be > missing > profiles, no profiles at all, corrupted IOR, ...). Huh? How does `the object processing the request' know that the object has an invalid IOR? Do you mean that each method which receives object parameters which might be actually used should be wrapped with code which does object_to_string, then uses special IOR-parsing technology (not in the current CORBA spec) to determine whether or not the object reference is useful? That's exactly the situation I think should be avoided. Consider how you'd feel if someone bound unusable NamingContexts everywhere in your CosNaming server, so that resolve() of paths would break with a COMM_FAILURE. Would that really help the cause of interoperable naming? Bill From: Paul Kyzivat To: interop@omg.org Subject: RE: Issue 3303 Date: Wed, 16 Feb 2000 16:44:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: RC Consider how you'd feel if someone bound unusable NamingContexts > everywhere in your CosNaming server, so that resolve() of paths > would > break with a COMM_FAILURE. Would that really help the cause of > interoperable naming? I can easily do that even if the server is implemented using your orb. All I need to do is bind a bunch of contexts hosted on a machine I control, and then disconnect it from the network. Nor is this any different than the web model, where I can easily post web pages with links to non-existent urls. The problem isn't with the orb permitting this to happen. It is with allowing untrustworthy people to use the server. The real concern should be with grafting some sort of explicit authentication model onto the name service. Paul From: karsten-oliver.starr@ubs.com X-OpenMail-Hops: 2 Date: Thu, 17 Feb 2000 13:49:59 +0100 Message-Id: In-Reply-To: <00Feb16.095344pst."3773"@watson.parc.xerox.com> Subject: Re: Issue 3303 MIME-Version: 1.0 TO: janssen@parc.xerox.com CC: interop@omg.org, jis@fpk.hp.com, karsten-oliver.starr@ubs.com Content-Disposition: inline ;Creation-Date="Thu, 17 Feb 2000 13:42:43 +0100" ;Modification-Date="Thu, 17 Feb 2000 13:49:59 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 17 Feb 2000 13:42:43 +0100" ;Modification-Date="Thu, 17 Feb 2000 13:49:59 +0100" X-UIDL: @WF!!S0a!!`7%e9>Qi!! > Huh? How does `the object processing the request' know that the > object has an invalid IOR? Do you mean that each method which > receives object parameters which might be actually used should be > wrapped with code which does object_to_string, then uses special > IOR-parsing technology (not in the current CORBA spec) to determine > whether or not the object reference is useful? > 'the object proecessing the request' does its daily business. > Consider how you'd feel if someone bound unusable NamingContexts > everywhere in your CosNaming server, so that resolve() of paths > would > break with a COMM_FAILURE. Would that really help the cause of > interoperable naming? a) only interoperable behaviour helps interoperability b) un-authorized users are not able to bind anything if the NameServer is access-controlled. Karsten