Issue 3231: chunked value encoding: (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: a chunk can be followed by: 1. a new chunk (starting with its size tag) (1 <= chunk_size_tag < 0x7fffff00 2. a new value (value_tag | 0 | value_ref) (0x7fffff00 <= value_tag <= 0x7fffffff) (valueref = 0xffffffff) 3. an end tag (0x80000000 <= end_tag <= 0xffffffff) A value indirection and a "top-level" end tag, both have the same tag (0xffffffff). Consequently, the 0xffffffff tag marks the end of the current value but it is not clear whether or not a new value (indirection) has started. An example where this situation occurs is a ring buffer that is chunked encoded. Resolution: to close with revision Revised Text: n 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. Actions taken: January 18, 2000: received issue October 4, 2000: closed issue Discussion: The following was extracted from Email discusson on this Issue > > > > 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..." > > > > This is a clear enough proposal for a vote. > > > There was quite a bit of further debate of this wording after this initial > 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. > I am OK with the 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. End of Annotations:===== Date: Tue, 18 Jan 2000 12:21:00 -0500 (EST) Message-Id: <200001181721.MAA09358@emerald.omg.org> From: stefanr@segue.at To: juergen@omg.org, web-incoming@omg.org Subject: Issue Report Content-Type: text X-UIDL: l<)e9]ZUd9n[-!!e9H!! Name: Stefan Reiner Company: Segue Software Inc. mailFrom: stefanr@segue.at Notification: Yes Specification: CORBA/IIOP Specification Section: 15 / Fragmentation Formal #: 99-10-07 Version: 2.3.1 Revision_Date: 10/07/99 Page: 15-19-21 Nature: Revision Severity: Significant full_desc: chunked value encoding: a chunk can be followed by: 1. a new chunk (starting with its size tag) (1 <= chunk_size_tag < 0x7fffff00 2. a new value (value_tag | 0 | value_ref) (0x7fffff00 <= value_tag <= 0x7fffffff) (valueref = 0xffffffff) 3. an end tag (0x80000000 <= end_tag <= 0xffffffff) A value indirection and a "top-level" end tag, both have the same tag (0xffffffff). Consequently, the 0xffffffff tag marks the end of the current value but it is not clear whether or not a new value (indirection) has started. An example where this situation occurs is a ring buffer that is chunked encoded. submit: Submit Issue Report From: Chris Wood To: "'interop@omg.org'" , "'stefanr@segue.at'" Subject: Issue 3231: chunked value encoding Date: Mon, 27 Mar 2000 13:29:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: lp5e9Q^a!!mC#"!B#7!! 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 it to "With the exception of indirected or null values enclosed in a chunked value, chunks are never..." -- Chris Wood IT Innovation Centre 2 Venture Road Chilworth Science Park Southampton, SO16 7NP, UK tel: +44 23 8076 0834 fax: +44 23 8076 0833 mailto:cww@it-innovation.soton.ac.uk http://www.it-innovation.soton.ac.uk/ Date: Mon, 27 Mar 2000 14:41:44 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Chris Wood CC: "'interop@omg.org'" , "'stefanr@segue.at'" Subject: Re: Issue 3231: chunked value encoding References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: p/$!!<[Ae9(p7e9N@3e9 Chris, Chris Wood wrote: > > All null values and indirections are stored as part of the > containing chunk, > therefore a chunk will never terminate with either of these values. > Chunks can terminate at (almost) any point, so they may terminate > either immediately before or immediately after these values. I think you > mean that a chunk does not have to terminate because 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 it to "With the exception > of indirected or null values enclosed in a chunked value, chunks are > never..." > I don't think this makes things clearer. Indirected or null values enclosed in a chunked value are not nested chunks (they are not chunks at all), so it is unnecessary and misleading to state this as an exception to the "chunks are never nested" rule. 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 From: Chris Wood To: "'Simon Nash'" Cc: "'interop@omg.org'" , "'stefanr@segue.at'" Subject: RE: Issue 3231: chunked value encoding Date: Mon, 27 Mar 2000 16:30:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 2`Ge9YENe9o!a!!/^#"! > > All null values and indirections are stored as part of the > containing chunk, > > therefore a chunk will never terminate with either of these > values. > > > Chunks can terminate at (almost) any point, so they may > terminate either > immediately before or immediately after these values. I > think you mean that > a chunk does not have to terminate because of these values. It's true that the chunk can terminate at any point, but as i interpret things at that point there is either an end tag (negative) new value header tag (large positive) or a new chunk begins with a size tag (positive). If the chunk terminates immediatly before, say for example, a null value, the null value will move 4 bytes downstream and a continuation chunk header gets inserted. ie: valuetype ValCompBase {}; valuetype Val { ... }; valuetype ValComp : truncatable ValCompBase { Val val1; Val val2; }; we encode a ValComp with both val1 and val2 being null. It's state chunk could look like: (len) (val1) (val2) (terminates) 00000008 00000000 00000000 FFFFFFFF or alternativly: (len) (val1) (cont) (val2) (terminates) 00000004 00000000 00000004 00000000 FFFFFFFF the second one here has been fragmented over two chunks. Now say val2 is set to some value, the simplest encoding looks like (len) (val1) (val2) (state-begins) (terminates all) 00000004 00000000 7FFFFFnn ... 00000004 xxxxxxxx FFFFFFFF or an alternative: (len) (val1) (val2) (state-begins) (terminates all) 00000004 00000000 7FFFFFnn ... 00000004 xxxxxxxx FFFFFFFE FFFFFFFF essentialy what we have are two types of chunks, value header chunks and value state chunks. Neither is ever nested, state chunks always follow value headers or other state chunks are terminated with a negative value. for example here's some legal chunk sequences: H=header with chunk bit set: h=header without chunk bit set: S=state chunk 1,2... = termination value h1 (simplest) HS1 (chunked) hHS1 (enclosed value) hHSSS1 (enclosed value, lots of state) hHS21 (enclosed value, full terminating) HHS1 * (enclosed value, topmost has no state other than the enclosed value) HSHS21 (enclosed value, some state before enclosed value) HSHS2S1 (enclosed value, some state before and after enclosed value) hH1 * (the enclosed value has empty state) hH21 * (the enclosed value has empty state) * see below, more issues. > I don't think this makes things clearer. Indirected or null > values enclosed > in a chunked value are not nested chunks (they are not chunks > at all), so it > is unnecessary and misleading to state this as an exception > to the "chunks are never nested" rule. It's not an exception to the 'chunks are never nested' it's an exception to 'nested values are always chunked', chunks are still never nested, but null values and indirections do not introduce a new chunk. This brings me to two things i think need clarification: It's important to always arrive at the value tag of all encoded values even when the containing valuetype is truncated. This is because these skipped over values may be indirected to later in the buffer. If the value tags are not visited then an indirection table will not contain their values, and the forward reading charicteristics of the encoding are destroyed, thus the entire buffer would have to be stored. An alternative interpretation of the spec is that the header data for an enclosed value always appears within the enclosing state chunk, and state chunks ane the chunks which are 'never nested' rather than both state and value header chunks. The problem with this is that if an enclosing value is truncatable and the stuff that's skipped over contains a value which is indirected to later in the buffer then you would have to skip backwards through the buffer to decode that value. Another problem is with encoding a nested value without any state information (ValCompBase for example). You can't have a zero length chunk for the state data and you must use a chunked encoding, so what do you do? A similar condition occours when a valuetype has another valuetype as it's first state member, the state chunk of the enclosing valuetype is zero length. My feeling is that what would possibly be a zero length state chunk should get removed from the marshalled data entirely, an end tag or a new value header appears straight away instead of a chunk opening, implying an empty state chunk. Sender: jbiggar@corvette.floorboard.com Message-ID: <38DFD11C.50656E93@floorboard.com> Date: Mon, 27 Mar 2000 13:22:36 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Chris Wood CC: "'Simon Nash'" , "'interop@omg.org'" , "'stefanr@segue.at'" Subject: Re: Issue 3231: chunked value encoding References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: OMjd9e?O!!AkWd9PbS!! Chris Wood wrote: > for example here's some legal chunk sequences: > H=header with chunk bit set: > h=header without chunk bit set: > S=state chunk > 1,2... = termination value > > h1 (simplest) > HS1 (chunked) > hHS1 (enclosed value) > hHSSS1 (enclosed value, lots of state) > hHS21 (enclosed value, full terminating) > > HHS1 * (enclosed value, topmost has no state other than the > enclosed > value) > HSHS21 (enclosed value, some state before enclosed value) > HSHS2S1 (enclosed value, some state before and after enclosed > value) > > hH1 * (the enclosed value has empty state) > hH21 * (the enclosed value has empty state) I read the valuetype encoding documentation differently. You indicate that all valuetypes must have an end-tag, whether chunked or not. I think the spec calls only for end-tags on chunked valuetypes, not non-chunked valuetypes. > This brings me to two things i think need clarification: > > It's important to always arrive at the value tag of all encoded > values even > when the containing valuetype is truncated. This is because these > skipped > over values may be indirected to later in the buffer. If the value > tags are > not visited then an indirection table will not contain their > values, and > the forward reading charicteristics of the encoding are destroyed, > thus the > entire buffer would have to be stored. Right. Either you have to unmarshal all of the valuetypes in the skipped portions of the parent valuetype, or else you need to keep the marshalled data around until you are sure it can't be referenced again (effectively the end of the request.) > An alternative interpretation of the spec is that the header data for an > enclosed value always appears within the enclosing state chunk, and state > chunks ane the chunks which are 'never nested' rather than both state and > value header chunks. The problem with this is that if an enclosing value is > truncatable and the stuff that's skipped over contains a value which is > indirected to later in the buffer then you would have to skip backwards > through the buffer to decode that value. Although I can see that some might read the spec this way, the requirement that valuetype header "chunks", state chunks, and end tags all have different allocated spaces withing the range of a CORBA long. (Which brings up another question: what happens when the nesting level of valuetypes goes beyond 255? The encoding breaks at this point.) The separate allocated spaces is a very strong indicator that valuetype headers should not be encoded as part of a parent valuetype's state chunk. Also, the valuetype encoding "grammar" (15.3.4.7) shows that the components of a chunked valuetype's state is either a chunk or another valuetype. > Another problem is with encoding a nested value without any state > information (ValCompBase for example). You can't have a zero length > chunk > for the state data and you must use a chunked encoding, so what do > you do? If valuetype headers are not part of the parent valuetype's state chunk, then I don't think this is a problem. You encode the valuetype as a header (with chunking), followed immediately by an end-tag. > A similar condition occours when a valuetype has another valuetype as it's > first state member, the state chunk of the enclosing valuetype is zero > length. This is also not a problem if valuetype headers aren't part of the parent's state chunk. > My feeling is that what would possibly be a zero length state chunk should > get removed from the marshalled data entirely, an end tag or a new value > header appears straight away instead of a chunk opening, implying an empty > state chunk. I think the valuetype encoding "grammar" in 15.3.4.7 is wrong. The rule for should be: ::= |* [ ] to allow for zero value_chunks. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 28 Mar 2000 14:27:11 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar CC: Chris Wood , "'interop@omg.org'" , "'stefanr@segue.at'" Subject: Re: Issue 3231: chunked value encoding References: <38DFD11C.50656E93@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: W9P!!5(=!!"Qh!!,AQ!! Jon, Jonathan Biggar wrote: > > Chris Wood wrote: > > for example here's some legal chunk sequences: > > H=header with chunk bit set: > > h=header without chunk bit set: > > S=state chunk > > 1,2... = termination value > > > > h1 (simplest) > > HS1 (chunked) > > hHS1 (enclosed value) > > hHSSS1 (enclosed value, lots of state) > > hHS21 (enclosed value, full terminating) > > > > HHS1 * (enclosed value, topmost has no state other than the > enclosed > > value) > > HSHS21 (enclosed value, some state before enclosed value) > > HSHS2S1 (enclosed value, some state before and after enclosed > value) > > > > hH1 * (the enclosed value has empty state) > > hH21 * (the enclosed value has empty state) > > I read the valuetype encoding documentation differently. You > indicate > that all valuetypes must have an end-tag, whether chunked or not. I > think the spec calls only for end-tags on chunked valuetypes, not > non-chunked valuetypes. > I agree. The grammar says that is either (not > chunked) or + [ ] (chunked). > > This brings me to two things i think need clarification: > > > > It's important to always arrive at the value tag of all encoded > values even > > when the containing valuetype is truncated. This is because these > skipped > > over values may be indirected to later in the buffer. If the value > tags are > > not visited then an indirection table will not contain their > values, and > > the forward reading charicteristics of the encoding are destroyed, > thus the > > entire buffer would have to be stored. > > Right. Either you have to unmarshal all of the valuetypes in the > skipped portions of the parent valuetype, or else you need to keep > the > marshalled data around until you are sure it can't be referenced > again > (effectively the end of the request.) > > > An alternative interpretation of the spec is that the header data > for an > > enclosed value always appears within the enclosing state chunk, > and state > > chunks ane the chunks which are 'never nested' rather than both > state and > > value header chunks. The problem with this is that if an enclosing > value is > > truncatable and the stuff that's skipped over contains a value > which is > > indirected to later in the buffer then you would have to skip > backwards > > through the buffer to decode that value. > > Although I can see that some might read the spec this way, the > requirement that valuetype header "chunks", state chunks, and end > tags > all have different allocated spaces withing the range of a CORBA > long. > (Which brings up another question: what happens when the nesting > level > of valuetypes goes beyond 255? The encoding breaks at this point.) > The limit is 2**31, not 255. Here are the ranges in ascending order: 0x80000000 - 0xffffffff end tags 0x00000000 reserved 0x00000001 - 0x7ffffeff chunk lengths 0x7fffff00 - 0x7fffffff header tags > The > separate allocated spaces is a very strong indicator that valuetype > headers should not be encoded as part of a parent valuetype's state > chunk. Also, the valuetype encoding "grammar" (15.3.4.7) shows that the > components of a chunked valuetype's state is either a chunk or another > valuetype. > Right, and includes but not . This rules out the possibility of value headers being part of chunks. > > Another problem is with encoding a nested value without any state > > information (ValCompBase for example). You can't have a zero > length chunk > > for the state data and you must use a chunked encoding, so what do > you do? > > If valuetype headers are not part of the parent valuetype's state > chunk, > then I don't think this is a problem. You encode the valuetype as a > header (with chunking), followed immediately by an end-tag. > > > A similar condition occours when a valuetype has another valuetype > as it's > > first state member, the state chunk of the enclosing valuetype is > zero > > length. > > This is also not a problem if valuetype headers aren't part of the > parent's state chunk. > > > My feeling is that what would possibly be a zero length state > chunk should > > get removed from the marshalled data entirely, an end tag or a new > value > > header appears straight away instead of a chunk opening, implying > an empty > > state chunk. > > I think the valuetype encoding "grammar" in 15.3.4.7 is wrong. The > rule > for should be: > > ::= |* [ ] > > to allow for zero value_chunks. > Yes, I agree. 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: jbiggar@corvette.floorboard.com Message-ID: <38E1335D.68E6F9FF@floorboard.com> Date: Tue, 28 Mar 2000 14:34:05 -0800 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: Chris Wood , "'interop@omg.org'" , "'stefanr@segue.at'" Subject: Re: Issue 3231: chunked value encoding References: <38DFD11C.50656E93@floorboard.com> <38E0B32F.C21E785A@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: EE"!!Ip=!!$)Ee9jg+e9 Simon Nash wrote: > > Although I can see that some might read the spec this way, the > > requirement that valuetype header "chunks", state chunks, and end > tags > > all have different allocated spaces withing the range of a CORBA > long. > > (Which brings up another question: what happens when the nesting > level > > of valuetypes goes beyond 255? The encoding breaks at this > point.) > > > The limit is 2**31, not 255. Here are the ranges in ascending > order: > 0x80000000 - 0xffffffff end tags > 0x00000000 reserved > 0x00000001 - 0x7ffffeff chunk lengths > 0x7fffff00 - 0x7fffffff header tags Right you are. I was looking at the wrong part of the grammar. > > I think the valuetype encoding "grammar" in 15.3.4.7 is wrong. The rule > > for should be: > > > > ::= |* [ ] > > > > to allow for zero value_chunks. > > > Yes, I agree. Another issue, then. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Chris Wood To: "'Simon Nash'" , Jonathan Biggar Cc: Chris Wood , "'interop@omg.org'" , "'stefanr@segue.at'" Subject: RE: Issue 3231: chunked value encoding Date: Tue, 4 Apr 2000 10:00:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: L4p!!d33e9S^:e9_jgd9 > > > for example here's some legal chunk sequences: > > > H=header with chunk bit set: > > > h=header without chunk bit set: > > > S=state chunk > > > 1,2... = termination value > > > > > > h1 (simplest) > > > HS1 (chunked) > > > hHS1 (enclosed value) > > > hHSSS1 (enclosed value, lots of state) > > > hHS21 (enclosed value, full terminating) > > > > > > HHS1 * (enclosed value, topmost has no state other > > > than the enclosed value) > > > HSHS21 (enclosed value, some state before enclosed value) > > > HSHS2S1 (enclosed value, some state before and after > > > enclosed value) > > > > > > hH1 * (the enclosed value has empty state) > > > hH21 * (the enclosed value has empty state) > > > > I read the valuetype encoding documentation differently. > > You indicate > > that all valuetypes must have an end-tag, whether chunked or not. > I > > think the spec calls only for end-tags on chunked valuetypes, not > > non-chunked valuetypes. > > > I agree. The grammar says that is either > (not chunked) > or + [ ] (chunked). Yes you're right. My mistake. The above table needs some encodings changed: h1 changed to h hHS21 removed hH21 removed hHS2 added The last one could be a bit of an implementation gotcha, you could expect all value encodings to end with -1. 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