Common Object Request Broker Architecture Avatar
  1. OMG Specification

Common Object Request Broker Architecture — All Issues

  • Acronym: CORBA
  • Issues Count: 36
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
CORBA34-175 New issue: ForwardRequest() CORBA 2.6 CORBA 3.4 Deferred closed
CORBA34-176 Proposal for extension to CosNaming CORBA 2.6 CORBA 3.4 Deferred closed
CORBA34-174 ForwardRequest is impossible to detect in clients CORBA 2.6.1 CORBA 3.4 Deferred closed
CORBA3-134 IDL keyword clash in CosNotification.idl CORBA 2.6 CORBA 3.0 Resolved closed
CORBA3-129 DATA_CONVERSION minor code 2 not listed in Table 4-3 CORBA 2.6.1 CORBA 3.0 Resolved closed
CORBA3-106 components-ftf: connectevent element CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-105 components-ftf: registercomponent element CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-104 components-ftf: repository id in software package descriptor CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-102 Generic operations for subscribing/unsubscribing at publishing ports CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-103 IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-64 Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-62 Avoiding Interceptors for colocated method requests CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-63 pragma prefix syntax CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-60 Replace deprecated anonymous type declarations? CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-53 discussion on the create_union_tc operation could use some clarifications CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-52 IDL inheritance issue CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-54 definition of the TypeCode interface (4.11.1) CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-55 GIOP version in replies CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-56 IOR processing performance CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-59 reference_to_servant CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-57 Inconsitent exception handling with find_POA & unknown_adapter CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-58 Valuetypes supporting forward declared interfaces CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-61 Codeset negotiation and the CODESET_INCOMPATIBLE exception CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-45 11.3.2.1 Processing States (end of second paragraph and third paragraph CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-51 Codeset negotiation requires clarification CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-48 IPv6 in corbaloc URLs CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-49 interaction of #pragma and typeid, typeprefix CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-44 Potential problem using BiDir GIOP and codeset conversion service context CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-50 The whole negotiation thing should be removed, Unicode should be mandated CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-46 conflict between CORBA specification and C++ mapping (_this method CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-42 TypeCode indirections CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-43 Issue with chunking CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-47 Wide string in reply before codeset was negotiated CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-41 Chapters 13.10.1.9, and 13.10.1.12 -- issue CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-40 GIOP 1.2 encoding of wstring CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-39 ORBs using BOMs for UTF-16 (closely related to issue 4008) CORBA 2.6 CORBA 3.0.2 Resolved closed

Issues Descriptions

New issue: ForwardRequest()

  • Legacy Issue Number: 5231
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The Portable Object Adapter and Portable Interceptors both are able to
    raise a ForwardRequest exception to allow redirection to another
    object.

    What happens if the ForwardRequest is to a local object?

    Is this even possible?

    Should it be allowed?

    I suggest we change the specification to make this illegal.

  • Reported: CORBA 2.6 — Thu, 25 Apr 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Proposal for extension to CosNaming

  • Legacy Issue Number: 5214
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    Since there doesn't appear to be a CosNaming mailing list this seems like as good a forum as any this discussion.

    It has long struck me that the use of CosNaming for JNDI in J2EE applications creates a significant outage in being able to bind and retrieve objects that are not remote (see the EJB 2.0 spec for details). In JNDI you can bind pretty much anything that is Remote (aka an Object reference) or Serializable (aka a valuetype), however CosNaming only allows you to do the former.

    One easy way to solve this would be to create a new NamingContext extension that allows one to bind and resolve Any's. This is in keeping with the Java-to-IDL spec's treatment of untyped Java objects and at the same time would not compromise non-java implementations. For JNDI it would only be necessary to support Any's containing:

    1. Object references
    2. valuetypes
    3. valueboxes

    An exception could be thrown for any other types. The candidate interface might look something like this:

    module CosNaming {
    interface NamingContextAny : NamingContextExt {
    exception TypeNotSupported {};

    void bind_any(in Name n, in any obj)
    raises (NotFound, CannotProceed,
    InvalidName, AlreadyBound, TypeNotSupported);

    void rebind_any(in Name n, in any obj)
    raises(NotFound, CannotProceed, InvalidName, TypeNotSupported);

    any resolve_any (in Name n)
    raises (NotFound, CannotProceed, InvalidName);

    any resolve_str_any(in StringName n)
    raises (NotFound, CannotProceed,
    InvalidName, AlreadyBound);
    };
    };

    The implementation of this interface in Java is trivial, although perhaps less so in other languages. Whether or not that matters is open to question.

  • Reported: CORBA 2.6 — Wed, 10 Apr 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Mon, 30 Mar 2020 19:47 GMT

ForwardRequest is impossible to detect in clients

  • Legacy Issue Number: 5266
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    REQUIREMENT

    To be able to use interceptors, and in particular ForwardRequest, in a client to perform active, per-request, load-balancing.

    PROBLEM

    It is not possible to detect in an interceptor whether ForwardRequest has previously been thrown for the same client request. Thus it is possible for a client to go into an infinite loop throwing ForwardRequest.

    DISCUSSION

    The basic problem is that although for a single client request the request-scoped PICurrent is shared across across interceptor invocations - even when ForwardRequest is thrown - it is not possible to modify this information in an interceptor to indicate to a future invocation that the invocation has been seen. The two relevant parts of the spec here are:

    21.3.6.5

    For retries, depending on the policies in effect, a new request may or may not follow
    when a retry has been indicated. If a new request does follow, while this request is a
    new request, with respect to Interceptors, there is one point of correlation between the
    original request and the retry: because control has not returned to the client, the request
    scoped PortableInterceptor::Current for both the original request and the retrying
    request is the same (see Chapter 21, Portable Interceptors on page 21-32).

    21.4.2

    Before an invocation is made, PICurrent is obtained via a call to
    ORB::resolve_initial_references ("PICurrent")
    From within the interception points, the data on PICurrent that has moved from the
    thread scope to the request scope is available via the get_slot operation on the
    RequestInfo object. A PICurrent can still be obtained via
    resolve_initial_references, but that is the Interceptor's thread scope PICurrent.
    See section 21.4.4.4, Request Scope vs Thread Scope on page 21-36 for a detailed
    discussion of the scope of PICurrent.

    Thus modifications to the thread's PICurrent are lost on retries and modifications to the request's PICurrent are not possible.

    PROPOSED RESOLUTION

    I have made several different attempts at coming up with a portable way of solving this problem without changing the spec, but have failed. It seems to me that it really should be possible for the interceptor to know that a retry is in effect and I can think of a number of different solutions to this:

    1. add:
    void set_slot (in SlotId id, in any data) raises (InvalidSlot);
    to RequestInfo. This would allow interceptors to transfer information between invokes of the same client request and thus a retry could be detected.

    2. Add a new function to RequestInfo to indicate that a forward is in operation. The minimalist fix here would be to allow forward_reference() to be accessed in send_request() as well as in receive_other(). i.e. returning the object from the previous ForwardRequest if that has been thrown.

    I'm ambivalent about which of these is best but for the sake of simplicity I'm going to plump for (1) because this is already allowed in ServerRequestInfo.

    So:

    • Change the IDL in 21.3.12 to include
      void set_slot (in SlotId id, in any data) raises (InvalidSlot);
    • After 21.3.12.12 move in the text from 21.3.14.6
    • Change the IDL in 21.3.14 to remove set_slot()
  • Reported: CORBA 2.6.1 — Thu, 2 May 2002 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Mon, 30 Mar 2020 19:47 GMT

IDL keyword clash in CosNotification.idl

  • Key: CORBA3-134
  • Legacy Issue Number: 4901
  • Status: closed  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    CosNotification.idl contains a struct named 'EventType', which
    clashes with the new CCM-related keyword 'eventtype'.

  • Reported: CORBA 2.6 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0
  • Disposition Summary:

    purely editorial issue

  • Updated: Wed, 11 Mar 2015 04:16 GMT

DATA_CONVERSION minor code 2 not listed in Table 4-3

  • Key: CORBA3-129
  • Legacy Issue Number: 5322
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    It is used by RealTime CORBA as documented in 24.17.2

  • Reported: CORBA 2.6.1 — Thu, 23 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0
  • Disposition Summary:

    non issue...editorial, issue withdrawn

  • Updated: Fri, 6 Mar 2015 21:38 GMT

components-ftf: connectevent element

  • Key: CORBA3-106
  • Legacy Issue Number: 5093
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    On page 69-521 (ptc/01-11-03), the connectevent
    element of an Assembly Descriptor is defined as

    <!ELEMENT connectevent (consumesport,
    (emitsport |
    publishesport))>

    This does not allow for emits and publishes
    ports to be connected to existing consumer
    interfaces that are registered in the naming
    or trading service. I suggest to change that
    element in the spirit of connectinterface to

    <!ELEMENT connectevent (emitsport |
    publishesport) ,
    (consumesport |
    existinginterface)>

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

components-ftf: registercomponent element

  • Key: CORBA3-105
  • Legacy Issue Number: 5092
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    On page 69-532 (ptc/01-11-03), the
    registercomponent element of an Assembly
    Descriptor is defined to optionally
    contain an emitsidentifier and publishes-
    identifier element, in order to register
    an event source in the Naming or Trading
    Service. There is also a note saying, "In
    the case of events, what gets registered?"

    I suggest to replace the emitsidentifier
    and publishesidentifier elements with the
    consumesidentifier element, and to change
    the first two paragraphs to read:

    "The registercomponent element is to specify
    that a component, a provided interface, or
    an event consumer interface should be regis-
    tered with a naming service or trader.

    If a consumesidentifier or publishesidentifier
    is specified, then that element is registered.
    If none of the above are specified, then it is
    implied that the component itself is to be
    registered."

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

components-ftf: repository id in software package descriptor

  • Key: CORBA3-104
  • Legacy Issue Number: 5091
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The id attribute of the idl element in a
    Software Package Descriptor currently
    contains the Repository Id of the component.

    I suggest to change this to the Repository
    Id of the home, as the home implies the
    component, but not vice versa. This makes
    it easier for the deployment application to
    find out about the home interface, e.g. for
    the purpose of configuring properties.

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The Repository Id of the home should be added as an attribute of the idl element

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Generic operations for subscribing/unsubscribing at publishing ports

  • Key: CORBA3-102
  • Legacy Issue Number: 4983
  • Status: closed  
  • Source: Anonymous
  • Summary:

    generic operations for subscribing and unsubscribing at publishing ports of components should have the same funtionality as the specific ones. Therefore the generic unsubscribe operation should return the unsubscribed consumer reference like the specific operation does. proposal: change

    void unsubscribe (in FeatureName publisher_name, in Cookie ck) raises (InvalidName, InvalidConnection);

    to

    EventConsumerBase unsubscribe (in FeatureName publisher_name, in Cookie ck) raises (InvalidName, InvalidConnection);

  • Reported: CORBA 2.6 — Fri, 15 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType

  • Key: CORBA3-103
  • Legacy Issue Number: 4986
  • Status: closed  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    The "eventtype" keyword defined in Section 3.2.4 of the "CORBA 3.0 New
    Components Chapters" (ptc/2001-11-03) will make the Notification
    Service IDL un-compilable because Notification Service defines a
    struct called "EventType" in Section 3.1 of formal/00-06-20.

    I guess one of the specs will have to change.

  • Reported: CORBA 2.6 — Mon, 18 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent

  • Key: CORBA3-64
  • Legacy Issue Number: 5329
  • Status: closed  
  • Source: Xanalys ( Martin Simmons)
  • Summary:

    The minor codes in the specified NO_IMPLEMENT exceptions are incomplete/inconsistent.

    In particular:

    1) In 3.7.6.1 "Semantics", minor code 3 is mentioned for DII support pseudo-operations, but 3.7.6.2 seems to specify minor code 4 for these (though it uses different wording).

    2) 3.7.6.2 "LocalObject" doesn't specify the minor code for "is_a" etc, though presumably it should be 3 as in 3.7.6.2.

    3) The explanation for minor code 3 is "Unable to use any profile in IOR." but that isn't particular clear for local objects, which probably don't have an IOR at all.

  • Reported: CORBA 2.6.1 — Tue, 28 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Avoiding Interceptors for colocated method requests

  • Key: CORBA3-62
  • Legacy Issue Number: 5296
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    Could we please discuss the possibility of introducing a performance
    optimization for Interceptors.

    There may be considerable overhead involved in invoking Portable
    Interceptors. While some interceptors need to be invoked when caller
    and target are colocated (the locally optimized path), many do not.
    I think it would be useful to introduce a mechanism to allow this
    unnecessary overhead to be avoided for interceptors that do not need
    to be invoked on the colocated path, for example by adding a
    'run_local' parameter to the add_xxx_request_interceptor methods of
    the ORBInitInfo interface.

    I realise that this issue was touched upon during discussion of interop
    issue 4291 but, at the time, the focus was on getting the interceptor
    mechanism to work correctly in the colocated case; the performance
    aspect of the issue seems to have been lost.

  • Reported: CORBA 2.6.1 — Mon, 13 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Provide means for the optimization as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

pragma prefix syntax

  • Key: CORBA3-63
  • Legacy Issue Number: 5327
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    suppose the following [pseudo-]idl:

    #pragma prefix "2abc.def"

    module xyz {
    interface q

    {...}

    ;
    };

    It would generate a Java class 'q' within package 'def.2abc.xyz'.
    The package name '2abc' is not that popular with the java compiler
    since it starts with a digit.

    From what I could see in CORBA 2.6.1, identifiers have to start
    with a character (or at least not a digit). So, I guess that the
    prefix pragma is erroneous here, right ?

    The OpenORB IDL parser 1.2.0 did though generate Java code without any
    complaints, which confuses me ...

  • Reported: CORBA 2.6.1 — Sat, 25 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace deprecated anonymous type declarations?

  • Key: CORBA3-60
  • Legacy Issue Number: 5232
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Now that we've deprecated defining types anonymously with bounded
    strings, fixed, sequences and arrays, should we take the next step and
    deliberately purge them from the Core IDL?

    Here are the offenders that I've identified and the edits that should
    occur:

    In module CORBA:

    1. the service_detail member of struct ServiceDetail

    Fix: Add 'typedef sequence<octet> ServiceDetailData' and replace
    member type

    2. the service_options & service_details members of struct
    ServiceInformation

    Fix: Add 'typedef sequence<ServiceOption> ServiceOptionSeq' and
    'typedef sequence<ServiceDetail> ServiceDetailSeq' and replace
    member type

    In module GIOP:

    3. the magic member in the various struct MessageHeader_1_X types

    Fix: Add 'typedef char Magic[4]' and replace member types

    4. the reserved member in the struct RequestHeader_1_1 and
    RequestHeader_1_2 types

    Fix: Add 'typedef octet RequestReserved[3]' and replace member
    types

    5. the object_key member in various Header structures

    Fix: replace member types with IOP::ObjectKey

    In module IIOP:

    6. the object_key member in various struct ProfileBody_1_X types

    Fix: replace member types with IOP::ObjectKey

    7. the components member in struct ProfileBody_1_1

    Fix: replace member type with IOP::ComponentSeq

    In module IOP:

    8. the profile_data member in struct TaggedProfile

    Fix: Add 'typedef sequence<octet> ProfileData' and replace member
    type

    9. the profiles member in struct IOR

    Fix: Add 'typedef sequence<TaggedProfile> TaggedProfileSeq' and
    replace
    member type

    10. the component_data member in struct TaggedComponent

    Fix: Add 'typedef sequence<octet> ComponentData' and replace member
    type

    11. the context_data in struct ServiceContext

    Fix: Add 'typedef sequence<octet> ContextData' and replace member
    type

    also to complete fixes for cases 5, 6, and 20:

    Fix: Add 'typedef sequence<octet> ObjectKey' and
    'typedef sequence<TaggedComponent> TaggedComponentList'

    In module MessageRouting:

    12. the body member in struct MessageBody

    Fix: Add 'typedef sequence<octet> BodyData' and replace member type

    13. the object_key member in struct RequestMessage

    Fix: replace member type with 'IOP::ObjectKey'

    14. the reserved member in struct RequestMessage

    Fix: replace member type with 'GIOP::RequestReserved'

    15. the typed_excep_holder_repids in struct ReplyDestination

    Fix: replace member type with 'CORBA::RepositoryIdSeq'

    In module Messaging:

    16. the pvalue member in struct PolicyValue

    Fix: Add 'typedef sequence<octet> PolicyData' and replace member
    type

    17. the marshaled_exception member in valuetype ExceptionHolder

    Fix: Add 'typedef sequence<octet> MarshalledException' and replace
    member
    type

    In module CONV_FRAME:

    18. the conversion_code_sets member in struct CodeSetComponent

    Fix: Add 'typedef sequence<CodeSetId> CodeSetIdSeq' and replace
    member type

    In module DCE_CIOP:

    19. the object_key member in struct InvokeRequestHeader and struct
    LocateRequestHeader

    Fix: replace member type with 'IOP::ObjectKey'

    In module DCE_CIOPSecurity.idl:

    20. the components member in struct DCESecurityMechanismInfo

    Fix: replace member type with 'IOP::TaggedComponentList'

  • Reported: CORBA 2.6 — Tue, 30 Apr 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

discussion on the create_union_tc operation could use some clarifications

  • Key: CORBA3-53
  • Legacy Issue Number: 4852
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The discussion on the create_union_tc operation could use some clarifications to prevent implementation errors.

    Firstly, in the previous paragraph of the spec it states that member names must be unique, but this is not true for unions: only the member (label) values need to be unique, not the member names.

    Secondly, there is a check that each member (label) type matches the discriminator type, but this will not hold for the default label, because according to the typecode spec (section 4.11.1) the default label type of a union will be octet so it will never match the discriminator type.

  • Reported: CORBA 2.6 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    There is indeed a defect that should be fixed by replacing a single sentence as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL inheritance issue

  • Key: CORBA3-52
  • Legacy Issue Number: 4851
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    The IDL specification is unclear about the names that can be used to
    denote a base interface. Section 3.7.2 says

    "Each <scoped_name> in an <interface_inheritance_spec> must denote a
    previously defined interface."

    but the word "denote" is not defined. In particular, is the following
    legal?

    interface I { };
    typedef I J;
    interface K : J { };

    There is real IDL in use in the world that assumes that inheriting
    from a typedef is permitted. I therefore suggest re-wording the part
    of section 3.7.2 to be

    "Each <scoped_name> in an <interface_inheritance_spec> must be the
    name of a previously defined interface or an alias to a previously
    defined interface."

    A similar clarification is required in section 3.8.1.3, regarding
    valuetype inheritance.

  • Reported: CORBA 2.6 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Good point. Incorporate the clarification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

definition of the TypeCode interface (4.11.1)

  • Key: CORBA3-54
  • Legacy Issue Number: 4870
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • Summary:

    In the definition of the TypeCode interface (4.11.1) the length operation is defined as:

    // for tk_string, tk_sequence, and tk_array unsigned long length () raises (BadKind);

    The comment for this operation should include tk_wstring.

  • Reported: CORBA 2.6 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fixed editorially in CORBA 3.0, close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP version in replies

  • Key: CORBA3-55
  • Legacy Issue Number: 4899
  • Status: closed  
  • Source: seimet.de ( Uwe Seimet)
  • Summary:

    is it allowed to return a reply with a GIOP version number of 1.0 for a
    request with GIOP version number 1.1 or 1.2, as long as the reply can be
    correctly encoded with GIOP 1.0? IMO the spec is not clear about that, i.e.
    it does not explicity state that the version numbers of request and reply
    must match. This should be clarified.

  • Reported: CORBA 2.6 — Fri, 1 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify that the reply message must have the same GIOP version as the request message

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IOR processing performance

  • Key: CORBA3-56
  • Legacy Issue Number: 4945
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    The overhead of processing TaggedComponents within an IOR becomes
    significant when done many times, as in the case of J2EE implementations
    where multiple request interceptors are used. IOR access and creation
    performance could be improved by making better use of Java facilities to
    provide access to an IOR's components without the overhead of CDR encoding,
    and by recognising that many of the constituent parts of an IOR are
    identical for all objects within an object adapter.

    I would like to propose that we introduce a Java API for IOR, along the
    following lines:-

    An abstract model of an IOR could be defined as follows:
    an IOR has a type ID string, and contains TaggedProfile instances
    an IIOPProfile is a TaggedProfile
    an IIOPProfile is composed of an IIOPProfileTemplate and an object ID
    an IIOPProfileTemplate has an ObjectKeyTemplate, and contains
    TaggedComponents
    a TaggedComponent has an ID, and can be written to an OuputStream.
    a TaggedComponentFactory reads a TaggedComponent from an InputStream.

    It should be possible to manipulate IOR TaggedProfiles and
    IIOPProfileTemplate TaggedComponents using all of the facilities in the
    Java collections framework.

    Templates can be used to create IIOPProfile and ObjectKey because the basic
    object adapter model for object creation is to establish all properties of
    an IOR (except for type and object ID) when the object adapter is created.
    This has been present for the POA essentially from the beginning, since
    policies can only be passed to create_POA, and cannot be changed on an
    existing POA. The Portable Interceptors work has also made this clear,
    since the IOR interceptor runs only when an object adapter is created,
    which is the only time that user code can add tagged components to an IOR.

    TaggedComponent is a framework that may be extended to support application
    defined TaggedComponents. It would be necessary to be able to register
    TaggedComponentFactory instances with an ORB, in which case any IOR
    unmarshalled by that ORB instance would use the registered
    TaggedComponentFactory to unmarshal the TaggedComponent.

    In order to use the IOR API, a method would be needed, probably on ORB,
    to obtain an abstract IOR from an object reference.

  • Reported: CORBA 2.6 — Wed, 6 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

reference_to_servant

  • Key: CORBA3-59
  • Legacy Issue Number: 5105
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For reference_to_servant(), the spec says:

    > This operation requires the RETAIN policy or the USE_DEFAULT_SERVANT
    policy.
    > If neither policy is present, the WrongPolicy exception is raised.
    >
    > If the POA has the RETAIN policy and the specified object is present in
    the Active
    > Object Map, this operation returns the servant associated with that object
    in the Active
    > Object Map. Otherwise, if the POA has the USE_DEFAULT_SERVANT policy and a
    > default servant has been registered with the POA, this operation returns
    the default
    > servant. Otherwise, the ObjectNotActive exception is raised.

    This says that, if I use USE_DEFAULT_SERVANT, reference_to_servant() always
    and unconditionally returns the default servant.

    This appears to be wrong. In particular, I can have USE_DEFAULT_SERVANT but
    still add other servants explicitly to the AOM. If I do that, I can have,
    for example,
    servant X with object ID 1 as an explicitly activated servant, in addition
    to the default
    servant. In this situation, if I call reference_to_servant() with a
    reference with object ID 1,
    it should return servant X instead of the default servant.

    The exact same reasoning applies to id_to_servant(), which also
    unconditionally returns
    the default servant with USE_DEFAULT_SERVANT().

    I think we need to fix this – it appears that the current words are simply
    wrong.

  • Reported: CORBA 2.6 — Tue, 2 Apr 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsitent exception handling with find_POA & unknown_adapter

  • Key: CORBA3-57
  • Legacy Issue Number: 4982
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I think we totally messed up the resolution to issue 3740. We added the
    following text (circa CORBA 2.5) to 11.3.3.2:

    "If unknown_adapter returns FALSE then find_POA raises
    AdapterNonExistent. If
    unknow_adapter raises any system exception then find_POA passes through
    the
    system exception it gets back from unknown_adapter."

    [ There is also a typo in this text: "unkown_adapter".]

    and this text to 11.3.8.3:

    "If find_POA receives a system exception in response to a call to
    unknown_adapter
    on a POA, find_POA raises OBJ_ADAPTER system exception with standard
    minor
    code 1."

    In the former, system exceptions raised by unknown_adapter are to be
    passed through unchanged by find_POA. In the latter, system exceptions
    raised by unknown_adapter are to be replaced with OBJ_ADAPTER(1).

    I think the former behavior is more correct, since it preserves the
    original exception and doesn't throw away useful debugging information.

  • Reported: CORBA 2.6 — Thu, 14 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The former (i.e. 11.3.3.2) is right. Change the latter to match the former

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetypes supporting forward declared interfaces

  • Key: CORBA3-58
  • Legacy Issue Number: 5100
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Interfaces cannot inherit from forward declared interfaces and
    valuetypes cannot inherit from forward declared valuetypes, but there is
    no specific prohibition against a valuetype supporting a forward
    declared interface. There should be.

    Proposed resolution:

    Add the following sentence to section 3.8.4:

    "It is illegal for a value type to support a forward-declared interface
    whose definition has not yet been seen."

  • Reported: CORBA 2.6 — Fri, 29 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Do as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Codeset negotiation and the CODESET_INCOMPATIBLE exception

  • Key: CORBA3-61
  • Legacy Issue Number: 5270
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    1. There's no minor code assigned to the use of CODESET_INCOMPATIBLE
    for a failed codeset negotiation in 13.10.2.6.

    2. There's no indication of what a server should do if the client
    delivers a codeset via a CodeSetContext that the server does not support
    as a transmission codeset). This isn't likely to happen, but we ought
    to close the hole. I propose that we have the server raise
    CODESET_INCOMPATIBLE (with a different minor code from 1) in this case
    too.

    3. Would it be a good idea for us to include recommendations on how to
    change a persistent server's native codeset while remaining backwards
    compatible with existing IORs floating around the world with obsolete
    CodeSetComponent data? Or is it too obvious? (Just make sure the new
    server advertises (or at least continues to support) the old native
    codeset as a transmission codeset.)

  • Reported: CORBA 2.6.1 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

11.3.2.1 Processing States (end of second paragraph and third paragraph

  • Key: CORBA3-45
  • Legacy Issue Number: 4822
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Hello, I think I've found inconsistency (or slips of the pen) in CORBA specification.

    ----------------------------------------- 11.3.2.1 Processing States (end of second paragraph and third paragraph):

    For example, if a POA is in active state, it does not change state due to an activate operation. Such operations complete successfully with no special notice.

    The only exception is the inactive state: a deactivate operation raises an exception just the same as every other attempted state change operation.

    Probably incosistent to:

    11.3.2.5 deactivate (first paragraph):

    This operation changes the state of the POA manager to inactive. This operation has no affect on the POA manager's state if it is already in the inactive state. (no more explanation about AdapterInactive exception)

    ------------------------------------------ So, each POAManager state changing operation do nothing if it will not really change the state of the POAManager (activate call on already active POAManager, for example)

    On the other hand:

    Each POAManager state changing operation raises the AdapterInactive exception if issued while the POA manager is in the inactive state.

    CORBA 2.5 specification was the first in which explanation about AdapterInactive exception during deactivate operation was removed (but third paragraph of 11.3.2.1 was not changed respectively).

    Probably, the third paragraph of 11.3.2.1 should be removed.

    Could you please provide some explanation about this problem (even if I am not right).

  • Reported: CORBA 2.6 — Mon, 4 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Codeset negotiation requires clarification

  • Key: CORBA3-51
  • Legacy Issue Number: 4850
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    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.

  • Reported: CORBA 2.6 — Thu, 28 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IPv6 in corbaloc URLs

  • Key: CORBA3-48
  • Legacy Issue Number: 4825
  • Status: closed  
  • Source: Progress Software ( Markus Heichel)
  • Summary:

    is there any recent specification for IPv6 addresses in corbaloc
    URLs? I could not find any hint.

    Since it is not possible to unambiguously determine the meaning
    of something like:

    corbaloc::10:5::5:6/Hello

    there should be an escape for the colons or a delimiter for
    the IP address.

  • Reported: CORBA 2.6 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interaction of #pragma and typeid, typeprefix

  • Key: CORBA3-49
  • Legacy Issue Number: 4835
  • Status: closed  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    The CCM final draft has a section on repository identity
    related declarations (3.15), and the rules for which trumps
    which and what may be reset a second time are clear. Likewise
    for the #pragma prefix, version and ID directives in section
    10.7.5. But I'm still confused about how these two things
    interact – I haven't been able to find anywhere where this is
    addressed.

  • Reported: CORBA 2.6 — Mon, 18 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Potential problem using BiDir GIOP and codeset conversion service context

  • Key: CORBA3-44
  • Legacy Issue Number: 4820
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    I've just noticed there's a potential problem when using BiDir GIOP and the codeset conversion service context, or in fact any service context that has connection rather than request scope.

    Take the following example:

    A opens connection to B

    A issues a request 1 (R1) containing the bidir service context, but not the codeset conversion service context.

    B processes R1, marking the connection as bidirectional.

    B invokes a callback object with a request (R2), this request does contain the codeset conversion service context, since B has noticed A has not set one for the request.

    A symultaniously issues another request (R3), this one does contain the codeset service context, however the codesets it selects are different.

    So we have a problem, which codesets should be used for the connection?

    The obvious solution is to force each direction to negotiate it's own character encodings, however this is not stated anywhere in the spec AFAICS. This problem will also occour for any connection specific state as set up by service contexts.

    Suggested resolution: add to the BiDir part of chapter 15 the following:

    "For any connection level state negotiated by exchange of service contexts, each direction of a bidirectional connection should be negotiated independently. For example, the codeset negotiation process shall produce independent transmission codesets for each direction"

  • Reported: CORBA 2.6 — Fri, 1 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The whole negotiation thing should be removed, Unicode should be mandated

  • Key: CORBA3-50
  • Legacy Issue Number: 4846
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The whole negotiation thing should be removed from the spec and Unicode should be mandated"

  • Reported: CORBA 2.6 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

conflict between CORBA specification and C++ mapping (_this method

  • Key: CORBA3-46
  • Legacy Issue Number: 4823
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I think that there is conflict between CORBA specification and C++ mapping (_this method). May be it relates both to CORBA specification and C++ mapping.

    The Portable Object Adapter chapter of CORBA 2.6 specification 11.2.7 Implicit Activation (last paragraph - before Note)

    If the POA has the MULTIPLE_ID policy, the servant_to_reference and servant_to_id operations will always perform implicit activation, even if the servant is already associated with an Object Id. The behavior of language mapping operations in the MULTIPLE_ID case is specified by the language mapping. For example, in C++, the _this() servant member function will not implicitly activate a MULTIPLE_ID servant if the invocation of _this() is immediately within the dynamic context of a request invocation directed by the POA to that servant; instead, it returns the object reference used to issue the request.

    If I am right, author thinks that _this operation can be called on servant (related to POA with MULTIPLE_ID policy) multiple times (and it will not raise PortableServer::WrongPolicy exception).

    But C++ mapping provides the following semantics of _this:

    1.36.5 Skeleton Operations 3. ... This requires the POA with which the servant was activated to have been created with the UNIQUE_ID and RETAIN policies. If the POA was created with the MULTIPLE_ID or NON_RETAIN policies, the PortableServer::WrongPolicy exception is thrown.

    Moreover CORBA specification provides the following semantics for servant_to_reference method: 11.3.8.20 servant_to_reference 2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and either the POA has the MULTIPLE_ID policy or the specified servant is not active, the servant is activated using a POA-generated Object Id and the Interface Id associated with the servant, and a corresponding object reference is returned.

    If I am right, _this and servant_to_reference are very close by their semantics (sometimes _this can be implemented using servant_to_reference invocation on appropriate POA). That's why I think that C++ mapping conflicts with CORBA specification.

    Could you please provide some explanation about this problem (even if I am not right).

  • Reported: CORBA 2.6 — Mon, 4 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode indirections

  • Key: CORBA3-42
  • Legacy Issue Number: 4796
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    This issues was previously raised as issue 4294, and was deferred to the
    GIOP 1.3 wishlist. Now that GIOP 1.3 is about to become a reality, I am
    re-raising the issue because of its importance for efficient RMI-IIOP
    communications. This is an interop issue, but I am also copying the
    Java to IDL list because of its impact on RMI-IIOP performance.

    CDR should allow TypeCode indirections that refer to top-level TypeCodes.
    The current prohibition of this causes servere performance penalties for
    RMI-IIOP because the Java to IDL mapping requires that Java objects of
    declared type java.lang.Object are marshalled as CORBA anys. In the case
    of a Vector or HashTable with 100 elements, this means that 100 anys must
    be marshalled. If all of these are of actual type foo, the restriction
    on TypeCode indirections means that all 100 of these data values must repeat
    the TypeCode for foo, which could be very large. This causes very substantial
    overheads, since the space and time needed to marshal the TypeCode for foo
    can greatly exceed that needed to marshal the data for foo.

    I understand why a nested indirection cannot refer to any TypeCode outside
    the scope of its enclosing top-level TypeCode. However, this restriction
    does not need to apply to a top-level TypeCode. We have made this change
    experimentally without any adverse effects and we have discovered that
    using indirections for all repeated top-level TypeCodes can speed up some
    common scenarios by at least a factor of 5 on end-to-end measurements.
    There appears to be no downside to making this change.

    Proposed Resolution:

    In the section headed "Indirection: Recursive and Repeated TypeCodes" within
    section 15.3.5.1, replace the current first bullet:

    The indirection applies only to TypeCodes nested within some “top-level”
    TypeCode. Indirected TypeCodes are not “freestanding,” but only exist inside
    some other encoded TypeCode.

    by the following two bullets:

    For GIOP 1.2 and below, the indirection applies only to TypeCodes nested
    within some “top-level” TypeCode. Indirected TypeCodes are not “freestanding,”
    but only exist inside some other encoded TypeCode.

    For GIOP 1.3 and above, the indirection applies only to TypeCodes nested
    within some “top-level” TypeCode, or from one top-level TypeCode to another.
    Indirected TypeCodes nested within a top-level TypeCode can only reference
    TypeCodes that are part of the same top-level TypeCode, including the
    top-level TypeCode itself. Indirected top-level TypeCodes can reference
    other top-level TypeCodes but cannot reference TypeCodes nested within
    some other top-level TypeCode.

  • Reported: CORBA 2.6 — Fri, 21 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with chunking

  • Key: CORBA3-43
  • Legacy Issue Number: 4806
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    15.3.4 is silent on the treatment of encapsulations containing chunked valuetypes and in particular chunked valuetypes containing encapsulations containing chunked valuetypes. My understanding of encapsulations leads me to believe that the encapsulation should ignore the current nesting level and chunk length and start from scratch, i.e. chunks within an encapsulation are calculated relative to the start of the encapsulation rather than relative to the stream.

    The reason this needs clarification is because the spec goes to great lengths to make sure chunks are not nested so I think that it would be clearer if this case was specifically discussed. Additionally I don't know whether 15.3.4.6 should include encapsulations in the list of data types that cannot be split across a chunk. In general you would probably have to read the entire encapsulation before you can decode it, so allowing it to be split across chunks might be problematic.

  • Reported: CORBA 2.6 — Tue, 15 Jan 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify as shown below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wide string in reply before codeset was negotiated

  • Key: CORBA3-47
  • Legacy Issue Number: 4824
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Martin von Loewis posed the following rather intersting question in
    comp.object.corba:

    > Also notice that you must perform character set negotiation to
    > communicate wstring values, unlike string values. You don't have to do
    > that in the first message, though, but sometime before the first wide
    > string is transmitted (I wonder what happens if the client does not
    > negotiate a character set in its first message but the server wants to
    > sent back a wstring response, e.g. inside an any).

    The current codeset negotiation rules don't address this problem.

  • Reported: CORBA 2.6 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapters 13.10.1.9, and 13.10.1.12 -- issue

  • Key: CORBA3-41
  • Legacy Issue Number: 4725
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapters 13.10.1.9, and 13.10.1.12] apparently indicate that both TCS-C
    and TCS-W can be byte-oriented or non-byte-oriented.

    Assume the following configurations for two communicating ORBs.

    CNCS-C = windows-1252, SNCS-C = ISO-8859-1, and CCCS-C = SCCS-C =

    {UTF-16}

    .

    The execution of the OMG code set negotiation algorithm [3, Chapter
    13.10.2.6] in this case will result in the value of the TCS-C as UTF-16!

    An IDL string will then be marshalled as UTF-16 encoded data, which may
    have embedded single-octet NULLs. This point should be mentioned explicitly
    somewhere in [3, Chapter 15.3.1.6], especially when IDL string data types
    are not allowed to contain any embedded NULLs [3, Chapter 3.10.3.2]. [3,
    Chapter 15.3.1.6] states that "Both the string length and contents include
    a terminating null". If TCS-C is selected to be UTF-16, this 'null' should
    be a null of two-octet size. [3, Chapter 15.3.1.6] should be explicit in
    stating that the concrete representation of the 'terminating null' is
    dependent on the TCS-C.

    Similarly, for the following configuration
    CNCS-W = UCS-2, SNCS-W = UCS-4, and CCCS-W = SCCS-W =

    {UTF-8}

    TCS-W will be selected as UTF-8!

    Are these configurations valid? Regardless of the answer to this question,
    [3, Chapters 13.10.1.9, and 13.10.1.12] should clarify the issue of the
    orthogonality of TCS with respect to the byte-oriented and
    non-byte-oriented code sets with appropriate examples.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP 1.2 encoding of wstring

  • Key: CORBA3-40
  • Legacy Issue Number: 4724
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapter 3.10.3.2] defines an IDL wstring data type to be a sequence of
    wchars. But the GIOP 1.2 encoding of wstring is defined differently [3,
    Chapter 15.3.2.7]. A GIOP 1.2 encoded wstring is not a sequence of GIOP 1.2
    encoded wchars.

    Each individually encoded wchar is associated with an octet containing the
    size of the encoded wchar in octets [3, Chapter 15.3.1.6], whereas an
    encoded wstring is associated with an unsigned long containing the length
    of the entire wstring in octets. Probably [3, Chapter 15.3.2.7] should
    clearly mention and explain this point with sample layout diagrams of
    appropriately encoded wchars and wstrings.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORBs using BOMs for UTF-16 (closely related to issue 4008)

  • Key: CORBA3-39
  • Legacy Issue Number: 4723
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapter 15.3.1.6] mentions the use of BOM to indicate (and override the
    OMG byte order indicator flag [3, Chapter 15.2.1]) the endian-ness of the
    UTF-16 encoded wchar or wstring data.

    This is incorrect and goes against the Unicode recommendations [1]?refer to
    the Unicode conformance clause C3 [4, Chapter 3.1], and the discussion
    related to the use of BOM [4, Chapter 2.7].

    [4, Chapter 3.1] unambiguously implies that a BOM is not necessary if a
    higher-level protocol indicates the endian-ness. [4, Chapter 2.7]
    categorically states: "if other signaling methods (the OMG byte order flag
    in this context) are used, signatures (BOM) should not be employed".

    The UTF-16 endian rules of [3, Chapter 15.3.1.6] are clearly influenced by
    [2]. In the MIME world, an initial U+FEFF or U+FFFE is interpreted as BOMs.
    The BOM (or its absence) indicates the endian-ness of UTF-16 encoded data
    in the internet MIME world. But for CORBA messages or CDR encapsulations,
    the OMG byte order flag is already explicitly marking the UTF-16 encoded
    data as UTF-16BE or as UTF-16LE. U+FEFF or U+FFFE should not be used as
    BOMs for UTF-16 encoded data in the CORBA domain.

    Therefore, it is proposed that any U+FEFF or U+FFFE, regardless of their
    positions in the marshalled data, must be interpreted as ZERO WIDTH
    NO-BREAK SPACE characters, and not as BOMs. All the references to BOM in
    [3, Chapter 15.3.1.6] must be removed altogether.

    Adoption of the above Unicode conformant rule will
    – result in more efficient encoding of wchar/wstring data?no need to place
    U+FFFE for little-endian UTF-16/UTF-32 wchars/wstrings,
    – eliminate the ugly situation, where the BOM of an UTF-16/UTF-32 encoded
    wchar/wstring data contained in a message or CDR encapsulation indicate a
    different byte order than that specified by the OMG byte order flag for the
    same message or CDR encapsulation.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This proposal results in a complete reversal of an earlier adopted resolution, and hence would be in

  • Updated: Fri, 6 Mar 2015 20:58 GMT