Issue 2069: CORBA::PolicyManager (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: SecurityCurrent should probably inherit from PolicyCurrent to marry this functionality of dealing with policies. However, the messaging specification I don"t think is "adopted", although it has an RTF. I don"t know what is the proper procedure about RTFing things on not-yet adopted technology. The PolicyManager has a serious, or at least I think it"s serious flaw. The PolicyManager has "get_policy_overrides" and "set_policy_overrides" functions. So does CORBA::Object. However, the problem is. Not only do these operations on PolicyManager have different semantics than the corresponding ones on CORBA::Object, "set_policy_overrides" has a different signature! Resolution: Revised Text: Actions taken: October 9, 1998: received issue June 18, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 9 Oct 1998 18:36:21 -0400 (EDT) From: Polar Humenn Reply-To: Polar Humenn To: secsig@omg.org, sec-rev@omg.org, orb_revision@omg.org Subject: CORBA::PolicyManager Apparently, there is slated with adoption of the messaging specification changes to the ORB core concerning policy objects that the Security RTF should visit and comment on. They introduce this PolicyManager interface which handles the management of "default" policies which are thread specific, basically, the PolicyCurrent object inherits from Current and PolicyManager. (IDL is provided below). Two things: SecurityCurrent should probably inherit from PolicyCurrent to marry this functionality of dealing with policies. However, the messaging specification I don't think is "adopted", although it has an RTF. I don't know what is the proper procedure about RTFing things on not-yet adopted technology. If we take that approach we can start a migration path and get rid of some nastyness on SecurityCurrent. I see in the violation of the object model with respect to SecurityCurrent. The violation I see is that on Current we use "get_policy" to get the polices that we set for defaults on a new object binding, and they don't really apply to the Current object itself! I think this semantically hoses the Object model, doesn't it? It still has more problems! The PolicyManager has a serious, or at least I think it's serious flaw. The PolicyManager has "get_policy_overrides" and "set_policy_overrides" functions. So does CORBA::Object. However, the problem is. Not only do these operations on PolicyManager have different semantics than the corresponding ones on CORBA::Object, "set_policy_overrides" has a different signature! I think this might need some fixing? Or am I missing something? Comments? -Polar PS: Current state of the PolicyManager and relavent Object IDL is below: module CORBA { interface PolicyManager { PolicyList get_policy_overrides(in PolicyTypeSeq ts); void set_policy_overrides( in PolicyList policies, in SetOverrideType set_add) raises (InvalidPolicies); }; interface PolicyCurrent : PolicyManager, Current { }; interface Object { Policy get_policy(in PolicyType type); Policy get_client_policy(in PolicyType type); Object set_policy_overrides( in PolicyList policies, in SetOverrideType set_add) raises (InvalidPolicies); PolicyList get_policy_overrides( in PolicyTypeSeq types); boolean validate_connection(out PolicyList inconsistent_policies); }; }; ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Return-Path: Date: Fri, 09 Oct 1998 23:29:39 -0700 From: "Jon Goldberg" Reply-To: goldberg@inprise.com X-Accept-Language: en To: Polar Humenn CC: secsig@omg.org, sec-rev@omg.org, orb_revision@omg.org, messaging-rtf@omg.org Subject: Re: CORBA::PolicyManager References: Hi- I've also CC'd 'messaging-rtf@omg.org' on this thread... comments below... Polar Humenn wrote: [...snip...] > It still has more problems! The PolicyManager has a serious, or at least I > think it's serious flaw. The PolicyManager has "get_policy_overrides" and > "set_policy_overrides" functions. So does CORBA::Object. However, the > problem is. Not only do these operations on PolicyManager have different > semantics than the corresponding ones on CORBA::Object, > "set_policy_overrides" has a different signature! > > I think this might need some fixing? Or am I missing something? I don't see the inconsistency. Since Object references are immutable, the set_policy_overrides on CORBA::Object returns a new object reference with the new overrides imposed (or raises an exception). The PolicyManager interface allows you to set new overrides at wider scopes (thread/ORB). These overrides are not directly linked to an object reference so it is not appropriate to return a new Object. What is the semantic difference you are trying to reconcile? -Jon > > PS: Current state of the PolicyManager and relavent Object IDL is > below: > > module CORBA > { > interface PolicyManager { > PolicyList get_policy_overrides(in PolicyTypeSeq ts); > void set_policy_overrides( > in PolicyList policies, > in SetOverrideType set_add) > raises (InvalidPolicies); > }; > > interface PolicyCurrent : PolicyManager, Current { > }; > > interface Object { > Policy get_policy(in PolicyType type); > Policy get_client_policy(in PolicyType type); > Object set_policy_overrides( > in PolicyList policies, > in SetOverrideType set_add) > raises (InvalidPolicies); > PolicyList get_policy_overrides( > in PolicyTypeSeq types); > boolean validate_connection(out PolicyList > inconsistent_policies); > }; > }; Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Sat, 10 Oct 1998 16:10:30 -0400 (EDT) From: Polar Humenn To: goldberg@inprise.com cc: secsig@omg.org, sec-rev@omg.org, orb_revision@omg.org, messaging-rtf@omg.org Subject: Re: CORBA::PolicyManager On Fri, 9 Oct 1998, Jon Goldberg wrote: > Hi- > > I've also CC'd 'messaging-rtf@omg.org' on this thread... > > comments below... > > Polar Humenn wrote: > [...snip...] > > It still has more problems! The PolicyManager has a serious, or at > least I > > think it's serious flaw. The PolicyManager has > "get_policy_overrides" and > > "set_policy_overrides" functions. So does CORBA::Object. However, > the > > problem is. Not only do these operations on PolicyManager have > different > > semantics than the corresponding ones on CORBA::Object, > > "set_policy_overrides" has a different signature! > > > > I think this might need some fixing? Or am I missing something? > > I don't see the inconsistency. Since Object references are > immutable, > the set_policy_overrides on CORBA::Object returns a new object > reference with the new overrides imposed (or raises an exception). > The PolicyManager interface allows you to set new overrides at wider > scopes (thread/ORB). These overrides are not directly linked to > an object reference so it is not appropriate to return a new Object. > What is the semantic difference you are trying to reconcile? Well, the first difference is that policies that come from get_policy or get_policy_overrides are the policies that apply to communication with the object being referred to, remote, local, or locality constrained. That is, they apply to communication with the object behind the reference and not with what that object does. The policies set_policy_overrides on the policy manager are for what the policy manager does, applies policies to object references created within its scope. Say, I have a SecurityLevel2::QOPPolicy object containing the qop attribute of SecQOPIntegrity. If I put that on the PolicyCurrent using set_policy_overrides, I should expect it to have the same effect as if I put that policy on a remote object, would I not? Otherwise, the method is overloaded. Finally, the set_policy_overrides has a different signature for PolicyManager than it does for CORBA::Object! I believe this thing is highly illegal. These operations and what they are trying to accomplisy for the PolicyManager interface shouldn't be mixed up with the ones on CORBA::Object. They should have different names to reflect the semantic difference. A couple of (poor) examples: PolicyManager::get_manager_policy_overrides PolicyManager::set_manager_policy_overrides PolicyManager::get_policies_for_scope PolicyManager::set_policies_for_scope Hope you see the difference. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Return-Path: Date: Mon, 12 Oct 1998 14:13:34 -0700 From: "Jon Goldberg" Reply-To: goldberg@inprise.com X-Accept-Language: en To: Polar Humenn CC: secsig@omg.org, sec-rev@omg.org, orb_revision@omg.org, messaging-rtf@omg.org Subject: Re: CORBA::PolicyManager References: Hi Polar- Just to make sure I understand your point... Are you saying that because PolicyManager is an interface (and therefore supports the CORBA::Object pseudo-operations) that there is a conflict between those inherited pseudo-ops and the PolicyManager operations that are used to set policies on the appropriate "managed" object references? You aren't pointing out anything problematic with the actual operation semantics, right? Here is the relevant PIDL and IDL: interface Object { // PIDL Policy get_policy(in PolicyType type); Policy get_client_policy(in PolicyType type); Object set_policy_overrides( in PolicyList policies, in SetOverrideType set_add) raises (InvalidPolicies); PolicyList get_policy_overrides( in PolicyTypeSeq types); }; interface PolicyManager { // IDL PolicyList get_policy_overrides(in PolicyTypeSeq ts); void set_policy_overrides( in PolicyList policies, in SetOverrideType set_add) raises (InvalidPolicies); }; The PolicyManager operations are not overriding the inherited Object pseudo ops (all language mappings ensure this cannot happen). They are completely distinct. The inherited pseudo- operations would be used to override policies on accessing the PolicyManager itself (probably a strange thing to do given that the object is always local, but not illegal). So, a PolicyManager still has both sets of operations -- pseudo-ops that control the PolicyManager reference behavior, and real operations that control the PolicyManager implementation behavior. We decided to keep the names/signatures as close as possible so the APIs would be as easy as possible to learn. take care, Jon Polar Humenn wrote: > > On Fri, 9 Oct 1998, Jon Goldberg wrote: > > > Hi- > > > > I've also CC'd 'messaging-rtf@omg.org' on this thread... > > > > comments below... > > > > Polar Humenn wrote: > > [...snip...] > > > It still has more problems! The PolicyManager has a serious, or > at least I > > > think it's serious flaw. The PolicyManager has > "get_policy_overrides" and > > > "set_policy_overrides" functions. So does CORBA::Object. > However, the > > > problem is. Not only do these operations on PolicyManager have > different > > > semantics than the corresponding ones on CORBA::Object, > > > "set_policy_overrides" has a different signature! > > > > > > I think this might need some fixing? Or am I missing something? > > > > I don't see the inconsistency. Since Object references are > immutable, > > the set_policy_overrides on CORBA::Object returns a new object > > reference with the new overrides imposed (or raises an exception). > > > The PolicyManager interface allows you to set new overrides at > wider > > scopes (thread/ORB). These overrides are not directly linked to > > an object reference so it is not appropriate to return a new > Object. > > > What is the semantic difference you are trying to reconcile? > > Well, the first difference is that policies that come from > get_policy or > get_policy_overrides are the policies that apply to communication > with > the object being referred to, remote, local, or locality > constrained. That > is, they apply to communication with the object behind the reference > and > not with what that object does. > > The policies set_policy_overrides on the policy manager are for what > the > policy manager does, applies policies to object references created > within > its scope. > > Say, I have a SecurityLevel2::QOPPolicy object containing the qop > attribute of SecQOPIntegrity. If I put that on the PolicyCurrent > using > set_policy_overrides, I should expect it to have the same effect as > if I > put that policy on a remote object, would I not? Otherwise, the > method is > overloaded. > > Finally, the set_policy_overrides has a different signature for > PolicyManager than it does for CORBA::Object! I believe this thing > is > highly illegal. > > These operations and what they are trying to accomplisy for the > PolicyManager interface shouldn't be mixed up with the ones on > CORBA::Object. They should have different names to reflect the > semantic > difference. A couple of (poor) examples: > > PolicyManager::get_manager_policy_overrides > PolicyManager::set_manager_policy_overrides > > PolicyManager::get_policies_for_scope > PolicyManager::set_policies_for_scope > > Hope you see the difference. > Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 15 Oct 1998 11:13:08 -0400 (EDT) From: Polar Humenn To: orb_revision@omg.org, messaging-rtf@omg.org, messaging@omg.org, secsig@omg.org, sec-rev@omg.org Subject: CORBA::PolicyManager, any more comments? Are there any more comments on my issue about the operations on the CORBA:PolicyManager (from the Messaging specification) having operations of the same name as CORBA::Object? Those operations are "set_policy_overrides" and "get_policy_overrides". They have different semantics, yet the same names. Jon Goldberg pointed out that the CORBA::Object operations are pseudo operations, so they shouldn't "technically" be confused. However, I believe it is dangerous to have such similarity. For example in the Java mapping those names are only different by a prepended underbar: pm._set_policy_overrides() and pm.set_policy_overrides() I believe this situation is not good software engineering. Especially, when convention and precedent is set at the naming similarity of operations by the standard org.omg.portable.ObjectImpl implementation (from the Java Mapping RTF update, orbos/98-07-19) public org.omg.CORBA.Object _set_policy_overrides(org.omg.CORBA.Policy[] np, int set_add) throws org.omg.CORBA.PolicyManagerPackage.InvalidPolicies { return _get_delegate().set_policy_overrides(np, set_add); } That is, _set_policy_overrides delegates a call to set_policy_overrides which has the same semantics. Anyway, in IDL or PIDL, whatever, the names are the same, yet the semantics of the operations are different. May I raise an issue on this one? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Return-Path: Sender: "Jon Goldberg" Date: Thu, 15 Oct 1998 09:57:45 -0700 From: Jon Goldberg Reply-To: goldberg@inprise.com Organization: Visigenic Software, Inc. X-Accept-Language: en To: Polar Humenn CC: orb_revision@omg.org, messaging-rtf@omg.org, messaging@omg.org, secsig@omg.org, sec-rev@omg.org Subject: Re: CORBA::PolicyManager, any more comments? References: I think you should go ahead and open an issue along the lines of: "The CORBA::PolicyManager operation names should be changed to prevent confusion between those operations and the pseudo- operations inherited from CORBA::Object." take care, Jon Polar Humenn wrote: > > Are there any more comments on my issue about the operations on the > CORBA:PolicyManager (from the Messaging specification) having > operations > of the same name as CORBA::Object? Those operations are > "set_policy_overrides" and "get_policy_overrides". They have > different > semantics, yet the same names. > > Jon Goldberg pointed out that the CORBA::Object operations are > pseudo > operations, so they shouldn't "technically" be confused. However, I > believe it is dangerous to have such similarity. For example in the > Java > mapping those names are only different by a prepended underbar: > pm._set_policy_overrides() > and > pm.set_policy_overrides() > > I believe this situation is not good software > engineering. Especially, > when convention and precedent is set at the naming similarity of > operations by the standard org.omg.portable.ObjectImpl > implementation > (from the Java Mapping RTF update, orbos/98-07-19) > > public org.omg.CORBA.Object > _set_policy_overrides(org.omg.CORBA.Policy[] np, int set_add) > throws org.omg.CORBA.PolicyManagerPackage.InvalidPolicies > { > return _get_delegate().set_policy_overrides(np, set_add); > } > > That is, _set_policy_overrides delegates a call to > set_policy_overrides which has the same semantics. > > Anyway, in IDL or PIDL, whatever, the names are the same, yet the > semantics of the operations are different. > > May I raise an issue on this one? > > -Polar Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 15 Oct 1998 14:22:47 -0400 (EDT) From: Polar Humenn To: issues@omg.org Subject: Re: CORBA::PolicyManager, any more comments? (fwd) Document: Messaging orbos/98-05-06 Summary: The CORBA::PolicyManager operation names should be changed to prevent confusion between those operations and the pseudo- operations inherited from CORBA::Object. Discussion: > Are there any more comments on my issue about the operations on the > CORBA:PolicyManager (from the Messaging specification) having > operations > of the same name as CORBA::Object? Those operations are > "set_policy_overrides" and "get_policy_overrides". They have > different > semantics, yet the same names. > > Jon Goldberg pointed out that the CORBA::Object operations are > pseudo > operations, so they shouldn't "technically" be confused. However, I > believe it is dangerous to have such similarity. For example in the > Java > mapping those names are only different by a prepended underbar: > pm._set_policy_overrides() > and > pm.set_policy_overrides() > > I believe this situation is not good software > engineering. Especially, > when convention and precedent is set at the naming similarity of > operations by the standard org.omg.portable.ObjectImpl > implementation > (from the Java Mapping RTF update, orbos/98-07-19) > > public org.omg.CORBA.Object > _set_policy_overrides(org.omg.CORBA.Policy[] np, int set_add) > throws org.omg.CORBA.PolicyManagerPackage.InvalidPolicies > { > return _get_delegate().set_policy_overrides(np, set_add); > } > > That is, _set_policy_overrides delegates a call to > set_policy_overrides which has the same semantics. > > Anyway, in IDL or PIDL, whatever, the names are the same, yet the > semantics of the operations are different. > > May I raise an issue on this one? > > -Polar Return-Path: Date: Thu, 15 Oct 1998 18:37:00 -0400 From: Paul H Kyzivat Organization: NobleNet To: Polar Humenn CC: orb_revision@omg.org, messaging-rtf@omg.org, messaging@omg.org, secsig@omg.org, sec-rev@omg.org Subject: Re: CORBA::PolicyManager, any more comments? References: Polar Humenn wrote: > > Are there any more comments on my issue about the operations on the > CORBA:PolicyManager (from the Messaging specification) having > operations > of the same name as CORBA::Object? Those operations are > "set_policy_overrides" and "get_policy_overrides". They have > different > semantics, yet the same names. [snip] > I believe this situation is not good software engineering. [snip] > Anyway, in IDL or PIDL, whatever, the names are the same, yet the > semantics of the operations are different. > > May I raise an issue on this one? I agree with you - at best this is ugly certain to result in confusion. Please do raise it as an issue. Return-Path: Cc: orb_revision@omg.org, messaging-rtf@omg.org, messaging@omg.org, secsig@omg.org, sec-rev@omg.org Date: Fri, 16 Oct 1998 12:59:32 -0400 From: Tom Rutt Organization: Lucent Technologies - Bell Labs To: Polar Humenn Original-CC: orb_revision@omg.org, messaging-rtf@omg.org, messaging@omg.org, secsig@omg.org, sec-rev@omg.org Subject: Re: CORBA::PolicyManager, any more comments? References: Polar Humenn wrote: > Are there any more comments on my issue about the operations on the > CORBA:PolicyManager (from the Messaging specification) having > operations > of the same name as CORBA::Object? Those operations are > "set_policy_overrides" and "get_policy_overrides". They have > different > semantics, yet the same names. > > May I raise an issue on this one? > > -Polar > > ------------------------------------------------------------------- > You may raise an issue, but I do not see why there is a problem. The semantics are the same, except the level at which they are scoped (unless I misunderstand the Subltleties of the message policy stuff)? Operation names are scoped within the interface type. Other than multiple inheritance problems, operation names should be able to be kept short, but meaningful. I see no problem in the usage of an opertion name, such as "query" used in many different interface types. When a programmer types it into a program it will be "objectHandle->query()" which give the entire context, and has a short amount for typing. Tom Rutt -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 16 Oct 1998 13:56:09 -0400 (EDT) From: Polar Humenn To: Tom Rutt cc: orb_revision@omg.org, messaging-rtf@omg.org, messaging@omg.org, secsig@omg.org, sec-rev@omg.org Subject: Re: CORBA::PolicyManager, any more comments? On Fri, 16 Oct 1998, Tom Rutt wrote: > > > Polar Humenn wrote: > > > Are there any more comments on my issue about the operations on > the > > CORBA:PolicyManager (from the Messaging specification) having > operations > > of the same name as CORBA::Object? Those operations are > > "set_policy_overrides" and "get_policy_overrides". They have > different > > semantics, yet the same names. > > > > May I raise an issue on this one? > > > > -Polar > > > > > ------------------------------------------------------------------- > > > > You may raise an issue, but I do not see why there is a problem. > > The semantics are the same, except the level at which they are > scoped > (unless I misunderstand the Subltleties of the message policy > stuff)? The semantics are not the same. Object::get_policy_overrides gets policies that apply to the object reference itself. PolicyManager::get_policy_overrides gets policies that apply to other potential object references when they become bound, (i.e. IOR to object reference). The semantics is subtlely different, but nonetheless, different. > Operation names are scoped within the interface type. Other than > multiple inheritance problems, operation names should be able to > be kept short, but meaningful. > > I see no problem in the usage of an opertion name, such as "query" > used > in many different interface types. When a programmer types it into > a > program > it will be "objectHandle->query()" which give the entire context, > and has a > short > amount for typing. That is fine, however names should not be overriden in the case of simple inheritance, both in syntax (if the signatures are different, it is already condoned to be illegal), and in semantics. interface A { void foo(); }; interface B : A { void foo(); } is syntactly legal, however, if A::foo is defined to have semantics, "Takes fido for a walk", and the sematics for B::foo is defined "Eats an apple then cries", then we have a problem. And it all comes down to those substitutability arguments I think I saw fly by here a couple of weeks ago. > Tom Rutt > > > -- > ---------------------------------------------------------------- > Tom Rutt Tel: +1 732 949 7862 > Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 > Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com > Holmdel NJ, 07733 ---------------------------------------------- > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Return-Path: Sender: jon@floorboard.com Date: Fri, 16 Oct 1998 11:00:21 -0700 From: Jonathan Biggar X-Accept-Language: en To: Tom Rutt CC: Polar Humenn , orb_revision@omg.org, messaging-rtf@omg.org, messaging@omg.org, secsig@omg.org, sec-rev@omg.org Subject: Re: CORBA::PolicyManager, any more comments? References: <36277B74.85353FE6@lucent.com> Tom Rutt wrote: > > Polar Humenn wrote: > > > Are there any more comments on my issue about the operations on > the > > CORBA:PolicyManager (from the Messaging specification) having > operations > > of the same name as CORBA::Object? Those operations are > > "set_policy_overrides" and "get_policy_overrides". They have > different > > semantics, yet the same names. > > > > May I raise an issue on this one? > > > > -Polar > > > > > ------------------------------------------------------------------- > > > > You may raise an issue, but I do not see why there is a problem. > > The semantics are the same, except the level at which they are > scoped > (unless I misunderstand the Subltleties of the message policy > stuff)? > > Operation names are scoped within the interface type. Other than > multiple inheritance problems, operation names should be able to > be kept short, but meaningful. > > I see no problem in the usage of an opertion name, such as "query" > used > in many different interface types. When a programmer types it into > a > program > it will be "objectHandle->query()" which give the entire context, > and has a > short > amount for typing. Tom, here is the problem. When you are looking at existing code and see something like: PolicyList_var pl = policymanager->get_policy_overrides(types); it is not immediately obvious which "version" of get_policy_overrides is being called. To have the distinction be between get_policy_overrides and _get_policy_overrides is too prone to error. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: "Daniel R. Frantz" To: "'Polar Humenn'" , "'Tom Rutt'" Cc: , , , , Subject: RE: CORBA::PolicyManager, any more comments? Date: Wed, 21 Oct 1998 13:13:38 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 >-----Original Message----- >From: Polar Humenn [mailto:polar@adiron.com] >Sent: Friday, October 16, 1998 1:56 PM >To: Tom Rutt >Cc: orb_revision@omg.org; messaging-rtf@omg.org; messaging@omg.org; >secsig@omg.org; sec-rev@omg.org ... >That is fine, however names should not be overriden in the >case of simple >inheritance, both in syntax (if the signatures are different, it is >already condoned to be illegal), and in semantics. > >interface A { > void foo(); >}; > >interface B : A { > void foo(); >} > >is syntactly legal, however, if A::foo is defined to have semantics, Did I miss something earlier? CORBA 2.3a, Section 3.7, p. 3-22 states Operation and attribute names are used at run-time by both the stub and dynamic interfaces. As a result, all operations attributes that might apply to a particular object must have unique names. This requirement prohibits redefining an operation or attribute name in a derived interface, as well as inheriting two operations or attributes with the same name. interface A { void make_it_so(); }; interface B: A { short make_it_so(in long times); // Error: redefinition of make_it_so }; It says nothing about the signature, just the name. Are there words elsewhere that make this not so? Dan