CORBA3 — Portable Interceptors / register_initial_reference()

I am in the process of implementing Portable Interceptors within a C++
ORB,
and I would like to raise an issue for resolution regarding the semantics
of the
"register_initial_reference()" function, particularly with respect to the
memory
management of the object being registered.

The interface for this function is as follows:

void register_initial_reference (
ObjectId id,
Object_ptr obj
);

Within the Portable Interceptors specification, there is really no
information about
how the memory for the object should be managed. For example, does the
caller of
"register_initial_reference()" pass ownership of the object to the ORB, or
not?
Also, does the caller of "resolve_initial_references()" gain ownership of
the object
which is returned, or not?

Here is my proposed resolution:

The fact that the "obj" parameter is a CORBA::Object implies that it is a
reference-counted
object. Therefore, it would make sense that when
"register_initial_reference()" is called, the
ORB performs a "_duplicate()" on the object to increment its reference
count (the ORB would
then hold its own reference count). The caller of
"register_initial_reference()" can decide
whether to call "release()" or retain its own reference count.

Later, when "resolve_initial_references()" is called, the ORB would call
"_duplicate()" on the
object prior to returning it to the caller, thereby giving the caller its
own reference count.
The caller would then need to call "release()" when it is finished with
the object.

When the ORB is deleted, it must clean up the lookup table of registered
objects. To do this,
it simply calls "release()" on each one, and if no one else holds a
reference count, then
the object is simply deleted.

I would like the hear other people's thoughts on this, particularly those
who have done or are
working on a C++ implementation of PI.

see above