Issue 3014: padding at the end of a non-fragmented 1.2 request message (interop) Source: AT&T (Dr. Sai-Lai Lo, ) Nature: Clarification Severity: Summary: Suppose a GIOP 1.2 request message is sent for an operation with *no* argument. In this case the request body is empty because there is no argument. Furthermore, the whole request message is non-fragmented, i.e. the 2nd least significant bit of Flags in the request header is 0. Now if the request message header ends on a boundary which is not 8-byte aligned. Should the request message be extended with extra padding after the request message header to make the whole request message multiple of 8? I think the relevant statement is in section 15.4.1 (page 15-31): "For GIOP version 1.2, if the second least significant bit of Flags is 1, the sum the message_size value and 12 must be evenly divisible by 8" My intepretation of the statement is that the condition I just described does not meet this critera. Hence the message should not be padded to multiple of 8. It should just be ended with the end of the message header, just like previous GIOP versions. I'm asking for clarification on this issue because I'm seeing a different behaviour in another ORB implementation and would like to pre-empt any interoperability problem in future. Resolution: see above Revised Text: Actions taken: November 9, 1999: received issue May 13, 2002: closed issue Discussion: Rationale for Rejection Changes of this magnitude cannot be cannot be done by an RTF and require an RFP. End of Annotations:===== Date: Tue, 9 Nov 1999 19:21:33 GMT Message-Id: <199911091921.TAA25703@neem.uk.research.att.com> To: interop@omg.org Subject: padding at the end of a non-fragmented 1.2 request message From: Sai-Lai Lo Content-Type: text X-UIDL: $K\d9O%Ge9KTT!!*m""! Suppose a GIOP 1.2 request message is sent for an operation with *no* argument. In this case the request body is empty because there is no argument. Furthermore, the whole request message is non-fragmented, i.e. the 2nd least significant bit of Flags in the request header is 0. Now if the request message header ends on a boundary which is not 8-byte aligned. Should the request message be extended with extra padding after the request message header to make the whole request message multiple of 8? I think the relevant statement is in section 15.4.1 (page 15-31): "For GIOP version 1.2, if the second least significant bit of Flags is 1, the sum the message_size value and 12 must be evenly divisible by 8" My intepretation of the statement is that the condition I just described does not meet this critera. Hence the message should not be padded to multiple of 8. It should just be ended with the end of the message header, just like previous GIOP versions. I'm asking for clarification on this issue because I'm seeing a different behaviour in another ORB implementation and would like to pre-empt any interoperability problem in future. Sai-Lai Lo -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND Sender: jon@floorboard.com Message-ID: <38288D97.B031F769@floorboard.com> Date: Tue, 09 Nov 1999 13:09:43 -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: Sai-Lai Lo CC: interop@omg.org Subject: Re: padding at the end of a non-fragmented 1.2 request message References: <199911091921.TAA25703@neem.uk.research.att.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: S]5!!+5*e9La'!!3;U!! Sai-Lai Lo wrote: > > Suppose a GIOP 1.2 request message is sent for an operation with > *no* > argument. In this case the request body is empty because there is no > argument. > > Furthermore, the whole request message is non-fragmented, i.e. the > 2nd least significant bit of Flags in the request header is 0. Now > if the > request message header ends on a boundary which is not 8-byte > aligned. Should the request message be extended with extra padding > after the > request message header to make the whole request message multiple of > 8? > > I think the relevant statement is in section 15.4.1 (page 15-31): > > "For GIOP version 1.2, if the second least significant bit of Flags > is 1, > the sum the message_size value and 12 must be evenly divisible by 8" > > My intepretation of the statement is that the condition I just > described > does not meet this critera. Hence the message should not be padded > to > multiple of 8. It should just be ended with the end of the message > header, > just like previous GIOP versions. > > I'm asking for clarification on this issue because I'm seeing a > different > behaviour in another ORB implementation and would like to pre-empt > any > interoperability problem in future. The text you quote has to do with fragmenting, and since the example request you have detailed is not fragmented, the "padding" restriction does not apply. By the way, I wouldn't call this "padding" anyway. It is a restriction on the place where fragmentation may occur. No extra pad bytes are inserted into the message. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: sll@uk.research.att.com To: interop@omg.org CC: Jonathan Biggar Subject: Re: padding at the end of a non-fragmented 1.2 request message References: <199911091921.TAA25703@neem.uk.research.att.com> <38288D97.B031F769@floorboard.com> From: Sai-Lai Lo In-Reply-To: Jonathan Biggar's message of "Tue, 09 Nov 1999 13:09:43 -0800" Date: 10 Nov 1999 11:05:13 +0000 Message-ID: <3o66zad2ty.fsf@neem.uk.research.att.com> Lines: 34 User-Agent: Gnus/5.070099 (Pterodactyl Gnus v0.99) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: Ym_!!kFl!!Lkgd91!~!! >>>>> Jonathan Biggar writes: > The text you quote has to do with fragmenting, and since the example > request you have detailed is not fragmented, the "padding" > restriction > does not apply. > By the way, I wouldn't call this "padding" anyway. It is a restriction > on the place where fragmentation may occur. No extra pad bytes are > inserted into the message. I certainly agree with you that no extra byte are to be inserted at the end of the request message. I think the problem is that the developer of the ORB sees that "15.4.2.2 .. In GIOP version 1.2, the Request Body is always aligned on an 8-octet boundary." and just goes ahead and aligns the output stream after the request header to 8-octet aligned without looking at whether there is a request body to follow. Looks to me it is a bug. I'll report this to the developer as a bug unless someone on this list can point me to a different intepretation. Thanks. Sai-Lai -- Sai-Lai Lo S.Lo@uk.research.att.com AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com 24a Trumpington Street Tel: +44 1223 343000 Cambridge CB2 1QA Fax: +44 1223 313542 ENGLAND