Can OmniORB 2.2.0 handle IIOP contexts?

[Bill Janssen]

In testing ILU 2.0alpha11 against OmniORB 2.2.0, I find that sending a
context in a request (a new context, the CODE_SETS context added by
the type extensions RFP) causes OmniORB to respond with a
MessageError.  My reading of the IIOP spec is that an ORB should
discard unrecognized contexts, but not abort, so this looks like an
OmniORB bug.  Here's a trace of an ILU client running against the
OmniORB echo service:

% python eg2_clt.py 'IOR:00fff3240000000d49444c3a4563686f3a312e30007a58c0000000010000000000000028000100000000000c31332e312e3130312e323600a06020200000000c3439a21d2cb5d17800000001'
ILU version 2.0alpha11.  Copyright 1990-1996 Xerox Corporation.
------------------------------------------------------------
Configuration info: big-endian, is BSD, is POSIX, Solaris 2 threads, variant, size_t=size_t,
  char=1s, short=2, int=4, long=4, void *=4, fnptr=4, long long=8, long double=16, enum=4,
  arch=sparc-sun-solaris2.5.1, compiler="/import/sunpro-4.0/SUNWspro/bin/cc -xs -Xt -v",
  ANSI C lib=" -lm", sys aux libs=" -lsocket -lnsl -lthread",
  protocols = sunrpc courier iiop http javarmi, transports = inmem tcp sunrpcrm w3mux batching,
  binding via ILU service on watson.parc.xerox.com:12003
------------------------------------------------------------
ilu_SetDebugLevel:  setting debug mask from 0x0 to 0x20404
_ilu_IIOP_ParseIOR:  byte order BigEndian, repository id <IDL:Echo:1.0>, 1 profile
_ilu_IIOP_ParseIOR:  profile 1 is 40 bytes, tag 0 (INTERNET), BigEndian byte order
(iiop.c:parse_IIOP_Profile):  bo=BigEndian, version=1.0, hostname=13.1.101.26, port=41056, object_key=<49..,..x....>
(iiop.c:parse_IIOP_Profile):  encoded object key is <49%A2%1D%2C%B5%D1x%00%00%00%01>
(iiop.c:parse_IIOP_Profile):  non-native cinfo is <iiop_1_0_1_49%25A2%251D%252C%25B5%25D1x%2500%2500%2500%2501@tcp_13.1.101.26_41056>
_ilu_IIOP_ParseIOR:  byte order BigEndian, repository id <IDL:Echo:1.0>, 1 profile
_ilu_IIOP_ParseIOR:  profile 1 is 40 bytes, tag 0 (INTERNET), BigEndian byte order
(iiop.c:parse_IIOP_Profile):  bo=BigEndian, version=1.0, hostname=13.1.101.26, port=41056, object_key=<49..,..x....>
(iiop.c:parse_IIOP_Profile):  encoded object key is <49%A2%1D%2C%B5%D1x%00%00%00%01>
(iiop.c:parse_IIOP_Profile):  non-native cinfo is <iiop_1_0_1_49%25A2%251D%252C%25B5%25D1x%2500%2500%2500%2501@tcp_13.1.101.26_41056>
_ilu_IIOP_FindClassViaRPC(9dce8 "%8BS%7D%B4%D1%9Fő%DB" "ilu--corba-native-object:49%A2%1D%2C%B5%D1x%00%00%00%01")
ilu_StartCall       (efffe648 over 9f0e8 to "%8BS%7D%B4%D1%9Fő%DB" #1, ilu.Object.-is-a, pl=0, si=0).
_IIOP_SizeOfObjectID (efffe648, 9dce8, is disc, ilu.Object) => 35
_IIOP_StartRequest:  call efffe648 (sn 1), argSize 52, class ilu.Object (ilu:root-object-type), meth -is-a (65413)
_IIOP_StartRequest:  request 1 begun (argsize 52).
ilu_StartRequest    (efffe648 over 9f0e8 to "%8BS%7D%B4%D1%9Fő%DB" #1, argSize 52) => success
ilu_FinishRequest   (efffe648 over 9f0e8 to "%8BS%7D%B4%D1%9Fő%DB" #1)
DumpPacket of outgoing TCP packet d3268, length 93 bytes, dumping 93 bytes:
     0:  47 49 4f 50  01 00 00 00  00 00 00 51  00 00 00 01   GIOP.......Q....
    16:  00 00 00 01  00 00 00 0c  00 01 00 20  00 01 00 01   ........... ....
    32:  00 01 01 00  00 00 00 01  01 00 00 00  00 00 00 0c   ................
    48:  34 39 a2 1d  2c b5 d1 78  00 00 00 01  00 00 00 06   49..,..x........
    64:  5f 69 73 5f  61 00 00 00  00 00 00 00  00 00 00 0d   _is_a...........
    80:  49 44 4c 3a  45 63 68 6f  3a 31 2e 30  00            IDL:Echo:1.0.
ilu_GetReply        (efffe648 over 9f0e8 to "%8BS%7D%B4%D1%9Fő%DB" #1)...
DumpPacket of incoming TCP packet 9de78, length 12 bytes, dumping 12 bytes:
     0:  47 49 4f 50  01 00 00 06  00 00 00 00                GIOP........
_IIOP_ReadHeader:  MessageError advisory received.
_IIOP_ReadHeader:  MessageError #0, 0 bytes, big-endian, short char codeset 00010001, char codeset 00000000.