CORBA3 — Codeset negotiation requires clarification

We need to analyze this problem in pieces, because our discussions have been all
over
the map.

I have identified some legitimate needs for clarification though this discussion.
To help
we should target each discussion to be within one or more of these scenarios:

Lets look at a few typical scenarios a, b, and c:

a) server does not support international Strings

Server cannot support Objects which use WSTRING in their IDL. It does not use
codeset component in IORs, thus closing off Client’s use of international strings
on the connection.

We have a problem as to what to do with an ANY which may have WSRING in it for
this case (we could mandate the orb to consider this a failed negotiation and go
to the fallback of UTF-16).

b) Server supports only Latin 1 for string, and Unicode UCS-2 for Wstring

Server places a Codeset component in the IOR with TCS-W indicated.

There may be a need for clarification as to what Native Code Sets should be used
for Unicode.

• If we view the GIOP negotiation mechanism as transport oriented, then the Server
  should put in UTF-16 as the Native Code set.in the IOR component
• If we view it as a presentation mechanism, then the Server might put UCS-2 as
  Native code set, and UTF-16 as Conversion Code Set in the IOR component.

What can the server legally put in the IOR component for TCS-C in this case. Is
Null allowed? Should ISO 8859-1 be explicitly called out in the TCS-C portion of
the codeset component?

c) Server supports ShiftJISC for string and Unicode UCS-2 for Wstring

There might be an issue on whether the server may also place UTF-8 in as an
explicit Conversion code set in the TCS-C portion of the IOR component?

If the client does not support ShiftJISC, it should assert UTF-8 in the Codeset
Service context for the TCS-C.

see above