From: Dr T A Urquhart To: "'interceptors-rtf@omg.org'" Cc: "Steve Osselton (E-mail)" Subject: Portable Interceptor Comments Date: Wed, 25 Apr 2001 23:10:31 +0100 Importance: high X-Priority: 1 (Highest) Organization: PrismTech Limited X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-UIDL: R!ad9JG1!![eF!!iZ_d9 Hi there We have an issue with part of the document that we would be grateful if the RTF could address: The draft specification we have is OMG document 2001-03-04 The bits that cause us problems are: 21.8.1 register_initial_reference An operation is available in the ORB interface: void register_initial_reference (in ObjectId id, in Object obj) raises (InvalidName); If this operation is called with an id, Y , and an object, YY, then a subsequent call to ORB::resolve_initial_references ( Y ) will return object YY. InvalidName is raised if: " this operation is called with an empty string id; or " this operation is called with an id that is already registered, including the default names defined by OMG. What we think this means is that it would be impossible to register (and resolve) ORB vendor external implementations of, for example, CORBA Services, such as Naming, Trading, Notification, etc. as they are some of the "default names". Could you please amend the second "or" clause to something like: or " this operation is called with an id that is already registered, including the default LOCALLY CONSTRAINED names defined by OMG, where 'LOCALLY CONSTRAINED' would not then apply to any predefined CORBA Service names such as NameService, NotificationService, etc. Many thanks and apologies if you've already addressed this. Tom P.S. I'm at the Technical Meeting in Paris if you need further detail. ======================================== Tom Urquhart, PhD Chief Technology Officer PrismTech Limited PrismTech House, 5th Avenue Business Park Team Valley, Gateshead NE11 0NG United Kingdom Tel: +44 (0)191 497 9900 Cell: +44 (0)7774 983 582 Fax: +44 (0)191 497 9901 e-mail: tom.urquhart@prismtechnologies.com Web: http://www.prismtechnologies.com "The Integration Server Company" ======================================== Date: Wed, 23 Oct 2002 15:48:56 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Issue 4284 Discussion Summary: 21.8.1 register_initial_reference An operation is available in the ORB interface: void register_initial_reference (in ObjectId id, in Object obj) raises (InvalidName); If this operation is called with an id, Y , and an object, YY, then a subsequent call to ORB::resolve_initial_references ( Y ) will return object YY. InvalidName is raised if: " this operation is called with an empty string id; or " this operation is called with an id that is already registered, including the default names defined by OMG. What we think this means is that it would be impossible to register (and resolve) ORB vendor external implementations of, for example, CORBA Services, such as Naming, Trading, Notification, etc. as they are some of the "default names". Could you please amend the second "or" clause to something like: or " this operation is called with an id that is already registered, including the default LOCALLY CONSTRAINED names defined by OMG, where 'LOCALLY CONSTRAINED' would not then apply to any predefined CORBA Service names such as NameService, NotificationService, etc. Many thanks and apologies if you've already addressed this. ___________________________________________________________ So what do y'all think about this proposed change? Basically this would allow non-ORB vendor supplied Name Service etc. to be substituted for the built in ones. Not a bad thing overall I think, as long as access to this is severely controlled. Otherwise it becomes a very lucrative path for planting Trojan Horses. Thanks, Jishnu. Sender: jbiggar@Resonate.com Date: Wed, 23 Oct 2002 13:24:17 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Issue 4284 Discussion Jishnu Mukerji wrote: > > Summary: 21.8.1 register_initial_reference ... > So what do y'all think about this proposed change? Basically this would > allow non-ORB vendor supplied Name Service etc. to be substituted for > the built in ones. Not a bad thing overall I think, as long as access to > this is severely controlled. Otherwise it becomes a very lucrative path > for planting Trojan Horses. I think we will have to do something, since the wording as written technically prevents a third party implementation of the OTS or Security services. I wouldn't worry about trojan horses. If malevolent code is already running in your process, then preventing it from using register_initial_references() is closing the barn door after the horse is gone. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 23 Oct 2002 17:24:26 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Issue 4284 Discussion Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > Summary: 21.8.1 register_initial_reference > > ... > > > So what do y'all think about this proposed change? Basically this would > > allow non-ORB vendor supplied Name Service etc. to be substituted for > > the built in ones. Not a bad thing overall I think, as long as access to > > this is severely controlled. Otherwise it becomes a very lucrative path > > for planting Trojan Horses. > > I think we will have to do something, since the wording as written > technically prevents a third party implementation of the OTS or Security > services. So does the proposal in the issue archive work, or do we need to do something else? Thanks, Jishnu. Sender: jon@floorboard.com Date: Wed, 23 Oct 2002 20:54:52 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: corba-rtf@omg.org Subject: Re: Issue 4284 Discussion Jishnu Mukerji wrote: > > > Summary: 21.8.1 register_initial_reference > > > > ... > > > > > So what do y'all think about this proposed change? Basically this would > > > allow non-ORB vendor supplied Name Service etc. to be substituted for > > > the built in ones. Not a bad thing overall I think, as long as access to > > > this is severely controlled. Otherwise it becomes a very lucrative path > > > for planting Trojan Horses. > > > > I think we will have to do something, since the wording as written > > technically prevents a third party implementation of the OTS or Security > > services. > > So does the proposal in the issue archive work, or do we need to do > something else? After thinking about it for a bit, I think we should drop the prohibition against registering reserved ObjectId names. I can see scenarios where virtually all of the "reserved" names could be removed from an ORB core implementation and provided as interceptor plugins instead. (Although it would be a bit of a stretch for ORBPolicyManager, PolicyCurrent or PICurrent.) How about changing the text to: ---- o this operation is called with an empty string id; or o this operation is called with an id that is already registered. It is implementation dependent whether or not the ORB will permit registration of object references using the reserved names listed in table 4-1. ---- BTW, shouldn't table 4-1 be moved to Appendix A? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 24 Oct 2002 11:37:15 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: corba-rtf@omg.org Subject: Re: Issue 4284 Discussion I could go with that. Anyone else with an opinion on this one? Thanks, Jishnu. Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > Summary: 21.8.1 register_initial_reference > > > > > > ... > > > > > > > So what do y'all think about this proposed change? Basically this would > > > > allow non-ORB vendor supplied Name Service etc. to be substituted for > > > > the built in ones. Not a bad thing overall I think, as long as access to > > > > this is severely controlled. Otherwise it becomes a very lucrative path > > > > for planting Trojan Horses. > > > > > > I think we will have to do something, since the wording as written > > > technically prevents a third party implementation of the OTS or Security > > > services. > > > > So does the proposal in the issue archive work, or do we need to do > > something else? > > After thinking about it for a bit, I think we should drop the > prohibition against registering reserved ObjectId names. I can see > scenarios where virtually all of the "reserved" names could be removed > from an ORB core implementation and provided as interceptor plugins > instead. (Although it would be a bit of a stretch for ORBPolicyManager, > PolicyCurrent or PICurrent.) > > How about changing the text to: > > ---- > o this operation is called with an empty string id; > > or > > o this operation is called with an id that is already registered. It is > implementation dependent whether or not the ORB will permit registration > of object references using the reserved names listed in table 4-1. > > ---- > > BTW, shouldn't table 4-1 be moved to Appendix A? > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Software Global Business Unit Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Date: Thu, 24 Oct 2002 16:40:49 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jishnu Mukerji CC: Jonathan Biggar , corba-rtf@omg.org Subject: Re: Issue 4284 Discussion > > How about changing the text to: > > > > ---- > > o this operation is called with an empty string id; > > > > or > > > > o this operation is called with an id that is already registered. > >It is > > implementation dependent whether or not the ORB will permit > >registration > > of object references using the reserved names listed in table 4-1. It seems that the spec is better served if it either says it works or it doesn't. Implementation dependent basically says you can't count on it - so why bother? I think it should be legal to replace reserved names. Cheers, Harold Sender: jbiggar@Resonate.com Date: Thu, 24 Oct 2002 10:08:11 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Harold Carr CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issue 4284 Discussion Harold Carr wrote: > > > > How about changing the text to: > > > > > > ---- > > > o this operation is called with an empty string id; > > > > > > or > > > > > > o this operation is called with an id that is already registered. It is > > > implementation dependent whether or not the ORB will permit registration > > > of object references using the reserved names listed in table 4-1. > > It seems that the spec is better served if it either says it works or it > doesn't. Implementation dependent basically says you can't count on it > - so why bother? I think it should be legal to replace reserved names. I could live with that, with an added caveat that replacing some names almost certainly breaks the ORB, like PICurrent, for example. Then the "builtin" versions of the reserved names would be found only if register_initial_reference() or -ORBInitRef didn't provide an override. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 24 Oct 2002 17:11:07 +0000 From: Harold Carr X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en To: Jonathan Biggar CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issue 4284 Discussion Hello Jonathan, > > It seems that the spec is better served if it either says it works or it > > doesn't. Implementation dependent basically says you can't count on it > > - so why bother? I think it should be legal to replace reserved names. > > I could live with that, with an added caveat that replacing some names > almost certainly breaks the ORB, like PICurrent, for example. Then the > "builtin" versions of the reserved names would be found only if > register_initial_reference() or -ORBInitRef didn't provide an override. > It seems we are in agreement. However the way the "Then" follows your first sentence confuses me. I do not think there is an implication between the first sentence and the second. Bottom line: You can replace reserved names - but replacer beware, you could break the ORB. If not replaced then the builtin versions are found. Right? Thanks, H Sender: jbiggar@Resonate.com Date: Thu, 24 Oct 2002 10:24:08 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Harold Carr CC: Jishnu Mukerji , corba-rtf@omg.org Subject: Re: Issue 4284 Discussion Harold Carr wrote: > > > It seems that the spec is better served if it either says it works or it > > > doesn't. Implementation dependent basically says you can't count on it > > > - so why bother? I think it should be legal to replace reserved names. > > > > I could live with that, with an added caveat that replacing some names > > almost certainly breaks the ORB, like PICurrent, for example. Then the > > "builtin" versions of the reserved names would be found only if > > register_initial_reference() or -ORBInitRef didn't provide an override. > > > > It seems we are in agreement. However the way the "Then" follows your > first sentence confuses me. I do not think there is an implication > between the first sentence and the second. The second sentence follows from the order of resolution defined in 4.5.3.4, which BTW, has an editorial error: two number 1s in the order list. > Bottom line: You can replace reserved names - but replacer beware, you > could break the ORB. If not replaced then the builtin versions are > found. Right? Yes, per the list in 4.5.3.4. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 24 Oct 2002 17:12:54 -0400 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Proposed resolution for 4284 Comments? Jishnu. _____________________________________________________________________ Issue 4284: 21.8.1 register_initial_reference (interceptors-rtf) Click http://cgi.omg.org/issues/issue4284.txt for this issue's archive. Source: Cap Gemini Ernst & Young (Tom Urquhart, PhD, tom.urquhart@capgemini.co.uk) Nature: Uncategorized Issue Severity: Summary: ....... etc ........ Resolution: Allow replacement of object reference associated with OMG specified default names. There appears to be no reason to disallow substitution of any object reference for any registered name, OMG specified standard names or otherwise. Revised Text: In formal/02-06-01 in section 21.8.1 1. Immediately following the second paragraph of the section insert the following paragraph: "This operation can be used to replace the object reference corresponding to any of the OMG specified Ids. For example: register_initial_reference ("NameService", Z) will cause Z to be substituted as the object reference that will be used to get to the Name Service instead of the ORB vendor supplied built in Name Service. This facility should be used with care since subsitution of certain OMG specified ids is unlikely to work at all." 2. Remove the bullets that follow the line that reads "InvalidName is raised if:" and replace the line with: "InvalidName is raised if this operation is called with an empty string id." Actions taken: Incorporate changes and close issue Reply-To: "Michi Henning" From: "Michi Henning" To: "Harold Carr" , "Jishnu Mukerji" Cc: "Jonathan Biggar" , Subject: Re: Issue 4284 Discussion Date: Fri, 25 Oct 2002 07:29:21 +1000 Organization: Triodia Technologies X-Mailer: Microsoft Outlook Express 6.00.2800.1106 > > > How about changing the text to: > > > > > > ---- > > > o this operation is called with an empty string id; > > > > > > or > > > > > > o this operation is called with an id that is already > > >registered. It is > > > implementation dependent whether or not the ORB will permit registration > > > of object references using the reserved names listed in table > > >4-1. > > It seems that the spec is better served if it either says it works > > >or it > doesn't. Implementation dependent basically says you can't count on > > >it > - so why bother? I think it should be legal to replace reserved > > >names. I agree. Saying that it is implementation-dependent is not much better than not saying anything at all. Cheers, Michi. -- Michi Henning Ph: +61 4 1118-2700 Triodia Technologies http://www.triodia.com/staff/michi X-Sender: cem@popserver.hursley.ibm.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 29 Oct 2002 02:36:28 +0000 To: corba-rtf@omg.org From: Caroline Maynard Subject: Re: Issue 4284 Discussion At 07:29 AM 25/10/2002 +1000, you wrote: >> > > How about changing the text to: >> > > >> > > o this operation is called with an empty string id; >> > > or >> > > o this operation is called with an id that is already registered. It is >> > > implementation dependent whether or not the ORB will permit registration >> > > of object references using the reserved names listed in table 4-1. >> >> It seems that the spec is better served if it either says it works or it >> doesn't. Implementation dependent basically says you can't count on it >> - so why bother? I think it should be legal to replace reserved names. > >I agree. Saying that it is implementation-dependent is not much better >than not saying anything at all. > I think the point of the original issue is that there is a distinction between two subsets of the reserved ObjectIds, a "mandatory" set, for example PICurrent, and an "optional" set, for example NameService. The issue was intended to remove the unnecessary restriction on registering ObjectIds in the "optional" set only. It's misleading to suggest that ObjectIds in the first set are replaceable, because the builtin implementation will already be in place before you ever get to invoke register_initial_reference(), so an attempt to override the builtin implementation can never succeed. So, table 4.1 could be modified to say which ObjectIds may be available for registration, and which will never be. I think this would be a little better than not saying anything at all. -- Caroline X-Sender: cem@popserver.hursley.ibm.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 05 Nov 2002 17:21:12 +0000 To: Jishnu Mukerji From: Caroline Maynard Subject: Re: Issue 4284 Discussion Cc: corba-rtf@omg.org At 11:58 AM 29/10/2002 -0500, Jishnu Mukerji wrote: > >1. Immediately following the second paragraph of the section insert the >following paragraph: > >"This operation can be used to replace the object reference >corresponding to any of the OMG specified Ids. For example: > > register_initial_reference ("NameService", Z) > >will cause Z to be substituted as the object reference that will be used >to get to the Name Service instead of the ORB vendor supplied built in >Name Service. This facility should be used with care since subsitution >of certain OMG specified ids is unlikely to work at all." > >Note: This is where we might want to identify specific Object Ids for >which substitution will never work. Do we want to do that? > Sorry for the delay, I've been out of the office. I think the set which can never be replaceable are RootPOA, POACurrent, DynAnyFactory, ORBPolicyManager, PolicyCurrent, CodecFactory, and PICurrent. I still claim it would be clearer to state this explicitly. However if any vendor does wish to allow substitution of these Object Ids, then I could live with the resolution as stated. -- Caroline Maynard IBM Centre for Java Technology, Hursley Date: Tue, 05 Nov 2002 12:33:12 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Caroline Maynard Cc: corba-rtf@omg.org Subject: Re: Issue 4284 Discussion Caroline Maynard wrote: > > At 11:58 AM 29/10/2002 -0500, Jishnu Mukerji wrote: > > > >1. Immediately following the second paragraph of the section insert the > >following paragraph: > > > >"This operation can be used to replace the object reference > >corresponding to any of the OMG specified Ids. For example: > > > > register_initial_reference ("NameService", Z) > > > >will cause Z to be substituted as the object reference that will be used > >to get to the Name Service instead of the ORB vendor supplied built in > >Name Service. This facility should be used with care since subsitution > >of certain OMG specified ids is unlikely to work at all." > > > >Note: This is where we might want to identify specific Object Ids for > >which substitution will never work. Do we want to do that? > > > Sorry for the delay, I've been out of the office. > > I think the set which can never be replaceable are RootPOA, POACurrent, > DynAnyFactory, ORBPolicyManager, PolicyCurrent, CodecFactory, and > PICurrent. I still claim it would be clearer to state this explicitly. > However if any vendor does wish to allow substitution of these Object Ids, > then I could live with the resolution as stated. How about if we say something like: "Implementtions are allowed to restrict substituability of references corresponding to the following ObjectIds: RootPOA, POACurrent, DynAnyFactory, ORBPolicyManager, PolicyCurrent, CodecFactory, and PICurrent. When substitutability is restricted it shall be clearly docmented and attempt to substitute references for one of those ObjectIds shall result in the raising of the InvalidName exception." Or something to that effect? Thanks, Jishnu. Date: Tue, 05 Nov 2002 16:51:13 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Issue 4284 proposed resolution The following resolution will appear in a vote in the near future unless there is significant technical objection to it. Jishnu. ___________________________________________________________________ Issue 4284: 21.8.1 register_initial_reference (interceptors-rtf) Click http://cgi.omg.org/issues/issue4284.txt for this issue's archive. Source: Cap Gemini Ernst & Young (Tom Urquhart, PhD, tom.urquhart@capgemini.co.uk) Nature: Uncategorized Issue Severity: Summary: . . . . . . . . . Resolution: Allow replacement of object reference associated with OMG specified default names. There appears to be no reason to disallow substitution of any object reference for any registered name, OMG specified standard names or otherwise. Revised Text: In formal/02-06-01 in section 21.8.1 1. Immediately following the second paragraph of the section insert the following paragraph: "This operation can be used to replace the object reference corresponding to any of the OMG specified Ids. For example: register_initial_reference ("NameService", Z) will cause Z to be substituted as the object reference that will be used to get to the Name Service instead of the ORB vendor supplied built in Name Service. This facility should be used with care since subsitution of certain OMG specified ids is unlikely to work at all." Implementtions are allowed to restrict substituability of references corresponding to the following ObjectIds: RootPOA, POACurrent, DynAnyFactory, ORBPolicyManager, PolicyCurrent, CodecFactory, and PICurrent. When substitutability is restricted it shall be clearly docmented. InvalidName exception is raised when any of these restricted ObjectIds are passed in as a parameter to resolve_initial_reference." 2. Remove the bullets that follow the line that reads "InvalidName is raised if:" and replace the line with: "InvalidName is raised if this operation is called with an empty string id." Actions taken: Incorporate changes and close issue