Issue 3526: Nesting depth in valuetype end tags (interop) Source: (Mr. Simon C. Nash, ) Nature: Uncategorized Issue Severity: Summary: Section 15.3.4.5 contains an inconsistency in the description of how end tags for valuetypes are written. Consider the case where an unchunked value (V) contains a chunked value (CV1). Should the end tag for CV1 contain a nesting depth of -2 or -1? The following sentence in the spec seems to imply that the correct value is -2: > The end tag is a negative long whose value is the negation of the absolute > nesting depth of the value type ending at this point in the CDR stream. However the spec also says: > The outermost value type will always be terminated by an end tag with a > value of -1. which is not true if the end tag for CV1 is written as -2, since no end tag with a -1 value will be written. Proposed resolution: Delete the second above sentence from the spec. Resolution: Close with revision using alternative A above. Revised Text: Apply alternative A above to 15.3.4.5. Actions taken: March 31, 2000: received issue October 4, 2000: closed issue Discussion: There are two interpretations of the text. There are current implementations with both interpretations, which probably will not interoperate at the moment. This was put to vote to determine one of two possible alternative resolutions: Alternative a) In section 15.3.4.5, add the following sentence to the end of the bullet paragraph that starts "The end tag is a negative long whose value is the negation...": " Enclosing non-chunked valuetypes are not considered when determining the nesting depth. " Alternative b) Remove the statement " The outermost value type will always be terminated by an end tag with a value of -1. " and replace with the following sentence " Enclosing non-chunked valuetypes are considered when determining the nesting depth. " End of Annotations:===== Date: Fri, 31 Mar 2000 20:06:53 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org CC: interop@omg.org Subject: Nesting depth in valuetype end tags Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &<4e9'/0!!H0%e9TIOe9 Section 15.3.4.5 contains an inconsistency in the description of how end tags for valuetypes are written. Consider the case where an unchunked value (V) contains a chunked value (CV1). Should the end tag for CV1 contain a nesting depth of -2 or -1? The following sentence in the spec seems to imply that the correct value is -2: > The end tag is a negative long whose value is the negation of the absolute > nesting depth of the value type ending at this point in the CDR stream. However the spec also says: > The outermost value type will always be terminated by an end tag with a > value of -1. which is not true if the end tag for CV1 is written as -2, since no end tag with a -1 value will be written. Proposed resolution: Delete the second above sentence from the spec. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jon@corvette.floorboard.com Message-ID: <38E7FDF7.5E33A60A@floorboard.com> Date: Sun, 02 Apr 2000 19:12:07 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: issues@omg.org, interop@omg.org Subject: Re: Nesting depth in valuetype end tags References: <38E4F74D.41D647FC@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *A^d9fof!!Jm2e9jOTd9 Simon Nash wrote: > > Section 15.3.4.5 contains an inconsistency in the description of how > end tags > for valuetypes are written. Consider the case where an unchunked > value (V) > contains a chunked value (CV1). Should the end tag for CV1 contain > a nesting > depth of -2 or -1? > > The following sentence in the spec seems to imply that the correct > value is -2: > > > The end tag is a negative long whose value is the negation of the > absolute > > nesting depth of the value type ending at this point in the CDR > stream. > > However the spec also says: > > > The outermost value type will always be terminated by an end tag > with a > > value of -1. > > which is not true if the end tag for CV1 is written as -2, since no > end tag > with a -1 value will be written. > > Proposed resolution: > > Delete the second above sentence from the spec. There is an alternative reading, where only chunked valuetypes count. This would mean that a chunked valuetype nested in a non-chunked valuetype would have an end-tag of -1. I don't think it matters greatly which one is chosen, as long as we resolve the ambiguity. Perhaps we should take a vendor straw poll to see which interpretation is used by implementations today? If there is an strong majority in one direction, we might as well jump that way. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@corvette.floorboard.com Message-ID: <38EE4973.7AE0423@floorboard.com> Date: Fri, 07 Apr 2000 13:47:47 -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: Simon Nash CC: interop@omg.org Subject: Re: Nesting depth in valuetype end tags References: <38E4F74D.41D647FC@hursley.ibm.com> <38E7FDF7.5E33A60A@floorboard.com> <38EA1C1B.277F1120@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: cU6e9ViPe94/o!!U:O!! Simon Nash wrote: > > Jon, > I think it's harder to argue from the spec words for this > alternative reading. Again, I don't much care, as long as it's consistent. However, I don't think it is torturing the spec to read it such that the "nesting" that it is talking about only applies to chunked valuetypes, not any outer non-chunked valuetypes. > FWIW, IBM's ORB uses an end tag value of -2. Ok, that's one. Any other vendors care to chime in? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sat, 8 Apr 2000 07:20:31 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Simon Nash , interop@omg.org, Mark Spruiell Subject: Re: Nesting depth in valuetype end tags In-Reply-To: <38EE4973.7AE0423@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: e"~!!$"3!!eiXd9j_7e9 On Fri, 7 Apr 2000, Jonathan Biggar wrote: > Simon Nash wrote: > > > > Jon, > > I think it's harder to argue from the spec words for this > alternative reading. > > Again, I don't much care, as long as it's consistent. However, I > don't > think it is torturing the spec to read it such that the "nesting" > that > it is talking about only applies to chunked valuetypes, not any > outer > non-chunked valuetypes. > > > FWIW, IBM's ORB uses an end tag value of -2. > > Ok, that's one. Any other vendors care to chime in? We currently have an end tag of -1. 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: <391091A6.B66967FD@floorboard.com> Date: Wed, 03 May 2000 13:52:54 -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: Simon Nash CC: interop@omg.org Subject: Re: Plan for interop 2kplus future votes References: <390F5581.7466492C@floorboard.com> <39106434.C2FAFA8@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: TfY!!3'"e9l_=e9>CUd9 Simon Nash wrote: > >----------------------------------------------------------------------------- > > > Issue 3231: chunked value encoding: > > > > Chris Wood answered this issue thusly: > > > > All null values and indirections are stored as part of the containing > > chunk, therefore a chunk will never terminate with either of these > > values. > > > > See 15.3.4.5, two pages along, 3rd bullet point from start of section, > > > > "Chunks are never nested. ... For purposes of chunking, values encoded > > as indirections or null are treated as non-value data" > > > > This should be made clearer, put the last sentance as a bullet point > > before the "Chunks are never nested.." point, and change the bullet > > point to "With the exception of indirected or null values enclosed in a > > chunked value, chunks are never..." > > > > I think this is a clear enough proposal for a vote. > > > There was quite a bit of further debate of this wording after Chris made his > proposal. I do not agree with adding "With the exception of indirected or > null values enclosed in a chunked value," to the "Chunks are never nested" > sentence. This is because indirected or null values enclosed in a chunked > value are not chunks and are therefore not an exception to the rule about > non-nesting of chunks. Ok. > I am OK with Chris's other proposed change to move up the sentence "For > purposes of chunking, values encoded as indirections or null are treated as > non-value data" and make it a separate bullet point. Ok. Given the short time that we have left, I think it behoves all of us, when we take a poke at a proposal to make a concrete counter-proposal so to save time. Revised Proposal: In section 15.3.4.5, 3rd bullet point, move the sentence "For the purposes of chunking, values encoded as indirections or null are treated as non-value data." to its own bullet point before the current 3rd bullet. > >----------------------------------------------------------------------------- > > > Issue 3526: Nesting depth in valuetype end tags > > > > We have two ORB vendors (IBM and OOC) who have each chosen the opposite > > interpretation for the end tag value when a chunked valuetype is nested > > in a non-chunked valuetype. This breaks interoperability, and should > > probably be considered an urgent issue. > > > > Here is a proposal that we could vote on: > > > > In section 15.3.4.5, add the following sentence to the end of the bullet > > paragraph that starts "The end tag is a negative long whose value is the > > negation...": > > > > "Enclosing non-chunked valuetypes are not considered when determining > > the nesting depth." > > > Alternatively we could vote on my proposal, which was to remove the > statement "The outermost value type will always be terminated by an end > tag with a value of -1." To make this even clearer, we can replace this > by the sentence "Enclosing non-chunked valuetypes are considered when > determining the nesting depth." He who writes the proposal gets to put his own slant into it. :-) Since the existing standard already contains the statement that "the outermost valuetype will always be terminated by an end tag with a value of -1", I believe that the only valid way to reconcile this with the ability to nest a chunked valuetype in a non-chunked valuetype is to not count the non-chunked valuetype when determining the nesting level. I believe your interpretation is incorrect for CORBA 2.3.1, since it directly violates this statement, which is very explicit. I think my proposal is merely a clarification of the protocol, while yours is a change to it. Of course, you are free to disagree. :-) I suppose if you feel strongly enough, Tom can make the vote a choice between your proposal and mine. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 04 May 2000 00:02:10 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: interop@omg.org Subject: Re: Plan for interop 2kplus future votes References: <390F5581.7466492C@floorboard.com> <39106434.C2FAFA8@hursley.ibm.com> <391091A6.B66967FD@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _pDe9lnF!!23;!!2='e9 Jon, Jonathan Biggar wrote: > > Simon Nash wrote: > > >----------------------------------------------------------------------------- > > > > Issue 3231: chunked value encoding: > > > > > > Chris Wood answered this issue thusly: > > > > > > All null values and indirections are stored as part of the containing > > > chunk, therefore a chunk will never terminate with either of these > > > values. > > > > > > See 15.3.4.5, two pages along, 3rd bullet point from start of section, > > > > > > "Chunks are never nested. ... For purposes of chunking, values encoded > > > as indirections or null are treated as non-value data" > > > > > > This should be made clearer, put the last sentance as a bullet point > > > before the "Chunks are never nested.." point, and change the bullet > > > point to "With the exception of indirected or null values enclosed in a > > > chunked value, chunks are never..." > > > > > > I think this is a clear enough proposal for a vote. > > > > > There was quite a bit of further debate of this wording after Chris made his > > proposal. I do not agree with adding "With the exception of indirected or > > null values enclosed in a chunked value," to the "Chunks are never nested" > > sentence. This is because indirected or null values enclosed in a chunked > > value are not chunks and are therefore not an exception to the rule about > > non-nesting of chunks. > > Ok. > > > I am OK with Chris's other proposed change to move up the sentence "For > > purposes of chunking, values encoded as indirections or null are treated as > > non-value data" and make it a separate bullet point. > > Ok. Given the short time that we have left, I think it behoves all of > us, when we take a poke at a proposal to make a concrete > counter-proposal so to save time. > > Revised Proposal: > > In section 15.3.4.5, 3rd bullet point, move the sentence "For the > purposes of chunking, values encoded as indirections or null are treated > as non-value data." to its own bullet point before the current 3rd > bullet. > Fine with me. > > >----------------------------------------------------------------------------- > > > > Issue 3526: Nesting depth in valuetype end tags > > > > > > We have two ORB vendors (IBM and OOC) who have each chosen the opposite > > > interpretation for the end tag value when a chunked valuetype is nested > > > in a non-chunked valuetype. This breaks interoperability, and should > > > probably be considered an urgent issue. > > > > > > Here is a proposal that we could vote on: > > > > > > In section 15.3.4.5, add the following sentence to the end of the bullet > > > paragraph that starts "The end tag is a negative long whose value is the > > > negation...": > > > > > > "Enclosing non-chunked valuetypes are not considered when determining > > > the nesting depth." > > > > > Alternatively we could vote on my proposal, which was to remove the > > statement "The outermost value type will always be terminated by an end > > tag with a value of -1." To make this even clearer, we can replace this > > by the sentence "Enclosing non-chunked valuetypes are considered when > > determining the nesting depth." > > He who writes the proposal gets to put his own slant into it. :-) > > Since the existing standard already contains the statement that "the > outermost valuetype will always be terminated by an end tag with a value > of -1", I believe that the only valid way to reconcile this with the > ability to nest a chunked valuetype in a non-chunked valuetype is to not > count the non-chunked valuetype when determining the nesting level. I > believe your interpretation is incorrect for CORBA 2.3.1, since it > directly violates this statement, which is very explicit. > > I think my proposal is merely a clarification of the protocol, while > yours is a change to it. Of course, you are free to disagree. :-) > I do disagree. The intention from day 1 was that this number be an absolute nesting depth. Indeed the phrase "absolute nesting depth" is used elsewhere in the paragraph. What happened was that the chunked encoding was made optional, and this made the paragraph self-inconsistent. Unfortunately no-one noticed the inconsistency until recently. > I suppose if you feel strongly enough, Tom can make the vote a choice > between your proposal and mine. > I feel very strongly, since making this change to our implementation would create very nasty migration compatibility issues for our customers. So I request that Tom makes this vote a choice between the two alternative resolutions. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb