Issue 4273: GIOP is silent about extra data in the Request or Reply body (interop) Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com) Nature: Uncategorized Issue Severity: Summary: The specification does not say whether extra data after the invocation parameters in a Request or Reply body is ignored or considered an error. For interoperability purposes, the spec should require one or the other. Resolution: see below Revised Text: In the para under the bullet point “message_size” on page 15-33, change the following: This count includes any alignment gaps. To r ead: The count includes any alignment gaps and must match the size of the actual request parameters (plus any final padding bytes that may follow the parameters to have a fragment message terminate on an 8-byte bound-ary). A MARSHAL exception with minor code 7 indicates that fewer bytes were present in a message than indicated by the count. (This condition can arise if the sender sends a message in fragments, and the receiver detects that the final fragment was received but contained insufficient data for all parameters to be unmarshaled.) A MARSHAL exception with minor code 8 indicates that more bytes were present in a message than indicated by the count. Depending on the ORB implementation, this condition may be reported for the current mes-sage or the next message that is processed (when the receiver detects that the previous message is not immediately followed by the GIOP magic number). Add the following entries to the exception minor code table in section 4.11.4, page 4-63: MARSHAL 7 Header byte count for GIOP message greater than available data. MARSHAL 8 Header byte count for GIOP message less than available data. Actions taken: April 18, 2001: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== Sender: jon@corvette.floorboard.com Message-ID: <3ADE18A8.E409161F@floorboard.com> Date: Wed, 18 Apr 2001 15:43:52 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: interop@omg.org, issues@omg.org Subject: GIOP is silent about extra data in the Request or Reply body Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3[\!!P,:!!6]_!!K9Le9 The specification does not say whether extra data after the invocation parameters in a Request or Reply body is ignored or considered an error. For interoperability purposes, the spec should require one or the other. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 19 Apr 2001 09:08:11 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Interoperability RTF Subject: Re: GIOP is silent about extra data in the Request or Reply body In-Reply-To: <3ADE18A8.E409161F@floorboard.com> Message-ID: Organization: Object Oriented Concepts - An IONA Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: EW`!!&dKe9ZB#!!YPa!! On Wed, 18 Apr 2001, Jonathan Biggar wrote: > The specification does not say whether extra data after the invocation > parameters in a Request or Reply body is ignored or considered an > error. For interoperability purposes, the spec should require one or > the other. I recently got a question about this: what happens if an operation expects two in parameters of type long, and the client sends a long followed by a short? (This is almost the same question as yours. There are really two cases: too much data is in the request, or too little data is in the request.) Current implementations may do any of the following: - detect the error and throw a MARSHAL exception - detect the error, reply with MessageError, and close the connection - silently gobble up any extraneous data if there is too much data - silently misinterpret the data if it is too short, by reading an extra few bytes of the message header for the next message, and optinally resynchronize on a message boundary by searching for the next GIOP magic number - any other behavior that's deemed convenient by the implementation My feeling is that we should be strict and state that MARSHAL must be thrown if the number of bytes required to unmarshal the parameters doesn't exactly match what's expected according to the GIOP header. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts - An IONA Company +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi.henning@iona.com Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi Sender: jon@corvette.floorboard.com Message-ID: <3ADE215F.62F5E4DC@floorboard.com> Date: Wed, 18 Apr 2001 16:21:03 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Interoperability RTF Subject: Re: GIOP is silent about extra data in the Request or Reply body References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [I~e9BV#!!RK]d9kko!! Michi Henning wrote: > > On Wed, 18 Apr 2001, Jonathan Biggar wrote: > > > The specification does not say whether extra data after the invocation > > parameters in a Request or Reply body is ignored or considered an > > error. For interoperability purposes, the spec should require one or > > the other. > > I recently got a question about this: what happens if an operation expects > two in parameters of type long, and the client sends a long followed by > a short? (This is almost the same question as yours. There are really two > cases: too much data is in the request, or too little data is in the request.) Too little data is unequivocably a MARSHAL error. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 19 Apr 2001 09:28:39 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Interoperability RTF Subject: Re: GIOP is silent about extra data in the Request or Reply body In-Reply-To: <3ADE215F.62F5E4DC@floorboard.com> Message-ID: Organization: Object Oriented Concepts - An IONA Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 5RUd9<'Yd9&W6!!T!`d9 On Wed, 18 Apr 2001, Jonathan Biggar wrote: > > I recently got a question about this: what happens if an operation expects > > two in parameters of type long, and the client sends a long followed by > > a short? (This is almost the same question as yours. There are really two > > cases: too much data is in the request, or too little data is in the request.) > > Too little data is unequivocably a MARSHAL error. I agree. But I don't think the spec says that. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts - An IONA Company +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi.henning@iona.com Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi X-Sender: beckwb@postel X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 21 Apr 2001 14:47:10 -0400 To: Jonathan Biggar From: Bill Beckwith Subject: Re: GIOP is silent about extra data in the Request or Reply body Cc: interop@omg.org, issues@omg.org In-Reply-To: <3ADE18A8.E409161F@floorboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ~L[d9_l=e9i`*e92*B!! At 06:43 PM 4/18/01, Jonathan Biggar wrote: >The specification does not say whether extra data after the invocation >parameters in a Request or Reply body is ignored or considered an >error. For interoperability purposes, the spec should require one or >the other. I'd prefer the ignore direction. Bill Date: Mon, 23 Apr 2001 14:34:12 +1000 (EST) From: Michi Henning To: Bill Beckwith cc: Jonathan Biggar , interop@omg.org, issues@omg.org Subject: Re: GIOP is silent about extra data in the Request or Reply body In-Reply-To: <5.0.0.25.2.20010421144633.02a37c50@postel> Message-ID: Organization: Object Oriented Concepts - An IONA Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: i2C!!]Bod9c_od9(lFe9 On Sat, 21 Apr 2001, Bill Beckwith wrote: > At 06:43 PM 4/18/01, Jonathan Biggar wrote: > >The specification does not say whether extra data after the invocation > >parameters in a Request or Reply body is ignored or considered an > >error. For interoperability purposes, the spec should require one or > >the other. > > I'd prefer the ignore direction. Why is that? Sending a message where the contents disagree with the byte count in the header clearly indicates a broken ORB. I don't think we do ourselves a favour by hiding such errors. Cheers, Michi. Sender: jon@corvette.floorboard.com Message-ID: <3AE3B22C.8034B0B9@floorboard.com> Date: Sun, 22 Apr 2001 21:40:12 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Bill Beckwith , interop@omg.org, issues@omg.org Subject: Re: GIOP is silent about extra data in the Request or Reply body References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Z`gd9$/Xd92H6e9+W""! Michi Henning wrote: > > On Sat, 21 Apr 2001, Bill Beckwith wrote: > > > At 06:43 PM 4/18/01, Jonathan Biggar wrote: > > >The specification does not say whether extra data after the invocation > > >parameters in a Request or Reply body is ignored or considered an > > >error. For interoperability purposes, the spec should require one or > > >the other. > > > > I'd prefer the ignore direction. > > Why is that? Sending a message where the contents disagree with the > byte count in the header clearly indicates a broken ORB. I don't think > we do ourselves a favour by hiding such errors. Or it's a sign of a IDL version mismatch, which would be best reported as an error as well. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 23 Apr 2001 14:47:30 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Interoperability RTF Subject: Re: GIOP is silent about extra data in the Request or Reply body In-Reply-To: <3AE3B22C.8034B0B9@floorboard.com> Message-ID: Organization: Object Oriented Concepts - An IONA Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: $Ao!!@1Ne91@Qd9g6M!! On Sun, 22 Apr 2001, Jonathan Biggar wrote: > > > I'd prefer the ignore direction. > > > > Why is that? Sending a message where the contents disagree with the > > byte count in the header clearly indicates a broken ORB. I don't think > > we do ourselves a favour by hiding such errors. > > Or it's a sign of a IDL version mismatch, which would be best reported > as an error as well. I strongly agree. If the data doesn't match the byte count, something is seriuosly broken, either in the ORB run time or the IDL at the two ends doesn't match. Either way, hiding the problem doesn't help anyone, as far as I can see. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts - An IONA Company +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi.henning@iona.com Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi Date: Wed, 06 Jun 2001 20:49:02 -0700 From: Vijaykumar Natarajan Subject: Issue 4273 To: interop@omg.org Message-id: <3B1EF9AE.1600DE7@inprise.com> Organization: Borland Software Corporation MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en Content-Type: multipart/mixed; boundary="Boundary_(ID_qwbR3ZNao1kzJzbtHFgCLw)" X-UIDL: l4=e9G$,e9/`X!!ac/!! All, Apologies for not bringing this up earlier, but I just took a close look at this issue. I don't see what the resolution actually did to solve the issue. First, the resolution still doesn't address whether or not it is compliant for an ORB to ignore an overflow (underflow is an easy case, so not a problem) condition (i.e. not throw the error). Second, I think there is a problem w/ implementing an overflow condition, as the stubs and skeletons would have to indicate that they are done reading from a stream for this condition to be detected and in Java there isn't any API on the portable streams to indicate this. Thanks, Vijay [] vnatarajan3.vcf X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from unknown (63.78.120.98) by hobbit.omg.org asmtp(1.0) id 9600; Thu, 07 Jun 2001 22:34:54 -0400 (EDT) Received: from theep.net (IDENT:rk@theep.theep.net [63.78.120.98]) by theep.theep.net (8.9.3/8.9.3) with ESMTP id WAA18970 for ; Thu, 7 Jun 2001 22:29:59 -0400 Sender: rk@theep.net Message-ID: <3B2038A7.BBE7935F@theep.net> Date: Thu, 07 Jun 2001 22:29:59 -0400 From: Robert Kukura X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-14 i586) X-Accept-Language: en MIME-Version: 1.0 To: interop@omg.org Subject: [Fwd: interop vote question] Content-Type: multipart/mixed; boundary="------------0914438F9A16B081FD4CDB32" X-UIDL: K7ad9\YNe9N/Ie9R,,!! I'm having trouble getting mail to OMG from IONA, so I'm trying from a different account. -BobReturn-Path: Received: from karloff.boston.amer.iona.com (boston.amer.iona.com [63.65.132.35] (may be forged)) by theep.theep.net (8.9.3/8.9.3) with ESMTP id WAA18962 for ; Thu, 7 Jun 2001 22:26:04 -0400 Received: from iona.com ([10.64.1.20]) by karloff.boston.amer.iona.com (8.9.3/iona-1.02-sjamison) with ESMTP id WAA12800 for ; Thu, 7 Jun 2001 22:25:28 -0400 (EDT) Message-ID: <3B20376F.D93A359A@iona.com> Date: Thu, 07 Jun 2001 22:24:47 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rk@theep.net Subject: interop vote question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I was about ready to vote, and noticed a couple of possible problems with the resolutions for 4273 (vote 1) and 4289 (vote 2): 1) 4273 specificies a single minor code to be used when the length expected for the the recieved message disagrees with the header byte count. Orbix 2000 uses two different proprietary minor codes for this - one for extra data on the wire and one for not enough data on the wire. I think its useful to distinguish these cases, but the proposal makes this non-conformant. 2) 4289 specifies a different minor code indicating an incomplete final fragment. How is this different than the "not enough data on the wire" situation in the resolution to 4273? Is the intent to distinguish between not enough data in a fragmentmented message and not enough data in a non-fragmented message? I really don't see the point in this. If so, it still seems inconsistent with the resolution to 4273 since 4273 doesn't say it is specific to non-fragmented messages. Am I missing something here? When I figure out our position on 4299 and vote, I'm intending to vote NO on both 4273 and 4289 unless someone clears this up, and I'd suggest others do the same if you think the these are real problems with the resolutions. In case it wasn't clear, I'd strongly prefer that we didn't distinguish between fragmented and non-fragmented messages, and did distinguish between too much and too little data. Thanks, -Bob From: "Everett Anderson" To: "Interoperability RTF" Cc: "Bob Kukura" Subject: RE: interop vote question (fwd) Date: Fri, 8 Jun 2001 01:36:52 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="us-ascii" X-UIDL: Dlad94lQd9MAl!!(l'e9 Hi, > 1) 4273 says a specific single minor code is used when the length > expected for the the recieved message disagrees with the header byte > count. Orbix 2000 uses two different proprietary minor codes for this - > one for extra data on the wire and one for not enough data on the wire. > I think its useful to distinguish these cases, but the proposal makes > this non-conformant. I believe 4273 deals with the case in which the message size field in the GIOP header is actually different than the number of bytes received, and 4289 deals with what happens when a GIOP Fragment message with the "no more fragments to come" bit set is received when more data would be necessary to read off the expected data. In the latter case, the message size field in the GIOP header was correct, but the unmarshaler was expecting more data. Does that clarify the difference? I think you may have a disagreement with the 4273 resolution since it sounds like you would like two minor codes -- one for when the message size indicates fewer byte should be received than were actually received, and one for when the message size indicates more bytes should be received than were actually received. Perhaps I'm misunderstanding you, though, since it would be difficult to distinguish if requests are multiplexed over the same connection. - Everett X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from rtp-msg-core-1.cisco.com (161.44.11.97) by hobbit.omg.org asmtp(1.0) id 15283; Fri, 08 Jun 2001 09:29:14 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f58DMsX00410; Fri, 8 Jun 2001 09:22:54 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145]) by cannon.cisco.com (Mirapoint) with ESMTP id AAM02142 (AUTH pkyzivat); Fri, 8 Jun 2001 09:24:15 -0400 (EDT) Message-ID: <3B20D12B.3F87AB82@cisco.com> Date: Fri, 08 Jun 2001 09:20:43 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Everett Anderson CC: Interoperability RTF , Bob Kukura Subject: Re: interop vote question (fwd) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^@ I believe 4273 deals with the case in which the message size field in the > GIOP header is actually different than the number of bytes received, This makes no sense, at least for stream oriented transports like TCP/IP. If the GIOP header says N bytes, then there is essentially no way to get less, because you will simply keep reading until you get N bytes. The only way you would not get them is if the connection is closed first. > and > 4289 deals with what happens when a GIOP Fragment message with the > "no more > fragments to come" bit set is received when more data would be > necessary to > read off the expected data. In the latter case, the message size > field in > the GIOP header was correct, but the unmarshaler was expecting more > data. Paul Date: Fri, 08 Jun 2001 17:34:08 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: interop@omg.org CC: terutt@lucent.com Subject: fix for issue 4273 in wordsmith Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5YZd9)C9e9aYn!!?K#"! Status: RO I found another typo. The section 15 changes for 4273 should read: Add the following to the section on Request body 15.4.2.2: A MARSHAL exeption with standard minor code should be thrown when an incomplete non-fragmented request is received (i.e., the demarshalling engine detects an incomplete request). A MARSHAL exception with standard minor code should be thrown when extra data is received in a request (i.e. the demarshalling engine detects extra data at at the end of the message). Add the following to the section on Reply body 15.4.3.2: A MARSHAL exeption with standard minor code should be thrown when an incomplete non-fragmented reply message is received (i.e., the demarshalling engine detects an incomplete reply). A MARSHAL exception with standard minor code should be thrown when extra data is received in a reply (i.e. the demarshalling engine detects extra data at at the end of the message). -- ---------- Tom Rutt Tel: +1 732 949 7862 Global Strategic Standards Fax: +1 732 949 1192 Lucent Technologies terutt@lucent.com Date: Fri, 08 Jun 2001 14:55:58 -0700 From: Vijaykumar Natarajan Subject: Re: Interop Final Wordsmith before Vote 3 To: terutt@lucent.com Cc: interop@omg.org Message-id: <3B2149EE.B41F97CE@inprise.com> Organization: Borland Software Corporation MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <3B21422F.55EBC160@lucent.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_g+A51ScbijHxAaDOF2DVtw)" X-UIDL: :FM!!&8d!!aGY!!SgB!! Status: RO All, Comments on this: > ---------------------------------------------------------------------- > > Issue 4273: GIOP is silent about extra data in the Request or Reply > body (interop) As I mentioned earlier, detecting extra data at the end of a request or reply in the Java portable stub model is not possible w/o some hackery and even so, cannot be done before actually dispatching the request to the servant. ORBs should not be required to detect the overflow condition. > ---------------------------------------------------------------------- > > Issue 4289: GIOP issue : fragmented replies with exceptions (interop) > Resolution: To close without revision First, the above should say close w/ revision Second, the resolution still does not say what the server should do when it encounters a problem. I would propose inserting a third paragraph to section 15.4.9 before the other two. When a server detects an error after having marshaled earlier fragments for a reply, it will send an empty fragment with the fragments to follow bit turned off. Thanks, vijay [] vnatarajan4.vcf Date: Sun, 10 Jun 2001 08:05:02 +1000 (EST) From: Michi Henning To: Vijaykumar Natarajan cc: Interoperability RTF Subject: Re: Interop Final Wordsmith before Vote 3 In-Reply-To: <3B2149EE.B41F97CE@inprise.com> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-ID: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-UIDL: \WLe9E"Ee9%1od9klhd9 Status: RO On Fri, 8 Jun 2001, Vijaykumar Natarajan wrote: > All, > > Comments on this: > > > > ---------------------------------------------------------------------- > > > > Issue 4273: GIOP is silent about extra data in the Request or > Reply > > body (interop) > > As I mentioned earlier, detecting extra data at the end of a request > or > reply in the Java portable stub model is not possible w/o some > hackery > and even so, cannot be done before actually dispatching the request > to > the servant. ORBs should not be required to detect the overflow > condition. Why is it not possible to do this? Suppose the header says "1000 bytes" and the request has a single string param. If the string is only 10 bytes long, then the rest of the data obviously shouldn't be there. I don't understand why you couldn't detect this. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi Date: Sun, 10 Jun 2001 08:07:50 +1000 (EST) From: Michi Henning cc: terutt@lucent.com, interop@omg.org Subject: Re: Interop vote 1 In-Reply-To: <5.0.0.25.2.20010608205847.07bb6c00@postel> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Nn~e9k@6e9RBD!!MCWd9 Status: RO On Fri, 8 Jun 2001, Bill Beckwith wrote: > Objective Interface votes NO on issue 4273 and votes YES on all other > issues in vote 1. > > The change in issue 4273 would render all of our existing and > future products non-interoperable. Not an idea I support! Bill, can you explain how this would cause problems? Cheers, Michi. Date: Thu, 1 Nov 2001 17:08:49 +1000 (EST) From: Michi Henning To: Interoperability RTF Subject: Re: Interop vote 1 In-Reply-To: Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: olc!!K]B!!VEn!!5QSd9 On Fri, 26 Oct 2001, Michi Henning wrote: > attached are a few issues to vote on. Votes are due by Friday, 2 November. > Voting members of the RTF are listed at > > http://www.omg.org/techprocess/meetings/schedule/Interop_December_2000_RTF.html IONA votes no on 4334, and yes on all other issues. For 4273/4289, here is a friendly amendment: Change the proposed text: The count includes any alignment gaps and must match the size of the actual request parameters (plus any final padding bytes that may follow the parameters to have a fragment message terminate on an 8-byte boundary). To read: The count includes any alignment gaps and must match the size of the actual request parameters (plus any final padding bytes that may follow the parameters to have a non-final fragment message ^^^^^^^^^ terminate on an 8-byte boundary). This makes it more explicit that the 8-byte alignment requirement does not apply to the terminating fragment of a message. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi