Issue 2968: Second bit of response_flags (interop) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: The question below was posted to the corba-dev list. I have to admit that I don't understand the purpose of the second-least significant bit of response_flags either. From the text in the spec, it appears that this bit is set if a request expects a response and is not invoked via the DII, whereas if a request is oneway or invoked via the DII with INV_NO_RESPONSE set, the bit is clear. Resolution: closed issue ...clarified Revised Text: Actions taken: November 2, 1999: received issue November 5, 1999: closed issue Discussion: End of Annotations:===== Date: Tue, 2 Nov 1999 12:18:17 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com Reply-To: interop@omg.org To: issues@omg.org cc: interop@omg.org Subject: Second bit of response_flags Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %o%"!TZ:!!\I`!!o-?e9 The question below was posted to the corba-dev list. I have to admit that I don't understand the purpose of the second-least significant bit of response_flags either. From the text in the spec, it appears that this bit is set if a request expects a response and is not invoked via the DII, whereas if a request is oneway or invoked via the DII with INV_NO_RESPONSE set, the bit is clear. There is certainly at least one issue here: the words in the spec are convoluted to the point of being obtuse. Why not state what each bit is used for? Second, it seems that this bit would enable the server to distinguish between a DII and non-DII invocation, which would fundamentally break the object model. What is the real purpose of this bit? Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html ---------- Forwarded message ---------- From: "Sherman, David" To: "'corba-dev@randomwalk.com'" Date: Mon, 1 Nov 1999 13:01:24 -0800 Subject: CORBA-DEV: Request Message Response Flags I do not understand one of the flags in the Header of the Request Message. The relevant location in the CORBA V2.3 documentation is section 15.4.2.1, "Request Header", the discussion of response_flags, page 15-33. It seems fairly clear that the lowest order bit indicates whether a reply is expected. From examination of the data sent between machines, I have determined that I can cause the response flags to be 0 when I make a one-way request, and to be 1 when I make a normal request. I do not understand the meaning of the second-lowest order bit. I am not able to cause this bit to be on in the response flags, and I don't understand the explanation of the bit's meaning in the documentation. Could someone please explain? David Sherman NAI Labs - Network Associates, Inc. 3060 Washington Road Glenwood, MD 21738 ================================================================== To unsubscribe from the corba-dev mailing list, send mail with the phrase "unsubscribe corba-dev " to "majordomo@randomwalk.com". mailto:majordomo@randomwalk.com?body=unsubscribe corba-dev List-server hosted by Random Walk Computing, Inc. http://www.randomwalk.com List archives available at http://lists.randomwalk.com ================================================================== Sender: jon@floorboard.com Message-ID: <381E64AA.D74D807A@floorboard.com> Date: Mon, 01 Nov 1999 20:12:26 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: interop@omg.org CC: issues@omg.org Subject: Re: Second bit of response_flags References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: JLCe9N#L!!Qg?!!H9!"! Michi Henning wrote: > > The question below was posted to the corba-dev list. I have to admit > that I don't understand the purpose of the second-least significant > bit > of response_flags either. From the text in the spec, it appears that > this bit is set if a request expects a response and is not invoked > via > the DII, whereas if a request is oneway or invoked via the DII with > INV_NO_RESPONSE set, the bit is clear. > > There is certainly at least one issue here: the words in the spec > are > convoluted to the point of being obtuse. Why not state what each bit > is > used for? I agree that the wording could potentially be clearer. It appears that someone took the bits as defined by the Messaging spec, and tried to write text that would make sense to someone implementing GIOP 1.2 without the Messaging spec handy. They obviously didn't succeed too well. :-) > Second, it seems that this bit would enable the server to distinguish > between a DII and non-DII invocation, which would fundamentally break > the object model. What is the real purpose of this bit? I don't think that the text as I read it does what you think. Where it mentions the DII, it always says "oneway or the request is invoked via the DII with the INV_NO_RESPONSE flag set". This is just a shorthand for saying that the client has indicated that it doesn't want to receive a response. If you look at the messaging spec, the meaning of the bits becomes clear: 00 means SyncScope of NONE or WITH_TRANSPORT 01 means SyncScope of WITH_SERVER 11 means SyncScope of WITH_TARGET 00 and 01 are for the different oneway options, and 11 is the usual two-way invocation. There is no 10. :-) If I had written it, I would have swapped 01 and 11, just to make the protocol look more like GIOP 1.1, but since the version is rev'ed anyway, there's no compatibility problem other than trying to grok the changes. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 2 Nov 1999 15:30:44 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Jonathan Biggar cc: interop@omg.org Subject: Re: Second bit of response_flags In-Reply-To: <381E64AA.D74D807A@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ~7B!!%Hp!!'>A!!36\!! On Mon, 1 Nov 1999, Jonathan Biggar wrote: > I agree that the wording could potentially be clearer. It appears that > someone took the bits as defined by the Messaging spec, and tried to > write text that would make sense to someone implementing GIOP 1.2 > without the Messaging spec handy. They obviously didn't succeed too > well. :-) Yes. Steve also pointed out to me that the messaging spec explains this properly. However, the words in the section 15 really had me stumped. I shouldn't have to draw truth tables and disentagle convoluted grammar to understand the purpose of a new bit :-) > If you look at the messaging spec, the meaning of the bits becomes > clear: > > 00 means SyncScope of NONE or WITH_TRANSPORT > 01 means SyncScope of WITH_SERVER > 11 means SyncScope of WITH_TARGET > > 00 and 01 are for the different oneway options, and 11 is the usual > two-way invocation. There is no 10. :-) Well, why can't we say it like that in Section 15? Even I could understand it then... :-) Cheers, michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@floorboard.com Message-ID: <381E8CDC.FCC4468F@floorboard.com> Date: Mon, 01 Nov 1999 23:03:56 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: interop@omg.org Subject: Re: Second bit of response_flags References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pJad96Ma!!0Ukd9`&%e9 Michi Henning wrote: > > If you look at the messaging spec, the meaning of the bits becomes > > clear: > > > > 00 means SyncScope of NONE or WITH_TRANSPORT > > 01 means SyncScope of WITH_SERVER > > 11 means SyncScope of WITH_TARGET > > > > 00 and 01 are for the different oneway options, and 11 is the > usual > > two-way invocation. There is no 10. :-) > > Well, why can't we say it like that in Section 15? Even I could > understand > it then... :-) It will say that eventually, when Messaging is integrated. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Paul Kyzivat To: "'interop@omg.org'" , "'issues@omg.org'" Subject: RE: Second bit of response_flags Date: Tue, 2 Nov 1999 08:56:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: (3Y!![$1e9nP-e9mlbd9 > From: Michi Henning [mailto:michi@ooc.com.au] ... > The question below was posted to the corba-dev list. I have to admit > that I don't understand the purpose of the second-least > significant bit > of response_flags either. From the text in the spec, it appears that > this bit is set if a request expects a response and is not invoked via > the DII, whereas if a request is oneway or invoked via the DII with > INV_NO_RESPONSE set, the bit is clear. > > There is certainly at least one issue here: the words in the spec are > convoluted to the point of being obtuse. Why not state what > each bit is used for? > > Second, it seems that this bit would enable the server to distinguish > between a DII and non-DII invocation, which would fundamentally break > the object model. What is the real purpose of this bit? I have struggled with this one too. As best I can understand the bottom two bits taken together are supposed to be an enumeration of cases: 00 - normal 1-way operation; never reply 01 - don't send normal or user exception replies, but do send location forwards & system exceptions 10 - INVALID 11 - normal 2-way operation, reply when complete I gather that the intent with "01" is to send the kinds of errors that might occur while preparing to dispatch the request, probably before actually doing the request. However, there is a problem with this. Suppose the request is not declared oneway in IDL, but rather was sent using the DII with the INV_NO_RESPONSE flag. Further, suppose that the operation is defined as having inout or out arguments, or a return value. If the operation is ok to dispatch, what should be sent in the reply? The caller doesn't want the return value, and apparently doesn't want to wait for it to be prepared and discarded either. But what can the server send that is valid? Who added this stuff? Maybe they could explain it to us. Sender: jis@fpk.hp.com Message-ID: <381F0B4F.EF60741C@fpk.hp.com> Date: Tue, 02 Nov 1999 11:03:27 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Juergen Boldt CC: Jonathan Biggar , interop@omg.org, issues@omg.org Subject: Re: Second bit of response_flags References: <381E64AA.D74D807A@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: `L > Michi Henning wrote: > > > > The question below was posted to the corba-dev list. I have to > admit > > that I don't understand the purpose of the second-least > significant bit > > of response_flags either. From the text in the spec, it appears > that > > this bit is set if a request expects a response and is not invoked > via > > the DII, whereas if a request is oneway or invoked via the DII > with > > INV_NO_RESPONSE set, the bit is clear. The not invoked via DII bit is a proxy for saying that this stuff gets its full meaning when Messaging is added.:-) > > There is certainly at least one issue here: the words in the spec are > > convoluted to the point of being obtuse. Why not state what each bit is > > used for? > > I agree that the wording could potentially be clearer. It appears that > someone took the bits as defined by the Messaging spec, and tried to > write text that would make sense to someone implementing GIOP 1.2 > without the Messaging spec handy. They obviously didn't succeed too > well. :-) I stand guilty as charged. My attempt was to make sure that we did not have to rev GIOP when Messaging finally got integrated. In doing so, I had to project back the new stuff and express it in terms of only those concepts that were known in a system sans Messaging. This was not an easy task. If you wish you can take a crack at it in your spare time for entertainment, if such things turn you on.:-) > > Second, it seems that this bit would enable the server to distinguish > > between a DII and non-DII invocation, which would fundamentally break > > the object model. What is the real purpose of this bit? > > I don't think that the text as I read it does what you think. Where it > mentions the DII, it always says "oneway or the request is invoked via > the DII with the INV_NO_RESPONSE flag set". This is just a shorthand > for saying that the client has indicated that it doesn't want to receive > a response. Jon's interpretation is right. As suggested by Jon go to the source to get the complete story.:-) > If you look at the messaging spec, the meaning of the bits becomes > clear: > > 00 means SyncScope of NONE or WITH_TRANSPORT > 01 means SyncScope of WITH_SERVER > 11 means SyncScope of WITH_TARGET > > 00 and 01 are for the different oneway options, and 11 is the usual > two-way invocation. There is no 10. :-) > > If I had written it, I would have swapped 01 and 11, just to make > the > protocol look more like GIOP 1.1, but since the version is rev'ed > anyway, there's no compatibility problem other than trying to grok > the > changes. May I point out while I am at it, there is no real issue here since this bullet gets replaced by the bullet as adopted in the Messaging spec in the next release of Chapter 15. See page 15-33 of ptc/99-10-03, to see what it will look like in the new version of Chapter 15. 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. Sender: jis@fpk.hp.com Message-ID: <38234B02.D9B93C11@fpk.hp.com> Date: Fri, 05 Nov 1999 16:24:18 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Juergen Boldt CC: issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2968 -- Interop RTF issue References: <4.1.19991105152519.00a37cc0@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: aNY!!9#)!!BT+e9X7Rd9 Juergen Boldt wrote: > > This is issue # 2968 > > Second bit of response_flags > > The question below was posted to the corba-dev list. I have to admit > that I don't understand the purpose of the second-least significant > bit > of response_flags either. From the text in the spec, it appears that > this bit is set if a request expects a response and is not invoked > via > the DII, whereas if a request is oneway or invoked via the DII with > INV_NO_RESPONSE set, the bit is clear. Juergen, This issue gets fixed automatically when the Messaging specification gets integrated into Chapter 15. So this really is a non-issue and will eventually get closed no change, when the RTF discovers that the text being referred to in the issue is no longer present in the chapter. In my opinion it should not be recorded as an issue, because this cannot be fixed by the Interop RTF, and the Messaging RTF does not need to do anything to fix this. See draft of concerned chapter in orbos/99-10-03 in which the Messaging spec has been integrated into the Core spec and notice that the paragraph in question is gone - replaced by the paragraph that was adopted in the messaging spec. The paragraph in question is an artifact of an attempt to shoehorn parts of the messaging spec into CORBA 2.3 via RTF. But of course others might disagree. Thanks, 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: Sat, 6 Nov 1999 08:27:14 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Jishnu Mukerji cc: Juergen Boldt , issues@emerald.omg.org, interop@emerald.omg.org Subject: Re: issue 2968 -- Interop RTF issue In-Reply-To: <38234B02.D9B93C11@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: dkNd9JS&!!CPL!!::,e9 On Fri, 5 Nov 1999, Jishnu Mukerji wrote: > Juergen Boldt wrote: > This issue gets fixed automatically when the Messaging specification > gets > integrated into Chapter 15. So this really is a non-issue and will > eventually > get closed no change, when the RTF discovers that the text being > referred to in > the issue is no longer present in the chapter. In my opinion it > should not be > recorded as an issue, because this cannot be fixed by the Interop > RTF, and the > Messaging RTF does not need to do anything to fix this. See draft of > concerned > chapter in orbos/99-10-03 in which the Messaging spec has been > integrated into > the Core spec and notice that the paragraph in question is gone - > replaced by > the paragraph that was adopted in the messaging spec. The paragraph > in question > is an artifact of an attempt to shoehorn parts of the messaging spec > into CORBA > 2.3 via RTF. But of course others might disagree. I agree with Jishnu. Sorry for this, it was caused largely by my own ignorance. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html