CORBA24 — interop issue: CodeSets service context in GIOP 1.0 request

Well, a new Java release is upon us, and with it comes a new CORBA
implementation. I'm trying Java 2 SE 1.3 CORBA clients against an ILU
2.0beta1 CosNaming server, and we find that the Java ORB cannot
reliably connect to the server. Why not? First, we must analyze the
IOR provided by the ILU service:

IOR:000000000000002849444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578743A312E300000000002000000000000002F0001000000000016776174736F6E2E706172632E7865726F782E636F6D00270F0000000B4E616D6553657276696365000000000100000024000100000000000100000001000000140001001800010001000000000001010000000000

If we look at this (those who've received it un-truncated) we find that it advertises the following:

_IIOP_ParseCDR: byte order BigEndian, repository id <IDL:omg.org/CosNaming/NamingContext:1.0>, 2 profiles
_IIOP_ParseCDR: profile 1 is 47 bytes, tag 0 (INTERNET), BigEndian byte order
_IIOP_ParseCDR: profile 2 is 36 bytes, tag 1 (MULTIPLE COMPONENT), BigEndian byte order
(iiop.c:parse_IIOP_Profile): bo=BigEndian, version=1.0, hostname=watson.parc.xerox.com, port=9999, object_key=<NameService>
(iiop.c:parse_IIOP_Profile): encoded object key is <NameService>
(iiop.c:parse_IIOP_Profile): non-native cinfo is <iiop_1_0_1_NameService@tcp_watson.parc.xerox.com_9999>
(iiop.c:parse_MultiComponent_Profile): profile contains 1 component
(iiop.c:parse_MultiComponent_Profile): component 1 of type 1, 20 bytes
(iiop.c:parse_MultiComponent_Profile): native codeset for SHORT CHARACTER is 00010001, with 0 converters
(iiop.c:parse_MultiComponent_Profile): native codeset for CHARACTER is 00010100, with 0 converters

That is, there's a vanilla Internet profile (bo=BigEndian,
version=1.0, hostname=watson.parc.xerox.com, port=9999,
object_key=<NameService>), plus a Multicomponent profile, noting that
the ILU ORB's native codesets are Latin-1 and UCS-2.

OK, great. Now we get the first message from the Java ORB:

0000 47 49 4f 50 01 00 00 00 00 00 01 00 GIOP........
0000 00 00 00 02 00 00 00 01 00 00 00 0c 00 00 00 00 ................
0010 00 01 00 20 00 01 01 00 00 00 00 06 00 00 00 90 ... ............
0020 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
0030 6f 72 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 org/SendingConte
0040 78 74 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 xt/CodeBase:1.0.
0050 00 00 00 01 00 00 00 00 00 00 00 54 00 01 01 00 ...........T....
0060 00 00 00 0c 31 33 2e 31 2e 31 30 33 2e 36 38 00 ....13.1.103.68.
0070 0e e9 00 00 00 00 00 18 af ab ca fe 00 00 00 02 ................
0080 67 d5 93 95 00 00 00 08 00 00 00 00 00 00 00 00 g...............
0090 00 00 00 01 00 00 00 01 00 00 00 14 00 00 00 00 ................
00a0 00 01 00 20 00 00 00 00 00 01 01 00 00 00 00 00 ... ............
00b0 00 00 00 05 01 00 00 00 00 00 00 07 53 79 6e 65 ............Syne
00c0 72 67 79 00 00 00 00 06 5f 69 73 5f 61 00 00 00 rgy....._is_a...
00d0 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
00e0 6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 org/CosNaming/Na
00f0 6d 69 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 mingContext:1.0.

Note that we are seeing a CodeSets service context, even though the
request is GIOP 1.0. The service context specifies a TCS-C of ASCII,
and a TCS-W of UCS-2.

The question is, what should the server do with it?

First of all, there seems to be no way in which the algorithm in
section 13.2.7.6 can result in the TCS-C specified in the service
context. So perhaps this bug should be detected and signalled back to
the sending ORB. How? Using CODESET_INCOMPATIBLE might make sense,
but that really doesn't flag the bug in the client-side implementation
of the codesets determination algorithm. Perhaps a straight
COMM_FAILURE would be better. Opinions?

Secondly, since this is GIOP 1.0, the client could reasonably ignore
the service context, and go ahead with using its default codeset
(Latin-1). However, to do so risks comm failure down the line, as
ASCII (the TCS-C assumed by the client) does not permit many Latin-1
characters. It seems better to flag this situation up front.

close with revision. See below