Issue 3235: Should an ORB be allowed to drop non-standard profiles (interop) Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com) Nature: Uncategorized Issue Severity: Summary: Part 2: Should an ORB be allowed to drop non-standard profiles (as it is allowed to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though it is not faced with any resource contraints. Moreover, when it is faced with resource contraints should it be required to follow a specific sequence in determining what profiles to drop. Resolution: The proposed resolution defines two possible IOR conformance classes for every ORB interoperability Revised Text: Suggested Proposed Changes: Change the last sentence in the paragraph in 13.6.6 under the IDL description of the IOR format, and its footnote from: " A bridge between two domains may need to know the detailed content of the profile for those domains’ profiles, depending on the technique it uses to bridge the domains.1 <footnote 1 on page 13-16:> Based on topology and policy information available to it, a bridge may find it prudent to add or remove some profiles as it forwards an object reference. For example, a bridge acting as a firewall might remove all profiles except ones that make such profiles, letting clients that understand the profiles make routing choices. " to the following new paragraphs: " When a specific protocol is used to convey an object reference passed as a parameter in an IDL operation invocation (or reply), an IOR which reflects, in its contained profiles, the full protocol understanding of the operation client (or server in case of reply) may be sent. A receiving ORB which operates (based on topology and policy information available to it) on profiles rather than the received IOR as a whole, to create a derived reference for use in its own domain of reference, is placing itself as a bridge between reference domains. Interoperability inhibiting situations can arise when an orb sends an IOR with multiple profiles (using one of its supported protocols) to a receiving orb, and that receiving orb later returns a derived reference to that object, which has had profiles or profile component data removed or transformed from the original IOR contents. To assist in classifying behaviour of ORBS in such bridging roles, two classes of IOR conformance may be associated with the conformance requirements for a given ORB interoperability protocol: Full IOR conformance requires that an orb which receives an IOR for an object passed to it through that ORB interoperability protocol, shall recover the original IOR, in its entirety, for passing as a reference to that object from that orb through that same protocol Limited-Profile IOR conformance requires that an orb which receives an IOR passed to it through a given ORB interoperability protocol, shall recover all of the standard information contained in the IOR profile for that protocol, whenever passing a reference to that object, using that same protocol, to another ORB. Note: Conformance to IIOP versions 1.0, 1.1 and 1.2 only requires support of limited-Profile IOR conformance, specifically for the IIOP IOR profile. However, due to interoperability problems induced by Limited-Profile IOR conformance, it is now depricated by the CORBA 2.4 specification for an orb to not support Full IOR conformance. Some future IIOP versions could require Full IOR conformance. " Page 13-17, last para of 13.6.2.1: Add the following at the end of the para. " ORBs claiming to support the Full-IOR conformance are required to preserve all the semantic content of any IOR (including the ordering of each profile and its components), and may only apply transformations which preserve semantics(e.g., changing Byte order for encapsulation). For example, consider an echo operation for object references: interface Echoer {Object echo(in Object o);}; Assume that the method body implementing this operation simply returns its argument. When a client application invokes the echo operation and passes an arbitrary object reference, if both the client and server ORBs claim support to Full IOR conformance, the reference returned by the operation is guaranteed to have not been semantically altered by either client or server ORB. That is, all its profiles will remain intact and in the same order as they were present when the reference was sent. This requirement for ORBs which claim support for Full-IOR conformance, ensures that, for example, a client can safely store an object reference in a naming service and get that reference back again later without losing information inside the reference. Page 13-18, section 13.6.2.3, last bullet: Replace last two bullet points and their preceding paragraph: " Specification of protocols must describe how the components affect the protocol. The following should be specified in any protocol definition for each TaggedComponent that the protocol uses: Mandatory presence: Whether inclusion of the component in profiles supporting the protocol is required (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). Droppable: For optional presence component, whether component, if present, must be retained or may be dropped. " with the following: " Specifications of protocols must describe how the components affect the protocol. In addition, a protocol definition must specify, for each TaggedComponent, whether inclusion of the component in profiles supporting the protocol is required (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). An ORB claiming to support Full-IOR conformance shall not drop optional components, once they have been added to a profile. " Page 13-18, first para of 13.6.3: Change the last sentence of this para from: " An ORB must not drop these components from an existing IOR. " to: " An ORB claiming to support IIOP must retain these components if present in an IOR. " Page 13-19, last sentence of 13.6.3.1: Change last sentence to read: " The TAG_ORB_TYPE component can appear at most once in any IORprofile. For profiles supporting IIOP 1.1 or greater, it is optionally present. " Page 15-48, 15.7 immediately before 15.7.1: add the following paragraph: " Conformance to IIOP versions 1.1 and 1.2 requires support of Limited-Profile IOR conformance (see 13.6.2), specifically for the IIOP IOR Profile. As of CORBA 2.4, this limited IOR conformance is deprecated, and ORBs implementing IIOP are strongly recommended to support Full IOR conformance. Some future IIOP versions could require support of Full IOR conformance. " Page 15-51, first nested bullet above penultimate paragraph of 15.7.2: Change " These rules specify which components are mandatory presence, which are optional presence, and which can be dropped. " to read: " These rules specify which components are mandatory and which are optional. " Page 15-51, 15.7.3, first para: Change first para to read: " The following components are part of IIOP 1.1 and 1.2 conformance. All these components are optional. " Page 15-52, first para: Change para to read: " The following components are part of IIOP 1.2 conformance. All these components are optional. " Actions taken: January 18, 2000: received issue October 4, 2000: closed issue Discussion: Consensus appears to be that ORBS should retain all information in an IOR received through IIOP messages, for subsequent. passing to other orbs as parameters in IIOP request and reply messages. However, ORBS should be able to continue to claim conformance to existing versions of IIOP event if they prune received IORs of all non IIOP IOR profile information. Comments from Vote 2 resulted in editorial changes to the wording of the deprecation text regarding future versions of GIOP from "future IIOP versions will" to "Some future IIOP versions could". End of Annotations:===== >]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: issues@omg.org, interop@omg.org Subject: Issue 2457 redux Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: gAA!!Ul#e9(*H!!%*e!! As per the discussion in the Interop RTF meeting in Mesa, it was decided to split up 2457 into two parts as follows: Part 2: Should an ORB be allowed to drop non-standard profiles (as it is allowed to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though it is not faced with any resource contraints. Moreover, when it is faced with resource contraints should it be required to follow a specific sequence in determining what profiles to drop. Juergen. Please assign new issue numbers to these two and close 2457 pointing it to these two. -- 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: jis@fpk.hp.com cc: issues@omg.org, interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Tue, 18 Jan 2000 13:44:11 PST." <3884DCFC.F5BF89AD@fpk.hp.com> From: Bill Janssen Message-Id: <00Jan18.153330pst."3619"@watson.parc.xerox.com> Date: Tue, 18 Jan 2000 15:35:01 PST Content-Type: text X-UIDL: A5Ge9#C&e9m(Ge9;^Je9 > Part 2: Should an ORB be allowed to drop non-standard profiles (as it is allowed > to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though it is not faced > with any resource contraints. Moreover, when it is faced with resource > contraints should it be required to follow a specific sequence in determining > what profiles to drop. Hmmmm, I don't see any reasonable answers to these. Perhaps someone else can suggest some? Every ORB has *some* resource constraints, so the first question is pointless. Bill Sender: jbiggar@corvette.floorboard.com Message-ID: <38850C5A.759AF7A3@floorboard.com> Date: Tue, 18 Jan 2000 16:59:06 -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: jis@fpk.hp.com, issues@omg.org, interop@omg.org Subject: Re: Issue 2457 redux References: <00Jan18.153330pst."3619"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,lbd9K>8e9mBQe9,VO!! Bill Janssen wrote: > > > Part 2: Should an ORB be allowed to drop non-standard profiles (as > it is allowed > > to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though > it is not faced > > with any resource contraints. Moreover, when it is faced with > resource > > contraints should it be required to follow a specific sequence in > determining > > what profiles to drop. > > Hmmmm, I don't see any reasonable answers to these. Perhaps someone > else can suggest some? Every ORB has *some* resource constraints, > so > the first question is pointless. I think the first question is referring to an ORB that does not currently face any constraints (low on memory being the primary one), not some theoretical ORB running on a universal turing machine. :-) My take on the questions at hand: Part 1: Clearly we need a standard minor error code to indicate that there is no available profile that the ORB knows how to use. Part 2: An ORB should not drop profiles unless it is experiencing a memory shortage. Poor implementation should not be an excuse. :-) Perhaps an ORB should be allowed to drop profiles if there is another one of the same "type"? Unfortunately multi-component profiles all have the same "type", even if they are representing different protocols. To analyze this further, let me posit three scenarios: 1. An IOR with a single profile, unrecognized by the ORB. 2. An IOR with an IIOP profile, and an unrecognized profile. 3. An IOR with more than one IIOP profile, or more than one unrecognized profile of the same "type". For case 1, allowing the ORB to drop the profile and thus convert the IOR into essentially a null object reference never makes sense to me. If someone created this IOR, obviously it is meaningfull and useful to someone, so to drop the information is simply to break many possible interoperability scenarios where the ORB doing the dropping is simply acting as an intermediary. For case 2, dropping the unknown profile may allow the ORB taking action to save some memory, but again looses the interoperability scenarios mentioned above. For case 3, dropping excess profiles of the same type appears to be relatively benign. I can live with that. In general, I feel that allowing an ORB to drop profiles due to resource limitations sounds reasonable, but fails to be useful in practical scenarios. An ORB that is so memory bound that it can't store an additional 100 or 200 bytes for a profile is probably just going to run out of memory on the next invocation anyway, so isn't it better just to fail entirely with a NO_RESOURCES exception instead of claiming that you succeeded when you may very well have taken an action that breaks stuff down the line? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 19 Jan 2000 12:58:09 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Bill Janssen , jis@fpk.hp.com, issues@omg.org, interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: <38850C5A.759AF7A3@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %)+!!75~e92 For case 3, dropping excess profiles of the same type appears to be > relatively benign. I can live with that. I disagree. For fault-tolerance, it may well be important to not drop any of these profiles. Basically, I think the notion of an "excess" profile simply doesn't apply. The ORB that created the IOR put all those profiles into it and, presumably, it had a good reason when it did that. Dropping profiles at the receiving end simply would be value judgement and, what is worse, value judgement without any information to base the judgement on. So, I would argue that in case 3, no profiles may be dropped either. > In general, I feel that allowing an ORB to drop profiles due to resource > limitations sounds reasonable, but fails to be useful in practical > scenarios. This is something an ORB can do already. There is always IMP_LIMIT, for example. 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: Mon, 24 Jan 2000 09:16:41 +0200 (EET) From: Kimmo Raatikainen Sender: kraatika@cs.helsinki.fi Reply-To: Kimmo Raatikainen Subject: Re: Issue 2457 redux To: jis@fpk.hp.com cc: interop@omg.org, telecom@omg.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-UIDL: *eRd9pc_!!("~e9[O8!! Jishnu Mukerji wrote: > As per the discussion in the Interop RTF meeting in Mesa, it was > decided to > split up 2457 into two parts as follows: > > Part 1: What should an ORB do when it does not find any profile in > an IOR > that it is able to use? This should usually not happen in a CORBA > interoperability compliant ORB, but the possibility should be > covered in the > spec anyway. > > Part 2: Should an ORB be allowed to drop non-standard profiles (as > it is > allowed to, indeed almost encouraged to do in GIOP/IIOP 1.2) even > though > it is not faced with any resource contraints. Moreover, when it is > faced > with resource contraints should it be required to follow a specific > sequence > in determining what profiles to drop. > If dropping non-standard profiles or IOR components is allowed or > encouraged, then there will be huge interoperability problems in the future if OMG > will adopt new standard profiles (for example for wireless access). In my understanding only future proofed solution is to prohibit dropping > unknown profiles and components. The only components that could be dropped > should be those ones that are specified as optional and droppable. Instead we > could specify that any unknown profile must be interpreted as the IIOP > profile. This would allow new kind of IORs to be used by clients that run on ORBs > not supporting new IOR profiles and/or components. Kimmo Raatikainen Professor Principal Scientist Univ. of Helsinki Nokia Research Center kimmo.raatikainen@{cs.helsinki.fi,nokia.com} From: karsten-oliver.starr@ubs.com X-OpenMail-Hops: 2 Date: Tue, 25 Jan 2000 09:44:03 +0100 Message-Id: In-Reply-To: Subject: Re: Re: Issue 2457 redux MIME-Version: 1.0 TO: kraatika@cs.helsinki.fi CC: interop@omg.org, karsten-oliver.starr@ubs.com Content-Disposition: IPM.Note ;Creation-Date="Mon, 24 Jan 2000 09:16:41 +0200" ;Modification-Date="Tue, 25 Jan 2000 09:44:02 +0100" Content-ID: <.83643> Content-Transfer-Encoding: 7bit Content-Type: TEXT/PLAIN; CHARSET=US-ASCII ;Creation-Date="Mon, 24 Jan 2000 09:16:41 +0200" ;Modification-Date="Tue, 25 Jan 2000 09:44:02 +0100" X-UIDL: 9L"e9TNS!!LXCe9-^$"! > If dropping non-standard profiles or IOR components > is allowed or encouraged, then there will be huge inter- > operability problems in the future if OMG will adopt new > standard profiles (for example for wireless access) Fully agreed - especially when an ORB acts as an interme- diate. Huge IT systems often rely on legacy systems which only can be wrapped up with CORBA technology by accessing it with Multi-protocol profiles. It's a customer's demand to rely on proper working interoperablity. Imagine a customer who assembles his middleware out of different commercial available products: IONA's ORB BEA's Transaction Service IBM's NameServer Inprise's EventService A short remark to this discussion: Issue 2457 arose through a problem with ORB A's object (represented through a proprietary profile) which should have been bound to ORB B's NameServer. There's a need to differentiate the intention of the method which is beeing passed the object. An ORB may reject an object if necessary information is not supplied within the IOR (eg. invoke BEA's Transaction Service). An ORB must NOT reject the object if it doesn't need to touch the object at all (eg. bind the object to a Name- Server which means just store the IOR stream in the Naming Context). Karsten ______________________________ Reply Separator _________________________________ Subject: UNAUTHENTICATED: Re: Issue 2457 redux Author: kraatika at unix,mime/DD.RFC-822=kraatika@cs.helsinki.fi Date: 24/01/2000 07:16 Jishnu Mukerji wrote: > As per the discussion in the Interop RTF meeting in Mesa, it was > decided to > split up 2457 into two parts as follows: > > Part 1: What should an ORB do when it does not find any profile in > an IOR > that it is able to use? This should usually not happen in a CORBA > interoperability compliant ORB, but the possibility should be > covered in the > spec anyway. > > Part 2: Should an ORB be allowed to drop non-standard profiles (as > it is > allowed to, indeed almost encouraged to do in GIOP/IIOP 1.2) even > though > it is not faced with any resource contraints. Moreover, when it is > faced > with resource contraints should it be required to follow a specific > sequence > in determining what profiles to drop. > If dropping non-standard profiles or IOR components is allowed or > encouraged, then there will be huge interoperability problems in the future if OMG > will adopt new standard profiles (for example for wireless access). In my understanding only future proofed solution is to prohibit dropping > unknown profiles and components. The only components that could be dropped > should be those ones that are specified as optional and droppable. Instead we > could specify that any unknown profile must be interpreted as the IIOP > profile. This would allow new kind of IORs to be used by clients that run on ORBs > not supporting new IOR profiles and/or components. Kimmo Raatikainen Professor Principal Scientist Univ. of Helsinki Nokia Research Center kimmo.raatikainen@{cs.helsinki.fi,nokia.com} To: karsten-oliver.starr@ubs.com cc: kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Tue, 25 Jan 2000 00:57:58 PST." From: Bill Janssen Message-Id: <00Jan25.083923pst."3426"@watson.parc.xerox.com> Date: Tue, 25 Jan 2000 08:39:29 PST Content-Type: text X-UIDL: '[dd9Vj,e9nX:e9XM@e9 > An ORB must NOT reject the object if it doesn't need to > touch the object at all (eg. bind the object to a Name- > Server which means just store the IOR stream in the Naming > Context). You know, I keep hearing these `principles' laid down, presumably based on experience with some ORB implementation, which are not necessarily valid for other implementations. Some ORB implementations always *potentially* need to touch the object, and thus will *never* accept an IOR without a valid communications profile. Even to the Naming service. Bill Sender: jbiggar@corvette.floorboard.com Message-ID: <388E1B3B.C2F561EF@floorboard.com> Date: Tue, 25 Jan 2000 13:52:59 -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: karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux References: <00Jan25.083923pst."3426"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: H:fd9ge&e9=2bd91mV!! Bill Janssen wrote: > > > An ORB must NOT reject the object if it doesn't need to > > touch the object at all (eg. bind the object to a Name- > > Server which means just store the IOR stream in the Naming > > Context). > > You know, I keep hearing these `principles' laid down, presumably > based on experience with some ORB implementation, which are not > necessarily valid for other implementations. Some ORB > implementations > always *potentially* need to touch the object, and thus will *never* > accept an IOR without a valid communications profile. Even to the > Naming service. Pardon me for my naivete, but I think you need to explain in more detail. If you claim that some ORBs MUST have a valid profile on all IORs they receive, you really ought to say why. Otherwise, given that there are counter-examples, why shouldn't I just consider that ORB buggy? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 26 Jan 2000 08:04:54 +1000 (EST) From: Michi Henning To: Bill Janssen cc: karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: <00Jan25.083923pst."3426"@watson.parc.xerox.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: kY?e9[A;e9LT]!!?8Le9 On Tue, 25 Jan 2000, Bill Janssen wrote: > > An ORB must NOT reject the object if it doesn't need to > > touch the object at all (eg. bind the object to a Name- > > Server which means just store the IOR stream in the Naming > > Context). > > You know, I keep hearing these `principles' laid down, presumably > based on experience with some ORB implementation, which are not > necessarily valid for other implementations. Some ORB > implementations > always *potentially* need to touch the object, and thus will *never* > accept an IOR without a valid communications profile. Even to the > Naming service. There may well be such ORBs. They are broken, as far as I'm concerned. It's trivial to retain the info in unknown profiles and there is no good reason to throw it away, but there are lots of good reasons to keep it. But I'm repeating myself... 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: "'Bill Janssen'" , karsten-oliver.starr@ubs.com Cc: kraatika@cs.helsinki.fi, interop@omg.org Subject: RE: Issue 2457 redux Date: Tue, 25 Jan 2000 17:45: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: XiNe9_Hk!!,/V!!62V!! Bill, Could you explain further? Why would an orb "always *potentially* need to touch the object"? If an orb is hosting a name service implementation, why would it need to ever touch an object that is only used via bind and resolve? Paul > -----Original Message----- > From: Bill Janssen [mailto:janssen@parc.xerox.com] > Sent: Tuesday, January 25, 2000 11:39 AM > To: karsten-oliver.starr@ubs.com > Cc: kraatika@cs.helsinki.fi; interop@omg.org > Subject: Re: Issue 2457 redux > > > > An ORB must NOT reject the object if it doesn't need to > > touch the object at all (eg. bind the object to a Name- > > Server which means just store the IOR stream in the Naming > > Context). > > You know, I keep hearing these `principles' laid down, presumably > based on experience with some ORB implementation, which are not > necessarily valid for other implementations. Some ORB > implementations > always *potentially* need to touch the object, and thus will *never* > accept an IOR without a valid communications profile. Even to the > Naming service. > > Bill > To: Paul Kyzivat cc: karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, > interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Tue, 25 Jan 2000 14:42:28 PST." <9B164B713EE9D211B6DC0090273CEEA9140312@bos1.noblenet.com> From: Bill Janssen Message-Id: <00Jan26.180730pst."3426"@watson.parc.xerox.com> Date: Wed, 26 Jan 2000 18:07:43 PST Content-Type: text X-UIDL: ;H\!!0#X!!$]Ke9099e9 > Bill, > > Could you explain further? Why would an orb "always *potentially* > need to > touch the object"? If an orb is hosting a name service > implementation, why > would it need to ever touch an object that is only used via bind and > resolve? Fair enough. Let me answer this tomorrow, as the reply is somewhat complex. Bill Date: Mon, 31 Jan 2000 12:55:06 -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: Paul Kyzivat , karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux References: <00Jan26.180730pst."3426"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: `7Zd9\D1e9!2ad9@b;!! Bill Janssen wrote: > > Bill, > > > > Could you explain further? Why would an orb "always *potentially* > need to > > touch the object"? If an orb is hosting a name service > implementation, why > > would it need to ever touch an object that is only used via bind > and > > resolve? > > Fair enough. Let me answer this tomorrow, as the reply is somewhat > complex. > > Bill Bill, Many of us are eagerly waiting for your promised answer. Did I miss it or have you not sent one out yet? Thanks, Jishnu. To: jis@fpk.hp.com cc: Paul Kyzivat , karsten-oliver.starr@ubs.com, kraatika@cs.helsinki.fi, interop@omg.org Subject: Re: Issue 2457 redux In-Reply-To: Your message of "Mon, 31 Jan 2000 09:59:02 PST." <3895CC7A.E3DC08C3@fpk.hp.com> From: Bill Janssen Message-Id: <00Jan31.110521pst."3624"@watson.parc.xerox.com> Date: Mon, 31 Jan 2000 11:05:34 PST Content-Type: text X-UIDL: ->d!!5\Rd9-,l!!`L^!! Not sent it out yet. I'm moving offices, which is impacting my connectivity... Bill 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 17:24:24 -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.122709pst."3647"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2jSd9bJnd9l1'e9j1f!! 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? 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: karsten-oliver.starr@ubs.com X-OpenMail-Hops: 2 Date: Tue, 15 Feb 2000 19:57:55 +0100 Message-Id: Subject: Issue 3235 MIME-Version: 1.0 Sender: karsten-oliver.starr@ubs.com TO: interop@omg.org Content-Disposition: inline ;Creation-Date="Tue, 15 Feb 2000 19:44:50 +0100" ;Modification-Date="Tue, 15 Feb 2000 19:57:55 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 15 Feb 2000 19:44:50 +0100" ;Modification-Date="Tue, 15 Feb 2000 19:57:55 +0100" X-UIDL: J4Ge9M1Wd9*5I!!)f`!! My proposal for issue 3235 ("Should an ORB be allowed to drop non-standard profiles..."): In cases where an interoperable ORB is intended to pass an IOR to another object it must not drop any of its profiles - regardless of whether the IOR contains profiles which the ORB is able to process or not. Karsten Date: Tue, 15 Feb 2000 15:16:44 -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: interop@omg.org Subject: Issue 3235 Proposed resolution Content-Type: multipart/mixed; boundary="------------F1058E8DC0C7F153D9B1B492" X-UIDL: _Kf!!(\ 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: interop@omg.org Subject: Re: Issue 3235 Proposed resolution References: <38A9B42B.C38423E8@fpk.hp.com> Content-Type: multipart/mixed; boundary="------------0CEA0D49B9E06194BC595CB7" X-UIDL: J:De9Eo*!!=h$e9Gbed9 Argh, the attachment with the previous message somehow contained bad HTML. So here goes again: Several of us have been discussing what would be the best way to resolve issue 3235, and what we have come up with is in the attached html file for discussion. Jishnu. Issue 3235: Should an ORB be allowed to drop non-standard profiles (interop) Click here for this issue's archive. Source: Hewlett-Packard (Dr. Jishnu Mukerji, jis@fpk.hp.com) Nature: Uncategorized Issue Severity: Summary: Part 2: Should an ORB be allowed to drop non-standard profiles (as it is allowed to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though it is not faced with any resource contraints. Moreover, when it is faced with resource contraints should it be required to follow a specific sequence in determining what profiles to drop. Note that this is part 2 of the two parts into which issue 2457 has been factored. The other part is issue 3234. Resolution: We need to look at the original interoperability architecturein Chapter 12. GIOP/IIOP is intended to connected enclaves in an interoperableway. The protocol used within the enclave can be GIOP/IIOP or anything else.The idea is that the bridges into/out of the enclaves maintain enough information to be able to transmit full GIOP/IIOP protocol in the inter-enclave communications. The only way in which this inter-enclavecommunication can provide transparent interoperability is if the bridges into and out of the enclaves preserve all elements of a message received over the inter-enclave link and a message sent out over the inter-enclave link. An important element in a GIOP message are the IORs that carry informationabout objects that may be invoked by the recepients of the message. Objectreferences carry information about the contract that the creator of the IOR iswilling to enter into with a client the terms of which will govern theinteraction between the client and the creator of the IOR. Any modification ofthe contents of an IOR amounts to changing the terms of the offered contract,which is something that no one should be allowed to do unilaterally, at leastin a universal interoperability domain. A common form of such change isdropping or modifying profiles contained in the IOR. The stricture againstchanging contracts unilaterally implies not dropping profiles from IORs and,further, not even change the order in which the profiles appear in theIOR. This does not preclude such a bridge from transmitting an IOR derived from the original IOR into its ownprivate enclave or domain, but it must maintain enough information about theoriginal IOR so that when an outbound message is sent from within the enclave onto an inter-enclave link, containing thederived IOR, the forwarded IOR is functionally equivalent to the one that was originally received. Currently there are all sorts of confusing words in Chapters 13 and15 that appear to allow dropping of profiles. This should be clearlydisallowed in order to ensure that seamless interoperability ispreserved when GIOP/IIOP is used in an inter-enclave connection role,going into the future.One reason for theconfusion is that references are described as things that can bemodified, like objects. Descriptions in terms of different referencesthat refer to the same object may help to reduce the confusion. Iforiginal and derived references have a profile in common, thisindicates only that they refer to the same object, and does not implythat the references are in any sense "the same". Revised Text: The most contentious para appears to be the footnote on page 13-16: Based on topology and policy information available to it, a bridge may find it prudent to add or remove some profiles as it forwards an object reference. For example, a bridge acting as a firewall might remove all profiles except ones that make such profiles, letting clients that understand the profiles make routing choices. This has one obvious error: ... might remove all profiles except ones that make suchprofiles... That sentence doesn't make sense to me. Anyone know what it means? (Which *whats* that make *what* such profiles?) By removing the idea of modifying a reference, and describing bridge behaviour in terms of creating derived references, any removal or addition of profiles by an ORB will have to be explained in terms of replacing a reference with a different reference, not just making some changes to "the same" reference. For now, I would suggest to replace the footnote text with the following text: Based on topology and policy information available to it, a bridge may be able to create a derived reference as described in section 13.5.2 by operating on profiles rather than the reference as a whole. The bridge must arrange that the reverse translation recovers the original reference to within the variations permitted by section 13.6.2. In particular, this implies that an ORB that is not acting as a bridge is not permitted to drop profiles at will (see 13.6.2.1), since typically such an ORB sends and receives messages to/from a single domain. Page 13-17, last para of 13.6.2.1: Add the following at the end of the para. An orb may be able to construct different references that refer to the same object as does some given reference by copying some of the profiles. Note that profiles cannot be 'removed' from a reference, nor can the order of profiles be changed in a reference; the manipulations of a structure containing a reference that might be described in those terms are causing the structure to contain a different reference. An ORB may not arbitrarily substitute a derived reference for the original reference, even if it doesn't understand the contents of one or more profiles. (This is possible because each profile is encapsulated inside object references and can be treated as an opaque datum by an ORB.) For example, consider an echo operation for object references: interface Echoer {Object echo(in Object o);}; Provided that the method body implementing this operation simply returns its argument, when a client invokes theecho operation and sends an arbitrary object reference, the reference returned by the operation is guaranteed to have not beenarbitrarily altered by either client or server ORB all its profiles intact and in the same order as they were present when the reference was sent.(1) This requirements guarantees that, for example, a client can safely store an objectreference in a naming service and get that reference back again later without losing information inside the reference. An ORB may substitute a new IOR for an original IOR only if it has authoritative information that the new IOR is a complete and preferred replacement for the original in all domains to which the reference might be passed. For example, an ORB may replace an IOR with theIOR received in an OBJECT_FORWARD_PERM or LOCATION_FORWARD_PERM for the original IOR. An ORB that includes a bridge function may assume that a new IOR it has created for forwarding into a different domain will return only via anappropriate bridge. The bridging ORB must ensure that the original IOR can berecovered if the new IOR returns, but it need not include any of the profiles required for the originating domain. (1) Note that in this case the reference is returning into the same domain so the reference substitution a bridge is permitted and required to perform does not apply. [ I've used (1) here to indicate a footnote. ] Page 13-18, section 13.6.2.3, last bullet: Replace last two bullet points and their preceding paragraph with: Specifications of protocols must describe how the components affect the protocol. In addition, a protocol definition must specify, foreach TaggedComponent, whether inclusion of the component in profiles supporting the protocol is required (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). Note that optional components, once they have been added to a profile, cannot be dropped by an ORB (see 13.6.2.1). Page 13-18, first para of 13.6.3: Delete the last sentence of this para. Page 13-19, last sentence of 13.6.3.1: Change last sentence to read: The TAG_ORB_TYPE component can appear at most once in any IORprofile. For profiles supporting IIOP 1.1 or greater, it is optionallypresent. Page 15-51, first nested bullet: Change These rules specify which components are mandatory presence, which are optional presence, and which can be dropped. to read: These rules specify which components are mandatory and which are optional. Page 15-51, 15.7.3, first para: Change first para to read: The following components are part of IIOP 1.1 and 1.2 conformance. All these components are optional. Page 15-52, first para: Change para to read: The following components are part of IIOP 1.2 conformance. All these components are optional. Actions taken: January 18, 2000: received issue From: Paul Kyzivat To: "'jis@fpk.hp.com'" , interop@omg.org Subject: RE: Issue 3235 Proposed resolution Date: Tue, 15 Feb 2000 18:19:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ;7l!!YI6e9c^o!!N(F!! I didn't go back to check every referenced paragraph to see that things go in the right place, but the words sound good to me. Paul > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > Sent: Tuesday, February 15, 2000 3:59 PM > To: interop@omg.org > Subject: Re: Issue 3235 Proposed resolution > > > Argh, the attachment with the previous message somehow > contained bad HTML. So > here goes again: > > Several of us have been discussing what would be the best way > to resolve issue > 3235, and what we have come up with is in the attached html > file for discussion. > > Jishnu. > > > From: "Rutt, T E (Tom)" To: interop@omg.org, "'jis@fpk.hp.com'" Subject: RE: Issue 3235 Proposed resolution Date: Wed, 16 Feb 2000 13:20:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: GhKe9@SX!!4&T!!ATF!! I like the html proposal. The definitions of domains might require some clarification, but overall it seems to be an ok resolution to me. -- 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 From: "Rutt, T E (Tom)" To: "'interop@omg.org'" Subject: New Proposal for Issue 3235 for wordsmithing before vote. Date: Wed, 5 Apr 2000 17:56:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: b5`d9`)'!!f"cd907K!! ----------------- Discussion: Issue 3235 - Dropping IOR Profiles This email contains a new proposed change for Issue 3235, which attempts to resolve all the comments from the interop2kPlus rtf vote1 (Lucent, IONA, SUN, and Persistence). This is being circulated before voting for a wordsmithing round. The result of the wordsmithing round will be put out as part of vote2. --------------- The reference domain terminology introduced in this discussion is used in the attached new proposed resolution. --------------------------------------------------------------- | Full-IOR | | ------------------------- | | | DCE-CIOP | | | | | | | | | | | -----+-------------------------+------------------ | | | | | IIOP | | | | | | | | | | | | | | | | | | | | | | | --------+------------- | | | | | | | | | | | | | | | | | | | | | | | | | | | | ----------------+-------- | | | | | | | | | | ----------------------+----------------------+---- | | | SS7-IOP | | | ---------------------- | --------------------------------------------------------------- Interface Reference Domains In the above Venn diagram, the outer box represents the Full-IOR reference domain. This Full-IOR domain includes all CORBA objects which have an interface reference using the CORBA IOR format. The larger inner box represents the IIOP reference domain, which includes all CORBA objects which have an interface reference including an IIOP IOR profile. CORBA interoperability is only assured for CORBA objects which are in this IIOP reference domain. The area of the Full-IOR domain which is not inside the IIOP reference domain is a dangerous place for CORBA objects to be placed, since they cannot be reached using IIOP. Since IIOP is the only mandatory OMG protocol required for conformance to CORBA Interoperability, one can consider the IIOP reference domain to be the Universal reference domain for interoperability. The changes proposed for resolution of Issue 3235 should be qualified as requirements for an ORB implementation claiming support to the Full-IOR reference domain. An ORB which has been implemented with the existing allowed behaviour specified in CORBA 2.1 thru 2.3 should be allowed to claim support for the IIOP reference domain. For example, three cases are presented. For one example, take case1 of an IOR for IOR passing across the reference domain boundary from: ? an object Obj1 in ORB2, which is in the portion of the SS7-IOP reference domain inside the IIOP reference domain (i.e, Obj1 and ORB2 is in { {SS7-CIOP} intersect {IIOP} }, to ? ORB1, which is in the IIOP reference domain, but not in the SS7-IOP reference domain A viable behavior for an ORB, clearly allowed by all versions of CORBA beyond 2.0, is to create new IORs for objects which have references outside the IIOP reference domain, by pruning off the portions their received IORs not associated with the standard IIOP-IOR profile and its standard IOR-components. Such an ORB can claim support for the IIOP reference domain. However, by behaving in such a manner in case1 above, that ORB would be placing itself as not supporting the SS7-IOP reference domain (i.e., ORB1 is in { {IIOP} intersect not{SS7-IOP} } ). Clients in this ORB1 would still be able to invoke operations on Obj1, however access using SS7-IOP would be disabled from ORB1. In such a case, another ORB could choose to retain the SS7-IOP IOR profile information in the IOR for Obj1. By behaving in such a manner, that ORB would be placing itself to support both the IIOP reference domain and the SS7-IOP reference domain. For another example, take case2 of an IOR passing across the IIOP reference domain boundary from: ? an object Obj2 in ORB3, which is in the portion of the SS7-IOP reference domain outside the IIOP reference domain (i.e. the object is in {{SS7-CIOP} intersect not{IIOP}} ), to ? ORB2, which supports both the IIOP reference domain and the SS7-IOP reference domain. A typical case2 scenario would involved an ORB3 which only speaks SS7-IOP passing an object reference as a parameter to ORB2, which speaks both SS7-IOP and IIOP. In this case it would be natural and wise for ORB2 to retain the portion of the IOR for Obj2 associated with SS7-IOP. By behaving in such a manner, ORB2 is placing itself as supporting both the IIOP reference domain and the SS7-IOP reference domain. However, the IOR for Obj2 would not contain an IIOP-IOR component (assuming, for clarity of example that ORB2 does not create in itself a "proxy-object" with an IIOP- IOR component, in order to delegate invocations to Obj2). Case2 results in ORB2 holding an interface reference for Obj2 which is outside of the IIOP reference domain. Proceeding further by example, take case3 involving the same IOR for Obj2 from case2, passing across a reference domain boundary from: ? ORB2 (same as above), to ? ORB1, which is in the portion of the IIOP reference domain outside the SS7-IOP reference domain (i.e, ORB3 is in { not{SS7-CIOP} intersect {IIOP} }. Case3 is somewhat troublesome, in that the new IOR derived from pruning the received IOR would be empty. This corresponds to the fact that the Obj2 in not in the IIOP reference domain, and thus is not guaranteed to be reachable from ORBs within the IIOP reference domain. However, since the object is not reachable using IIOP from any ORB, it has been placed outside of the mandates of CORBA interoperability. --------------------------- Suggested Proposed Changes: The most contentious para appears to be the footnote on page 13- 16: " Based on topology and policy information available to it, a bridge may find it prudent to add or remove some profiles as it forwards an object reference. For example, a bridge acting as a firewall might remove all profiles except ones that make such profiles, letting clients that understand the profiles make routing choices. " This has one obvious error: ... might remove all profiles except ones that make suchprofiles... That sentence doesn't make sense, and is grammatically incorrect. By removing the idea of modifying a reference, and describing bridge behaviour in terms of creating derived references, any removal or addition of profiles by an ORB will have to be explained in terms of replacing a reference with a different reference, not just making some changes to "the same" reference. Replace the footnote text with the following text: " Based on topology and policy information available to it, a bridge may be able to create a derived reference as described in section 13.5.2 by operating on profiles rather than the reference as a whole. Bridges to and from reference domains must arrange that the reverse translation recovers the original reference to within the variations permitted by section 13.6.2. In particular, two levels of reference domain conformance are specified in 13.6.2, namely IIOP reference domain conformance and Full-IOR reference domain conformance. " Page 13-17, last para of 13.6.2.1: Add the following at the end of the para. " An orb may be able to construct different references that refer to the same object as does some given reference by copying some of the profiles. Note that profiles cannot be 'removed' from a reference, nor can the order of profiles be changed in a reference; the manipulations of a structure containing a reference that might be described in those terms are causing the structure to contain a different reference. An ORB which claims support to the Full-IOR reference domain may not arbitrarily substitute a derived reference for the original reference, even if it doesn't understand the contents of one or more profiles. (This is possible because each profile is encapsulated inside object references and can be treated as an opaque datum by an ORB.) ORBs claiming to support the Full-IOR reference domain are required to preserve all the semantic content of any IOR (including the ordering of each profile and its components), and may only apply transformations which preserve semantics(e.g., changing Byte order for encapsulation). For example, consider an echo operation for object references: interface Echoer {Object echo(in Object o);}; Assume that the method body implementing this operation simply returns its argument. When a client application invokes the echo operation and passes an arbitrary object reference, if both the client and server ORBs claim support to the Full-IOR reference domain, the reference returned by the operation is guaranteed to have not been semantically altered by either client or server ORB. That is, all its profiles will remain intact and in the same order as they were present when the reference was sent.(1) This requirement for ORBs which claim support for the Full-IOR reference domain, ensures that, for example, a client can safely store an object reference in a naming service and get that reference back again later without losing information inside the reference. An ORB may substitute a new IOR for an original IOR only if it has authoritative information that the new IOR is a complete replacement for the original in all reference domains for which the ORB claims support. For example, an ORB may replace an IOR with the IOR received in an OBJECT_FORWARD_PERM or LOCATION_FORWARD_PERM returned from an invocation on the original IOR. An ORB that includes a bridge function must assure that a new IOR it has created for an object, to forward into a particular reference domain, will only be passed out of that reference domain via an appropriate bridge. A bridging ORB claiming support for the Full-IOR reference domain, must ensure that the original IOR for the object can be recovered if the new IOR is passed back to the reference domain which produced the original IOR. (1) Note that in this case the reference is returning into the same domain so the reference substitution a bridge is permitted and required to perform does not apply. " [ (1) here indicates a footnote. ] Page 13-18, section 13.6.2.3, last bullet: Replace last two bullet points and their preceding paragraph: " Specification of protocols must describe how the components affect the protocol. The following should be specified in any protocol definition for each TaggedComponent that the protocol uses: Mandatory presence: Whether inclusion of the component in profiles supporting the protocol is required (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). Droppable: For optional presence component, whether component, if present, must be retained or may be dropped. " with the following: " Specifications of protocols must describe how the components affect the protocol. In addition, a protocol definition must specify, for each TaggedComponent, whether inclusion of the component in profiles supporting the protocol is required (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). An ORB claiming to support the Full-IOR reference domain cannot drop optional components, once they have been added to a profile (see 13.6.2.1). " Page 13-18, first para of 13.6.3: Change the last sentence of this para from: " An ORB must not drop these components from an existing IOR. " to: " An ORB claiming to support the IIOP reference domain must retain these components if present in an IOR. " Page 13-19, last sentence of 13.6.3.1: Change last sentence to read: " The TAG_ORB_TYPE component can appear at most once in any IORprofile. For profiles supporting IIOP 1.1 or greater, it is optionally present. " Page 15-51, first nested bullet above penultimate paragraph of 15.7.2: Change " These rules specify which components are mandatory presence, which are optional presence, and which can be dropped. " to read: " These rules specify which components are mandatory and which are optional. " Page 15-51, 15.7.3, first para: Change first para to read: " The following components are part of IIOP 1.1 and 1.2 conformance. All these components are optional. " Page 15-52, first para: Change para to read: " The following components are part of IIOP 1.2 conformance. All these components are optional. " ------------- -- 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: Sat, 8 Apr 2000 09:52:46 +1000 (EST) From: Michi Henning To: "Rutt, T E (Tom)" cc: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ;'4e9]CBe9_*#!!)]0e9 On Wed, 5 Apr 2000, Rutt, T E (Tom) wrote: > This email contains a new proposed change for Issue 3235, which > attempts to resolve all the comments from the interop2kPlus rtf > vote1 (Lucent, IONA, SUN, and Persistence). I admire the attempt at defining full interoperability domains and such, but I still don't like this proposal very much. Basically, my concern is that, as a client, I'm faced with a situation where I successfully send some data (namely, object references) with no indication that anything may go wrong. Yet, the data may never arrive at its destination in its original form and may be unusable by the time it gets there. That can happen because profiles may be dropped at every hop along a request chain until the one I need at the destination is no longer there. I am also concerned about the ORB version fragmentation this creates. I can no longer ask whether the ORB is "2.4 compliant and interoperable", I now have to ask whether it is "2.4 compliant and fully interoperable, or 2.4 compliant and only IIOP interoperable, or 2.4 compliant and not interoperable". At run time, there is no way to enquire of an ORB what level of interoperability it supports, nor is there a way to be sure at deployment time that the requisite inteoperability guarantees are met. That is because, due to the dynamic nature binding, the paths along which invocations flow may change at any time and without warning. Even if the client were to be given a way to enquire about the status of a particular ORB's interoperability guarantees (for example, by adding an operation to Object), that would still not solve the problem because, in order to get the guarantee I need, I have to know the end-to-end guarantees via all intermediate hops. However, I can't answer that question because it is intractable. We already identified that, technically, preserving IOR profiles presents no difficulties (just as preserving parts of profiles that follow the the components member inside a provile does not present any difficulty). Given that, I don't like the proposed approach and suggest to make preservation of profiles mandatory, as in the original proposal. 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: "Rutt, T E (Tom)" To: "Rutt, T E (Tom)" , "'Michi Henning'" Cc: "'interop@omg.org'" Subject: RE: New Proposal for Issue 3235 for wordsmithing before vote. Date: Tue, 11 Apr 2000 15:10:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: 18G!!]Tj!!<\)e9U%i!! > ---------- > From: Michi Henning[SMTP:michi@ooc.com.au] > Sent: Friday, April 07, 2000 7:52 PM > To: Rutt, T E (Tom) > Cc: 'interop@omg.org' > Subject: Re: New Proposal for Issue 3235 for wordsmithing > before > vote. > > > We already identified that, technically, preserving IOR profiles > presents > no difficulties (just as preserving parts of profiles that follow > the > the components member inside a provile does not present any > difficulty). > Given that, I don't like the proposed approach and suggest to make > preservation of profiles mandatory, as in the original proposal. > What about orbs which are shipping in compliance with corba 2.1, 2.2, > 2.3. The other clarification now makes these orbs non compliant. Is this something which an RTF resolution should be able to do? > 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@omg.org'" Subject: RE: New Proposal for Issue 3235 for wordsmithing before vote. Date: Tue, 11 Apr 2000 16:28:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: HREe9WKed9EHVd9MV!e9 > From: Rutt, T E (Tom) [mailto:terutt@lucent.com] > What about orbs which are shipping in compliance with corba > 2.1, 2.2, 2.3. > > The other clarification now makes these orbs non compliant. Is this > something > which an RTF resolution should be able to do? It depends on what they are actually doing. Do any existing orbs currently drop profiles they don't understand? Paul Sender: jis@fpk.hp.com Message-ID: <38F39505.4F51AF80@fpk.hp.com> Date: Tue, 11 Apr 2000 17:11:33 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: "Rutt, T E (Tom)" Cc: "'Michi Henning'" , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &8Y!!lL#e9G'5e94'!!! Rutt, T E (Tom) wrote: > > > ---------- > > From: Michi Henning[SMTP:michi@ooc.com.au] > > Sent: Friday, April 07, 2000 7:52 PM > > To: Rutt, T E (Tom) > > Cc: 'interop@omg.org' > > Subject: Re: New Proposal for Issue 3235 for wordsmithing > before > > vote. > > > > > > We already identified that, technically, preserving IOR profiles > presents > > no difficulties (just as preserving parts of profiles that follow > the > > the components member inside a provile does not present any > difficulty). > > Given that, I don't like the proposed approach and suggest to make > > preservation of profiles mandatory, as in the original proposal. > > > What about orbs which are shipping in compliance with corba 2.1, > 2.2, 2.3. > > The other clarification now makes these orbs non compliant. Is this > something which an RTF resolution should be able to do? Existing implementations that are compliant with the existing compliance requirements need to allowed to claim compliance with the existing compliance requirements, pedantically speaking that is:-). The new compliance requirements can apply only to new implementations, or a new GIOP version or some such. Tom's proposal seems to be one way of achieving this. The theory being that existing compliance rule applies to the IIOP reference domain, and the new rule applies to the universal IOR reference domain. But there appears to be a few problems: (1) The concept of "reference domain" is not really defined anywhere. The term is used for the first time in Section 12.1.2 first paragraph, without even attempting to assign any specific meaning to it. We should correct that by adding a definition for it, perhaps in the vicinity of section 12.1.2. Perhaps we can say something like "A IOR reference domain consists of the set of ORBs that are able to use said type of IOR reference to effectively carry out an object invocation between any two of them." Of course, then we will need to clarify that the "type" of a IOR is determined by the profiles found in it, etc. (2) The IIOP reference domain is defined in Tom's excellent discussion paragraphs as "IIOP reference domain, which includes all CORBA objects which have an interface reference including an IIOP IOR profile." Then it goes on to say that the old dropping rules apply to this domain. In my mind, this is not what the intent is of the original resolution. The problem is that it leaves the "IIOP reference domain" based restricted conformance point available in perpetuity, for all practical purposes. Additionally it associates a pejorative with the term IIOP in conjunction with "reference domain", i.e. IIOP is less than universally interoperable. While this may be technically correct, it may not be the brightest thing to advertize through a conformance point named as such. Perhaps the best way to deal with this is to define the "Legacy IIOP Reference Domain" as: "Legacy IIOP reference domain, which includes all CORBA objects which have an interface reference including an IIOP IOR profile, and which expect that the component dropping rules as specified in CORBA 2.3 are followed." Then we can say (almost tautologically) that the 2.3 dropping rules apply to the Legacy IIOP reference domain", and anyone claiming conformance to CORBA 2.3 or earlier needs comply only to these rules. Then the "IIOP Reference domain" could be defined as the domain in which (i) IORs include an IIOP IOR profile, and (ii) where the new no dropping rule applies. (3) Tom really needs to spiffy up the discussion stuff in the resolution and include it somewhere in Chapter 12. It is going to be a difficult task for anyone without access to theat piece of background material, to figure out what the heck is going on. Still trying to figure out what is the best way to do this.:-) Cheers, Jishnu. To: "Rutt, T E (Tom)" cc: "'Michi Henning'" , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. In-Reply-To: Your message of "Tue, 11 Apr 2000 12:10:36 PDT." From: Bill Janssen Message-Id: <00Apr11.141449pdt."3432"@watson.parc.xerox.com> Date: Tue, 11 Apr 2000 14:14:54 PDT Content-Type: text X-UIDL: :o*!!_CG!!`%&!!CUdd9 > What about orbs which are shipping in compliance with corba 2.1, 2.2, 2.3. > > The other clarification now makes these orbs non compliant. Is this > something > which an RTF resolution should be able to do? Lord, I'd hope not! Unless of course we want people to junk CORBA in favor of RMI :-? Bill To: Paul Kyzivat cc: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. In-Reply-To: Your message of "Tue, 11 Apr 2000 13:24:24 PDT." <9B164B713EE9D211B6DC0090273CEEA926BDCE@bos1.noblenet.com> From: Bill Janssen Message-Id: <00Apr11.141954pdt."3433"@watson.parc.xerox.com> Date: Tue, 11 Apr 2000 14:19:58 PDT Content-Type: text X-UIDL: E2;!!AeIe9ZD!e9,ho!! Sure. ILU will. Bill Sender: jis@fpk.hp.com Message-ID: <38F39E14.B9B066B7@fpk.hp.com> Date: Tue, 11 Apr 2000 17:50:12 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: Bill Janssen Cc: Paul Kyzivat , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <00Apr11.141954pdt."3433"@watson.parc.xerox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2R(!!DRY!!^~Md9->I!! Bill Janssen wrote: > > Sure. ILU will. > > Bill So what will ILU surely?:-) Jishnu. Date: Wed, 12 Apr 2000 08:59:45 +1000 (EST) From: Michi Henning To: "Rutt, T E (Tom)" cc: "'interop@omg.org'" Subject: RE: New Proposal for Issue 3235 for wordsmithing before vote. In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %YG!!!FQ!!"+pd9I= > We already identified that, technically, preserving IOR profiles presents > > no difficulties (just as preserving parts of profiles that follow the > > the components member inside a provile does not present any difficulty). > > Given that, I don't like the proposed approach and suggest to make > > preservation of profiles mandatory, as in the original proposal. > > > What about orbs which are shipping in compliance with corba 2.1, 2.2, 2.3. > > The other clarification now makes these orbs non compliant. Is this > something > which an RTF resolution should be able to do? Only a CORBA 2.4 compliant ORB would be obliged to adhere to the change, of course. 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: Peter.Walker@eng.sun.com Message-ID: <38F3AFE3.AC228FFA@eng.Sun.COM> Date: Tue, 11 Apr 2000 16:06:11 -0700 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: "Rutt, T E (Tom)" , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: DHld9inNe9IJR!!5/Me9 Michi Henning wrote: > > On Tue, 11 Apr 2000, Rutt, T E (Tom) wrote: > > > > We already identified that, technically, preserving IOR profiles > presents > > > no difficulties (just as preserving parts of profiles that > follow the > > > the components member inside a provile does not present any > difficulty). > > > Given that, I don't like the proposed approach and suggest to > make > > > preservation of profiles mandatory, as in the original proposal. > > > > > What about orbs which are shipping in compliance with corba 2.1, > 2.2, 2.3. > > > > The other clarification now makes these orbs non compliant. Is > this > > something > > which an RTF resolution should be able to do? > > Only a CORBA 2.4 compliant ORB would be obliged to adhere to the > change, > of course. > Surely we are not planning to roll the changes made by this RTF into 2.4. I thought there was agreement on 2.4 content. Pj. -- ================================================================== Peter J. Walker Sun Microsystems, Inc. Senior Staff Engineer, Enterprise Java. Software Products and Platforms. Cupertino, CA. pwalker@eng.Sun.com http://java.sun.com/j2ee Phone (408)517-5679 ================================================================== To: Jishnu Mukerji cc: Paul Kyzivat , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. In-Reply-To: Your message of "Tue, 11 Apr 2000 14:46:44 PDT." <38F39E14.B9B066B7@fpk.hp.com> From: Bill Janssen Message-Id: <00Apr11.161921pdt."3432"@watson.parc.xerox.com> Date: Tue, 11 Apr 2000 16:19:35 PDT Content-Type: text X-UIDL: X3&!!1=4e9EKV!!E^=e9 > Bill Janssen wrote: > > > > Sure. ILU will. > > > > Bill > > So what will ILU surely?:-) > > Jishnu. What, your mailer doesn't point out the message I was replying to? It will drop unrecognized profiles. Bill Date: Wed, 12 Apr 2000 09:31:28 +1000 (EST) From: Michi Henning To: Peter Walker cc: "Rutt, T E (Tom)" , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. In-Reply-To: <38F3AFE3.AC228FFA@eng.Sun.COM> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ^X6e9feL!!!,[!!?Y+e9 On Tue, 11 Apr 2000, Peter Walker wrote: > > > The other clarification now makes these orbs non compliant. Is this > > > something > > > which an RTF resolution should be able to do? > > > > Only a CORBA 2.4 compliant ORB would be obliged to adhere to the change, > > of course. > > > > Surely we are not planning to roll the changes made by this RTF into > 2.4. I thought there was agreement on 2.4 content. Well, whatever version we roll them into then. Cheers, Michi. Date: Tue, 11 Apr 2000 18:35:09 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rutt, T E (Tom)" CC: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: U?hd9d1P!!C>H!!GoG!! Tom - This is a great improvement on the original resolution. Together, the clarifications address my original concerns. Regards, Max "Rutt, T E (Tom)" wrote: > ----------------- > Discussion: Issue 3235 - Dropping IOR Profiles > > This email contains a new proposed change for Issue 3235, which > attempts to resolve all the comments from the interop2kPlus rtf > vote1 (Lucent, IONA, SUN, and Persistence). > > This is being circulated before voting for a wordsmithing round. > > The result of the wordsmithing round will be put out as part of > vote2. > > --------------- > The reference domain terminology introduced in this discussion > is used in the attached new proposed resolution. > > --------------------------------------------------------------- > | Full-IOR | > | ------------------------- | > | | DCE-CIOP | | > | | | | > | | | | > | -----+-------------------------+------------------ | > | | | | IIOP | | > | | | | | | > | | | | | | > | | | | | | > | | | --------+------------- | | > | | | | | | | | > | | | | | | | | > | | | | | | | | > | | ----------------+-------- | | | > | | | | | | > | ----------------------+----------------------+---- | > | | SS7-IOP | | > | ---------------------- | > --------------------------------------------------------------- > > Interface Reference Domains > > In the above Venn diagram, the outer box represents the Full-IOR > reference domain. This Full-IOR domain includes all CORBA objects > which have an interface reference using the CORBA IOR format. > > The larger inner box represents the IIOP reference domain, which > includes all CORBA objects which have an interface reference > including an IIOP IOR profile. CORBA interoperability is only > assured for CORBA objects which are in this IIOP reference domain. > > The area of the Full-IOR domain which is not inside the IIOP > reference domain is a dangerous place for CORBA objects to be > placed, since they cannot be reached using IIOP. Since IIOP is > the only mandatory OMG protocol required for conformance to CORBA > Interoperability, one can consider the IIOP reference domain to be > the Universal reference domain for interoperability. > > The changes proposed for resolution of Issue 3235 should be > qualified as requirements for an ORB implementation claiming > support to the Full-IOR reference domain. An ORB which has been > implemented with the existing allowed behaviour specified in CORBA > 2.1 thru 2.3 should be allowed to claim support for the IIOP > reference domain. > > For example, three cases are presented. > > For one example, take case1 of an IOR for IOR passing across the > reference domain boundary from: > ? an object Obj1 in ORB2, which is in the portion of the SS7-IOP > reference domain inside the IIOP reference domain (i.e, Obj1 > and ORB2 is in { {SS7-CIOP} intersect {IIOP} }, to > ? ORB1, which is in the IIOP reference domain, but not in the > SS7-IOP reference domain > > A viable behavior for an ORB, clearly allowed by all versions of > CORBA beyond 2.0, is to create new IORs for objects which have > references outside the IIOP reference domain, by pruning off the > portions their received IORs not associated with the standard > IIOP-IOR profile and its standard IOR-components. Such an ORB can > claim support for the IIOP reference domain. However, by behaving > in such a manner in case1 above, that ORB would be placing itself > as not supporting the SS7-IOP reference domain (i.e., ORB1 is in > { {IIOP} intersect not{SS7-IOP} } ). Clients in this ORB1 would > still be able to invoke operations on Obj1, however access using > SS7-IOP would be disabled from ORB1. > > In such a case, another ORB could choose to retain the SS7-IOP IOR > profile information in the IOR for Obj1. By behaving in such a > manner, that ORB would be placing itself to support both the IIOP > reference domain and the SS7-IOP reference domain. > > For another example, take case2 of an IOR passing across the IIOP > reference domain boundary from: > ? an object Obj2 in ORB3, which is in the portion of the SS7-IOP > reference domain outside the IIOP reference domain (i.e. the > object is in {{SS7-CIOP} intersect not{IIOP}} ), to > ? ORB2, which supports both the IIOP reference domain and the > SS7-IOP reference domain. > > A typical case2 scenario would involved an ORB3 which only speaks > SS7-IOP passing an object reference as a parameter to ORB2, which > speaks both SS7-IOP and IIOP. In this case it would be natural > and wise for ORB2 to retain the portion of the IOR for Obj2 > associated with SS7-IOP. By behaving in such a manner, ORB2 is > placing itself as supporting both the IIOP reference domain and > the SS7-IOP reference domain. However, the IOR for Obj2 would not > contain an IIOP-IOR component (assuming, for clarity of example > that ORB2 does not create in itself a "proxy-object" with an IIOP- > IOR component, in order to delegate invocations to Obj2). > > Case2 results in ORB2 holding an interface reference for Obj2 > which is outside of the IIOP reference domain. > > Proceeding further by example, take case3 involving the same IOR > for Obj2 from case2, passing across a reference domain boundary > from: > ? ORB2 (same as above), to > ? ORB1, which is in the portion of the IIOP reference domain > outside the SS7-IOP reference domain (i.e, ORB3 is in { > not{SS7-CIOP} intersect {IIOP} }. > > Case3 is somewhat troublesome, in that the new IOR derived from > pruning the received IOR would be empty. This corresponds to the > fact that the Obj2 in not in the IIOP reference domain, and thus > is not guaranteed to be reachable from ORBs within the IIOP > reference domain. However, since the object is not reachable > using IIOP from any ORB, it has been placed outside of the > mandates of CORBA interoperability. > > --------------------------- > > Suggested Proposed Changes: > > The most contentious para appears to be the footnote on page 13- > 16: > " > Based on topology and policy information available to it, > a bridge may find it prudent to add or remove some profiles > as it forwards an object reference. For example, a bridge > acting as a firewall might remove all profiles except ones > that make such profiles, letting clients that understand the > profiles make routing choices. > " > > This has one obvious error: > > ... might remove all profiles except ones that make > suchprofiles... > > That sentence doesn't make sense, and is grammatically incorrect. > > By removing the idea of modifying a reference, and describing > bridge behaviour in terms of creating derived references, any > removal or addition of profiles by an ORB will have to be > explained in terms of replacing a reference with a different > reference, not just making some changes to "the same" reference. > > Replace the footnote text with the following text: > > " > Based on topology and policy information available to it, a > bridge may be able to create a derived reference as described > in section 13.5.2 by operating on profiles rather than the > reference as a whole. Bridges to and from reference domains > must arrange that the reverse translation recovers the > original reference to within the variations permitted by > section 13.6.2. > > In particular, two levels of reference domain conformance are > specified in 13.6.2, namely IIOP reference domain conformance > and Full-IOR reference domain conformance. > " > > Page 13-17, last para of 13.6.2.1: > > Add the following at the end of the para. > " > An orb may be able to construct different references that refer to > the same object as does some given reference by copying some of > the profiles. Note that profiles cannot be 'removed' from a > reference, nor can the order of profiles be changed in a > reference; the manipulations of a structure containing a reference > that might be described in those terms are causing the structure > to contain a different reference. An ORB which claims support to > the Full-IOR reference domain may not arbitrarily substitute a > derived reference for the original reference, even if it doesn't > understand the contents of one or more profiles. (This is possible > because each profile is encapsulated inside object references and > can be treated as an opaque datum by an ORB.) > > ORBs claiming to support the Full-IOR reference domain are > required to preserve all the semantic content of any IOR > (including the ordering of each profile and its components), and > may only apply transformations which preserve semantics(e.g., > changing Byte order for encapsulation). > > For example, consider an echo operation for object references: > > interface Echoer {Object echo(in Object o);}; > > Assume that the method body implementing this operation simply > returns its argument. When a client application invokes the echo > operation and passes an arbitrary object reference, if both the > client and server ORBs claim support to the Full-IOR reference > domain, the reference returned by the operation is guaranteed to > have not been semantically altered by either client or server ORB. > That is, all its profiles will remain intact and in the same order > as they were present when the reference was sent.(1) This > requirement for ORBs which claim support for the Full-IOR > reference domain, ensures that, for example, a client can safely > store an object reference in a naming service and get that > reference back again later without losing information inside the > reference. > > An ORB may substitute a new IOR for an original IOR only if it has > authoritative information that the new IOR is a complete > replacement for the original in all reference domains for which > the ORB claims support. > > For example, an ORB may replace an IOR with the IOR received in an > OBJECT_FORWARD_PERM or LOCATION_FORWARD_PERM returned from an > invocation on the original IOR. > > An ORB that includes a bridge function must assure that a new IOR > it has created for an object, to forward into a particular > reference domain, will only be passed out of that reference domain > via an appropriate bridge. A bridging ORB claiming support for > the Full-IOR reference domain, must ensure that the original IOR > for the object can be recovered if the new IOR is passed back to > the reference domain which produced the original IOR. > > (1) Note that in this case the reference is returning into > the same domain so the reference substitution a bridge is > permitted and required to perform does not apply. > > " > > [ (1) here indicates a footnote. ] > > Page 13-18, section 13.6.2.3, last bullet: > > Replace last two bullet points and their preceding paragraph: > " > Specification of protocols must describe how the > components affect the protocol. The following should be > specified in any protocol definition for each > TaggedComponent that the protocol uses: > Mandatory presence: Whether inclusion of the component in > profiles supporting the protocol is required > (MANDATORY PRESENCE) or not required (OPTIONAL > PRESENCE). > Droppable: For optional presence component, whether > component, if present, must be retained or may be > dropped. > " > with the following: > " > Specifications of protocols must describe how the components > affect the protocol. In addition, a protocol definition must > specify, for each TaggedComponent, whether inclusion of the > component in profiles supporting the protocol is required > (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). An ORB > claiming to support the Full-IOR reference domain cannot drop > optional components, once they have been added to a profile (see > 13.6.2.1). > " > > Page 13-18, first para of 13.6.3: > > Change the last sentence of this para from: > " > An ORB must not drop these components from an existing IOR. > " > to: > " > An ORB claiming to support the IIOP reference domain must retain > these components if present in an IOR. > " > > Page 13-19, last sentence of 13.6.3.1: > > Change last sentence to read: > " > The TAG_ORB_TYPE component can appear at most once in any > IORprofile. > > For profiles supporting IIOP 1.1 or greater, it is optionally > present. > " > > Page 15-51, first nested bullet above penultimate paragraph of > 15.7.2: > > Change > > " > These rules specify which components are mandatory presence, > which are optional presence, and which can be dropped. > " > > to read: > > " > These rules specify which components are mandatory and > which are optional. > " > > Page 15-51, 15.7.3, first para: > > Change first para to read: > > " > The following components are part of IIOP 1.1 and 1.2 > conformance. All these components are optional. > " > > Page 15-52, first para: > > Change para to read: > > " > The following components are part of IIOP 1.2 conformance. > All these components are optional. > " > ------------- > > -- > 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: Tue, 11 Apr 2000 18:58:58 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: "Rutt, T E (Tom)" , "'Michi Henning'" , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <38F39505.4F51AF80@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: llYd9OI:!!P\!e9RY-e9 Jishnu - Jishnu Mukerji wrote: > Rutt, T E (Tom) wrote: > > > > > ---------- > > > From: Michi Henning[SMTP:michi@ooc.com.au] > > > Sent: Friday, April 07, 2000 7:52 PM > > > To: Rutt, T E (Tom) > > > Cc: 'interop@omg.org' > > > Subject: Re: New Proposal for Issue 3235 for wordsmithing > before > > > vote. > > > > > > > > > We already identified that, technically, preserving IOR profiles > presents > > > no difficulties (just as preserving parts of profiles that > follow the > > > the components member inside a provile does not present any > difficulty). > > > Given that, I don't like the proposed approach and suggest to > make > > > preservation of profiles mandatory, as in the original proposal. > > > > > What about orbs which are shipping in compliance with corba 2.1, > 2.2, 2.3. > > > > The other clarification now makes these orbs non compliant. Is > this > > something which an RTF resolution should be able to do? > > Existing implementations that are compliant with the existing > compliance requirements need to > allowed to claim compliance with the existing compliance > requirements, pedantically speaking that > is:-). The new compliance requirements can apply only to new > implementations, or a new GIOP version > or some such. Tom's proposal seems to be one way of achieving > this. The theory being that existing > compliance rule applies to the IIOP reference domain, and the new > rule applies to the universal IOR > reference domain. > > But there appears to be a few problems: > > (1) The concept of "reference domain" is not really defined > anywhere. The term is used for the first > time in Section 12.1.2 first paragraph, without even attempting to > assign any specific meaning to > it. We should correct that by adding a definition for it, perhaps in > the vicinity of section 12.1.2. > Perhaps we can say something like "A IOR reference domain consists > of the set of ORBs that are able > to use said type of IOR reference to effectively carry out an object > invocation between any two of > them." Of course, then we will need to clarify that the "type" of a > IOR is determined by the > profiles found in it, etc. Altough I can agree that some sort of precise definition for IOR reference domain might be reasonable to give, I'm not sure its exclusion would be intolerable given Tom's proposed resolution. > (2) The IIOP reference domain is defined in Tom's excellent discussion paragraphs as > "IIOP reference domain, which includes all CORBA objects which have an interface reference including > an IIOP IOR profile." Then it goes on to say that the old dropping rules apply to this domain. In my > mind, this is not what the intent is of the original resolution. > > The problem is that it leaves the "IIOP reference domain" based restricted conformance point > available in perpetuity, for all practical purposes. Additionally it associates a pejorative with > the term IIOP in conjunction with "reference domain", i.e. IIOP is less than universally > interoperable. While this may be technically correct, it may not be the brightest thing to advertize > through a conformance point named as such. I didn't read the proposed resolution as an explicit pronouncement of that fact. It certainly doesn't advertise it. So, I don't think we need to worry about this. > Perhaps the best way to deal with this is to define the "Legacy IIOP Reference Domain" as: > "Legacy IIOP reference domain, which includes all CORBA objects which have an interface reference > including an IIOP IOR profile, and which expect that the component dropping rules as specified in > CORBA 2.3 are followed." Then we can say (almost tautologically) that the 2.3 dropping rules apply > to the Legacy IIOP reference domain", and anyone claiming conformance to CORBA 2.3 or earlier needs > comply only to these rules. > > Then the "IIOP Reference domain" could be defined as the domain in which (i) IORs include an IIOP > IOR profile, and (ii) where the new no dropping rule applies. You might have already considered this case but would that definition not exclude the possibility of a bridge that belongs both to the IIOP reference domain and some other domain for which some dropping might be required before relaying of an IOR. > (3) Tom really needs to spiffy up the discussion stuff in the resolution and include it somewhere in > Chapter 12. It is going to be a difficult task for anyone without access to theat piece of > background material, to figure out what the heck is going on. I agree that a bit more background on reference domains might be a good idea but to keep it to a very small addition and to veil it in more abstract terms seems more prudent. I believe the changes Tom has already suggested in the resolution takes care of that. I'm indifferent to whether the discussion is included in 12 as long as it is included, for the record, in the resolution. Regards, Max Sender: jis@fpk.hp.com Message-ID: <38F48E15.D84CE61C@fpk.hp.com> Date: Wed, 12 Apr 2000 10:54:13 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: Peter Walker Cc: Michi Henning , "Rutt, T E (Tom)" , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <38F3AFE3.AC228FFA@eng.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f^ld9/Xbd9%2i!!cIMd9 Peter Walker wrote: > > Michi Henning wrote: > > > > On Tue, 11 Apr 2000, Rutt, T E (Tom) wrote: > > > > > > We already identified that, technically, preserving IOR > profiles presents > > > > no difficulties (just as preserving parts of profiles that > follow the > > > > the components member inside a provile does not present any > difficulty). > > > > Given that, I don't like the proposed approach and suggest to > make > > > > preservation of profiles mandatory, as in the original > proposal. > > > > > > > What about orbs which are shipping in compliance with corba 2.1, > 2.2, 2.3. > > > > > > The other clarification now makes these orbs non compliant. Is > this > > > something > > > which an RTF resolution should be able to do? > > > > Only a CORBA 2.4 compliant ORB would be obliged to adhere to the > change, > > of course. > > > > Surely we are not planning to roll the changes made by this RTF into > 2.4. I thought there was agreement on 2.4 content. The agreement was to put all work that is completed in RTFs and ready for adoption by the Oslo meeting, into 2.4, in addition to the other stuff. This is necessary in order to get the Transaction and Messaging service related brokenness fixed before 2.4 is published. Cheers, Jishnu. Sender: jis@fpk.hp.com Message-ID: <38F492FC.4A5499DE@fpk.hp.com> Date: Wed, 12 Apr 2000 11:15:08 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: "M. Mortazavi" Cc: "Rutt, T E (Tom)" , "'Michi Henning'" , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <38F39505.4F51AF80@fpk.hp.com> <38F3D862.C3BDA861@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Z67!!mV6e9jf%e9]R3e9 M. Mortazavi wrote: > > Jishnu - > > Jishnu Mukerji wrote: > > > Rutt, T E (Tom) wrote: > > > > > > > ---------- > > > > From: Michi Henning[SMTP:michi@ooc.com.au] > > > > Sent: Friday, April 07, 2000 7:52 PM > > > > To: Rutt, T E (Tom) > > > > Cc: 'interop@omg.org' > > > > Subject: Re: New Proposal for Issue 3235 for wordsmithing > before > > > > vote. > > > > > > > > > > > > We already identified that, technically, preserving IOR > profiles presents > > > > no difficulties (just as preserving parts of profiles that > follow the > > > > the components member inside a provile does not present any > difficulty). > > > > Given that, I don't like the proposed approach and suggest to > make > > > > preservation of profiles mandatory, as in the original > proposal. > > > > > > > What about orbs which are shipping in compliance with corba 2.1, > 2.2, 2.3. > > > > > > The other clarification now makes these orbs non compliant. Is > this > > > something which an RTF resolution should be able to do? > > > > Existing implementations that are compliant with the existing > compliance requirements need to > > allowed to claim compliance with the existing compliance > requirements, pedantically speaking that > > is:-). The new compliance requirements can apply only to new > implementations, or a new GIOP version > > or some such. Tom's proposal seems to be one way of achieving > this. The theory being that existing > > compliance rule applies to the IIOP reference domain, and the new > rule applies to the universal IOR > > reference domain. > > > > But there appears to be a few problems: > > > > (1) The concept of "reference domain" is not really defined > anywhere. The term is used for the first > > time in Section 12.1.2 first paragraph, without even attempting to > assign any specific meaning to > > it. We should correct that by adding a definition for it, perhaps > in the vicinity of section 12.1.2. > > Perhaps we can say something like "A IOR reference domain consists > of the set of ORBs that are able > > to use said type of IOR reference to effectively carry out an > object invocation between any two of > > them." Of course, then we will need to clarify that the "type" of > a IOR is determined by the > > profiles found in it, etc. > > Although I can agree that some sort of precise definition for > IOR reference domain might be > reasonable to give, I'm not sure its exclusion would be intolerable > given Tom's proposed resolution. I guess we will just have to disagree then:-). Unless Tom's explanatory additional stuff is included somewhere, a new reader has very little idea about what "reference domain" means. Even with the explanation, it takes a bit of figuring out. Part of the root cause of all the problems we have had in revving GIOP/IIOP is the relative lack of precision in the specification. We should avoid perpatuating this problem. > > (2) The IIOP reference domain is defined in Tom's excellent discussion paragraphs as > > "IIOP reference domain, which includes all CORBA objects which have an interface reference including > > an IIOP IOR profile." Then it goes on to say that the old dropping rules apply to this domain. In my > > mind, this is not what the intent is of the original resolution. > > > > The problem is that it leaves the "IIOP reference domain" based restricted conformance point > > available in perpetuity, for all practical purposes. Additionally it associates a pejorative with > > the term IIOP in conjunction with "reference domain", i.e. IIOP is less than universally > > interoperable. While this may be technically correct, it may not be the brightest thing to advertize > > through a conformance point named as such. > > I didn't read the proposed resolution as an explicit pronouncement of that fact. It certainly > doesn't advertise it. So, I don't think we need to worry about this. We can agree to disagree again/:-). But I am not going to worry about this one extremely, this way or that. > > Perhaps the best way to deal with this is to define the "Legacy IIOP Reference Domain" as: > > "Legacy IIOP reference domain, which includes all CORBA objects which have an interface reference > > including an IIOP IOR profile, and which expect that the component dropping rules as specified in > > CORBA 2.3 are followed." Then we can say (almost tautologically) that the 2.3 dropping rules apply > > to the Legacy IIOP reference domain", and anyone claiming conformance to CORBA 2.3 or earlier needs > > comply only to these rules. > > > > Then the "IIOP Reference domain" could be defined as the domain in which (i) IORs include an IIOP > > IOR profile, and (ii) where the new no dropping rule applies. > > You might have already considered this case but would that definition not exclude the possibility of > a bridge that belongs both to the IIOP reference domain and some other domain for which some dropping > might be required before relaying of an IOR. Bridges between domains are already allowed to drop profiles, so long as they reconstruct the entire original IOR when passing them back into the domain from whence they came originally. > > (3) Tom really needs to spiffy up the discussion stuff in the resolution and include it somewhere in > > Chapter 12. It is going to be a difficult task for anyone without access to theat piece of > > background material, to figure out what the heck is going on. > > I agree that a bit more background on reference domains might be a good idea but to keep it to a > very small addition and to veil it in more abstract terms seems more prudent. I believe the changes Tom > has already suggested in the resolution takes care of that. I'm indifferent to whether the discussion is > included in 12 as long as it is included, for the record, in the resolution. Given the excellent record in issue database maintenance that OMG has, whatever is in the resolution may or may not be available in the future when you need it.:-) I'd strongly recommend including the explanatory stuff at least as a footnote in the spec. But the bottom line is that the specification should be a self standing precise document. One shouldn't need to go hunting through the labrynth of OMG document database just to understand fundamental concepts that are used in the specification. Until now there was the warm and fuzzy use of the term "reference domain" at a couple of places that didn't matter that much. If we are going to use this term to hang conformance rules on, a very precise definition is essential. Cheers, Jishnu. From: "Rutt, T E (Tom)" To: "'interop@omg.org'" Subject: RE: New Proposal for Issue 3235 for wordsmithing before vote. Date: Wed, 12 Apr 2000 12:51:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: 6F[!!+Bg!!]j9!!ZnWd9 I agree with Jishnu's wording (Legacy IIOP IOR Domain and IIOP IOR Reference Domain for 2.4 and above. I will put together a new proposal with the background Reference domain discussion. The point is, that ORbs with 2.4 and above (without reving GIOP) have to preserve IOR information for returning across bridges. -- 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 > ---------- > From: Jishnu Mukerji[SMTP:jis@fpk.hp.com] > Sent: Wednesday, April 12, 2000 10:54 AM > To: Peter Walker > Cc: Michi Henning; Rutt, T E (Tom); 'interop@omg.org' > Subject: Re: New Proposal for Issue 3235 for wordsmithing > before > vote. > > Peter Walker wrote: > > > > Michi Henning wrote: > > > > > > On Tue, 11 Apr 2000, Rutt, T E (Tom) wrote: > > > > > > > > We already identified that, technically, preserving IOR > profiles > presents > > > > > no difficulties (just as preserving parts of profiles that > follow > the > > > > > the components member inside a provile does not present any > difficulty). > > > > > Given that, I don't like the proposed approach and suggest > to make > > > > > preservation of profiles mandatory, as in the original > proposal. > > > > > > > > > What about orbs which are shipping in compliance with corba > 2.1, > 2.2, 2.3. > > > > > > > > The other clarification now makes these orbs non compliant. > Is this > > > > something > > > > which an RTF resolution should be able to do? > > > > > > Only a CORBA 2.4 compliant ORB would be obliged to adhere to the > change, > > > of course. > > > > > > > Surely we are not planning to roll the changes made by this RTF > into > > 2.4. I thought there was agreement on 2.4 content. > > The agreement was to put all work that is completed in RTFs and > ready for > adoption by the Oslo > meeting, into 2.4, in addition to the other stuff. This is necessary > in > order to get the Transaction > and Messaging service related brokenness fixed before 2.4 is > published. > > Cheers, > > Jishnu. > Sender: jbiggar@corvette.floorboard.com Message-ID: <38F4B5D5.D28E1D0A@floorboard.com> Date: Wed, 12 Apr 2000 10:43:49 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Rutt, T E (Tom)" CC: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: > > Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: mV*e9Y@!!!%4A!!e<1e9 "Rutt, T E (Tom)" wrote: > > I agree with Jishnu's wording (Legacy IIOP IOR Domain and > IIOP IOR > Reference Domain for > 2.4 and above. I will put together a new proposal with the > background Reference domain > discussion. > > The point is, that ORbs with 2.4 and above (without reving > GIOP) > have to preserve > IOR information for returning across bridges. Let me suggest another possible naming scheme: Limited IIOP IOR Domain. I think this is more descriptive than Legacy IIOP IOR Domain. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 12 Apr 2000 11:01:15 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <38F39505.4F51AF80@fpk.hp.com> <38F3D862.C3BDA861@eng.sun.com> <38F492FC.4A5499DE@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: P@~e9Ucpd9KBk!!Z+'e9 Dear Jishnu - Jishnu Mukerji wrote: > But the bottom line is that the specification should be a self standing precise document. One > shouldn't need to go hunting through the labrynth of OMG document database just to understand > fundamental concepts that are used in the specification. Until now there was the warm and fuzzy use > of the term "reference domain" at a couple of places that didn't matter that much. If we are going > to use this term to hang conformance rules on, a very precise definition is essential. All I'm saying is that precise definitions have associated costs. Not only must they be proven to be consistent and useful with respect to all other such definitions present, but they must also be part of a rational structure of defintions. (I'm not saying all our interoperability definitons are rational but I found the ones in 12 most rational.) Having a precise definition of "Reference Domain" can certainly be useful but having one that does not create further corner cases of issue research can be a bit more challenging. While the precise definition can be part of the current proposed resolution, I've a sense that putting forth such a definition might deserve further discussion. Let me begin with the following sample which might take it to a particular extreme. So, *be forewarned* before proceeding. As you've suggested, reference domain could be defined to be the set of all ORBs that can use a given reference type as valid target for invocation---this definition being complete once another definition is given for "reference type". You further suggest that reference type can be defined in terms of the collection of profiles in a reference. So the dependency graph of definitions is something like: (A) 'profile'<---'Reference Type'<---'Reference Domain'. I think this sort of structure makes the most abstract to depend on the most concerete. (Here, 'A'<---'B' means that the definition of 'B' depends on the definition of 'A'.) When I first read Chapter 12, my original sense was that the proper dependency could be something like: (B) 'Reference Domain' <---'Profile'<---'Reference Type'. I think this latter sort of dependency has better abstraction model but it also has greater "moral" cost because it makes what we're familiar with (i.e. the idea of 'profile') to depend on what we are not completely familiar with (i.e. 'reference domain'). However, beginning with the familiar (i.e. the 'profile') limits the possibilites for broadening and refining the definition for what's unfamiliar (i.e. the 'reference domain'), and that's the cost associated with semantic structures that so begin. [I'm assuming in all this that 'reference domain' is the unfamiliar. Otherwise, why would one want to define it (away)?] To give a visual analogy, I see (A) as standing the pyramid of definitions on its vertex, while (B) stands it on its base, with the broadest definition being the most abstract. Once you go with (A), addition and refinement of the base of the pyramid can produce a great deal of instability. [Well, that could be good for issue research!] Does this make any sense to anyone, or am I simply nitpicking? In any case, when it comes to abstract definitions, I don't think any effort is wasted. It might simply be unnecessary if precise definition of the more abstract concepts was left alone to be discovered by the interplay of those concepts in a chapter like 12. Chapter 12 must continue to be somewhat seductive, not all pedantic :--) Regards, Max Date: Wed, 12 Apr 2000 11:43:01 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <38F39505.4F51AF80@fpk.hp.com> <38F3D862.C3BDA861@eng.sun.com> <38F492FC.4A5499DE@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: oW0e9PFSd99j2e9_0%!! Jishnu - Since every invocation uses a single profile, and reference types are defined according to your original defintition to be given by the collection of the profiles in the reference type, I cannot see how you can define reference domain as a set of ORBs which can support invocation against a reference type. This seems immediately to produce a problematic definition for bridges. It's not clear whether they belong to any "reference domain" if we keep with your definition. That might be fine. Your definition might also be interepreted as meaning that multiple protocols are operative within a reference domain for invocation, implying that there are choices among protocols for any given invocation. That might be fine, too. Regards, Max Jishnu Mukerji wrote: > M. Mortazavi wrote: > > > > Jishnu - > > > > Jishnu Mukerji wrote: > > > > > Rutt, T E (Tom) wrote: > > > > > > > > > ---------- > > > > > From: Michi Henning[SMTP:michi@ooc.com.au] > > > > > Sent: Friday, April 07, 2000 7:52 PM > > > > > To: Rutt, T E (Tom) > > > > > Cc: 'interop@omg.org' > > > > > Subject: Re: New Proposal for Issue 3235 for > wordsmithing before > > > > > vote. > > > > > > > > > > > > > > > We already identified that, technically, preserving IOR > profiles presents > > > > > no difficulties (just as preserving parts of profiles that > follow the > > > > > the components member inside a provile does not present any > difficulty). > > > > > Given that, I don't like the proposed approach and suggest > to make > > > > > preservation of profiles mandatory, as in the original > proposal. > > > > > > > > > What about orbs which are shipping in compliance with corba > 2.1, 2.2, 2.3. > > > > > > > > The other clarification now makes these orbs non compliant. > Is this > > > > something which an RTF resolution should be able to do? > > > > > > Existing implementations that are compliant with the existing > compliance requirements need to > > > allowed to claim compliance with the existing compliance > requirements, pedantically speaking that > > > is:-). The new compliance requirements can apply only to new > implementations, or a new GIOP version > > > or some such. Tom's proposal seems to be one way of achieving > this. The theory being that existing > > > compliance rule applies to the IIOP reference domain, and the > new rule applies to the universal IOR > > > reference domain. > > > > > > But there appears to be a few problems: > > > > > > (1) The concept of "reference domain" is not really defined > anywhere. The term is used for the first > > > time in Section 12.1.2 first paragraph, without even attempting > to assign any specific meaning to > > > it. We should correct that by adding a definition for it, > perhaps in the vicinity of section 12.1.2. > > > Perhaps we can say something like "A IOR reference domain > consists of the set of ORBs that are able > > > to use said type of IOR reference to effectively carry out an > object invocation between any two of > > > them." Of course, then we will need to clarify that the "type" > of a IOR is determined by the > > > profiles found in it, etc. > > > > Although I can agree that some sort of precise definition for > IOR reference domain might be > > reasonable to give, I'm not sure its exclusion would be > intolerable given Tom's proposed resolution. > > I guess we will just have to disagree then:-). Unless Tom's > explanatory additional stuff is > included somewhere, a new reader has very little idea about what > "reference domain" means. Even with > the explanation, it takes a bit of figuring out. Part of the root > cause of all the problems we have > had in revving GIOP/IIOP is the relative lack of precision in the > specification. We should avoid > perpatuating this problem. > > > > (2) The IIOP reference domain is defined in Tom's excellent > discussion paragraphs as > > > "IIOP reference domain, which includes all CORBA objects which > have an interface reference including > > > an IIOP IOR profile." Then it goes on to say that the old > dropping rules apply to this domain. In my > > > mind, this is not what the intent is of the original resolution. > > > > > > The problem is that it leaves the "IIOP reference domain" based > restricted conformance point > > > available in perpetuity, for all practical > purposes. Additionally it associates a pejorative with > > > the term IIOP in conjunction with "reference domain", i.e. IIOP > is less than universally > > > interoperable. While this may be technically correct, it may not > be the brightest thing to advertize > > > through a conformance point named as such. > > > > I didn't read the proposed resolution as an explicit > pronouncement of that fact. It certainly > > doesn't advertise it. So, I don't think we need to worry about > this. > > We can agree to disagree again/:-). But I am not going to worry > about this one extremely, this way > or that. > > > > Perhaps the best way to deal with this is to define the "Legacy > IIOP Reference Domain" as: > > > "Legacy IIOP reference domain, which includes all CORBA objects > which have an interface reference > > > including an IIOP IOR profile, and which expect that the > component dropping rules as specified in > > > CORBA 2.3 are followed." Then we can say (almost tautologically) > that the 2.3 dropping rules apply > > > to the Legacy IIOP reference domain", and anyone claiming > conformance to CORBA 2.3 or earlier needs > > > comply only to these rules. > > > > > > Then the "IIOP Reference domain" could be defined as the domain > in which (i) IORs include an IIOP > > > IOR profile, and (ii) where the new no dropping rule applies. > > > > You might have already considered this case but would that > definition not exclude the possibility of > > a bridge that belongs both to the IIOP reference domain and some > other domain for which some dropping > > might be required before relaying of an IOR. > > Bridges between domains are already allowed to drop profiles, so > long as they reconstruct the entire > original IOR when passing them back into the domain from whence they > came originally. > > > > (3) Tom really needs to spiffy up the discussion stuff in the > resolution and include it somewhere in > > > Chapter 12. It is going to be a difficult task for anyone > without access to theat piece of > > > background material, to figure out what the heck is going on. > > > > I agree that a bit more background on reference domains might > be a good idea but to keep it to a > > very small addition and to veil it in more abstract terms seems > more prudent. I believe the changes Tom > > has already suggested in the resolution takes care of that. I'm > indifferent to whether the discussion is > > included in 12 as long as it is included, for the record, in the > resolution. > > Given the excellent record in issue database maintenance that OMG > has, whatever is in the resolution > may or may not be available in the future when you need it.:-) I'd > strongly recommend including the > explanatory stuff at least as a footnote in the spec. > > But the bottom line is that the specification should be a self > standing precise document. One > shouldn't need to go hunting through the labrynth of OMG document > database just to understand > fundamental concepts that are used in the specification. Until now > there was the warm and fuzzy use > of the term "reference domain" at a couple of places that didn't > matter that much. If we are going > to use this term to hang conformance rules on, a very precise > definition is essential. > > Cheers, > > Jishnu. Sender: jis@fpk.hp.com Message-ID: <38F4C430.386EA2E3@fpk.hp.com> Date: Wed, 12 Apr 2000 14:45:04 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: "M. Mortazavi" Cc: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <38F39505.4F51AF80@fpk.hp.com> <38F3D862.C3BDA861@eng.sun.com> <38F492FC.4A5499DE@fpk.hp.com> <38F4B9EB.C5725A90@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: S]T!!d*Ie92AO!!%:!!! M. Mortazavi wrote: > > Dear Jishnu - > > Jishnu Mukerji wrote: > > > But the bottom line is that the specification should be a self > standing precise document. One > > shouldn't need to go hunting through the labrynth of OMG document > database just to understand > > fundamental concepts that are used in the specification. Until now > there was the warm and fuzzy use > > of the term "reference domain" at a couple of places that didn't > matter that much. If we are going > > to use this term to hang conformance rules on, a very precise > definition is essential. > > All I'm saying is that precise definitions have associated > costs. Not only must they be proven to be > consistent and useful with respect to all other such definitions > present, but they must also be part of a > rational structure of defintions. (I'm not saying all our > interoperability definitons are rational but I found > the ones in 12 most rational.) > Having a precise definition of "Reference Domain" can certainly > be useful but having one that does not > create further corner cases of issue research can be a bit more > challenging. > While the precise definition can be part of the current proposed > resolution, I've a sense that putting > forth such a definition might deserve further discussion. > Let me begin with the following sample which might take it to a > particular extreme. So, *be forewarned* > before proceeding. > As you've suggested, reference domain could be defined to be the > set of all ORBs that can use a given > reference type as valid target for invocation---this definition > being complete once another definition is > given for "reference type". You further suggest that reference type > can be defined in terms of the collection > of profiles in a reference. So the dependency graph of definitions > is something like: > (A) 'profile'<---'Reference Type'<---'Reference Domain'. > I think this sort of structure makes the most abstract to depend on > the most concerete. (Here, 'A'<---'B' > means that the definition of 'B' depends on the definition of 'A'.) > When I first read Chapter 12, my original sense was that the > proper dependency could be something like: > (B) 'Reference Domain' <---'Profile'<---'Reference Type'. > I think this latter sort of dependency has better abstraction model > but it also has greater "moral" cost > because it makes what we're familiar with (i.e. the idea of > 'profile') to depend on what we are not completely > familiar with (i.e. 'reference domain'). However, beginning with the > familiar (i.e. the 'profile') limits the > possibilites for broadening and refining the definition for what's > unfamiliar (i.e. the 'reference domain'), > and that's the cost associated with semantic structures that so > begin. [I'm assuming in all this that > 'reference domain' is the unfamiliar. Otherwise, why would one want > to define it (away)?] > To give a visual analogy, I see (A) as standing the pyramid of > definitions on its vertex, while (B) stands > it on its base, with the broadest definition being the most > abstract. Once you go with (A), addition and > refinement of the base of the pyramid can produce a great deal of > instability. [Well, that could be good for > issue research!] > Does this make any sense to anyone, or am I simply nitpicking? > In any case, when it comes to abstract definitions, I don't > think any effort is wasted. It might simply be > unnecessary if precise definition of the more abstract concepts was > left alone to be discovered by the > interplay of those concepts in a chapter like 12. Chapter 12 must > continue to be somewhat seductive, not all > pedantic :--) Gosh, you should get a special prize for actually having read Chapter 12!:-) Fascinating!:-) I am actually stuck at a much more mundane level, like a domain is a set of something (presumably). What is the "reference domain" a set of? ORBs? IORs? ORBs that treat IORs a certain way? I was really worried about a much more basic outage. Anyway, assuming that "reference domains" are sets of ORBs that treat IORs a certain way, or deal with IORs with only certain specific characteristics, it may not do too much harm and bear too much moral cost:-), to just say so, in maybe a sentence or two, before using the term to describe a conformance criterion. Notice that the dependence on "profile" comes only in terms of describing a specific characteristic that characterizes a specific kind of reference domain, not in defining the general concept of a reference domain. Cheers, Jishnu. 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. Date: Wed, 12 Apr 2000 12:16:33 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <38F39505.4F51AF80@fpk.hp.com> <38F3D862.C3BDA861@eng.sun.com> <38F492FC.4A5499DE@fpk.hp.com> <38F4B9EB.C5725A90@eng.sun.com> <38F4C430.386EA2E3@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 84Ie9a#9e9X3Ie9ED#!! Jishnnu - > Gosh, you should get a special prize for actually having read Chapter 12!:-) According to authoritative sources, a bear in Oslo can do. > Fascinating!:-) I am actually stuck at a much more mundane level, like a domain is a set of > something (presumably). What is the "reference domain" a set of? ORBs? IORs? ORBs that treat IORs a > certain way? I was really worried about a much more basic outage. It's good to hear that you'd been so worried. Anything less, would have worried me more. > Anyway, assuming that "reference domains" are sets of ORBs that treat IORs a certain way, or deal > with IORs with only certain specific characteristics, As you can see, we're being forced to retreat into less and less precise definitions for reference domain. > it may not do too much harm and bear too much > moral cost:-), to just say so, in maybe a sentence or two, before > using the term to describe a > conformance criterion. Can we review what we're saying precisely about the conformance criteria wrt this? > Notice that the dependence on "profile" comes only in terms of describing a > specific characteristic that characterizes a specific kind of reference domain, not in defining the > general concept of a reference domain. That characteristic is not easy to describe. It seems to have something to do with ability to handle certain set of prorotocls for dispatching and processing of messages. Regards, M. Sender: jis@fpk.hp.com Message-ID: <38F4DD97.AD60493E@fpk.hp.com> Date: Wed, 12 Apr 2000 16:33:27 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: "M. Mortazavi" Cc: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <38F39505.4F51AF80@fpk.hp.com> <38F3D862.C3BDA861@eng.sun.com> <38F492FC.4A5499DE@fpk.hp.com> <38F4B9EB.C5725A90@eng.sun.com> <38F4C430.386EA2E3@fpk.hp.com> <38F4CB91.8353821E@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5,F!!:[g!!Adb!!!d!!! M. Mortazavi wrote: > > Jishnnu - > > > Gosh, you should get a special prize for actually having read > Chapter 12!:-) > > According to authoritative sources, a bear in Oslo can do. I would be happy to arrange for a beer or even two, but a bear may be a little too much for merely reading Chapter 12, don't you think?:-) Then again, I suppose we could try the Oslo Zoo/:-). > > Fascinating!:-) I am actually stuck at a much more mundane level, like a domain is a set of > > something (presumably). What is the "reference domain" a set of? ORBs? IORs? ORBs that treat IORs a > > certain way? I was really worried about a much more basic outage. > > It's good to hear that you'd been so worried. Anything less, would have worried me more. Worry(Jishnu) + Worry(Max) = Constant?:-) > > Anyway, assuming that "reference domains" are sets of ORBs that treat IORs a certain way, or deal > > with IORs with only certain specific characteristics, > > As you can see, we're being forced to retreat into less and less precise definitions for reference domain. I think we need to nail this simple thing down first. If it appears that we are retreating...... Oh well.... > > it may not do too much harm and bear too much > > moral cost:-), to just say so, in maybe a sentence or two, before > using the term to describe a > > conformance criterion. > > Can we review what we're saying precisely about the conformance > criteria wrt this? We are saying that something in a particular "reference domain" (as in "IIOP reference domain") shall behave in a certain way, while something in another "reference domain" (as in "IOR reference domain") shall behave a different way. In order for this specification to be effectively usable to determine whether an ORB is compliant or not, we need to know whether it belongs to the reference domain of interest or not. We need a simple definition of reference domain (or some other means) to address this simple requirement. The rest we can talk about over a beer or two in Oslo.:-) > > Notice that the dependence on "profile" comes only in terms of describing a > > specific characteristic that characterizes a specific kind of reference domain, not in defining the > > general concept of a reference domain. > > That characteristic is not easy to describe. It seems to have something to do with ability to handle certain set > of protocols for dispatching and processing of messages. Hmmm, then we should probably rethink the way in which we are describing the conformance point. Frankly, I think it would be much simpler to avoid domains altogether, and simply say that upto and including CORBA version 2.3 (+IIOP 1.2?) it is OK for ORBs to drop non-standard components/profiles. >From 2.4 onwards (+IIOP 1.3?) they are not allowed to drop non-standard components/profiles if they want to claim compliance to CORBA/IIOP at that revision level. Afterall, at the end of the day I think that is all that we are trying to say. Of course for any other OP, including ESIOPs DCE, embedded IIOP and what have you any other well specified rule is admissible, but the bridges to the IIOP world must follow the stated rules. An alternative, perhaps less desirable formulation would be to say that starting CORBA 2.4 (+GIOP 1.3?) an ORB might claim conformance to one of two interoperability conformance points: (i) GIOP Classic - "We can drop profiles/components that we don't like and that are not part of an OMG standard at the point in time when the implementation was created." i.e. the 2.3 and earlier rule. (ii) GIOP Universal - "We will not drop profiles/components that are in an IOR. If necessary, due to resource constraints, we will drop the entire IOR". The rest of the business about what bridges can and cannot do can then remain as is in the original resolution of the issue. Cheers, Jishnu. Cheers, Jishnu. Date: Wed, 12 Apr 2000 14:09:44 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <38F39505.4F51AF80@fpk.hp.com> <38F3D862.C3BDA861@eng.sun.com> <38F492FC.4A5499DE@fpk.hp.com> <38F4B9EB.C5725A90@eng.sun.com> <38F4C430.386EA2E3@fpk.hp.com> <38F4CB91.8353821E@eng.sun.com> <38F4DD97.AD60493E@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: KW0!!Yfcd9[ll!!Wo+!! Jishnu - Moving along the following suggestions makes better sense to me than undertaking a whole new semantics project. Regards, Max > Hmmm, then we should probably rethink the way in which we are describing the conformance point. > > Frankly, I think it would be much simpler to avoid domains altogether, and simply say that upto and > including CORBA version 2.3 (+IIOP 1.2?) it is OK for ORBs to drop non-standard components/profiles. > From 2.4 onwards (+IIOP 1.3?) they are not allowed to drop non-standard components/profiles if they > want to claim compliance to CORBA/IIOP at that revision level. Afterall, at the end of the day I > think that is all that we are trying to say. Of course for any other OP, including ESIOPs DCE, > embedded IIOP and what have you any other well specified rule is admissible, but the bridges to the > IIOP world must follow the stated rules. > > An alternative, perhaps less desirable formulation would be to say that starting CORBA 2.4 (+GIOP > 1.3?) an ORB might claim conformance to one of two interoperability conformance points: > > (i) GIOP Classic - "We can drop profiles/components that we don't like and that are not part of an > OMG standard at the point in time when the implementation was created." i.e. the 2.3 and earlier > rule. > > (ii) GIOP Universal - "We will not drop profiles/components that are in an IOR. If necessary, due to > resource constraints, we will drop the entire IOR". > > The rest of the business about what bridges can and cannot do can then remain as is in the original > resolution of the issue. Sender: jis@fpk.hp.com Message-ID: <38F4EAD9.1DFF6EEE@fpk.hp.com> Date: Wed, 12 Apr 2000 17:30:01 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: "M. Mortazavi" , Tom Rutt Cc: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: <38F39505.4F51AF80@fpk.hp.com> <38F3D862.C3BDA861@eng.sun.com> <38F492FC.4A5499DE@fpk.hp.com> <38F4B9EB.C5725A90@eng.sun.com> <38F4C430.386EA2E3@fpk.hp.com> <38F4CB91.8353821E@eng.sun.com> <38F4DD97.AD60493E@fpk.hp.com> <38F4E618.82536F27@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: i>?e9T?U!!A%2e9(CDe9 M. Mortazavi wrote: > > Jishnu - > > Moving along the following suggestions makes better sense to me > than undertaking a whole new semantics project. > > Regards, > Max Max, I agree. I was just trying to see what the complexity of the semantic project would be, if we proceeded down the "reference domain" line of presentation. Tom, Would it be possible to forumlate the conformance requirement in simple language dealing with just the dropping rules specifically for IIOP for this issue, and hold off on the more general theory of reference domains for another day, perhaps? Thanks, Jishnu. Ps. Actually you need to do a universal replacement of all GIOPs below by IIOP. GIOP applies to any protocol based on GIOP. The conformance requirements are only for IIOP. > > Hmmm, then we should probably rethink the way in which we are describing the conformance point. > > > > Frankly, I think it would be much simpler to avoid domains altogether, and simply say that upto and > > including CORBA version 2.3 (+IIOP 1.2?) it is OK for ORBs to drop non-standard components/profiles. > > From 2.4 onwards (+IIOP 1.3?) they are not allowed to drop non-standard components/profiles if they > > want to claim compliance to CORBA/IIOP at that revision level. Afterall, at the end of the day I > > think that is all that we are trying to say. Of course for any other OP, including ESIOPs DCE, > > embedded IIOP and what have you any other well specified rule is admissible, but the bridges to the > > IIOP world must follow the stated rules. > > > > An alternative, perhaps less desirable formulation would be to say that starting CORBA 2.4 (+GIOP > > 1.3?) an ORB might claim conformance to one of two interoperability conformance points: > > > > (i) GIOP Classic - "We can drop profiles/components that we don't like and that are not part of an > > OMG standard at the point in time when the implementation was created." i.e. the 2.3 and earlier > > rule. > > > > (ii) GIOP Universal - "We will not drop profiles/components that are in an IOR. If necessary, due to > > resource constraints, we will drop the entire IOR". > > > > The rest of the business about what bridges can and cannot do can then remain as is in the original > > resolution of the issue. Date: Thu, 13 Apr 2000 07:25:41 +1000 (EST) From: Michi Henning To: "M. Mortazavi" cc: Jishnu Mukerji , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. In-Reply-To: <38F4B9EB.C5725A90@eng.sun.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: b<%!!36Wd9^mo!!nJ~!! On Wed, 12 Apr 2000, M. Mortazavi wrote: > While the precise definition can be part of the current proposed resolution, I've a sense that putting > forth such a definition might deserve further discussion. Huh? I don't get it. We are going to publish a conformance requirement based around the notion of reference domains, without defining what that notion means exactly, and you are arguing that this is preferable to publishing a precise definition of that notion? > Chapter 12 must continue to be somewhat seductive, not all > pedantic :--) Well, frankly, as the implementor of the protocol, I'd rather have it pedantic... 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, 13 Apr 2000 07:41:48 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: "M. Mortazavi" , "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. In-Reply-To: <38F4DD97.AD60493E@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: A=Ke9ENX!!['fd9&1*e9 On Wed, 12 Apr 2000, Jishnu Mukerji wrote: > Frankly, I think it would be much simpler to avoid domains altogether, and simply say that upto and > including CORBA version 2.3 (+IIOP 1.2?) it is OK for ORBs to drop non-standard components/profiles. > >From 2.4 onwards (+IIOP 1.3?) they are not allowed to drop non-standard components/profiles if they > want to claim compliance to CORBA/IIOP at that revision level. Afterall, at the end of the day I > think that is all that we are trying to say. I strongly agree with that. And it keeps all the dangerous philosophical material out of the spec ;-) > An alternative, perhaps less desirable formulation would be to say that starting CORBA 2.4 (+GIOP > 1.3?) an ORB might claim conformance to one of two interoperability conformance points: > > (i) GIOP Classic - "We can drop profiles/components that we don't like and that are not part of an > OMG standard at the point in time when the implementation was created." i.e. the 2.3 and earlier > rule. > > (ii) GIOP Universal - "We will not drop profiles/components that are in an IOR. If necessary, due to > resource constraints, we will drop the entire IOR". I don't like this very much. Not just because I think that it has little technical merit, but because it will make things harder for customers when it comes to assessing particular products. 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: "Rutt, T E (Tom)" To: "'interop@omg.org'" Subject: RE: New Proposal for Issue 3235 for wordsmithing before vote. Date: Thu, 13 Apr 2000 10:13:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: =`g!!LKL!!V0Zd9Nl1!! > ---------- > From: Jishnu Mukerji[SMTP:jis@fpk.hp.com] > Sent: Wednesday, April 12, 2000 5:30 PM > To: M. Mortazavi; Tom Rutt > Cc: 'interop@omg.org' > Subject: Re: New Proposal for Issue 3235 for wordsmithing > before > vote. > > M. Mortazavi wrote: > > > > Jishnu - > > > > Moving along the following suggestions makes better sense to > me than > undertaking a whole new semantics project. > > > > Regards, > > Max > > Max, > > I agree. I was just trying to see what the complexity of the > semantic > project would be, if we > proceeded down the "reference domain" line of presentation. > > Tom, > > Would it be possible to forumlate the conformance requirement in > simple > language dealing with just > the dropping rules specifically for IIOP for this issue, and hold > off on > the more general theory of > reference domains for another day, perhaps? > > Thanks, > > Jishnu. > > Ps. Actually you need to do a universal replacement of all GIOPs > below by > IIOP. GIOP applies to any > protocol based on GIOP. The conformance requirements are only for > IIOP. > I agree that introducing concepts which are not required is dangerous. However, the thrust of the original Jishnu harmonization on this issue was that the "retention" of IOR profiles and components only has to occur in bridges. Well when I looked at the chapter 12 stuff, it talks about domain boundaries and bridges. If we want to keep this important clarification that it is the bridge between domains which has to return the same IOR as originally sent to it from another reference domain then we have to define domain. Otherwise we are back to making requirements on local representations of IORs in each orb instance. I see two choices: 1) use the domain crossing requirement, and make it mandatory for corba 2.4 and beyond 2) have two conformance points, one allowing dropping as today, another not allowing dropping. Personally I prefer 2 for its simiplicity. Please members let your preferences be know -- 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: Fri, 14 Apr 2000 06:42:44 +1000 (EST) From: Michi Henning To: "Rutt, T E (Tom)" cc: "'interop@omg.org'" Subject: RE: New Proposal for Issue 3235 for wordsmithing before vote. In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: M!&e9A:8!!`!2!!#U/!! On Thu, 13 Apr 2000, Rutt, T E (Tom) wrote: > I see two choices: > > 1) use the domain crossing requirement, and make it mandatory > for > corba 2.4 and beyond > > 2) have two conformance points, one allowing dropping as > today, > another not allowing > dropping. > > Personally I prefer 2 for its simiplicity. > > Please members let your preferences be know I prefer 1, for the reasons I outlined earlier. We'd effectively create three interoperability classes for ORBs: not interoperable, IIOP interoperable, and generally interoperable, but all three kinds of ORBs can also claim 2.4 compliance. I don't think that this is a good idea from a marketing and branding perspective, and I don't think it's desirable technically. 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, 14 Apr 2000 16:11:24 -0700 From: "M. Mortazavi" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rutt, T E (Tom)" CC: "'interop@omg.org'" Subject: Re: New Proposal for Issue 3235 for wordsmithing before vote. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1BZ!!,">e9bpFe9@EK!! Status: U Tom - > I agree that introducing concepts which are not required is > dangerous. We can save ourselves a lot of headache if we can avoid that danger. > However, the thrust of the original Jishnu harmonization on this > issue was that > the "retention" of IOR profiles and components only has to occur in > bridges. Well > when I looked at the chapter 12 stuff, it talks about domain > boundaries and bridges. It does and it looks to me that any definition of domain is bound up to some definition of bridge. Domains seem to be collections of endpoints (accessible through some operative set of protocols) separated by bridges, or something like that. We seemed to be saying, in the most recent resolution, that the bridges are the only place where profiles can be dropped in a given direction, and if they are so dropped, they must be reconstitutable (and reconstituted) in the opposite direction. That does not seem to require more than what it does wrt a precise definition of reference domains although I do like your analysis of reference domains in general. > If we want to keep this important clarification that it is the > bridge between domains > which has to return the same IOR as originally sent to it from > another reference domain > then we have to define domain. Why can we not simply say that a bridging ORB is an ORB that supports that behavior among others while leaving the definition of refererence domains alone. > Otherwise we are back to making > requirements on > local representations of IORs in each orb instance. > > I see two choices: > > 1) use the domain crossing requirement, and make it mandatory for > corba 2.4 and beyond > > 2) have two conformance points, one allowing dropping as today, > another not allowing > dropping. > > Personally I prefer 2 for its simiplicity. > > Please members let your preferences be know I think the most recent version of the resolution you've sent is generally correct. I'm not sure why we need to state any conformance rules, and am puzzled why we cannot simply say that the "bridge" is the only entity that can drop profiles from the IOR, according to the constraint given, and leave it at that. People hack bridges all the time and seem to know what they mean and will now have to live with the problem of reconstituability in the opposite direction if they drop referential information in one of the directions. M. > > -- > 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 X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 18 Apr 2000 16:32:13 -0700 To: interop@omg.org From: Edward Cobb Subject: Issue 3235 Clarification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 7Jjd96QHe9:m2e9-;E!! Before voting on issue 3235, I want to be sure I've read it properly and understand what's being proposed. This may or may not require a clarification to the text. I read the document to say that the following: - conformance for IIOP 1.1 and 1.2 requires support of Limited_Profile IOR conformance, specifically for the IIOP IOR profile - future versions of IIOP will require support of full IOR conformance - with CORBA 2.4, full IOR conformance for IIOP conformance is recommended My questions are as folloes: 1. I'm assuming that CORBA 2.4 is IIOP 1.2 (or maybe IIOP 1.1), but not a new version of IIOP, correct? 2. If #1 is correct, this requires only limited IOR conformance and full IOR conformance while strongly recommended is not required, correct? 3. Is a "new version of IIOP" refer to a mavjor version (IIOP 2.0) or a minor version (IIOP 1.3)? ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com **************************************************************