Legacy Issue Number: 3221
Source: Fujitsu ( Tom Rutt)
It seems that the only time an international string will ever appear in an
would be a private IOR component.
If we can keep the issue down to International strings in encapsulations
simplify the solution.
If anyone has an example of how any other GIOP header string could carry an
string please come forth with it quickly.
The use of international strings in GIOP 1.1 and 1.2 is dependant on the
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
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
This seems to be a consistent set of semantics.
The only problem with this interpretation, is that it does not allow
in IOR encapsulations.
Reported: CORBA 2.3.1 — Mon, 17 Jan 2000 05:00 GMT
Disposition: Resolved — CORBA 2.5
closed in interop/2000-05-01
Updated: Sat, 7 Mar 2015 02:37 GMT
CORBA25 — International Strings in Encapsulations
- Key: CORBA25-55
- OMG Task Force: Core December 2000 RTF