CORBA 2.5 NO IDEA Avatar
  1. OMG Issue

CORBA25 — International Strings in Encapsulations

  • Key: CORBA25-55
  • Legacy Issue Number: 3221
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    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
    this will
    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
    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.

  • Reported: CORBA 2.3.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    closed in interop/2000-05-01

  • Updated: Sat, 7 Mar 2015 02:37 GMT