There is currently no specification for fixed-point types in the COM/CORBA mapping. I'm interested in getting this changed: how can we proceed? better still, is this work already under way??

Page 2-7 of the CosExternalization Service Specification (April 2000)
defines the following interfaces:
CosStream::Node
CosStream::Role
CosStream::Relationship

A CosStream::Node inherits from the CosStream::Streamable interface and
therefore is a streamable object – it has an external_form_id attribute
that enables a FactoryFinder to recreate the object using the
create_uninitialized operation.

Unfortunately, the CosStream::Role and CosStream::Relationship interfaces do
not support the CosStream::Streamable interface and therefore are not
"streamable;" in particular, there is no standard method to obtain a KEY for
them when it is time to internalize them.

Perhaps, I am missing something (it wouldn't be the first time , but
having them support the Streamable interface would certainly make
implementation much easier. Might I suggest the following:

interface Role: CosGraphs::Role, CosStream::Streamable

at a minimum this would permit the CosStream::Node internalize_node()
operation and the CosStream::StreamIO read_graph() operation to use a KEY
value in the FactoryFinder to instantiate the object, before it is
internalized.

Section 23.14 of the CORBA/IIOP 2.4.1 specification lists the
complete IDL for a minimumCORBA implementation. However, the text in
the chapter and the IDL are inconsistent, for example, section 23.4.2
reads:

------------------------------------------------------------------------
---------------
The is_a operation is omitted so as not to introduce a requirement
either for holding

detailed type information in the object reference or for getting type
information over

the wire. Instead, minimumCORBA relies on design time resolution of type
checking

issues.

The non_existent operation is omitted, because of the design philosophy
of making

more decisions statically at design time.

The create_request operation is omitted, as the Dynamic Invocation
Interface is

omitted.

Section 23.14 of the CORBA/IIOP 2.4.1 specification lists the
complete IDL for a minimumCORBA implementation. However, the text in
the chapter and the IDL are inconsistent, for example, section 23.4.2
reads:

------------------------------------------------------------------------
---------------
The is_a operation is omitted so as not to introduce a requirement
either for holding

detailed type information in the object reference or for getting type
information over

the wire. Instead, minimumCORBA relies on design time resolution of type
checking

issues.

The non_existent operation is omitted, because of the design philosophy
of making

more decisions statically at design time.

The create_request operation is omitted, as the Dynamic Invocation
Interface is

omitted.

Deferred

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

Page 2-7 of the CosExternalization Service Specification (April 2000)
defines the following interfaces:
CosStream::Node
CosStream::Role
CosStream::Relationship

A CosStream::Node inherits from the CosStream::Streamable interface and
therefore is a streamable object – it has an external_form_id attribute
that enables a FactoryFinder to recreate the object using the
create_uninitialized operation.

Unfortunately, the CosStream::Role and CosStream::Relationship interfaces do
not support the CosStream::Streamable interface and therefore are not
"streamable;" in particular, there is no standard method to obtain a KEY for
them when it is time to internalize them.

Perhaps, I am missing something (it wouldn't be the first time , but
having them support the Streamable interface would certainly make
implementation much easier. Might I suggest the following:

interface Role: CosGraphs::Role, CosStream::Streamable

at a minimum this would permit the CosStream::Node internalize_node()
operation and the CosStream::StreamIO read_graph() operation to use a KEY
value in the FactoryFinder to instantiate the object, before it is
internalized.

Deferred

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

There is currently no specification for fixed-point types in the COM/CORBA mapping. I'm interested in getting this changed: how can we proceed? better still, is this work already under way??

Deferred

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

On page 22-6, we say for SYNC_WITH_SERVER:

For a server using a POA, the reply would be sent after invoking
any ServantManager, but before delivering the request to the target
Servant.

What's the motivation for this? Why wait that long? The ServantManager
may still fail to return a servant for the request, meaning that
the ORB might as well acknowledge the request before the ServantManager is
called without losing anything.

Also, as specified, the receiving ORB has to first run any adapter
activators. Again, there doesn't seem any point in waiting this long.
Why can't the receiving ORB simply acknowledge the request as soon as
it has read the request header off the wire?

withdrawn by submitter

Incorrect example for recursive definitions which can span multiple levels. I and my IDL compiler are missing an identifier in the following example union for the last struct member.

union Bar; // Forward declaration typedef sequence<Bar> BarSeq; union Bar switch(long) { // Define forward-declared union case 0: long l_mem; case 1: struct Foo

?identifier missing?; };

This has already been fixed in the previous RTF see orbrev/2001-03-01

I have an interoperability question regarding the
corbaname URL in the CORBA 2.4.2 specification and would appreciate
clarification.

In 13.6.7.3, it states that for a corbaloc URL which
uses IIOP, if the port number of the endpoint is
not specified, then the IIOP profile should default
to port 2809 which is specified by IANA as the corbaloc
port.
eg.
corbaloc:iiop:myhost.com/SomeKey

In 13.6.7.5, the corbaname URL is described.
If a corbaname URL is specified for IIOP, but the port
number is omitted, should the ORB assume that the
root naming context will be on port 2809 of the host
specified?

eg.
corbaname:iiop:myhost.com:3000#path/obj

will look for the root naming context on port
3000 of myhost.com.

eg.
corbaname:iiop:myhost.com#path/obj

Should this look to port 2809 for the root
naming context?

see above

In orbrev/01-03-01:

Production rule two at the end of this sections has a comment that it
should include all IDL types, but in actuality is missing "long long",
unsigned long long" and "long double".

Suggest we add these to the production rule in question.

No Data Available

When chunking and fragmenting, it is possible for a chunk length to be
inserted between the indirection tag and indirection offset.
Implementations must be careful to compute the indirection offset
correctly both when writing and reading to avoid errors.

For interoperability, we should elminate this possibility. From an
implementation point of view, the code for handling this special case
should already be there. Please see the original message (see
attachment) for a detailed description of the problem scenario and two
implementation possibilities.

Proposed resolution:

Elminate the possibility of chunk lengths between indirection tag and
indirection offset by changing the following paragraph in CORBA formal
00-11-03 15.3.4.6.

see below

In formal 00-11-03 10.6.2 in the discussion of the serial version UID in
the RMI hashed format, the spec defines the repository ID format as

RMI: <class name> : <hash code> [ : <serialization version UID> ]

and says

"If the actual serialization version UID for the Java class differs from
the hash code, a colon and the actual serialization version UID
(transcribed as a 16 digit upper-case hex string) shall be appended to
the RepositoryId after the hash code."

The Java to IDL spec ptc-00-01-06 1.3.5.7 says

"The syntax of the repository ID is the standard OMG RMI Hashed format,
with an initial “RMI:” followed by the Java class name, followed by a
hash code string, followed optionally by a serialization version UID
string."

Questions:

1) Is it legal to include the serial version UID in the repository ID
even when it is equal to the hash code? (Alternatively: Is it legal
for an ORB to throw an exception/fail if the hash code and serial
version UID in the repository Id are the same?)

2) If it is not legal to include the serial Version UID in the
repository ID when equal to the hash code, what should an ORB do?

Discussion:

Other than it not harming anything to include the SUID, there are rare
cases that the same Java class compiled with different compilers can
result in different default serial version UIDs, so it would be wise to
explicitly specify the serialVersionUID field even in the first version
of a class. If it is legal to always include the serial version UID
part of the repository ID, ORBs with classes from two different
compilers would still be able to interoperate.

see below

The specification does not say whether extra data after the invocation
parameters in a Request or Reply body is ignored or considered an
error. For interoperability purposes, the spec should require one or
the other.

see below

Let us assume that the server has sent a few reply fragments. But before sending all the reply
fragments, an exception occurs (say while marshalling the response).
What does the server and the client (which has already seen reply fragments) do ?

Just to note, notice that if the same problem happens while the client is in the midst of sending
request fragments, the client can choose to send a CancelRequest message to intimate the server.

Since there are various possible behaviours for the client and server, the GIOP specification needs
to clarify the standard behaviour, in order for different implementations to remain interoperable.

One possible behaviour :

The server could send back a seperate response (containing the exception with
CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that
another reply with the same requestId is pending, could discard the pending reply and process the
latest reply.

Another behaviour :

The client could simply timeout the request and discard any new reply streams (with the same
requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE.

This issue is resolved by the resolution to issue 4273.

The Components::Navigation interface that is implemented by all
components provides introspection ("generic navigation") capabilities.
There are lots of use cases for introspection, so I wonder why there
is introspection for facets, but not for receptacles or event ports.
I suggest to add such introspection capabilities. All introspection
features should be alike as much as possible for ease of usage.

see below

. I don't
think OMG specifications should use a single term in two distinctly
different ways. The text of the issue starts with the sentence,
"the Components spec and valuetype spec treat "supports" exactly
*OPPOSITE* in semantics regarding widening/narrowing." and continues
for about 3 or 4 paragraphs. Ed's comment should go in there too.

rejected

Looking at ptc/99-10-04, it is not clear to me which parts of this
document are intended as normative.

For example, the introduction to chapter 66, "Component Container
Architecture", states that the presented design "is not the only
possible design choice." Consequently, it appears that the entire
chapter 66 is not intended as normative. However, looking at the
actual text, a reader might be easily confused into taking aspects of
the design as normative.

While this text was helpful in the submission to give readers an
insight how the submitters might design their implementations, it
should be removed from the specification, to really give implementors
the freedom of design choice that was apparently intended with the
submission.

see below

Section 8.3.1 says "The signatures of the CORBA component operations are mapped to signatures of EJB remote interface methods following the IDL to Java mapping rules."

As far as I can see, this only works if the IDL signature has no out or inout parameters. The Holder classes for out and inout parameters cannot be used in an EJB interface signature because they need not be Serializable, which breaks the rules for an RMI compliant class. Even if they could the EJB stubs and skeletons would not implement their special return value behavior without modifications to the EJB spec.

Someone please tell me I've missed something!

see below

The CCM exceptions mapped from EJB standard exceptions need to be defined
explicitly in OMG IDL. The resolution to issue 3182 introduces new CCM
standard exceptions Components::CreateFailure, Components::FinderFailure
and Components::RemoveFailure but it does not define them explicitly.

see below

The use of the state keyword in the Components::Enumeration valuetype,
introduced by issue 3099 and extended in issue 3418, is not correct
syntactically. Also, anonymous sequences have been deprecated, so the
definition of the Components::Enumeration state is incorrect in this sense
as well.

see below

The CCM MOF IR draft (ptc/99-10-05) uses UML to denote the MOF model
of the IR. Without missing elaboration, it is not possible to mentally
construct the metamodel. For example, the enumeration, primitive, and
unchangeable stereotypes don't have a well-defined relationship to MOF
concepts. It seems that the MOF chapter should use the UML MOF profile
(ad/01-02-29). In addition, it would be desirable if a normative XML
document that defines the metamodel (following the MOF DTD) is
provided.

see below

Is there any reason to name the context interface for extended session
components as Session2Context in module Components::Extended? Why not simply
SessionContext like in the Basic module?

see below

How to activate servants by only using the Session2Context interface from
the Extended module? It only offers operations to create references like
create_ref() and create_ref_from_id() similar to those from the POA but no
means to activate servants are available in the whole container API!

see below

In CORBA 2.3, a GIOP 1.2 LocateReply message made no requirements as to
the alignment of the LocateReply body. This meant that the LocateReply
body needed to be aligned only on a 4-byte boundary. With the resolution
for issue 2521, published with CORBA 2.4, the spec was changed to require
alignment of the LocateReply body on an 8-byte boundary.

The change is incompatible with the CORBA 2.3 definition because the receiver
must know where to look for the ReplyBody in the the byte stream following
the message header. (The LocateReply header is 12 bytes long, so changing
the alignment rules means that the LocateReply body has to start at offset 12
for CORBA 2.3, but has to start at offset 16 for CORBA 2.4.)

The change in alignment did not result in a version change of GIOP,
despite the incompatibility, so it appears that the change is simply illegal.

There are already deployed products that use the CORBA 2.3 alignment
rule; therefore, we cannot deploy a CORBA 2.4 compliant product without
breaking interoperability with already deployed CORBA 2.3 compliant products.

So, I'd like to request that we back out the change and continue to
permit a LocateReply body to be aligned on a 4-byte boundary. There was
never any need to change the alignment of the LocateReply body anyway because
a LocateReply header has fixed length and, therefore, cannot ever cause
remarshaling of the body due to a size change in the header. In other
words, the motivation quoted in the spec for the 8-byte alignment rule
isn't founded on fact, and the change should never have been made in the first
place. (See issue 4309 for details.)

No Data Available

The table on page 15-31 (Table 15-3 "GIOP Message Types and Originators")
is in error. For CloseConnection, it shows that only the server can
send this message but, in GIOP 1.2, either client or server can send
the message, as detailed in 15.5.1 and 15.4.7.

Also. in 15.4.7, we have:

In GIOP version 1.2 both sides of the connection may send
the CloseConnection message.

That should be "must", not "may".

see above

Add the missing entry with the same information as tk_objref.

add the missing table entry with the same information as tk_objref

If the server ORB sends back a NEEDS_ADDRESSING_MODE reply to the client indicating the prefered
addressing disposition, then is the client ORB required to 'cache' the prefered addressing
disposition per object reference, and use it for further requests to the server ?

to close without revision

I have a query about the intended marshalling format for Fixed. Is the
sending ORB always required to transmit the number of digits specified
in the IDL, or is it permitted to transmit fewer if there are leading
zeros?

Consider transmitting 123.45 as fixed<6,2>. Is the ORB permitted to
transmit

12 34 5c

or must it send the leading zero (plus another zero to pad the first
octet):

00 12 34 5c

In both cases, the receiving ORB knows it is expecting a scale of 2,
and the sign half-octet tells it where the digits end, so it can
correctly unmarshal the value as 123.45.

The discussion of issue 3431 suggests that the first option is not
permitted, and leading zeros must always be sent. However, the 2.4
GIOP spec makes no mention of how many digits should be sent. The
specification should be clarified to either explicitly permit or
explicitly forbid stripping of leading zeros.

Close with clarification revision

15.4.6.2, "LocateReplyBody" says:

In GIOP version 1.0 and 1.1, Locate reply bodies are marshaled into
the CDR encapsulation of the containing Message immediately following
the Reply Header. In GIOP version 1.2, the Reply Body is always
aligned on an 8-octet boundary. The fact that GIOP specifies the
maximum alignment for any primitive type is 8 guarantees that
the ReplyBody will not require remarshaling if the Locate Reply
Header are modified.

The final sentence doesn't make sense because the LocateReply header is
a fixed-length header and therefore can't possibly cause remarshalling.

I suggest to delete the final sentence of this para.

see resolution of Urgent Issue 4314

There is nothing in the specification that explicitly states whether the
data in the body of a GIOP 1.1 Fragment message is marshalled relative
to the Fragment header or relative to the unfragmented message as a
whole.

The restriction in GIOP 1.2 that all fragments but the last must have a
multiple of 8 bytes, and the careful padding of the GIOP 1.2 Fragment
header to 16 bytes both strongly suggest that GIOP 1.1 fragments should
be marshalled only relative to the fragment header.

Proposed Resolution:

In section 15.4.9, right after the paragraph that reads:

"A primitive data type of 8 bytes or smaller should never be broken
across two
fragments."

add the following paragraph:

In GIOP 1.1, the data in a fragment is marshalled with alignment
relative to its position in the fragment, not relative to its position
in the whole unfragmented message.

Accept proposal above

I don't understand why tk_indirect isn't allowed as a top-level typecode.
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 tk_indirect 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 tk_indirect cannot refer to any TypeCode outside
the scope of its enclosing top-level TypeCode. However, I don't think this
restriction needs to apply to a top-level TypeCode. We have made this
change experimentally without any adverse effects and we have discovered that
using tk_indirect for all the top-level foo TypeCodes after the first one can
speed up some common scenarios by at least a factor of 5 on end-to-end
measurements. There seems to be no downside to making this change.

I would therefore like to propose the following change to the section headed
"Indirection: Recursive and Repeated TypeCodes" within section 15.3.5.1:

Change the first bullet from:

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 words:

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.

If this change finds favour, then we need to work out how it can be brought
into GIOP without causing problems interoperating with older ORBs that insist
on the stronger restriction of the current spec. This could perhaps be
added to the "wish list" for GIOP 1.3.

Close this issue and add it to the GIOP wish list

The spec doesn't say whether or not resolve_initial_references() is allowed
to return nil. Clearly, it doesn't make sense for it to do that – we
should say so in the spec.

see below

in the absence of an RTF for the time service, I'm sending this to the
core RTF. (You could argue that this is a core issue anyway, since
the core depends on the time service for messaging.)

What is the interpretation of the time and tdf fields in a UtcT?

The spec shows:

struct UtcT

;

For TimeT, the spec says:

TimeT represents a single time value, which is 64 bits in size, and
holds the number of 100 nanoseconds that have passed since the base
time. For absolute time the base is 15 October 1582 00:00.

For UtcT, the spec says:

UtcT defines the structure of the time value that is used
universally in this service. The basic value of time is of type
TimeT that is held in the time field. Whether a UtcT structure
is holding a relative or absolute time is determined by its history.
[...]
The tdf field holds time zone information. Implementation must
place the time displacement factor for the local time zone in this
field whenever they create a UTO.

see below

There is no mapping for fixed types in the COM/CORBA mapping. Why has this been omitted? Is there a submission underway?

Close with answers to the qestions raised, as given above under Resolution

Please have a look at the news article below. Basically, the problem is
that we don't say in the spec what has to happen if I try to give
conflicting prefixes/IDs/versions to a module (which can happen if a module
is reopened).

My feeling is that we should deal with this the same way as for forward
declarations, that is, force the compiler to emit a diagnostic. I think
we should also add a note that this can't be enforced by the compiler
under all circumstances because of separate compilation.
> Orbacus distribution contains following IDL file.
>
> > #pragma prefix "omg.org"
> >
> > module CosNaming
> > {
> > typedef string Istring;
> >
> > struct NameComponent
> >

;
> > };
> >
> > #pragma prefix "ooc.com"
> >
> > module CosNaming
> >

;
>
> And here the error message of IDL to Visual Basic compiler.
>
> orbacusnaming.idl:16(8): Attempt to assign a different prefix
> to a forward-declared identifier
> orbacusnaming.idl:3(8): Position of the first identifier definition

The error message is misleading becuase there is no forward-declared
identifier here. But the compiler has a point – something strange is
going on there...

> I look in the CORBA specification and found that modules do have
> repository ids.

Absolutely.

> > Forward-declared constructs (interfaces, value types, structures,
> > and unions) must have the same prefix in effect wherever
> > they appear. Attempts to assign conflicting prefixes
> > to a forward-declared construct result in a compile-time
> > diagnostic. For example:
> [...]
>
> And what about reopened modules?

This part of the spec simply doesn't apply because it talks about
forward-declared things only.

> Which repository id do they
> have if someone use different prefix statements? I think
> they can have only one because the IFR of CORBA allows only
> one (if the repository version is equal).

Yes. The spec isn't really clear on this point. Here is your example
once more, simplified to the bare bones:

#pragma prefix "X"
module M

;

#pragma prefix "Y"
module M

;

The spec simply does not address this problem, so we have a hole. Thinking
about it, there are two possible interpretations:

1) Module M gets a prefix "X" initially. Then, when the prefix
changes to "Y" and the compiler sees M for the second time,
it could just ignore the prefix for M because M has the prefix
"X" already.

2) The compiler could notice that M previously got prefix "X"
and then complain when it sees M for the second time because
it would get a conflicting prefix.

For forward-declared things, the spec applies the philosophy that
the prefixes must not change. Seeing that a reopened module is somewhat
similar to a forward declaration (because the same definition can be seen
more than once), I'd be inclined to amend the spec to say that the prefix
for a module must not change.

For cases where the compiler can actually detect this, we can even force
a diagnostic. However, as for forward-declared things, this is not always
detectable by the compiler. In particular, if the reopened module is
reopened in different source files and the two source files are compiled
separately, there is no way for the compiler to detect that the module
is getting a different prefix in each source file. If the generated code
from the two files is linked into the same binary, you should at least
get a multiple definition error. But if the code for the two files ends
up in different executables, there is no way to detect the error at all
and you will get strange things happening at run time.

As far as the ORBAcus IDL is concerned, I think it needs fixing. The second
prefix pragma should be inside the module, to avoid the conflict:

#pragma prefix "omg.org"

module CosNaming
{
typedef string Istring;

struct NameComponent

;
};

module CosNaming

;

> Is my IDL2VB compiler again buggy or the Orbacus IDL file
> or the CORBA specification not clear?

Well, a little bit of all three I'll raise an issue with the core RTF.

> I recently solve all founded bugs in IDL2VB and it compiles now
> all examples of syntax chapter in CORBA spec and find
> all errors. CORBA is to difficult for humans...

That's why we use compilers for IDL instead of humans

Clarify as described below

CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion): "If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If an application does this in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock."

But does this mean that things will be as if the operation has not been called (suggested by the name of the exception raised?), or will they be as if the operation had been called with wait_for_completion FALSE (seems more appropriate)? Or should the implementation decide, and should it just use an appropriate completion code? In this case, is COMPLETION_MAYBE allowed? Letting the implementation decide puts a higher burden on the developer, though, if s/he wants to write portable code, so that developer may decide to just program for the current implementation...

This question has additional relevance for me because I'm implementing an ORB.

Clarify that BAD_INV_ORDER is raised in this case with COMPLETED_NO

For local interfaces, we seem to have internal inconsistencies in the spec.
For one, it is not clear whether or not a local interface implicitly inherits
from Object. There is one sentence in the spec that seems to imply that
there is implicit inheritance from object, on page 3-23 of the 2.5 draft
(http://doc.omg.org/ptc/1-6-10):

Any attempt to marshal a local object, such as via an unconstrained
base interface, as an Object, or as the contents of an any, or to
pass a local object to ORB::object_to_string, shall result in a
MARSHAL system exception with OMG minor code 4.

This implies that I can at least try to pass local object as CORBA::Object,
which implies that local interfaces do indeed implicitly inherit from Object.

But then, a bit further down, it says:

The is_a, get_interface, get_domain_managers, get_policy,
get_client_policy, set_policy_overrides, get_policy_overrides, and
validate_connection pseudo-operations, and any DII support
pseudo-operations, may result in a NO_IMPLEMENT system exception
with minor code 3 when invoked on a reference to a local object.

"May result in a NO_IMPLEMENT system exception"? I would suggest "shall"!

But, more seriously, I can't call is_a() on a local interface. In turn,
that seems to imply that I can't narrow a local interface either, but
narrowing is clearly necessary in the presence of inheritance for local
interfaces.

It seems that local interfaces must inherit from Object. After all,
it would be difficult to see, for example, how resolve_initial_references
can return a reference to the Root POA if it were otherwise... But then,
if local interfaces do inherit from Object, It doesn't make sense to
prohibit calling is_a() on them.

Related to that then is the question of "What is the repository ID of
a local interface?" Given that they can be narrowed, it would seem that
they must have repository IDs. (Although, you could argue that narrowing
is to be achieved via some mechanism other than repository IDs – that
would also permit is_a() not to be supported and would make narrowing
an issue that is specific to each language mapping.)

But the inheritance issue seems serious – if something doesn't inherit
from Object, I can't return or pass it as an Object, but we are doing
just that for local objects.

I think this will require some careful thought. We don't want to find
ourselves in yet another maze of twisty little passages, all different,
as we did with pseudo-objects...

Incorporate changes and close issue

the terms "pseudo-object", "pseudo-interface", and "PIDL" appear in many
places in the spec. However, there does not appear to be a definition
of what these things actually are anywhere in the spec. Now, for many years
now, I've been telling people that PIDL objects differ from normal ones
in the following ways:

• They don't inherit from Object.

• They can't be invoked via the DII.

• They don't have definitions in the IFR.

• They can't be passed as arguments to remote operations
  (except for TypeCode).

• They may have special mapping rules.

I know that, once upon a time, when I first wrote these points into a CORBA
training course, I didn't just make them up – I found them in the spec.
However, I'm damned if I can find them now. I looked in the 2.0 spec as
well as the 2.4.2 spec to no avail. Can someone help me out?

At any rate, we should add the definition somewhere because, write now,
we have lots of free-floating terms in the spec.

On a related note, by searching for "pseudo", I found a few places where
it is stated that "pseudo-objects do not have object references". That
seems to be wrong. After all, we pass these things across (local) interfaces
by reference (instead of by value) and, at the language mapping level,
pseudo-objects have references that are indistinguishable from any other
reference. We should correct this.

see above

Steve's and my book contains a bit of code that pretty-prints a TypeCode.
(See page 704ff, in particular, 709-711.) No big deal – just write
a recursive function that does a depth-first traversal of a TypeCode tree
and prints things out, except for one thing: recursive types.

For recursive types, the code has to be careful not to get trapped in
infinite recursion. In essence, this means that the pretty-printer has to
remember which TypeCodes it has already seen and end the recursion if it gets
to a TypeCode that was printed previously. This is where we run into
problems because there is no legal way to do this:

• I cannot rely on the repository ID in the TypeCode to determine
  TypeCode identity because the repository ID for structs and
  unions is optional prior to GIOP 1.2, but recursion happens
  via structs and unions. (A GIOP 1.2 implementation may interoperate
  with a GIOP 1.0 or 1.1 implementation and still end up sending
  TypeCodes without repository IDs.)

• The code in the book uses is_equivalent() to determine whether
  it has seen a TypeCode previously. However, doing this is
  completely illegal (even though it happens to work with most
  ORBs) because:

• is_equivalent() does not provide object identity.

• TypeCode is a pseudo-object, and pseudo-objects do
  not inherit from CORBA object. This means that TypeCode
  doesn't even have an is_equivalent() operation that I
  could call.

So, as far as I can see, there is no compliant way to reliably and portably
determine TypeCode identity and, as a result, I can't ever reliably parse
a TypeCode...

I can see several solutions for this problem, all with different drawbacks:

1) Add an identity() operation of some kind to TypeCode.

An ORB that receives a TypeCode would have to make sure that
it generates a unique ID for each TypeCode. But that's not
all that easy to implement – in particular, if we have an
older TypeCode where all the optional bits are missing, we
can't reliably establish object identity for a TypeCode.
(Only structural comparison is possible.)

2) Add an identity() operation to TypeCode, but have the TypeCode's
identity generated at the sending end instead of the receiving
end.

Major drawbacks: the identity would have to large because it
needs to be globally unique (e.g. a UUID) and it would change
the marshaling of TypeCodes.

3) Add is_equivalent() and hash() operations to TypeCode.

This might break existing ORB implementations because a lot
of ORBs seem to inherit from Object for TypeCode and other PIDL
objects, even though they shouldn't.

4) Make PIDL objects implicitly inherit from CORBA::Object.

Note that making the repository ID mandatory is impossible because we
can't legislate for existing GIOP 1.0 or 1.1 implementations...

On a related note, we seem to have further problems with the idea that
PIDL objects don't inherit from CORBA::Object. For example, in the C++ mapping,
pseudo-objects such as TypeCode, ORB, etc. can be passed as Object_ptr
(for example, to CORBA::is_nil()). This really means that the C++ mapping
(and possible mappings for other languages) are completely in conflict
with the core spec...

My feeling is that option 4 is really the least-intrusive one. But I'm
not sure that I fully understand all the ramifications of making that change.

see above

Please take a look at the resolution of issues 4285 and 4306 in
> ptc/2001-06-08 - the RTF report that is up for recommendation to adopt
> at this upcoming meeting, and see if they do not fix these problems.
> 4285 fixes the BAD_OPERATION problem most definitely. 4306 seems to fix
> the OBJ_ADAPTER problem too, although slightly differently from how you
> suggest. If these fixes address the problem that you raise in your
> message, could you please ask Juergen to not create an issue?I didn't CC issues, so I don't think Juergen will create an issue (at least,
that was the intent). My apologies for the duplication. However, looking
at 4285 once again, I think there may be a problem:

In order to return something that means "ServantManager returned wrong
servant type", I think the ORB core has to insert an active check
at the point where the servant manager returns. If it doesn't, it will
either get an unmarshaling error or return a BAD_OPERATION exception with
some other minor code when it detects that the operation isn't in the
function pointer table for the servant. In the latter case, the ORB won't
know anymore why the operation is missing (for example, it could also
be missing because the client used the DII to invoke a non-existent operation.)

I am also not sure whether BAD_OPERATION is really the correct exception to
use. To me, BAD_OPERATION tells the client "you invoked an operation that
doesn't exist". If we give this exception to the client when it invokes
an operation that's perfectly good, that's highly misleading because the
actual problem isn't with the client, but with the servant manager.

So, I think that using OBJ_ADAPTER, as I suggested, would be better.

For the resolution to 4306, I think we also have something that is suboptimal.
That's because minor code 2 say "Servant not found" in table 4-3. But
I don't see how this is possible. Basically, a servant manager isn't allowed
to return a null servant. If it can't find the servant, it's supposed to
throw a system exception. So, a servant manager that returns null is simply
broken and needs to be recoded. 4306 (by using "Servant not found" as
the explanation of minor code 2) is misleading, because that condition simply
can't happen.

So, without trying to create a procedural mess, could we reconsider the
resolution to these two issues, maybe for the next vote?

Fix inconsistency as described below

the text for get_interface() says:

An operation on the object reference, get_interface, returns an object
in the Interface Repository, which provides type information that may
be useful to a program. See the Interface Repository chapter for a
definition of operations on the Interface Repository. The
implementation of this operation may involve contacting the ORB
that implements the target object.

This does not say what should happen if I call _get_interface() and

• the interface repository isn't running,

• the interface repository is running and can be reached, but
  doesn't contain an entry for the object's interface.

Looking at the INTF_REPOS exception, we have:

An ORB raises this exception if it cannot reach the interface
repository, or some other failure relating to the interface
repository is detected.

This would indicate that, if the repository isn't running, the client should
get INTF_REPOS. However, we have no idea what should happen if the repository
is in fine shape, but no entry exists for the interface.

Since an unpopulated interface repository is very much the same thing as
no interface repository at all, I would like to flag both scenarios as an
error.

Proposal: add the following sentence to the end of 4.11.3.22:

If the interface repository is not available, get_interface() raises
INTF_REPOS with minor code 1. If the interface repository does not
contain an entry for the object's (most derived) interface,
get_interface() raises INTF_REPOS with minor code 2.

Update the minor code table in 4.11.4 accordingly.

Make the suggested change and the additional change suggested in the archive

The UML diagram on page 11-49 uses "the_manager" in two places. This
should be "the_POAManager".

In one place, it uses the attribute "the_servant_manager". No such attribute
exists.

Make the suggested corrections

CORBA 2.4.1 final, Section 7.2.1 (create_request), page 7-7, last
paragraph reads:

"If the name of an implicit operation that is not invocable through DII
is passed to create_request with a "_" prepended, create_request shall
raise a BAD_PARAM standard system exception".

This does not specifies the minor code for the exception.

see above

Section 4.3.5.1 non_existent last paragraph says:

Probing for object non-existence may require contacting the ORB that
implements the
target object. Such an attempt may fail at either the local or the
remote end. If non-existent
cannot make a reliable determination of object existence due to failure,
it
raises an exception in the calling application code. This enables the
application to
distinguish among the true, false, and indeterminate cases.

This does not define what exception gets thrown in the indeterminate
case. I picked TRANSIENT, but COMM_FAILURE or NO_RESPONSE may also be
valid choices.

Proposal:

Change the sentence in last paragraph of section 4.3.5.1:
If non-existent cannot make a reliable determination of object existence
due to failure, it
raises an exception in the calling application code.

to:
If non-existent cannot make a reliable determination of object existence
due to failure, it
raises a TRANSIENT with XX minor code in the calling application code.

close, no change

The following from the CORBA 2.4.1 specification.
3.2.5.2 Character Literals
A character literal is one or more characters enclosed in single quotes,
as in ’x.’
Character literals have type char.
A character is an 8-bit quantity with a numerical value between 0 and
255 (decimal).

3.2.5.4 String Literals
A string literal is a sequence of characters (as defined in Section
3.2.5.2, “Character
Literals,” on page 3-9) surrounded by double quotes, as in “...”.

The above statements together implies that a string literal may contain
embedded NULL characters. That is incorrect. The definition of string
literals must explicitly eliminate NULL.

Proposal:
Revised text:

Section 3.2.5.4 String Literals

replace this first paragraph
A string literal is a sequence of characters (as defined in Section
3.2.5.2, “Character
Literals,” on page 3-9) surrounded by double quotes, as in “...”.

with
A string literal is a sequence of characters (as defined in Section
3.2.5.2, “Character
Literals,” on page 3-9), with the exception of the character with
numeric value 0, surrounded by double quotes, as in “...”.

Make it so

on page 3-23 of section 3.7.6.1, first bullet point, we find:

Local types cannot be marshaled and references to local objects
cannot be converted to strings. Any attempt to marshal a local
object, such as via an unconstrained base interface, as an Object,
or as the contents of an any, or to pass a local object to
ORB::object_to_string, shall result in a MARSHAL system exception
with OMG minor code 2.
^^^^^^^^^^^^^^^^
However, the minor code table, page 4-59, section 4.11.4 shows:

MARSHAL 1 Unable to locate value factory.
2 ServerRequest::set_result called before
ServerRequest::ctx when the operation IDL contains a
context clause.
3 NVList passed to ServerRequest::arguments does not
describe all parameters passed by client.
4 Attempt to marshal Local object.

This is inconsisent – the text requires minor code 2, but the table
requires minor code 4.

I would suggest to update the first bullet of 3.7.6.1 to require minor code 4,
in line with what is shown in the table.

Make it so

"If a ServantManager returns a null Servant (or the equivalent in a language mapping) as the result of an incarnate() or preinvoke() operation, the POA will return the OBJ_ADAPTER system exception with standard minor code 3 as the result of the request."

Should that be minor code 2 rather than 3? I couldn't find any other reference to OBJ_ADAPTER minor code 2 and the description makes more sense for this condition.

Yes the minor code in this case should indeed be 2. Make it so

the current way of dealing with POAManager objects is less than satisfactory.
Consider:

interface POA

;

The problem here is twofold:

• There is no way to get at the list of all existing POA managers,
  at least not easily; I have to either keep a list myself,
  or I have to traverse the POA tree and build the list as I go.

• POA managers have no identity. There is no name or other piece
  of state that would allow me to distinguish one POA manager from
  another.

The second problem is the more serious one because POA managers are used
to control the behavior of one or more transport endpoints. Most ORBs
permit configuration control over transports. For example, it is usually
possible to configure things such as which protocols/transports should
be associated with a POA manager, how many protocols/transports should
be associated, at what address/port the transport controlled by a
POA manager should listen for requests, what timeouts to apply, etc, etc...

Currently, ORBs have to resort to proprietary means to attach such
configuration information. For example, in ORBacus, we use a proprietary
POA manager factory that permits a name to be attached to a POA manager.
That name then is used as a hook to attach configuration information
to POA managers, so we can do things like configure port numbers, etc.

I'd like to improve the spec such that it becomes possible to control
identity for POA managers through a standard API. The thoughts are:

• Add a POAManagerFactory interface that allows

• creation of POA managers

• listing of existing POA managers

• searching for POA managers by name

• Add an id() accessor to POAManager that returns the name

For creation of POA managers, a CORBA::PolicyList can be passed into
the call in addition to the POA manager name. That policy list would permit
configuration of POA managers through a defined API (even though the
actual policies that apply would still be proprietary).

These changes would be completely backward-compatible, so no existing
code breaks.

see below

"This indicates that an object reference denotes an existing object,
but that the object does not support the operation that was invoked."

This text does not specify a minor code nor a completion status.

Section 11.3.4.1 (last paragraph) says:

"If the ServantManager returns the wrong type of Servant, it is
indeterminate when that error is detected. It is likely to result in a
BAD_OPERATION with standard minor code 5 or MARSHAL exception at the
time of method invocation."

This implies that 4.11.3.13 should specify a '5' for the minor code.

A specific minor code for this case is necessary since BAD_OPERATION
may be raised in other contexts (e.g., IDL->Java mapping for union,
Any, any extraction, ...).

I am not sure why it says '5' in 4.11.3.13. Is this minor code
specified somewhere else that I'm missing?

Assuming that this is underspecified I would suggest:

1. assigning a minor code for the case discussed in 4.11.3.13,

2. making sure that 11.3.4.1 is in sync with that assignment,

3. specifying a completion status of COMPLETED_NO (since there is no
way anything could be completed since the call never makes it out of
the skeleton into the servant).

see above

The second paragraph of "3.10.1.7 Any Type" uses a cross-reference to explain the concept of the TypeCode in an Any value. This cross-reference refers to section 3.10, which is useless.

Suggestion: Change this cross-reference to read as follows: '(see Section 10.7, "Type Codes", on page 10-51)'

Fix as suggested

Section 4.5.3.2 says:
<ObjectURL> can be any of the URL schemes supported by
CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3
Specification).

Couple of problems w/ this. Shouldn't the reference be Section 13.6.10
of this spec. Also, the ObjectURL specifications in chapter 13 include a
"rir" protocol which obviously makes no sense for ORBInitRef.

Proposal:

Replace first sentence of last paragraph of section 4.5.3.2 from:

<ObjectURL> can be any of the URL schemes supported by
CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3
Specification).

to

<ObjectURL> can be any of the URL schemes supported by
CORBA::ORB::string_to_object (Section 13.6.10), with the exception of
the corbaloc URL scheme with the rir protocol (i.e. corbaloc:rir:...).

Fix as suggested above

What happens when someone attempts to set the mode attribute while not
adhering to the restrictions spelled out?

We should say what happens if these conditions
aren't met. Furthermore, a oneway method can't have exceptions.
I suggest:

• add a new row to the BAD_PARAM block in Table 10-1 (p.10-10):

Exception Minor Code Explanation

BAD_PARAM N Attempt to define a oneway
operation with non-void result,
out or inout parameters or
exceptions

• Add a similar entry to table 4.3 (p.4-61).

• Change the last para of 10.5.22.2 to read:

"The mode attribute can be set to OP_ONEWAY only if the result is
TC_void, all elements of params have a mode of PARAM_IN, and the
list of exceptions is empty. If the mode is set to OP_ONEWAY
when these conditions do not hold, a BAD_PARAM exception is
raised with minor code N."

This is perhaps rather large to be a friendly ammendment. I'm
happy to vote YES to the current resolution, which is still a
useful change, and raise this for next time. I can't discuss
further in this round, as I'm on vacation for a week from this
evening.

see above

The new text in 3.10.5 states: "Native type parameters are permitted
only in operations of local interfaces or valuetypes". However, 11.4
states that:
a) Servant is a native type, and
b) that it is used on the POA::get_servant operation, and
c) that POA is not a local interface
(Taking POA as an arbitrary example here; other POA interfaces show
the same problem). Does that mean that CORBA 2.5 will be inconsistent?

see above

I think it would be nice to mention something about code generation in
section 19.5.22.2. People seem to either expect that the compiler will
generate code for everything, or that it will generate code only for
things that are not in included files. The following might help to clear
this up:

"Note that whether a particular IDL compiler generates code for included
files is an implementation-specific issue. To support separate
compilation, IDL compilers may not generate code for included files, or
do so only if explicitly instructed."

Insert the sugested text in section 3.3

The definition of the NamingContextExt interface in the IDL of Appendix A is not consistent with the definition in section 2.5.4.

Specifically,

1. The Appendix A version has an extra operation: resolve_context

2. In Appendix A, there is an extra exception type in the raises clause of the resolve_str operation: AlreadyBound

see above

Section 3.7.4 doesn't mention local as a legal prefix for an interface
forward declaration.

Proposal 1:

Change the sentence:

"The syntax is: optionally the keyword abstract, followed by the keyword
interface, followed by an <identifier> that names the interface."

to:

"The syntax is: optionally either the keyword abstract or the keyword
local, followed by the keyword interface, followed by an <identifier>
that names the interface."

Proposal 2:

Just strike the sentence entirely, since it is redundant.

Make the recommended change in Proposal 1

The CORBA::DataInputStream abstract valuetype has operations like:

void read_boolean_array( inout BooleanSeq seq,
in unsigned long offset,
in unsigned long length);

However, the spec says nothing about whether the provided sequence must
already have sufficient length to satisfy the offset+length or whether
the operation will extend the sequence to fit.

Clarify that the operations are expected to extend the sequence to fit

A minor issue with section 3.3 of the 2.4 specification:

"... Text in files included with a #include directive is treated as
if it appeared in the including file. ..."

That is not true since, as we find out in chapter 10, included files
behave specially with regard to assigning repository identifiers.

e.g. in

// a.idl
#pragma prefix "foo"
interface bar {};

the repository id of bar is IDL:foo/bar:1.0, but in

// a.idl
#pragma prefix "foo"
#include "b.idl"

// b.idl
interface bar {};

it is just IDL:bar:1.0.

Incorporate changes and close issue

As with other DynAny operations that accept an Any parameter,
the set_boxed_value operation should be capable of raising
InvalidValue.

Proposal:

• In sections 9.2 and 9.12, add InvalidValue to the raises clause for
  set_boxed_value

• In section 9.12, replace the text describing set_boxed_value with the
  following:

"The set_boxed_value operation replaces the boxed value with the specified
value. If the type of the passed Any is not equivalent to the boxed type,
the operation raises TypeMismatch. If the passed Any does not contain a
legal value, the operation raises InvalidValue. If the DynBoxedValue
represents a null valuetype, it is converted to a non-null value."

Make it so

The mode attribute can only be set to OP_ONEWAY if the result is TC_void and all
elements of params have a mode of PARAM_IN.

which might be taken to mean that the mode attribute must be set to
OP_ONEWAY if the signature is as described. A better wording might be

The mode attribute can be set to OP_ONEWAY only if the result is TC_void and all
elements of params have a mode of PARAM_IN.

This was brought to my attention by an email question I received today, from
someone who thought he understood CORBA oneway semantics until he
read that sentence - then he became confused.

make it so

In document 01-01-01, there are the following paragraphs which seem
contrary to one another regarding the minor code to be used when an
ORB receives an unrecognized system exception.

4.11.2
Vendors may define non-standard system exceptions, but these exceptions are
discouraged because they are non-portable. A non-standard system exception, when
passed to an ORB that does not recognize it, shall be presented by that ORB as an
UNKNOWN standard system exception. The minor code and completion status from
the unrecognized exception shall be preserved in the UNKNOWN exception.

15.3.5.5 Exception
Exceptions are encoded as a string followed by exception members, if any. The string
contains the RepositoryId for the exception, as defined in the Interface Repository
chapter. Exception members (if any) are encoded in the same manner as a struct.
If an ORB receives a non-standard system exception that it does not support, or a user
exception that is not defined as part of the operation's definition, the exception shall be
mapped to UNKNOWN, with standard minor code set to 2 for a system exception, or
set to 1 for a user exception.

Incorporate changes and close issue

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

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

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.

see above

21.8.1 register_initial_reference

An operation is available in the ORB interface:
void register_initial_reference (in ObjectId id, in Object obj) raises
(InvalidName);
If this operation is called with an id, Y , and an object, YY, then a
subsequent call to ORB::resolve_initial_references ( Y ) will return object
YY.
InvalidName is raised if:
" this operation is called with an empty string id;
or
" this operation is called with an id that is already registered, including
the default names defined by OMG.
What we think this means is that it would be impossible to register (and
resolve) ORB vendor external implementations of, for example, CORBA
Services, such as Naming, Trading, Notification, etc. as they are some of
the "default names".

Could you please amend the second "or" clause to something like:
or
" this operation is called with an id that is already registered, including
the default LOCALLY CONSTRAINED names defined by OMG, where 'LOCALLY
CONSTRAINED' would not then apply to any predefined CORBA Service names
such as NameService, NotificationService, etc.
Many thanks and apologies if you've already addressed this.

see above

I'm seeing more and more questions along the lines of:

"How can I get the repository ID of an object, given its reference?"

The standard answer is to call get_interface() and to then grope around
in the IFR. However, that's cumbersome, and the IFR may well not be
populated or running.

So, why is it that there is no way to get the repository ID from the target
object directly? I would think that adding something like the following
to CORBA::Object would work nicely:

interface Object

;

As far as the implementation is concerned, it would be trivial. We'd have
another "_rep_id" operation name in IIOP (similar to "_get_interface" and
"_non_existent"). On the server side, the implementation would simply
return the repository ID of the servant (the result of _primary_interface()
in the C++ mapping).

Yes, I know, we'd have to rev IIOP (which we are due to do some time
soon anyway, so we might as well add this at the same time).

Apart from the IIOP issue, I'd be interested in hearing what other people
think of this idea. Any glitches with it?

see above

on page 13-17, the spec says:

A Null TypeID is the only mechanism that can be used to represent
the type CORBA::Object.

This is in conflict with the information provided on page 15-28:

When a reference to a base Object is encoded, there are two allowed
encodings for the Repository ID: either "IDL:omg.org/CORBA/Object:1.0"
or "" may be used.

I would suggest to strike the sentence on page 13-17 because that is a
historical hangover.

Also, the entire section talks about "type IDs", when what it really means
are "repository IDs". I would suggest to hunt down all uses of "type ID"
and to replace them with "repository ID", because that's the correct
terminology.

see above Close no change

On page 15-43, we have a note:

Note--Usage of OBJECT_FORWARD_PERM is now deprecated, due to problems it
causes with the semantics of the Object::hash operation.
OBJECT_FORWARD_PERM features could be removed from some future GIOP
versions if solutions to these problems are not provided.

This seems to be in conflict with the decision to retain permanent forwarding
for FT ORBs. The note needs to be either deleted or updated to reflect
the real state of affairs.

Good catch. The note is simply wrong and should be removed

If the ServiceConfigurationSyntax identifier is a 0, the specification
says that the contents of the associated ServiceConfiguration is an ANS.1
Encoded version of a GeneralNames construct.

It is not specified what a conforming client implementation does when it
encounters this type of privilege authority. What is the conforming
behavior of a client?

If there is no conforming behavior, I believe the definition of
CSIIOP:SCS_GeneralNames should be removed from the specification, as there
is nothing "interoperable" about it, and this specification is an
interoperability specification.

As a remedy to this situation we should probably use a resolution of the
VMCID solution sought after in issue 4268, and let that Vendor specify it
in their specification (i.e. does EJB have a use for this?), when there is
a specification for it.

The ServiceConfigurationSyntax identifier of 1 specifies that the
ServiceConfiguration is a GSSExported name.

This one has a bit more use than 0, as the contents of a GSS exported name
construct can imply a lot, such as the protocol, the format of the token,
and a specification of where to get the authorization token.

So, the specification should state the specific OIDs that are understood
by a conforming CSS, and where to find the specification of the conforming
behavior of each OID.

Obviously there are no OID specified (yet), but there might be in the
future. It would be nice to know where to look, or otherwise remove the
definition of SCS_GSSExportedName from the specification.

close no change

Please forgive me if this is old news. I was trying to find a recent
CORBA Components spec to see what changes it has had on the core spec.

It looks like several new TypeCode kinds have been added (two from
CCM?), but doesn't that require a new GIOP version? Even if the specs
did declare the wire formats in new versions of Chapter 15, how could
older GIOP 1.2 ORBs handle them?

Specs:

CCM FTF drafts of modified CORBA Core chapters
Adds tk_component and tk_home in 10.7.1. No update to 15.
http://www.omg.org/cgi-bin/doc?ptc/99-10-03

CORBA 2.4.2 complete specification
Adds tk_local_interface in 10.7.1. No update to 15.
http://www.omg.org/cgi-bin/doc?formal/01-02-01

close no change, see above

It is underspecified what value member information for custom
marshaled valuetypes an ORB must provide.

Users of custom marshaled valuetypes must provide their own marshaling
code, and the ORB has no way of knowing what it does before executing
it.

This comes into play for custom marshaled valuetypes inside of Anys,
as well as the ValueMemberSeq in the FullValueDescription of a custom
marshaled valuetype.

In both cases, one can query whether or not the valuetype is custom
marshaled. With Anys, the TypeCode has a ValueModifier type_modifier
which is set to VM_CUSTOM. The FullValueDescription includes a
boolean is_custom.

I can see two possible solutions:

1. TypeCodes for custom marshaled valuetypes will encode no value
member information, so the member_count will be 0. The
FullValueDescription will have a zero length sequence for the
ValueMemberSeq members.

or

2. Value member information for the TypeCode or FullValueDescription
for a custom marshaled valuetype is the state defined in the
valuetype's IDL in the same way as if it were not custom marshaled.

I propose #1 as the solution. This member information is only useful
for finding out what is encoded, and solution #2 doesn't provide
that. Plus, it can be very expensive to create and transmit if many
repository IDs are involved.

see above