CORBA25 — International Strings in Encapsulations

It seems that the only time an international string will ever appear in an
encapsulation
would be a private IOR component.

If we can keep the issue down to International strings in encapsulations
this will
simplify the solution.

If anyone has an example of how any other GIOP header string could carry an
international
string please come forth with it quickly.

The use of international strings in GIOP 1.1 and 1.2 is dependant on the
asserted use
of service context code set negotiation. In particular:
1) if the negotiatiation is not initiated, then strings are passed
as latin-1 only and wstrings are not allowed to be passed as parameters.
2) If the negotiation is initated and successfully completed, the
agreed codesets are used
respectively for string and wstring
3) If negotiation is initated by no comon codeset is agreed, then
UTF-8 is the default for
string and UTF-16 is the default for Wstring (note: the current codeset
negotiation does not
discuss the big endian or litte endian aspects of UTF-16).

There is also text somewhere in GIOP stating that Encapsulations in IORs
should be
encoded in giop 1.0 for maximum interoperability.

It just occured to me that disallowing international strings in IOR
encapsulations (i.e., private
IOR components) is equivalent to assuming that negotiation is not initiated
for encapsulations.
This seems to be a consistent set of semantics.

The only problem with this interpretation, is that it does not allow
international strings
in IOR encapsulations.

closed in interop/2000-05-01