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

purely editorial issue

In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
is this text:

"Declarations for facets, receptacles, event sources, event sinks,
and attributes all map onto operations on the component's equivalent
interface. These declarations and their meanings are described in
detail below."

In the following sections, I see facets, receptacles, event sources,
and event sinks described, but I see no mention of attributes.
It would be usefult to have an example of attributes in an appropriate
place, as outlined by section 1.3.3.

In section "1.10 Configuration with Attributes", I see that configurators
are described, but I see no example of using attributes directly
to configure a component.

It would be very useful to include a small example to illustrate
how to configure a component directly by using attributes.

Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):

======================================================

component Whatever

;

home WhateverHome manages Whatever
{
};

// C++
WhateverHome_var weh = // obtain ref
Whatever_var we = weh->create();

we->cacheMaxKb(200);

we->configuration_complete();

======================================================

I don't suggest that this example be used verbatim,
but a similar example would be useful to have in the
CCM spec.

duplicate of issue 5898

Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface." Moreover the sentence you depicted is a contradiction with the formal/02-06-65 section 1.3.2.4 page 1-7.
Resolution:

In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence

"A derived component type may not directly support an interface."

with

"If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both the interface of its base component type and the supported interfaces."

No Data Available

there is a serious error in Chapter 21 in both the CORBA 3.0 specification and the 3.1 drafts. The ORT final adopted specification (ptc/01-08-31 mentioned above) does NOT contain the methods ObjectReferenceFactory::equals an ObjectReferenceFactory::make_profiles. These methods were first added in the ORT FTF in issue 4476, then removed after further discussion in issue 4478. The final adopted specification reflects this, but somehow the incorrect text was incorporated into the official CORBA 3.0 specification. Unfortunately I only noticed this recently

issue closed editorially

Section 11.3.2.5 states that BAD_INV_ORDER with minor code 6 is raised
if POAManager::deactivate is called from an invocation on a POA that
would be affected by the deactivate call.

This minor code ought to be 3 instead

editorially fixed in 3.0

It is used by RealTime CORBA as documented in 24.17.2

non issue...editorial, issue withdrawn

chapter 69.4.5.4
"The information obtained by (...) it allows component assembly
tools to decide WHAT ports
on a component are capable (...)"
it seems that the word "which" would be better than "what" in
this sentence

Replace "what" by "which".

> // ulgy conversion to objectref: we should think about
> // creating utilities for IOR<->objref conversion

I meant to raise that second issue (the ugly IOR to ObjRef conversion).
It is too painful and I think we should address it. I can think of a few
possible solutions.

1. have make object just return profiles, so the ORB can do the
conversion internally.
2. Add a method on the ORT to provide this functionality
3. Add a separate CODEC interface to manufacture IORs from Profiles
(IORFactory, rir etc)

Undo the resolution of issue 4476 and close 4478 no change

If I wish to register an ORF (ObjectReferenceFactory) as the current
factory, there is no way for it to append to the current template. In
other words, an updated factory can only replace the original but not
say add another profile to the one the given POA would generate w/ the
adapter template.

As an inverse, there is no way for a POA to require or even request an
ORF to include profiles that it deems fit.

Proposal:

Add a parameter to make_object

Object make_object( in string repositoryId, in ObjectId id,
ObjectReferenceTemplate template);

Add the following methods to ObjectReferenceTemplate

abstract valuetype ObjectReferenceTemplate : ObjectReferenceFactory

;

where ProfileSeq is defined as

module IOP

Add the following sections:

21.5.3.8 getProfiles

This returns the set of profiles that the POA would have generated using
its default template. This can optionally be included in the generated
IOR.
[ED: This is independent of make_object, because make_object returns an
object reference from which profiles would have to be extracted for
inclusion]

21.5.3.9 getComponents
This returns set of components that would have been include in the
profile with the id profile_id and allows the factory to choose to
include those in the profiles that it generates.

see above

Nothing in the specs (I think the submission does say this somewhere)
say that the valuetypes defined in this spec and implemented by the ORB
vendor are not expected to be transmitted across different ORB
implementations.

Proposal:

Add paragraph to 51.5.3.1:

Concrete definitions and implementations of ObjectReferenceTemplate and
ObjectReferenceFactory are ORB implementation specific and are not
defined as they are not expected to be exchanged between ORB
implementations.

Add a clarification to the specification

The adopted specification for the Object Reference Template is
ptc/01-04-03. This specification introduces adapter names for
object adapters. Adapter names are needed in the definition of the
ObjectReferenceTemplate abstract valuetype. An AdapterName is
simply a sequence of strings that is used to identify an
instance of an object adapter.

In the case of the POA, the spec defines the AdapterName as follows
in section 21.5.2.1:

In the case of the POA, the adapter name shall be the sequence
of names starting with the root POA that is required to reach
the POA using the find_POA call. The name of the root POA is
the empty sequence.

Also, in section 21.3.14.6:

The adapter_name attribute defines a name for the object adapter that
services requestws for the invoked object. In the case of the POA,
the adapter_name is the sequence of names from the root PAO to the POA
that services the request. The root POA is not named in this sequence.

The problem here is that the POA occupies the entire name space of
possible adapter names, so an ORB that supports other proprietary
object adapters cannot unambiguously identify instances of other
object adapter through ServerRequestInfo.adapter_name.

Update the specification so that the Object Adapter ID of the root POA is

Productions 140, 141, 142 and 143 must be removed. Catalog has been
removed
from the PSS specification.
Production 145 : <home_executor_body> refers to <stored_on_dcl> which is
defined in production 151
as <home_persistence_dcl>. Pick one or the other and changes references
as required ...
Productions 149 and 150 are not valid any more. Remove them and add a
new production :
<abstract_storage_home_name> ::= <identifier>
identifier must be the name of an abstract storagehome previously
declared

see above

• Capital letters are not appropriated. Correct "storageHome" with
  "storagehome".
• The keyword "catalog" must be removed as it was removed from PSDL.

see above

In ptc/01-11-03, page 64-410, there is the following note

Issue This table will be completed after the Interface Repository
chapter is ready.

Then Table 5-13 in formal/02-06-65 would be completed.

No Data Available

The Adopted CORBA Components Specification (formal/02-06-65)
always contains some texts removed by the Components December
2000 RTF (ptc/01-11-02 and ptc/01-11-03). See at

formal/02-06-65 ptc/01-11-03

page 1-24 and 25 page 61-241
page 1-26 page 61-243
page 1-28 page 61-245
page 4-37 page 62-363
page 6-67 page 69-542
page 6-72 page 69-548
page 8-23 page 70-601

Remove these old texts once again.

Proposed revised text:

Following must be applied on formal/02-06-65.

At pages 1-24 and 1-25, remove

module <module_name> {
module <component_name>EventConsumers

;
interface <component_name> : Components::CCMObject

;
module <component_name>EventConsumers {
interface <event_type> Consumer :
Components::EventConsumerBase

;
};
};

At page 4-37, remove in Session2Context interface
the two occurrences of PortableServer::ObjectId.

At page 6-67, remove

Note Of the interfaces described below, only
ComponentInstallation,
AssemblyFactory, and Assembly are required by this specification;
the other
interfaces are included for illustrative purposes and to support an
end-to-end scenario.

At page 6-72, remove

exception InvalidLocation { };

At page 8-23, remove Figure 8-20.

see above

Proposed resolution:

The Adopted CORBA Components Specification (formal/02-06-65)
always contains the section 4.4.1.4 at page 4-36.

However, this section was removed in the ptc/01-11-03 document
by the resolution of the issue 3937 of the Final Report of
Components December 2000 FTF (ptc/01-11-02).

Proposed revised text:

In formal/02-06-65 page 4-36, remove the section 4.4.1.4.

see above

The name of the create operation in the AssemblyFactory Interface shall
be renamed to a more specific identifier. Create is often used in other
interfaces and this may lead to problems e.g. in inheritance relationships.

suggested change:

create -> create_assembly

see below

Productions must be renumbered : 134 -> 1, ...

In all productions, replace ...storage_home... by ...storagehome... and
...storage_type...
by storagetype...

see above

1. 69.8.2.1 The properties Root Element, page 69-537
Properties Element Cardinality. Suggested change is to replace "*" with "
+".
Why does it make sense to have an empty properties file, since the
properties are
optional references in the Software Package DTD, CORBA Component DTD, and
Component Assembly DTD?

Current Format

<!ELEMENT properties
( description?
, ( simple

Suggested New Format

<!ELEMENT properties
( description?
, ( simple

No Data Available

In the CCM specification document ptc/2001-11-03 page 61-227
the 'session' word should be removed from the OMG IDL 3.0
example, i.e.:

component baz session {

should be replaced by:

component baz {

Correct the typo by removing the 'session' word

In the Adopted CORBA Components Specification (formal/02-06-65),
page 6-4, section 6.3.2.1, the version attribute of the softpkg
element is tagged as #OPTIONAL and is tagged as #IMPLIED at page 7-5.
As #OPTIONAL is not valid in XML, then replace it by #IMPLIED.

In chapter 7, the softpkg XML DTD does not contain the
ins and objref elements which they are used by the repository
element described at page 7-4. Add them.

Proposed revised text:

In formal/02-06-65:

At page 6-4, section 6.3.2.1, replace #OPTIONAL
by #IMPLIED for the version attribute of the softpkg element.

At page 7-3, add before the humanlanguage element

<!ELEMENT ins EMPTY >
<!ATTLIST ins
name CDATA #REQUIRED >

At page 7-4, add before the os element

<!ELEMENT objref EMPTY >
<!ATTLIST objref
string CDATA #REQUIRED >

see above

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)>

see above

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."

see above

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.

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

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.

see above

chapter 695.4
the elements aren't in the alphabetical order
proxyhome must be placed before publishesidentifier

see above

chapter 69.7.2.38
the processcollocation element given in this chapter lacks a
DESTINATION child element
right one:
<!ELEMENT processcollocation
(usagename?
, impltype?
, (homeplacement

see above

In 01-11-03.pdf page 61-255

Given a base home definition with a primary key (H, T, K), and a derived home
definition with no primary key (H', T'), such that H' is derived from H, then the
definition of H' implicitly includes a primary key specification of type K, becoming
(H', T', K). The implicit interface for H' shall have the form specified for an
implicit interface of a home with primary key K and component type T'.

In same document section 615.3.3.6 Home I see no mention that a keyless
home that inherits from a keyed home is implicitly a keyed home and thus
the Home Implicit Executor Interface must be constructed for a keyed home
using the key type declared for the base keyed home. Everyone agree?

see above

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);

see above

In document 01-11-03.pdf section 69.8.2.8 the simple type element
of the property file descriptor excludes the types:

long long
unsigned long long
long double
wchar

Is there any reason why we can't add these types to the simple element?

see above

chapter 69.7.2.25
the given reference to the fileinarchive element is wrong
(69.3.2.11);
the right one is 69.3.2.12

Correct the false cross-reference

chapter 69.4.5.16
this eventpolicy element is said to be child element of
corbacomponent
in fact it can be child element of: consumes, emits, publishes
but it's NOT a child element of corbacomponent

see above

chapter 69.4.4
the sample componentkind definition given as an entity with
"process" lifetime seems
unadapted as described in 69.4.5.49, we can give a best lifetime
with "container"

see above

Isit possible to add a ClientInterceptor then create_POA() in the
post_init()
method? It seems that the ClientInterceptor is not called after that. Do
you know the
reason why?

My Investigation:
If the post_init method in SampleClientLoader.C creates the new POA
using create_POA method, the client side PI will not be called. Even if
an ORB-mediated call is made from within post_init(), ServerInterceptor
is called beyond the scope of post_init(). Moreover, even if an
ORB-mediated call is made from within post_init() in VisiBroker for
Java, ClientInterceptor and ServerInterceptor are called beyond the
scope of post_init(). However, in Visibroker for C++, the
ClientInterceptor of VBC is not called. Please see the attachments for
the difference in results of VBC & VBJ. A testcase is also attached.

Any comments will be greatly appreciated.

close no change

How can a portable OTS implementation, using only Portable Interceptors,
achieve the correct semantics for raising CORBA::WrongTransaction from
Request::get_response or ORB::get_next_response or type specific
pollers? There doesn't appear to be a way to do this for two reasons:

1. ClientRequestInterceptors can only change a request result into a
system exception, but WrongTransaction is a user exception.

2. 21.4.4.6 says:

"Interceptors shall assume that each client-side interception point
logically runs in its own thread, with no context relationship between
it and any other thread. While an ORB implementation may not actually
behave in this manner, it is up to the ORB implementation to treat
PICurrent as if it did."

I take this to mean that the PICurrent in the receive_* client
interception points cannot be guaranteed to share the same slot data as
the client thread that called Request::get_response. This means that
the interceptor has no way to determine whether or not the transaction
context of the client thread matches that of the request.

Resolved together with 3599. Resolution appears in the resolution for 3599

In the messaging callback model, the response is delivered as a request
invocation on another object. What is the call-pattern for
ClientRequestInterceptors in this case?

My guess is that the receive_other interception point is called for each
registered ClientRequestInterceptor.

close no change

There is no information in chapter 21 that specifies which operations on
ORBInitInfo can be legally called during pre_init or post_init.

The intention appears to be that calls to register new interceptors or
allocate a new slot id should be illegal during post_init.

Calling resolve_initial_references during pre_init does not appear to be
wise, but otherwise seems benign.

Proposed resolution:

Add the following to 21.7.1.2:

"During a call to post_init(), invoking the ORBInitInfo methods:
add_client_request_interceptor, add_server_request_interceptor,
allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER
standard system exception with minor code nnn."

Fix it as suggested in the archive.

21.7.2.3 states:

"This attribute contains the arguments passed to ORB_init. They may or
may not contain the ORB's arguments."

First, what good does this do? A portable application can't depend on
anything useful being returned by this attribute.

This should be changed to state that ORBInitInfo::arguments() returns
the original unmodified argv parameter that was passed to ORB_init.

Second, this attribute really ought to be read-write, so that an
Interceptor implementation can find and strip out arguments that are
intended for the Interceptor.

Alternatively, we should specify a standard prefix for arguments that
are recognized and processed by interceptors, so that the ORB and client
code can be explicitly coded to recognize and ignore them.

see above

It is undocumented what should happen if an exception is thrown while
the ORB initialization process is calling ORBInitializer::pre_init or
post_init.

In section 21.7.3.1 concerning the Java binding, the following statement
related to calling pre_init and post_init appears:

"If there are any exceptions, the ORB shall ignore them and proceed."

Taking this as precedent, it suggests that exceptions raised by pre_init
and post_init should be ignored. However, I'm not convinced that this
is a good idea, since a failure in an ORBInitializer is very likely to
cause the application to fail in mysterious ways later on that would be
difficult to debug.

I think it would be better to define explicit behavior for exceptions
raised from pre_init and post_init to be that the ORB initialization is
abandoned and the ORB is destroyed. Any ORBInitializer implementation
that really needs the ORB to ignore any thrown exceptions can simply
catch and discard them itself.

see above

Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface."
Resolution:

In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence

"A derived component type may not directly support an interface."

with

"If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both the interface of its base component type and the supported interfaces."

see above

A bullet in 3.8.7 states:

"o A local type may not appear as a parameter, attribute, return type,
or exception declaration of an unconstrained interface or as a state
member of a valuetype."

while 3.9.1.4 says:

"A valuetype that has a state member that is local (i.e. non-marshalable
like a local interface), is itself rendered local. That is, such
valuetypes behave similar to local interfaces when an attempt is made to
marshal them."

I presume the second statement is the correct one.

Proposed resolution:

Strike "or as a state member of a valuetype." from the bullet in 3.8.7.

Presumption is correct. Fix as suggested

Is there a particular design reason to limit the Pollable count to
65535?

Incorporate change and close issue

The descriptions of Pollable and PollableSet in 7.4 do not indicate if
it is legal to add a Pollable to more than one PollableSet. If this is
made illegal, it is easier to implement Pollable and PollableSet to
cooperate behind the scenes to improve the efficiency of the PollableSet
implementation.

Recommended Resolution:

Make it illegal to add a Pollable to more than one PollableSet, by
adding the following text to 7.4.3.2:

"If the supplied Pollable has already been added to another PollableSet,
this operation raises the standard BAD_PARAM system exception with minor
code XYZ.

and add a new minor code for BAD_PARAM to appendix A:

"XYZ: Attempt to add a Pollable to a second PollableSet."

see above

Somewhere in the discussion in 22.6, it should specify that oneway
operations are not mapped with sendc_ and sendp_ variants, because they
would be useless.

see above

7.2.10 states that sendc delivers the reply by using the supplied
Messaging::ReplyHandler, but it does not spell out the mechanics of the
delivery.

I presume that for an invocation of operation "foo", the "foo" or
"foo_excep" methods of the ReplyHandler will be invoked to deliver the
reply

Yes, indeed. Insert a short description in section 7.10.2 on how the reply is obtained from the Repl

The example code in 22.11.4.3 seems to be from a draft version of the
Messaging specification where the Pollable type was an interface rather
than a valuetype

Turns out that the examples in both 22.11.4.2 and 22.11.4.3 need fixing. Make changes as described

22.10.1 states that Type-Specific poller valuetypes inherit from the
poller valuetype associated with the interface that the original
interface inherits from. This does not address multiple inheritance,
and in fact it cannot, since valuetype inheritance is more limited than
interface inheritance.

The problem is that the base valuetype for polling, Messaging::Poller,
is not abstract, and cannot be inherited more than once by a derived
valuetype. So as it stands now, the AMI polling model is broken for
multiple inheritance, and needs to be treated as an urgent issue in
order to produce an immediate fix.

Proposed resolution:

1. Make Messaging::Poller an abstract valuetype, and remove the state
members from it. Change the IDL for Poller in 22.9 and 22.16.1 to:

module Messaging {
abstract valuetype Poller : CORBA::Pollable

;
};

2. Add back the private target and op_name state members to the
persistent type-specific poller valuetypes. Modify the example IDL in
22.10.2 to:

valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller

;

This is necessary so the PersistentPoller can be propagated from one
process to another with all of its necessary state.

3. Change the text in 22.10.1 that describes inheritance of
type-specific pollers to:

For each interface, the IDL compiler generates a type-specific Poller
value. A Poller is created by the ORB for each asynchronous invocation
that uses the polling model operations. The name of the basic
type-specific Poller is AMI_<ifaceName>Poller, where ifaceName is the
unqualified name of the interface for which the Poller is being
generated. If the interface ifaceName derives from one or more IDL
interfaces, then the Poller is derived from the corresponding
Poller for each base interface, but if it does not, then it is derived
from Messaging::Poller. Poller valuetypes are declared abstract. If
this name conflicts with definitions in the original IDL, additional
AMI_ prefixes are prepended before <ifaceName> until a unique valuetype
name is generated (such as "AMI_AMI_FooPoller"for interface Foo).

4. Change the example IDL in 22.10.3 to make the poller abstract:

// AMI implied-IDL of type-specific Poller
// for original example IDL defined in Section 22.5
abstract valuetype AMI_StockManagerPoller : Messaging::Poller {
...

and add the target and op_name private state members to the persistent
poller:

valuetype AMI_StockManagerPersistentPoller : AMI_StockManagerPoller

;

Make the changes recommended in the archive

The rule for generating a unique AMI_ callback or poller name is to
stuff additional "AMI_" strings until the name is unique. However,
consider the following IDL:

// IDL
module M {

interface A {
};

interface AMI_A {
};

};

this apparently maps to the implied IDL:

// implied IDL
module M {

interface A {
};

interface AMI_AMI_A

;

interface AMI_A {
};

interface AMI_AMI_AMI_A

;
};

however, if I switch the order of declaration of A and AMI_A, the names
of the associated callback interfaces change.

Not only that, but if I split the IDL into two files:

// File 1
module M {

interface A {
};
};

// File 2
module M {
interface AMI_A {
};

};

and try to compile them separately, the generated code will fail.

I don't think there is any solution to this problem other than to
declare it an error to use an IDL identifier that begins with "AMI_" if
it causes a name clash.

The same problem applies to the AMI poller valuetypes.

Resolution: Insert the requirement that any IDL that is meant to be used for AMI should not have any

The name generated for the type-specific poller timeout argument is
"timeout", which could clash with a real IDL argument name.

The name should be changed to "ami_timout", similar to "ami_return_val".

make it so

There is no information in chapter 21 that specifies which operations on
ORBInitInfo can be legally called during pre_init or post_init.

The intention appears to be that calls to register new interceptors or
allocate a new slot id should be illegal during post_init.

Calling resolve_initial_references during pre_init does not appear to be
wise, but otherwise seems benign.

Proposed resolution:

Add the following to 21.7.1.2:

"During a call to post_init(), invoking the ORBInitInfo methods:
add_client_request_interceptor, add_server_request_interceptor,
allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER
standard system exception with minor code nnn."

duplicate of issue 5691

The spec is silent about the interaction of AMI implied IDL and abstract
interfaces

Clarify that sendc_ and sendp_ operations are not generated for abstract interfaces

Question: Is it legal to send the same codeset context more than once
on the same connection?

The spec says:

Codeset negotiation is not performed on a per-request basis,
but only when a client initially connects to a server.

These words suggest that the codeset must be sent on the first request,
but don't say whether it's OK to send it more than once.

I would like to have clarification, and also a loose interpretation. Here
is why:

A multithreaded client starts talking to a new object from
multiple threads more or less simultaneously. If the codeset
info must be sent only on the first request and is illegal on
subsequent requests, we end up with rather complex locking
logic in the connection management layer of the ORB. In effect,
each request is no longer a stand-alone and context-free thing;
instead, how to send a specific request now depends on what
other threads may have done in the past.

That's not very nice (even though it can be implemented) because
it needlessly complicates things.

So, I would like to change things such that it is legal to send the
codeset context even if it was sent previously on the same connection.
When that happens, the server should simply and silently ignore all
but the first context (even if the subsequent contexts have different
codeset information from earlier ones). That way, requests remain
context-free. [ Yet again, we see a sterling demonstration that attaching
semantics to the duration of a connection was a very bad idea, especially
in a model that is connectionless ]

Further, it seems pointless to send codeset info at all unless the client
actually uses an operation that involves a wchar or wstring parameter.
So, I think it would make sense to relax things such that the codeset
need not be sent until the first request is made that requires sending it.

see above

Summary: It does not appear that reply service contexts are maintained when retrieving
polled requests from a Router. Although the Router interfaces properly
propogate the service contexts to the the untyped reply handler representing the
PersistentRequest, there is no way for the client to retrieve these contexts
from the PersistentRequest::get_reply. This may make it impossible for the
client to interpret the reply data (e.g. if the reply contained CodeSet
contexts).

see above

The core spec says in section 4.11.3:

Typecode creation operations that take name as an argument shall check that
the name
is a valid IDL name or is a null string.

This is oxymoronic: we are talking about IDL here; IDL does not have the
concept of
a null string. If anything, we can say "empty string".

Looking at this bit of spec, it would appear that a call such as

orb->create_interface_tc(someRepId, 0);

is legal. But that doesn't make sense because it's illegal to pass null
pointers
across IDL interfaces in C++ (or null references as strings in Java).

Fix as suggested

Document: Chapter 24 Corba, CSIv2

There is a misinterpretation in the current JDK implementations as to the
interpretation of the word of "encapsulation" in the CSIv2 specification
in relation to the encoding of the fields within the CSI Identity Token.

The issue is that the JDK and already certified implementations have
performed a CDR encapsulation of the byte arrays within the Identity
Token. This CDR encapsulation is not needed as the the Identity Token is
already a CDR encapsulation, so further CDR encapsulating the byte array
containing the ASN.1 encodings is inefficient.

We can suggest that current implementations do not generate CDR
encapsulation for these fields, yet accept them to be compatible with
misaligned implementations.

Proposed Fix:

Remove the word "encapsulation" before "octet stream" from the rows of the
table 24-2 "Identity Token Types".

Remove the word "encapsulation" in the paragraph in section 24.2.3
"Authorization Token Format".

Remove the word "encapsulated" in the comments in the IDL section for the
definition of the X509CertifcateChain.

Remove the sentence "The two-part SEQUENCE is encapsulated in an octet
stream." in the IDL definition for "const AuthorizationElementType
X509AttributeCertChain".

Add paragraph to section 24.2.5 "Identity Token Formats".

The identity token for ITTPrincipalName, ITTDistinguishedName,
ITTX509CertChain should contain their respective ASN.1 encodings of the
name directly. However, the token may contain a CDR encapsulation of the
octet stream that contains the ASN.1 encoding of the name. The TSS shall
distinguish the difference by the first octet of the field. The values of
0x00 or 0x01 shall indicate that the field contains a CDR encapsulation.
Any other value indicates the field for these identity token types
contains the ASN.1 encoded value. For instance, the ASN.1 encoding for
ITTPrincipalName starts with 0x04, and ITTDistinguishedName and
ITTX509CertChain each start with 0x30. The TSS shall accept both the CDR
encapsulation form and the direct ASN.1 encoding for these identity token
types.

Indeed a severe interoperability problem. Fix as suggested.

The generated type-specific poller valuetypes generated for an interface
should be abstract valuetypes and should inherit the corresponding
type-specific poller valuetypes of the base interfaces.

Without this, code reuse is prevented in both implementing the
type-specific poller valuetypes, as well as in using them in client
code.

The resolution of 5666 fixes this. Close this one no change with that comment

The definintion of Messaging::Poller in section 22.9 is missing the
keyword "private" on the target & op_name valuetype attribute
declarations.

The persistent poller in 22.10.2 is also missing a "private" on the
"outstanding_request" attribute, as well as the example in 22.10.3.

Resolution: Fix as suggested. No problem with versioninhg since the published IDL already contains t

22.10.3 has bad example code for the type specific poller generated for
the StockManager interface. The AMI_StockManagerPoller is shown with
the following:

valuetype AMI_StockManagerPoller : Messaging::Poller

;

This is illegal, since Messaging::Poller also defines an attribute named
"associated_handler". Since the text does not specify that this
attribute ought to be generated in a type-specific poller, I suspect
that this is an editing mistake from a draft version of the Messaging
RFP response and should be removed.

The C++ example generated code in 22.11.4.2 also needs to be edited to
remove the associated_handler attribute as well.

The observation above is correct. Fix it

I was reading the CORBA specification (formal/02-06-01) concerning the
SyncScope for oneway invocations. I found out that there is a mismatch on
the meaning of SYNC_WITH_TARGET:

On page 21-23 (Request Interceptors), there is the following paragraph:

"For SYNC_WITH_SERVER and SYNC_WITH_TARGET, the server does send an empty reply back to the client before the target is invoked."

That is true for SYNC_WITH_SERVER, but not correct according to the specification of the CORBA Messaging service, given on page 22-7:

"SYNC_WITH_TARGET - equivalent to a synchronous, non-oneway operation in CORBA. The server-side ORB shall only send the reply message after the target has completed the invoked operation."

Note that a reply is send back to the client AFTER the target has completed the invoked operation, not BEFORE.

This error has been around already in eariler versions of the CORBA specification.

The statement about SYNC_WITH_TARGET in 21-23 is indeed wrong. Fix it.

Section 22.2.4 provides various time-based policies to bound the
delivery and lifetime of requests, but has no information about who
(client, router or target server) is responsible for enforcing those
policies. Without this information, there will certainly be
interoperability issues.

Fix it as suggested in the archive with a few minor changes

The Time service states that determining if a TimeT or UtcT value is
absolute or relative needs to be specified by the context. One presumes
that the Messaging RequestStartTimePolicy, RequestStopTimePolicy,
ReplyStartTimePolicy and ReplyEndTimePolicy contain absolute timestamps,
and that RelativeRequestTimeoutPolicy and RelativeRoundtripTimeoutPolicy
contain relative timestamps. The specification should make the context
explicit.

see above

Does it make sense (and is it legal) for a request to be sent with a
RequestPriorityPolicy or ReplyPriorityValue in a service context where
the min and max priorities are not the same? Is a router allowed to
pick any value in the range for a priority?

Close no change

What is the expected behavior of a server or router that receives a
request with a RequestEndTimePolicy or ReplyEndTimePolicy value that has
expired? Who is responsible for generating the TIMEOUT exception--the
client or server or both?

This issue is a subset of issue 5626. Merge it with 5626 and close this issue

How does Object::validate_connection() interact with RoutingPolicy
values of ROUTE_FORWARD or ROUTE_STORE_AND_FORWARD? Should
validate_connection() force the client to open a connection to a message
router and fail if it cannot?

see above

In CORBA 3.0 section 4.3.8.1, the description of the Object::get_policy
operation says:

"Invoking non_existent on an object reference prior to get_policy
ensures the accuracy of the returned effective Policy.Ifget_policy is
invoked prior to the object reference being bound, the returned
effective Policy is implementation dependent. In that situation, a
compliant implementation may do any of the following: raise the standard
system exception BAD_INV_ORDER, return some value for that PolicyType
which may be subject to change once a binding is performed, or attempt a
binding and then return the effective Policy."

This is silly, since the only portable thing that applications can do is
to call validate_connection or non_existent before calling get_policy,
having two other non-portable behaviors just serves to make the standard
larger and confuse users.

We should pick one of the two reasonable behaviors--throw BAD_INV_ORDER
or force a binding before returning a valid policy value--and make that
the only valid behavior. Either one will be backwards compatible with
portable code.

Makes sense. Fix it as suggested

4.3.7.2 says:

"Returns the effective overriding Policy for the object reference. The
effective override is obtained by first checking for an override of the
given PolicyType at the Object scope, then at the Current scope, and
finally at the ORB scope. If no override is present for the requested
PolicyType, the system-dependent default value for that PolicyType is
used. Portable applications are expected to set the desired defaults
at the ORB scope since default Policy values are not specified."

Some policies may not have a sensible default value, such as
RequestStartTime and in fact, perhaps should not have one to avoid
putting any value in the INVOCATION_POLICIES service context. In this
case, it would be better if get_client_policy were allowed to return a
nil Policy reference.

Suggested revision:

Change the sentence that reads:

"If no override is present for the requested PolicyType, the
system-dependent default value for that PolicyType is used."

to:

"If no override is present for the requested PolicyType, a
system-dependent default value for that Policy Type may be returned. A
nil Policy reference may also be returned to indicate that there is no
default for the policy."

Fix as suggested

4.12.3.32 states:

> REBIND is raised when the current effective RebindPolicy, as described in
> Section 22.2.1.2, interface RebindPolicy on page 22-5, has a value of
> NO_REBIND or NO_RECONNECT and an invocation on a bound object reference results
> in a LocateReply message with status OBJECT_FORWARD or a Reply message with
> status LOCATION_FORWARD. This exception is also raised if the current effective
> RebindPolicy has a value of NO_RECONNECT and a connection must be re-opened.
> The invocation can be retried once the effective RebindPolicy is changed to
> TRANSPARENT or binding is re-established through an invocation of
> CORBA::Object::validate_connection.

but 22.2.1.2 says:

> If the effective Policy of this type has a rebind_mode value of NO_REBIND, the
> ORB will raise a REBIND system exception if any rebind handling would cause a
> client-visible change in policies. This could happen under the following
> circumstances:
>
> o The client receives a LocateReply message with an OBJECT_FORWARD status and a
> new IOR that has policy requirements incompatible with the effective policies
> currently in use.
>
> o The client receives a Reply message with LOCATION_FORWARD status and a new
> IOR that has policy requirements incompatible with the effective policies
> currently in use.

So the former says that a REBIND exception always occurs a rebind is
necessary (and NO_REBIND is set), but the latter says that a REBIND
exception only occurs when any client-visible policies would change.

Which one is correct?

Also, it is not clear from the specification whether an invocation on a
new object reference that has never been bound must fail if RebindMode
is not TRANSPARENT, forcing the use of validate_connection, or whether
the first initial binding can proceed without the use of
validate_connection.

see above

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

see above

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.

Provide means for the optimization as shown below

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.)

see above

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'

see above

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.

see above

From the descriptions in CORBA 2.6.1 sections 7.2 and 7.2.3, the
BAD_INV_ORDER minor codes 5 and 10 appear to mean the same thing. We
should officially deprecate one, or state that either is acceptable

Easiest fix is to state either is acceptable

I have recently realized that there is a serious backward compatibility
issue in the PI changes introduced by the Object Reference Template.
The problem is in the IORInterceptor. The original PI specification
defined only the establish_components method on IORInterceptor.
ORT added 3 new methods to this interface: components_established,
adapter_state_changed, and adapter_manager_state_changed.

The compatibility problem arises with the Java mapping. Prior to
the CORBA 3.0 IDL to Java mapping, local interfaces were simply
mapped to interfaces. The mapping for the CORBA 3.0 IORInterceptor
is then simply:

public interface IORInterceptorOperations
extends org.omg.PortableInterceptor.InterceptorOperations

public interface IORInterceptor extends IORInterceptorOperations,
org.omg.PortableInterceptor.Interceptor, org.omg.CORBA.portable.IDLEntity
{
}

Any client of PI that implements IORInterceptor from CORBA 2.6 defines only the
establish_components method, so that client will fail on a CORBA 3.0 version of PI.

I propose the following changes to the draft CORBA 3.0 spec to fix this problem:

In Section 21.5.4, replace the definition of IORInterceptor with:

local interface IORInterceptor : Interceptor

;

local interface IORInterceptor_3_0 : IORInterceptor

;

Replace the first sentence in 21.5.4.2 with:

After all of the establish_components methods have been called, the
components_established methods are called on all registered IORInterceptor_3_0
instances.

Replace the first sentence in 21.5.4.3 with:

Any time the state of an adapter manager changes, the adapter_manager_state_changed
method is invoked on all registered IORInterceptor_3_0 instances.

Replace the first sentence in 21.5.4.4 with:

Adapter state changes unrelated to adapter manager state changes are reported by
invoking the adapter_state_changed method on all registered IORInterceptor_3_0
instances.

Resolve urgently as suggested

As far as I can tell, OpaqueValue, a new native type
introduced in Issue 2162 (void * in DII Chapter) for
add_arg, was never documented in any of the language
mappings.

Also, the len parameter of add_arg is underspecified.

see above

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.

see above

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."

Do as suggested

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.

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

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.

No Data Available

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.

see above

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).

see above, close no change

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

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

see above, close no change

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.

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

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.

Good point. Incorporate the clarification

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.

see above

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.

see above

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.

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

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.

Fixed editorially in CORBA 3.0, close no change

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.

Clarify as shown below

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.

see above

[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 =

.

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 =

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.

see above

struct X

;

The question is, how should things be padded if double_seq is empty?
(Assume that we are starting at byte offset 0 for marshaling this structure.)

Approach taken by ORB 1:

• long_1 is aligned on a four-byte boundary (offset 0).

• The length of double_seq is aligned on a four-byte boundary,
  immediately following long_1 (offset 4).

• long_2 is aligned on a four-byte boundary. Because double_seq is
  empty, this means that long_2 immediately follows the length of
  double_seq on the wire, so long_2 begins at offset 8 and the total
  number of bytes for the struct is 12.

Approach taken by ORB 2:

• long_1 is aligned on a four-byte boundary (offset 0).

• The length of double_seq is aligned on a four-byte boundary,
  immediately following long_1 (offset 4).

• Now four bytes of padding are inserted because the sequence element
  type is double, so the next data item is expected to start on
  an eight-byte boundary.

• long_2 is aligned on that eight-byte boundary, so long_2 begins at
  offset 12 and the total number of bytes for the struct is 16.

The spec isn't clear on what should happen:

Sequences are encoded as an unsigned long value, followed by the
elements of the sequence. The initial unsigned lon gcontains the
number of elements in the sequence. The elements of the sequence
are encoded as specified for their type.

>From this, I cannot infer unambiguously which interpretation is correct.

Both approaches seem reasonable. (Personally, I have a slight preference
toward approach 2 because it's more consistent: after consuming the sequence,
the next data item will always start on an 8-byte boundary, which is more
consistent than approach 1, because the padding rules don't depend on the
length of the sequence at run time.)

I suspect that the best way to resolve this might be to take a majority vote
in line with the behavior of current implementations. And, of course,
the question now is what do we do with the GIOP version? We probably should
increment it, but I don't see what that would achieve for already existing
implementations, sigh...

see above, no change necessary

The new Portable Interceptor chapter in the CORBA 2.5 specification
has apparently been mismerged. Section 13.8 "Coder/Decoder
Interfaces," the Codec related interfaces added to the "IOP" module,
should supercede those in the deprecated "IOP_N" module that is listed
in section 21.10 "Portable Interceptor IDL."

Suggested changes include:

• Remove the IOP_N module from Section 21.10 "Portable Interceptor
  IDL."
• Change all instances of "IOP_N" to "IOP." In particular, methods
  listed in sections 21.3.13 (ClientRequestInfo IDL) and 21.10 refer
  to the "IOP_N" module. The following methods in section 21.10 must
  be updated:

module PortableInterceptor {

// ...
local interface ClientRequestInfo

;
// ...

local interface ORBInitInfo

;

};

Fixed in CORBA 3.0 (ptc/02-01-14). Close no change

We have identified a requirement where the interceptors for one service
need to be able to detect recursive invocations made by some other
interceptor during the processing of a request. As far as we have been
able to determine there is no way to achieve this using the
Request-scope/Thread-scope Current mechanism described in the spec.

It is probably easiest to explain this using a specific example. Start
with some form of "transaction" service that registers client-side
interceptors so it can detect all new request invocations and add service
contexts that perform some form of "begin transaction" processing at the
server. This transaction service must only perform this "begin
transaction" once per application-level request, so it allocates a
PICurrent slot and performs the processing described in section 21.4.4.2 to
ensure that any recursive calls it makes itself will form part of the same
transaction and not begin a new one.

However a problem now occurs if we introduce some other service, say a
"security" service that has its own interceptors registered. The order in
which these two service's interceptors run can affect what happens, but
since interceptor ordering is undefined assume that the security
interceptor runs first.

An application makes a request on its own thread A. The send_request
interceptors start to run on thread B and the security interceptor runs
first, at this point both the RSC and TSC slots for the transaction service
are empty. The security interceptor makes a recursive request so the
send_request interceptors run again on a new thread C. The security
interceptor runs again and this time doesn't recurse so the transaction
interceptor now runs on thread C. At this point it finds its RSC slot
empty so does a "begin transaction" and sets its TSC for thread C. We've
now finished interceptors on thread C and return to thread B and invoke
send_request for the transaction service. Once again it finds its RSC slot
empty and will try to "begin transaction" again. Now we have a problem as
we have issued two "begin transactions" for the same application request.

In fact it as actually the second of those two "begin transactions" that we
really want to do, as that represents the true start of the application's
transaction. The first one (caused by the recursive call in the other
interceptor) is at best redundant and wasteful and at worst wrong and
problematic.

Does anyone have any comments on this problem?

close no change

13.9.1 refers to the X/Open (nee OSF) Codeset registry. This registry
is obsolete and no longer maintained. We should replace it with the
IANA codeset registry instead and grandfather the old values for a
transition period.

see above

To me the key word is "EACH" - in other words values set via
PICurrent.set_slot in send_request are visible to other interceptors in
that point and go into the RSC of client interceptors serving any
requests made from within the interceptor(s). However, the TSC for
receive_reply (etc) would have a clean PICurrent since it runs in its
own logical thread.

We should clarify this.

Clarify as shown below

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).

see above

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"

see above, close no change

[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.

see above

[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.

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

CSIv2 uses GIOP ServiceContexts to associate a security context with a
given GIOP message, but the GIOP LocateRequest & LocateReply messages to
not have a ServiceContext field to carry the CSIv2 security context
information. Thus, it is impossible to use LocateReuest & LocateReply
when using CSIv2.