CORBA3 — Chapters 13.10.1.9, and 13.10.1.12 -- issue

[3, Chapters 13.10.1.9, and 13.10.1.12] apparently indicate that both TCS-C
and TCS-W can be byte-oriented or non-byte-oriented.

Assume the following configurations for two communicating ORBs.

CNCS-C = windows-1252, SNCS-C = ISO-8859-1, and CCCS-C = SCCS-C =

.

The execution of the OMG code set negotiation algorithm [3, Chapter
13.10.2.6] in this case will result in the value of the TCS-C as UTF-16!

An IDL string will then be marshalled as UTF-16 encoded data, which may
have embedded single-octet NULLs. This point should be mentioned explicitly
somewhere in [3, Chapter 15.3.1.6], especially when IDL string data types
are not allowed to contain any embedded NULLs [3, Chapter 3.10.3.2]. [3,
Chapter 15.3.1.6] states that "Both the string length and contents include
a terminating null". If TCS-C is selected to be UTF-16, this 'null' should
be a null of two-octet size. [3, Chapter 15.3.1.6] should be explicit in
stating that the concrete representation of the 'terminating null' is
dependent on the TCS-C.

Similarly, for the following configuration
CNCS-W = UCS-2, SNCS-W = UCS-4, and CCCS-W = SCCS-W =

TCS-W will be selected as UTF-8!

Are these configurations valid? Regardless of the answer to this question,
[3, Chapters 13.10.1.9, and 13.10.1.12] should clarify the issue of the
orthogonality of TCS with respect to the byte-oriented and
non-byte-oriented code sets with appropriate examples.

see above