Issue 2940: Need clarification on GIOP::TargetAddress (interop) Source: Cisco Systems (Mr. Paul Kyzivat, nobody) Nature: Clarification Severity: Summary: Something seems unclear to me about how to interpret a RequestHeader_1_2 when the AddressingDisposition of the TargetAddress is ReferenceAddr: In the case the request contains a full IOR, which may have several profiles. Since each profile has its own object_key, and there is no requirement that they all be the same, the key for the operation may depend on which profile chosen. The client had to choose some profile in order to send the request, but that information is not included in the request. So apparently the server must decide on its own which profile it would like to use. This may not be the same one the client chose. What if any requirements are there on how this is done? Resolution: withdrawn by submitter...issue closed Revised Text: Actions taken: September 22, 1999: received issue October 22, 1999: closed issue Discussion: End of Annotations:===== Date: Wed, 22 Sep 1999 16:07:09 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: issues@omg.org, Interop RTF Subject: Need clarification on GIOP::TargetAddress X-Priority: 3 (Normal) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Q,~!!j2n!!^:ed9~_[d9 Something seems unclear to me about how to interpret a RequestHeader_1_2 when the AddressingDisposition of the TargetAddress is ReferenceAddr: In the case the request contains a full IOR, which may have several profiles. Since each profile has its own object_key, and there is no requirement that they all be the same, the key for the operation may depend on which profile chosen. The client had to choose some profile in order to send the request, but that information is not included in the request. So apparently the server must decide on its own which profile it would like to use. This may not be the same one the client chose. What if any requirements are there on how this is done? If the orb is allowed to assume the object reference is one it created, then it can make its own assumptions about what mixtures of profiles might be present and how to choose among them. But if there is a chance that the orb may be faced with an IOR that has been created by someone else, perhaps by splicing parts from various other object references, then this could be very difficult to do. The INS spec has legitimized the creation of IORs by an agent other than the receiving orb. For now I think they will be a single profile, making the choice easy. But I am concerned that there may be other ways (such as bridges) that might create more difficult cases. Date: Wed, 22 Sep 1999 17:06:38 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul H Kyzivat CC: Interop RTF Subject: Re: Need clarification on GIOP::TargetAddress References: <37E936EC.7D45F5C7@roguewave.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: gVK!!Q_)!!Xmed92+Be9 Hi Paul, This may not be specified clearly enough, but I think the information you say is missing is in fact included in the request. Here is the CORBA 2.3 IDL: // GIOP 1.2 typedef short AddressingDisposition; const short KeyAddr = 0; const short ProfileAddr = 1; const short ReferenceAddr = 2; struct IORAddressingInfo { unsigned long selected_profile_index; IOP::IOR ior; }; union TargetAddress switch (AddressingDisposition) { case KeyAddr: sequence object_key; case ProfileAddr: IOP::TaggedProfile profile; case ReferenceAddr: IORAddressingInfo ior; }; The explaination of selected_profile_index given in the spec is: IORAddressingInfo is the full IOR of the target object. The selected_profile_index indicates the transport-specific GIOP profile that was selected by the client ORB. My understanding of the text and of the intent is that if the ReferenceAddr addressing mode is being used, an IORAddressingInfo struct is passed from client to server, and the selected_profile_index member of this IORAddressingInfo struct idenfifies which profile the client is using to make the invocation. Do you feel additional clarification is needed? -Bob Paul H Kyzivat wrote: > > Something seems unclear to me about how to interpret a > RequestHeader_1_2 > when the AddressingDisposition of the TargetAddress is > ReferenceAddr: > > In the case the request contains a full IOR, which may have several > profiles. Since each profile has its own object_key, and there is no > requirement that they all be the same, the key for the operation may > depend on which profile chosen. > > The client had to choose some profile in order to send the request, > but > that information is not included in the request. So apparently the > server must decide on its own which profile it would like to > use. This > may not be the same one the client chose. > > What if any requirements are there on how this is done? > > If the orb is allowed to assume the object reference is one it > created, > then it can make its own assumptions about what mixtures of profiles > might be present and how to choose among them. > > But if there is a chance that the orb may be faced with an IOR that > has > been created by someone else, perhaps by splicing parts from various > other object references, then this could be very difficult to do. > > The INS spec has legitimized the creation of IORs by an agent other > than > the receiving orb. For now I think they will be a single profile, > making > the choice easy. But I am concerned that there may be other ways > (such > as bridges) that might create more difficult cases. Date: Thu, 23 Sep 1999 10:15:28 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Bob Kukura CC: Interop RTF Subject: Re: Need clarification on GIOP::TargetAddress X-Priority: 3 (Normal) References: <37E936EC.7D45F5C7@roguewave.com> > <37E944DE.6D4B0177@iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: <`Oe9~?ed9U~E!!9K`d9 Bob Kukura wrote: > > Hi Paul, > > This may not be specified clearly enough, but I think the > information > you say is missing is in fact included in the request. Here is the > CORBA 2.3 IDL: > > // GIOP 1.2 > typedef short AddressingDisposition; > > const short KeyAddr = 0; > const short ProfileAddr = 1; > const short ReferenceAddr = 2; > > struct IORAddressingInfo { > unsigned long selected_profile_index; > IOP::IOR ior; > }; OOPS! My mistake. I guess it was sitting there staring me in the face all the time and I didn't see it. Thanks!