Issue 5941: valuetype fragmentation ambiguous (corba-rtf)
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity: 
Summary: Although I now think I know the intent of the spec, its is ambiguous if not plain wrong with respect to valuetype fragmentation.


In particular 15.3.4.6:


Bullet 1 says:


"End tags, chunk size tags, and value tags are encoded using non-overlapping ranges
so that the unmarshaling code can tell after reading each chunk whether:
• another chunk follows (positive tag).
• one or multiple value types are ending at a given point in the stream (negative
tag).
• a nested value follows (special large positive tag)."


Bullet 3 says:


"• For the purposes of chunking, values encoded as indirections or null are treated as
non-value data."


And the pseudo-BNF says:


"(1) <value> ::= <value_tag> [ <codebase_URL> ]
[ <type_info> ] <state>
| <value_ref>
(2) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
(3) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
(4) <type_info> ::= <rep_ids> | <repository_id>
(5) <state> ::= <octets> |<value_data>* [ <end_tag> ]
(6) <value_data> ::= <value_chunk> | <value>"


Now clearly the implication of bullet 1 is that an indirection or null must appear  inside a chunk in a chunked encoding, otherwise you would be able to see the value 0 or -1 after a chunk and the -1 in particular could mean an end tag or an indirection. However the possible implication of bullet 3 and the BNF (note the use of "value data") is that nulls and indirections are values and thus must appear outside of chunks. Clearly the former interpretation is the correct one otherwise anarchy ensues.


So I propose that we change the 3rd bullet to say:


"For the purposes of chunking, values encoded as indirections or null are treated as
if they were not values and therefore must always appear inside a chunk when a chunked encoding is in effect."


and then change the BNF to say:


"(1) <value> ::= <concrete_value> | <value_ref>
(2) <concrete_value> ::= <value_tag> [ <codebase_URL> ]
[ <type_info> ] <state>
(3) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
(4) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
(5) <type_info> ::= <rep_ids> | <repository_id>
(6) <state> ::= <octets> |<value_data>* [ <end_tag> ]
(7) <value_data> ::= <value_chunk> | <concrete_value>"


etc

Resolution: 
Revised Text: 
Actions taken:
May 23, 2003: received issue
April 11, 2012: Deferred
Discussion: 

End of Annotations:=====
X-Sender: andyp@san-francisco.beasys.com 
X-Mailer: QUALCOMM Windows Eudora Version 5.0 
Date: Fri, 23 May 2003 17:10:21 -0700 
To: corba-rtf@omg.org, issues@omg.org 
From: Andy Piper <andyp@bea.com> 
Subject: valuetype fragmentation ambiguous 
X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h4O0KF4g018313 


Although I now think I know the intent of the spec, its is ambiguous if not plain wrong with respect to valuetype fragmentation.


In particular 15.3.4.6:


Bullet 1 says:


"End tags, chunk size tags, and value tags are encoded using non-overlapping ranges
so that the unmarshaling code can tell after reading each chunk whether:
    another chunk follows (positive tag).
    one or multiple value types are ending at a given point in the stream (negative
tag).
    a nested value follows (special large positive tag)."


Bullet 3 says:


"    For the purposes of chunking, values encoded as indirections or null are treated as
non-value data."


And the pseudo-BNF says:


"(1) <value> ::= <value_tag> [ <codebase_URL> ]
[ <type_info> ] <state>
| <value_ref>
(2) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
(3) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
(4) <type_info> ::= <rep_ids> | <repository_id>
(5) <state> ::= <octets> |<value_data>* [ <end_tag> ]
(6) <value_data> ::= <value_chunk> | <value>"


Now clearly the implication of bullet 1 is that an indirection or null must appear  inside a chunk in a chunked encoding, otherwise you would be able to see the value 0 or -1 after a chunk and the -1 in particular could mean an end tag or an indirection. However the possible implication of bullet 3 and the BNF (note the use of "value data") is that nulls and indirections are values and thus must appear outside of chunks. Clearly the former interpretation is the correct one otherwise anarchy ensues.


So I propose that we change the 3rd bullet to say:


"For the purposes of chunking, values encoded as indirections or null are treated as
if they were not values and therefore must always appear inside a chunk when a chunked encoding is in effect."


and then change the BNF to say:


"(1) <value> ::= <concrete_value> | <value_ref>
(2) <concrete_value> ::= <value_tag> [ <codebase_URL> ]
[ <type_info> ] <state>
(3) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
(4) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
(5) <type_info> ::= <rep_ids> | <repository_id>
(6) <state> ::= <octets> |<value_data>* [ <end_tag> ]
(7) <value_data> ::= <value_chunk> | <concrete_value>"


etc


andy


Date: Sat, 24 May 2003 22:56:30 +0100 
From: Simon Nash <nash@hursley.ibm.com> 
Organization: IBM 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) 
X-Accept-Language: en 
To: Andy Piper <andyp@bea.com> 
CC: corba-rtf@omg.org 
Subject: Re: valuetype fragmentation ambiguous 
X-MIME-Autoconverted: from 8bit to quoted-printable by sp15en17.hursley.ibm.com id WAA169200 
X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h4OM1E4g020612 


Andy,
I agree with your interpretation of the current spec and with
your proposed clarifications.


   Simon


Andy Piper wrote:
> 
> Although I now think I know the intent of the spec, its is ambiguous if not
> plain wrong with respect to valuetype fragmentation.
> 
> In particular 15.3.4.6:
> 
> Bullet 1 says:
> 
> "End tags, chunk size tags, and value tags are encoded using
> non-overlapping ranges
> so that the unmarshaling code can tell after reading each chunk whether:
>     another chunk follows (positive tag).
>     one or multiple value types are ending at a given point in the stream
> (negative
> tag).
>     a nested value follows (special large positive tag)."
> 
> Bullet 3 says:
> 
> "    For the purposes of chunking, values encoded as indirections or null are
> treated as
> non-value data."
> 
> And the pseudo-BNF says:
> 
> "(1) <value> ::= <value_tag> [ <codebase_URL> ]
> [ <type_info> ] <state>
> | <value_ref>
> (2) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
> (3) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
> (4) <type_info> ::= <rep_ids> | <repository_id>
> (5) <state> ::= <octets> |<value_data>* [ <end_tag> ]
> (6) <value_data> ::= <value_chunk> | <value>"
> 
> Now clearly the implication of bullet 1 is that an indirection or null must
> appear  inside a chunk in a chunked encoding, otherwise you would be able
> to see the value 0 or -1 after a chunk and the -1 in particular could mean
> an end tag or an indirection. However the possible implication of bullet 3
> and the BNF (note the use of "value data") is that nulls and indirections
> are values and thus must appear outside of chunks. Clearly the former
> interpretation is the correct one otherwise anarchy ensues.
> 
> So I propose that we change the 3rd bullet to say:
> 
> "For the purposes of chunking, values encoded as indirections or null are
> treated as
> if they were not values and therefore must always appear inside a chunk
> when a chunked encoding is in effect."
> 
> and then change the BNF to say:
> 
> "(1) <value> ::= <concrete_value> | <value_ref>
> (2) <concrete_value> ::= <value_tag> [ <codebase_URL> ]
> [ <type_info> ] <state>
> (3) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
> (4) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
> (5) <type_info> ::= <rep_ids> | <repository_id>
> (6) <state> ::= <octets> |<value_data>* [ <end_tag> ]
> (7) <value_data> ::= <value_chunk> | <concrete_value>"
> 
> etc
> 
> andy


-- 
Simon C Nash   IBM Distinguished Engineer
Hursley Park, Winchester, UK   nash@hursley.ibm.com
Tel. +44-1962-815156   Fax +44-1962-818999