Summary: I am having difficulty understanding the intended use of
BiDirPolicy::BidirectionalPolicy. This is described (in section 15.9) as
a POA policy to be passed to create_POA. That section also says that
both client and server must have the policy with the value of BOTH for
bi-directional communication to take place.

My problem is that I don"t see how this policy applies to a particular
POA. Once bi-directional communication has been negotiated on a
connection, it applies to any request targetted at the negotiated
address(es), regardless of what POA is the recipient of the request. Nor
is it tied to the lifetime of a particular POA. And, what is supposed to
happen if one POA has the policy with value BOTH, and another POA has
the policy with value NORMAL?

:BidirectionalPolicy. This is described (in section 15.9) as

Summary: The new OBV keyword "supports" collides with the operation "supports"
defined in CosLifeCycle::GenericFactory.

:GenericFactory.

Summary: If we accept 2 above, we may want to revisit the following:
– 8.8.2, page 8-104, bullet 4:
"Inserting an abstract interface reference into a CORBA::Any
operates polymorphically. Either the object reference or value to
which the abstract interface reference refers is what actually gets
inserted into the Any. This is because there is no TypeCode for
abstract interfaces. Since abstract interfaces can not be inserted into
an Any, there is no need for abstract interface extraction operators."

Summary: The Query Service IDL code (document 97-12-18) has multiple syntax
errors. I have checked it with Orbix, OrbixWeb and Visibroker IDl
compiler.

No Data Available

Summary: For valuetypes that inherit from concrete valuetypes, the
ORB::create_value_tc operation is insufficient. In particular, it does not
allow the TypeCode for the base valuetype to be supplied. This means that
if a valuetype with a concrete base valuetype is passed in an Any to a
process that has no compile-time information concerning that valuetype, the
receiving process will be unable to marshal it. Having the RepositoryId of
the concrete base in the TypeCode does not solve the problem because the
two processes might not have an Interface Repository (IFR) in common, or
the concrete base RepositoryId may not be in the IFR known to the receiving
process. Also, never in CORBA should unmarshaling require lookups in the
IFR (this in fact should be an absolute ORB Core rule).

Proposal: change create_value_tc to

TypeCode create_value_tc(
in RepositoryId id,
in Identifier name,
in boolean is_custom,
in TypeCode concrete_base,
in ValueMembersSeq members
);

If the valuetype has no concrete valuetype base, the concrete_base argument
shall be a nil TypeCode reference.

:create_value_tc operation is insufficient. In particular, it does not

Summary: The module separator within "IDL: style" repository IDs is a "/".
The module separator within "H: style" repository IDs is a "::".
Was this difference intentional? If so, why? It seems confusing
to treat scoped names differently in the two kinds of IDs.

style" repository IDs is a "::".

Summary: OBV specifies a DynAny::get_value operation to retrieve a value from a
DynAny, but this operation breaks the existing DynFixed::get_value
operation. I suggest renaming the DynAny::get_value to avoid the collision
(gee, if we didn"t use "value" as one of those funny keyword identifiers,
this wouldn"t be a problem).

:get_value

Summary: 1. The following IDL cannot be translated into C++ code by an IDL
compiler for a C++ environment that does not support namespaces:

// IDL
module M {
struct S

;

interface I

;

value V supports A {
};
};

The reason for this is that module M maps to a C++ class when namespaces
are not available, and you end up with the following definition loop:

POA_M::I must be defined before M::V, since M::V inherits from it
M must be defined before POA_M, because POA_M::I depends on M::S
but defining M also defines M::V

Summary: On p. 6-63 of orbos/98-01-18, the get_value_def() method is defined in
the helper class as:

public static org.omg.CORBA.ValueDef get_value_def();

Currently, there is no portable way to implement this method for all
vendor ORB"s. One suggestion is to pass an ORB implementation instance
as parameter:

get_value_def(org.omg.CORBA.ORB orb);

and then add a method to the ORB class such as:

get_value_def(String idl_name);

Thus a portable implementation could be

public static org.omg.CORBA.ValueDef get_value_def(org.omg.CORBA.ORB
orb)

Summary:

issue was missing information, no action

Summary: Clarify which exception should be raised when no local class is
available to support an incoming value:
p 5-29, item 3 says it should be NO_IMPLEMENT
p 5-34, 3rd paragraph says it should be MARSHAL
p 5-34, last paragraph says it should be BAD_PARAM
p 6-67, last item says it should be MARSHAL
p 7-93, first paragraph of 7.3.10.2 says it should be MARSHAL

Summary: The new grammar rule:
<state_member> ::= <public_token> <type_spec> <declarators> ";"

:= <public_token> <type_spec> <declarators> ";"

Summary: I"ve come across another small glitch in the orbos/98-01-18
"Objects by Value" spec. This is in section 5.4.1 "Syntax", for the grammar rule:

<value_inheritance_spec> ::= ":" [ <safe_token ] <scoped_name>

* ]

As the rule (and the rules referring to this rule) are written now, a value
inheritance spec is either optional, or if specified, MUST begin with an
inheritance relation to another value type (e.g. : value foo2: foo1

).

Summary: CODESET_INCOMPATIBLE is not defined in CORBA 2.0, and so must be added to the list of standard exceptions in section 3.15.1

resolved is current core 2.3 draft, issue closed

Summary: Are the string lengths number of bytes or characters (in 3.1.2 of orbos/96-02-03)?

resolved in current 2.3 draft, close issue

Summary: There is an error in the grammar as written, so that you cannot (for example) have attributes of type wstring.

resolved in Core 2.3 draft, close dissue

Summary: Algorithm on p. 27 says to raise DATA_CONVERSION exception, but textual description on p. 28 par 1 specifies CODESET_INCOMPATIBLE exception when client and server native codesets aren"t compatible

resolved is current 2.3 draft, closed issue

Summary: Section 15.3.4.4. of ptc/98-10-11 includes the following statement wrt to
ObV chunking:

"The data may be split into multiple chunks at arbitrary points except
within primitive CDR types, arrays of primitive types, strings, and
wstrings."

Unfortunately, this provides only dubious benfits, but introduces
significant problems. Traditionally, CDR has been designed so that encoding
engines are only responsible for marshalling CDR primitives, and remain
independent of the actual constructed IDL type being marshalled. The above
clause violates this rule: the CDR stream must know that the primitives
being marshalled are part of an array, understand the size of the array,
distinguish sequences from arrays, etc.

In addition, this is impossible to implement using the Java portable
streams.

Summary: Document interop/98-08-02 states:

For GIOP versions prior to 1.2, interoperability for Wstring is limited
to the use of two octet fixed length encodings.

Does this mean simply that only fixed length character encodings that
are use 2 byte characters are allowed for GIOP versions prior to 1.2?

The statement is slightly ambiguous, in that it can be parsed as: "(two
octet) fixed length encodings" or "two (octet fixed length encodings)".

Close issue without change

Summary: CORBA 2.2 has the following sentences near the beginning of section
8.7.2:

In the case of an unnamed, bounded string type used directly in an
operation or attribute declaration, a TypeCode constant named
TC_string_n, where n is the bound of the string is produced. (For
example, "string<4> op1();" produces the constant "TC_string_4".)

CORBA 2.3 is missing these sentences.

Summary: The final draft (ptc/98-10-16 - from 15-Nov-98) defines
DynValue::get_members/set_members as:

–
struct NameValueAccess

;

typedef sequence<NameValueAccess> NameValueAccessSeq

NameValueAccessSeq get_members();
void set_members(in NameValueAccessSeq values) raises (InvalidSeq),
–

and goes on to say "Any attempt to set or get a member which has been
declared private in the IDL definition of the value contained in the
dynamic any raises the exception NO_PERMISSION."

:get_members/set_members as:

Summary:
the TypeCode pseudo interface makes no mention about the order of parameters
for structured types. For example, given the IDL struct

struct MyStruct

;

it is legal for member_name(0) to return "s_mem" and member_name(1) to
return "c_mem" (provided member_type(0) returns a char type code and
member_type(1) returns a string type code).

The same comments apply to unions, exceptions, and enums, where the order
in which members are presented is not necessarily the same order as in the IDL
definition.

No Data Available

Summary: 1) The insert_dyn_any and get_dyn_any operations are barely documented. It
seems the only explanation is given on 9-15: "The get_dyn_any and
insert_dyn_any operations are provided to deal with any values that contain
another any." The insert_dyn_any function should be specified as behaving
identically to insert_any, except that it allows an any in the form of a
DynAny to be inserted. The get_dyn_any should be specified as behaving
identically to get_any, except that it returns its result in the form of a
DynAny rather than an any.

"The get_dyn_any and

Summary: Hi, is it possible to pass a supporting value type by value when used as
a interface? It looks like this is droped from the OBV spec
(ptc/98-10-06.pdf says when a supporting value type is used as a
interface then an object reference will be used).

No Data Available

Summary: WRONG_TRANSACTION Exception

The CosTransactions module adds the WRONG_TRANSACTION exception
that can be raised by the ORB when returning the response to a
deferred synchronous request. This exception is defined in Chapter 4
of the Common Object Request Broker: Architecture and Specification.
This para doesn"t state what module is to be used for
WRONG_TRANSACTION. I assume what is meant is that it should be
a system exception?

• I can"t find this exception in either chapter 4 or chapter 3
  of the 2.3 spec. Looks like it needs to be added. I don"t know
  why the above para refers to chapter 4 though – it seems that
  this exception should be added to the list of system exceptions
  in chapter 3?

issue merged with issue1963

Summary: I"m preparing a proposal to "fix" fixed point types, but I"d like to
outline what I am thinking before I have it completed, in order to give
people a chance to comment.
Michi has pointed out a few issues with the fixed point constant
grammar, but I think I can resolve those pretty easily by making changes
so that fixed point constants are only allowed to be defined using the
syntax:

const fixed FOO = 1.2D;

Some people have expressed the idea that the fixed point type
specification is lacking sufficient semantic content, and they are
afraid that since different languages or even implementations of
languages might do the math differently that portability or
interoperability is affected. Frankly, I don"t see the problem as
serious for the CORE RTF. In most cases, the fixed point type is mapped
to the native fixed point facility of the language. If that isn"t
sufficiently robust to support stuff like banking applications, the CORE
RTF can"t do much to fix it anyway.

For the C++ RTF:

For the C++ binding, of course, things are broken. However, I think I
may have a solution to the problem:

First, define a new class CORBA::FixedValue which is used as the results
of all of the Fixed arithmetic operations, as well as for the type for
fixed point constants. FixedValue would store the digits and scale
information dynamically. All of the defined fixed point types would be
convertable from/to the FixedValue type, with the DATA_CONVERSION
exception available to signal overflow.

Second, get rid of the explicit reference to a template type. Since the
grammar will be changed to no longer allow anonymous fixed point
declarations (as parameter types), there is no longer a specific need to
define the exact type name for the Fixed types, and in fact,
implementations no longer must implement fixed as a template type.

No Data Available

Summary: Some ORBs are sloppy about existence. One ORB used raises INV_OBJREV whenever object doesn"t exist, even when server can be reached. Behavior is compliant..tighten spec here.

close no change in 2.4

Summary: Both operations permit the flag CORBA::RESP_NO_WAIT to be set. How is is invoker being informed that there is no response available? Incorrect to use exception.

resolved, closed issue

Summary: Para indicates that there may be more than 1 interface Repository in any given environment. How can portable application determine this, and how can it determine what the requirements are?

the application should use either the naming or trading service to determine which IR to use.

he description of null value semantics (in ptc/99-03-07) is insufficient to ensure an adequate mapping to an
implementation language. Issues that should be specified include: - Creation. How are null values created? Are all declared (but
uninitialized) values born null? Is this a language mapping requirement or allowance? - Invocation. Presumably invoking an
operation ON a null value should result in an exception. But, what exception? Shouldn't the exception be specified for application
portability? - Passing. Presumably, it is allowable to provide a null value as the actual parameter for a non member operation (i.e.,
not on itself). True? - Typing: are null values typed, untyped, or is this governed by the language mapping? - Substitutability (see
"typing" above): – Presumably: a null value may be successfully widened to a null value of an ancestor stateful value type. True?
– Can a null value be successfully widened to a (null) supporting concrete interface? (Can a null value be activated as a servant?)
– Can a null value be successfully widened to a (null) supporting abstract interface? – Can a null value be successfully widened
to a (null) ancestor abstract value type? The only mentions of null values currently are: - the bullet in 5.2 - 5.2.4.2

close issue, no change

Summary: Page 9-10 of the new DynAny draft says that you pass "DynFactory" to
resolve_initial_references() to get a DynAnyFactory. The third comment on
page 9-2, however, says the string should be "DynAnyFactory". I believe the
latter is correct.

No Data Available

Summary: I noticed the IDL for Container in ptc/98-12-04, page 10-59 is missing
is_abstract parameter in create_interface() operation.
The instance on page 10-16 does include it.

No Data Available

Summary: how is the ORB object destroyed? There is no ORB::destroy() operation,
like for the POA. (With "destroy", I mean to remove it from memory
(C++), or to allow it to be garbage collected (Java).)

Is shutdown to be meant to destroy the ORB? If so, then this must be
clarified in the specification. For example, if shutdown() destroys the
ORB, all subsequent calls to ORB operations (via ORB references) must
raise OBJECT_NOT_EXIST, just as it is with any other (locality
constrained) object.

If shutdown() does not destroy the ORB, but just shuts down
communications and stops handling of further requests, then some other
operation is needed to destroy the ORB.

No Data Available

Summary: Well, it looks like I get to choose what OMG"s VMCID is going to be. My
> current thoughts are to allocate 65613 as OMG"s VMCID. This will make
> the minor code value unsigned long appear on the wire as \x00, "M",
> \x0<e>, <E>; where <e> is the high four bits of the minor code and <E>
> is the lower 8 bits of the minor code.

No Data Available

Summary: The basic problem of creating recursive TypeCodes has become more
complex with the addition of valuetypes. The current mechanism for
creating TypeCodes (as adopted by the last RTF) cannot create
TypeCodes for a large number of cases, and can be quite confusing.
The new proposal solves the problem of creating recursive TypeCodes in
general and would deprecate all existing mechanisms for creating
recursive TypeCodes.

No Data Available

Summary: The create_value_tc() api and C++ example use ValueMembersSeq, but the name
should match the ValueMemberSeq ( no "s" after Member) definition given on page
10-33 & 10-65

No Data Available

Summary: deactivate_object page no: 9-35

void deactivate_object(in Objectid oid)
raises (ObjectNotActive,WrongPolicy)

If a servant manager is associated with the poa, ServantLocator:: etherealize will be invoked with the oid and the servant.
It should be ServantActivator::etherealize instead of ServantLocator:: etherealize.

The Note of deactivate object it should be ServantActivator::etherealize instead of ServantLocator:: etherealize

No Data Available

Summary: We have spent some time pondering the various issues surrounding
recursive TypeCodes and OBV, and have come up with a proposed
solution. This is not a formal proposal (it does not include actual
changes to the CORBA spec) and is intended mostly to promote
discussion.

For this discussion a recursive TypeCode is defined as a TypeCode
which contains data members which refer to the containing type or any
type containing the containg type.

The basic problem of creating recursive TypeCodes has become more
complex with the addition of valuetypes. The current mechanism for
creating TypeCodes (as adopted by the last RTF) cannot create
TypeCodes for a large number of cases, and can be quite confusing.
The new proposal solves the problem of creating recursive TypeCodes in
general and would deprecate all existing mechanisms for creating
recursive TypeCodes.

No Data Available

Summary: Where am I supposed to pick up the types defined in the CORBA module,
such as CORBA::Identifier, if I want to use them in my IDL?

The (now apparently missing) orb.idl file gave me access to the
TypeCode interface and the IFR interfaces, but mentioned nothing about
other types defined in the CORBA module.

:Identifier, if I want to use them in my IDL?

Summary: It appears that during the editing for the POA changes for 2.2, Appendix A
of the old BOA chapter was dropped without a trace. As a result, it looks
like the definition for the orb.idl include file has disappeared.

No Data Available

Summary: The IDL chapter says on page 3-24:

OMG IDL defines a char data type that is an 8-bit quantity which...

This seems to imply that chars must map to an 8-bit type in the target
language. Not all CPUs can do this. For example, on a Cray, chars are a
32-bit type.

I would suggest to remove the size requirement.

No Data Available

Summary: Section 6.2 of formal/98-07-05 mentions

typedef Naming::Name Key;

I believe it should be CosNaming::Name instead.

No Data Available

Summary: Firstly, in Section 3.10.2, "Parameter Declarations" on
page 3-32, the last paragraph states:

When an unbounded string or sequence is passed as an
inout parameter, the returned value cannot be longer
than the input value.

This seems like an undesirable and unnecessary restriction to me.
Is there any chance that you could remove this restriction in a
future version of the specification? Alternatively, if there is
a good reason for this restriction then perhaps you could document
it in a future revision of the specification.

Summary: Does anyone know why the CosObjectIdentity::ObjectIdentifier was changed
from "typedef sequence<octet,16>" to "typedef unsigned long"? This
happened some time ago between the 3/94 and 3/95 versions of the
CosRelationships specification.

It seems odd since the earlier version could support the 128 bit UUIDs
used in DCE and the 128 bit GUIDs found in Microsoft but the current
version is only one quarter the size. Also, all available literature I
can find on the topic indicates that the 128 bit version is necessary
for uniqueness "across space and time". In large distributed object
environments, I don"t think the 32 bit version will cut it.

No Data Available

Summary: The IDL in module CosTime for the compare_time and
time_to_interval operations is illegal. Reference
http://www.omg.org/archives/experts/msg00890.html
for further information.

No Data Available

Summary: 10. Define two new operations on TypeCodes:

pseudo interface TypeCode

;

TypeCode::get_compact_typecode() strips out all optional name & member
name fields. TypeCode::get_canonical_typecode() looks up the TypeCode
in the Interface Repository and returns the fully fleshed-out TypeCode.
If the top level TypeCode does not contain a RepositoryId, (such as
array and sequence TypeCodes, or TypeCodes from older ORBs), then a new
TypeCode is constructed by calling TypeCode::get_canonical_typecode() on
each member TypeCode of the original TypeCode. If the Interface
Repository is unavailable, or does not contain the information needed,
the call raises the INTF_REPOS system exception.

No Data Available

Summary: Points 1 through 9 need to be considered as one unit. Point 10 can be
voted on independently, but does provide a useful capability for
controlling the size and content of TypeCodes.

Proposal:

1. Make RepositoryIds mandatory for all TypeCodes that have them. [This
was done by the previous core RTF. I am just reiterating it here for
completeness.]

2. All TypeCode constants generated by the IDL compiler, as well as all
TypeCodes returned by the Interface Repository must include alias
TypeCodes wherever a typedef declaration appears in the original IDL
source.

3. Each IDL programming language mapping must provide a mechanism for
the programmer to ensure that values of the IDL any type contain the
exact typecode desired by the programmer.

4. The name() and member_name() fields of the TypeCode are for
documentary purposes only, and are never considered significant when
comparing TypeCodes.

5. Define a new equivalent operation for TypeCodes:

pseudo interface TypeCode

;

with the following semantics:

a) If the two TypeCodes are the same primitive type (null, void, short,
long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode,
longlong, ulonglong, longdouble, wchar) then equivalent() returns true.

b) If the two TypeCodes are string, wstring or fixed with the same
parameters (bounds, digits or scale) then equivalent() returns true.

c) If the two TypeCodes are both arrays or both sequences, with the
same bounds and their component types are equivalent(), then
equivalent() returns true.

d) If the two TypeCodes are both object references, return true if the
their RepositoryIds are the same.

e) If the two TypeCodes are both structs, exceptions, unions, enums or
aliases, and they have the same RepositoryId, then equivalent() returns
true. Note in this case that member TypeCodes are not compared.

f) If either or both of the TypeCodes have an empty RepositoryId, then
equivalent() falls back to a structural comparison, and returns true if
all members of the two TypeCodes also are equivalent(). This case will
only occur when interoperating with an older ORB that does not yet
require RepositoryIds as mandatory for these TypeCodes. Note that the
name() and member_name() fields are not used in this comparison.

g) Otherwise, equivalent() returns false.

6. The ORB uses TypeCode::equivalent for all internal TypeCode
comparisons, such as for supporting any (and thus DII and DSI) and
DynAny.

7. If the programmer needs to distinguish between a type and/or
different aliases of that type, he can call TypeCode::id() and compare
the RepositoryIds.

8. All DynAny insert & get operations do not consider aliases as
significant. The type() operation however, will return the TypeCode
with all of the aliases intact, including type() from any DynAny member
components. DynAny::assign() and DynAny::from_any compare the internal
TypeCode of the DynAny with the TypeCode of its argument using
TypeCode::equivalent() and raise Invalid if equivalent() returns false.

9. The TypeCode::equal() operation is not used internally by the ORB
and is deprecated.

No Data Available

Summary: Null termination is a marshalling and language mapping issue and should not
appear as part of the semantic description of the IDL type. It should be
completely valid for a language with a native wide string type to handle the
varying length nature of the wide string with or without use of null
termination and certainly without exposing it to the user. Therefore, the
description of the wide string type in 3.8.3 should not mention null
termination.

Also the syntax should be included.

No Data Available

Summary: In the course of a discussion Philippe Gautron pointed out to me that in
ISO-C++, the scope of a class begins with its declaration, and hence a
member or type declaration in the class may not introduce the same name
as that of the class, exception being constructors of the class.
Analogous rules apply to struct and namespace. When this principle is
extended to the case insensitivity of IDL a consequence is that

interface I

;

is illegal as is:

module M {
interface m

;
};

The basic rule is that the name of the scope, if it has one is
implicitly inserted into the scope and hence cannot be reused for other
purposes in that scope. Given that IDL has to be mapped to C++ this
seems like an eminently reasonable restriction. However, I could not
find this explicitly stated anywhere. Do y"all feel this is reasonable?
If so, and if it is indeed not mentioned then I think we should add a
line or two in 3.13 clarifying this?

No Data Available

Summary: IDL structs are specified to have "one or more" members rather than
"zero or more".

Whilst it might be argued from a stylistic point of view that an empty
struct is of limited use, of should be avoided, there are places where
it may be desirable to specify a placeholder struct for later expansion,
or for machine generated code where there happens to be nothing to fill
the struct with.

I can see no compelling technical reasons for requiring that a struct
contain at least one member, so I propose that the grammar be revised to
alow for a struct with zero members.

Such a change would not break any existing IDL.

No Data Available

Summary: Fix this by stating that member_label returns an Any containing
a sequence of labels if a single member has more than label.

Add a typedef to the TypeCode pseudo-IDL:

typedef sequence<any> LabelSeq;

A sequence of this type would be contained in the Any returned by
member_label() if a member has multiple labels (this avoids changing the
signature of member_label()).

For the above union, the member_count() operation would return 2, not 5.

No Data Available

Summary: On page 8-38:

Member_count [sic] returns the number of members
constituting the type.

This is a little ambiguous and easily confused with the number of parameters.
For clarity, I would suggest to add a sentence to make this clearer, e.g.
"For example, the member count of a structure with three members is three."

This would help to avoid confusion with parameters (if I am not careful,
I might think the number is six, because a the three members of a structure
are described by six parameters, or I might think that the number is nine,
because a three-member structure has a total of nine parameters).

The origin for the index to the member_name operation is never defined.
Presumably, indexes start at zero? If so, this must be stated.

No Data Available

Summary: There are a few typos in the spec for type codes.

Page 8-40:

A structure with N members results in a tk_struct TypeCode with
2N+1 parameters.

This is no longer correct. Because of the Repository ID parameter that
was added, this is now 2N+2.

Similar fixes need to be applied to the text for unions (3N+3 parameters,
not 3N+2), enumerations (N+2 parameters instead of N+1 as implied by
the text), and aliases (they have three parameters, not two).

The text for tk_objref also needs updating, because it states that
it has one parameter instead of two.

Also, Table 7-1 for tk_objref should be updated because it is internally
inconsistent.

No Data Available

Summary: Table 8-1 on page 3-39 of the CORBA spec contains a typo.
"tx_fixed" should be "tk_fixed".

No Data Available

Summary: There are two types of standard operations: ones that are transmitted
over the wire, and ones that are not. Now it seems reasonable to
support the over-the-wire operations via the DII, such as "is_a",
"non_existent", "get_interface" and "get_implementation" (obsolete), but
what about the ones that don"t go over the wire:

hash
is_equivalent
get_policy
get_domain_managers

I would guess that the DII should not support these operations, but the
spec does not explicitly say that. So, should we add a statement to the
DII part of the spec that an attempt to invoke these non-over-the-wire
operations should raise BAD_OPERATION?

No Data Available

Summary: - Section 8.8 page 8-55: change "element type" to "element_type" in
operation create_sequence_tc.

No Data Available

Summary: - Section 8.8 page 8-53: add "," after "tk_except" in definition of TCKind.

No Data Available

Summary: - Section 8.8 page 8-48: remove incorrect "};" between "create_array" and
"create_fixed".

No Data Available

Summary: - Section 8.8 page 8-47: need forward declarations of WstringDef and
FixedDef before use on page 8-48. Again, it would seem that they were
left out of the list of forward declarations on 8-47.

No Data Available

Summary: The following problems appear in the 2.2 spec (98-02-23) and the IDL
summary extracted from it (98-03-01.idl).

• Section 8.8 page 8-45: need forward declaration of ExceptionDef, i.e.,
  "interface ExceptionDef" before use on page 8-47. There are a number of
  forward declarations in the middle of 8-45 that would seem to be the
  logical place for it.

No Data Available

Summary: currently, #pragma prefix is completely unconstrained and can contain
any character. This includes potentially troublesome things such as space
and "/", or non-printing characters.

I would suggest to define a syntax for #pragma prefix. In particular, I think
that "/" should be forbidden in a prefix. This is because otherwise, given
a repository ID, I cannot work out where the prefix ends and the scoped
name starts. In addition, things that cannot normally be part of file names
or identifiers should probably be forbidden as well, otherwise we could
get problems with things like the class path in Java.

No Data Available

Summary: I"ve always been under the impression that CORBA does not have versioning.
it looks like we
actually do have versioning. Could someone please let me know what
the correct interpretation should be? Has this versioning stuff sort
of quietly snuck in via the back door?

I find this section of the spec particularly stunning because a few pages
earlier, it says about #pragma directives:

An IDL compiler must eithe rinterpret these annotations
as specified, or ignore them completely.

So, on the one hand, we can happily ignore #pragma, and a few pages
later, we go and add semantics to the version pragma?!

No Data Available

Summary: Section 4.2 (page 4.4) of the corba 2.2 spec defines a "non_existent" operation
on CORBA::Object. In Section 13.4.1 (page 13-23) it sates that the operation
name for such a request is encoded as the string "_not_existent". This latter
string looks like a typo, and we propose to change this (on page 13.23) to
"_non_existent".

:Object. In Section 13.4.1 (page 13-23) it sates that the operation

Summary: 3) There is no way at present to implement the
Object:get_domain_managers operation in an interoperable fashion. To fix
this it seems a new GIOP message needs to be defined to carry the
implicit get_domain_managers operation. There of course may be other
ways to fix this. Some of the submitters of the original security spec
saw domain managers as replicated objects such that a replica of it was
present in each ORB instance where there was an object belonging to that
domain manager was instantiated, thus relegating the problem of getting
the domain manager information to the replication mechanism. Well, the
hoped for replication facility has not happened yet and there is no
other way to implement this interoperably. This needs to be fixed.

get_domain_managers operation in an interoperable fashion. To fix

Summary: The spec lists the standard exceptions in section 3.15.1.

However, for many of these, there are no semantics specified anywhere.
Instead, for the majority of standard exceptions, the only "semantics"
are what is in the comments in section 3.15.1.
We badly need an explanation of which standard exception indicates what
error condition in the spec, otherwise we"ll never get agreement on which
exception means what...

No Data Available

Summary: The IDL spec explains forward declarations at the end of section 3.5.2.
However, it does not make the following illegal:

interface base; // Forward declaration

interface derived: base

;

interface base

;

The problem here is that a forward-declared interface is used as a base
interface before the definition for that interface has been seen.
In the absence of further words in the spec, this is legal, but clearly,
it should be illegal (otherwise, I can"t use a single-pass compiler).

Summary: interface Object on page 4-4 shows:

interface Object

;

The first four declarations use no indentation, the fifth declaration
uses one indentation level, and the final four declarations use a different
indentation level. This could be tidied up a bit.

No Data Available

Summary: In the recap IDL at the end of chapter 8, there is a missing comma after
the tk_except enumerator in the definition of TCKind.

No Data Available

Summary: Page 4-9 of CORBA 2.2:

ORBid strings other than the empty string are intended to be used
to uniquely identify each ORB used within the same address space
in a multi-ORB application.

I don"t believe this is possible, mainly because the language mappings
do not permit multiple ORB run-time libraries to be linked into the same
address space.

No Data Available

Summary: It appears that the IDL concept of a module is tightly bound to
the storage of IDL statements in files. In other words, it does not
seem to be possible to distribute IDL statements in the same logical
module across multiple files. Consequently, few people use the
concept, and name collisions occur sooner or later when trying to
integrate systems that have not been developed by only one group.

No Data Available

Summary: I"m not quite sure where this should go, but there should be an explicit
statement somewhere in the CORBA descriptions that states how to deal
with object identity with respect to subscribe/unsubscribe schemes.

The (language/CORBA/etc independent) pattern
interface SomeSender

is very commonly found, and as far as I understand it (I might be wrong,
but if so, it needs to be documented that this would be incorrect),
SomeListener actually needs to implement a "is_identical( Object )"
operation that would be called by the removeSomeListener() operation
in order to find out which of the registered listeners should be removed.

No Data Available

Summary: On page 13-13, CORBA 2.2:

A "simple" parameter list has a fixed number of fixed length entries,
or a single parameter which is has its length encoded first.

This should probably be

... single parameter which has is length encoded first.

No Data Available

Summary: Page 3-20 of CORBA 2.2:

A fixed-point literal has the apparent number of total and
fractional digits, except that leading an trailing zeros are
factored out, including non-significant zeros before the decimal
point. For example, 0123.450d is considered to be fixed<5,2> and
3000.00 is fixed<1,-3>.

Apart from the fact that 3000.00 is not a fixed point constant literal,
I"m confused about something else...

If 3000.00d is fixed<1,-3>, then 3000.0000d is also fixed<1,-3>.

These rules result in

3000.00d being fixed<1,-3>
BUT
3000.01d being fixed<6,2>

This doesn"t seem to make sense. If I bother to write the trailing zeros,
surely I have a reason, namely, that I mean to use that scale. In other words,
I think that

3000.00d should be fixed<6,2>
and
3000.0000d should be fixed<8,4>

Why are fractional trailing zeros thrown away but fractional trailing
non-zeros retained?

No Data Available

Summary: Section 3.2.5 on page 3-9, 2nd para says:

Wide character and wide string literals are specified exactly
like character and string literals. All character and string
literals, both wide and non-wide, may only be specified
(portably) using the characters found in the ISO 8859-1 character
set, that is interface, names, operation names, type names, etc., will
continue to be limited to the ISO 8859-1 character set.

• The first part says that wide character literals and wide string literals
  are to be specified exactly like character and string literals.

This seems to be impossible - if they were exactly the same, there would
be no point in having them... At any rate, the sentence seems to
imply that I must restrict myself to ISO Latin-1 characters in
wide literals.

• The second part then says that wide literals are restricted to 8859-1,
  but that interface names (etc.) will continue to be limited to 8859-1.

Now what is that supposed to mean? Interface names have always (and
incorrectly) been limited to 8859-1. Nothing has changed. Am I to
imply then that the sentence was meant to suggest that wide literals
can actually contain wide characters other than 8859-1?

This paragraph simply doesn"t make sense as it stands.

No Data Available

Summary: the 2.2 spec on page 3-20 defines the type of a fixed point division as:

fixed<(d1-s1+s2) + Sinf, Sinf>

I"m having a problem with this: The type of the result cannot be known
at compile-time because it depends on the actual values.

This differs from the add, subtract, and multiplication operators,
where the result type can be determined statically.

There is a C++ mapping problem too. The C++ mapping uses a template
type for fixed point, where the digits and the scale are template parameters
(i.e. must be compile-time constants).

No Data Available

Summary: Section 3.7.2 of CORBA 2.2 contains an error on page 3-20, last para:

For example, 0123.450d is considered to be fixed<5.2> and
3000.00 is fixed<1,-3>.

This is in conflict with section 3.2.5 on page 3-9, last para:

A fixed-point decimal literal consists of an integer part, a
decimal point, a fraction part and d or D. [ ... ]
Either the integer part of the fraction part (but not both)
may be missing; the decimal point (but not the letter d (or D))
may by missing.

So, it seems that the "3000.00" on page 3-20 really should be
"3000.00d" or "3000.00D".

No Data Available

Summary: CORBA 2.2 GIOP does not define a way to invoke is_equivalent on an object remotely

close no change with above explanation

Summary: How does the scope of #pragma prefix interact with #include? Find details in the corresponding archive

No Data Available

Summary: Whilst implementing the POA I noticed that there were no extensions to
the Interface Repository or TypeCodes to handle native types.

The nett result appears to be that there is no way to express some of
the POA interfaces in the Interface Repository. Obviously the native
interfaces themselvse can"t be expressed, but nor can some of the IDL
specified interfaces.

e.g. ServantLocator has two operations (preinvoke and postinvoke) both
of which have a Cookie listed as a parameter. There appears to be no way
to generate a TypeCode for the Cookie (native) paramter and therefore no
way to perform an InterfaceDef.create_operation to desribe either of
preinvoke or postinvoke.

No Data Available

Summary: The CDR encoding rules for fixed-point types are incomplete.

In particular, it is not stated which value encodes what digit in each
nibble of an octet. It seems sensible to use 0x0 -> "0", 0x1 -> "1", ...,
0x9 -> "9". However, this isn"t stated (but should be).

The same comment applies to page 7-10 for DynFixed. I would suggest that
rather than repeat the same explanations in the CDR section and the DynFixed
section, the spec should use a cross-reference in the DynFixed section that
points at the CDR rules.

Interop RTF has recommended adoption of this resolution.

Summary: GIOP 1.1 only allows Request and Reply headers to be fragmented. But
GIOP 1.2 increases the size of LocateRequest messages, and large
LocateReply messages are also likely. I see no reason why GIOP 1.2
should not allow LocateRequest and LocateReply messages to be
fragmented. If noone objects, I"d like to see the following put to a
vote in the next ORB 2.4 Interoperability RTF for inclusion in CORBA
2.3:

see above

Section 15.7.3 includes TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS
in the list of tagged component ids when they are tagged profile ids.

editorial change to CORBA 3.0 resolved

Something seems unclear to me about how to interpret a RequestHeader_1_2
when the AddressingDisposition of the TargetAddress is ReferenceAddr:

In the case the request contains a full IOR, which may have several
profiles. Since each profile has its own object_key, and there is no
requirement that they all be the same, the key for the operation may
depend on which profile chosen.

The client had to choose some profile in order to send the request, but
that information is not included in the request. So apparently the
server must decide on its own which profile it would like to use. This
may not be the same one the client chose.

What if any requirements are there on how this is done?

withdrawn by submitter...issue closed

Summary: The IDL in section 5.5.3 is incorrect. It refers to
CORBA::FullValueDescription
but the correct name for this type according to chapter 10 is
CORBA::ValueDef::FullValueDescription

Proposed Resolution:

Change chapter 5 to match up with chapter 10.

make it so.

Summary: There is a problem with the currently defined algorithm for computing
the hash code component of the RMI Hashed Format repository ID as
defined in section 10.6.2. Because it is based only on the structural
information in the most derived Java class and does not take into
acoount any superclass information, it can give a "false positive"
result when the state of a superclass changes but the state of the
most derived class does not.

This is a core RTF issue since the affected text is in chapter 10.

Replace the currently defined algorithm with one that fixes the problem as described below

Summary: Pages 3-18 and 3-19 of the CORBA 2.3a spec state that a forward declaration consists of the following:
[abstract] "interface" <identifier>
I believe that this should be:
[abstract] "interface" <scoped_name>

Otherwise, the following would be illegal:
module A
{
interface B::d; //forward decl of d
interface c

;
};
module B
{
interface d

;
};

Close no change in 2.4

Summary: What should happen if the servant returned from a
ServantActivator::incarnate call is already registered for another
object id, and the POA has the UNIQUE_ID policy?

Since this is clearly an error, I suggest raising the OBJ_ADAPTER
exception (which will be returned to the client whose request prompted
the call to incarnate). I also suggest requiring the POA to call
ServantActivator::etherealize for that object id. The latter is
necessary to allow the application to dispose of any resources
associated with that object, and to ensure that an application will
never recieve two calls to ServantActivator::incarnate for a particular
object id without an intervening call to ServantActivator::etherealize.

Incorporate change and close issue

Summary: The description of IdUniquenessPolicy in section 11.3.7.3 fails to
mention how this policy interacts with the ServantRetentionPolicy.

My interpretation is that the IdUniquenessPolicy is irrelevant when the
ServantRetentionPolicy is NON_RETAIN. If this is the case it should be
explicitly stated. Alternatively, one specific value might be required
when NON_RETAIN is in effect. (If so, it ought to be MULTIPLE_ID.)

Without some statement clarifying this there could be portability
problems with some orbs allowing either value while others require a
particular value.

No Data Available

Summary: I propose the addition of the new basic data type "opaque."

Many applications require the sending or retrieving of opaque data,
like graphical data or file contents. Currently, such data is packaged
as sequence<octet>.
In the past, the performance of passing sequence<octet> parameters
was not satisfactory because of the generic mapping of sequences. In
the recent C++ mapping, the dubious get_buffer() is introduced for
the mapping of sequences.
I feel that this matter is best resolved by adding a new data type
which can then be mapped efficiently into target languages without
the side effect of complicating the mapping of other sequences.
After all, a "string," too, is nothing but a sequence of char.

No Data Available

Summary: The DynAny::equal operator does not mention how to compare object
references or TypeCodes. It should be specified to require is_equivalent()
to be called for object reference comparison and equivalent() to be called
for TypeCode comparison.

No Data Available

Summary: Should valuetype identity be preserved across arguments when those
valuetypes reside within Anys?

No Data Available

Summary: The IDL in section 9.2 of ptc/98-12-04 is incorrect. The OBV RTF adopted
method names insert_val and get_val instead of the original insert_value
and get_value which conflicted with the get_value method in the DynFixed
subclass. The IDL incorectly shows these methods as insert_valuetype
and get_valuetype.

Proposed Resolution:

Change insert_valuetype to insert_val and get_valuetype to get_val.

fix the names in section 9.2

Summary: Section 4.3 of ptc/98-10-05 documents Object Reference Operations. These
are described as "not operations in the normal sense, in that they are
implemented directly by the ORB, not passed on to the object
implementation".

This includes a variety of operations, requiring varying contexts to be
used successfully:

• Some require remote communication to the orb of the server
  or (contrary to the quote above) may actually be passed on
  to the object implementation, or something similar like a
  servant manager (e.g. is_a, non_existent)
• some may require remote communication to an interface repository
  (e.g. get_interface)
• some require the local orb to be operational
  (e.g. create_request)
• some can function even without a local orb
  (e.g. is_nil, duplicate, release)

No Data Available

Summary: If I use activate_object_with_id and the object ID is already in the AOM,
the operation raises ObjectAlreadyActive.

If I use activate_object_with_id and the servant is already in the AOM, and
the POA has UNIQUE_ID, the operation raises ServantAlreadyActive.

What happens if I have UNIQUE_ID, and I run the following code?

poa->activate_object_with_id(my_id, my_servant);
poa->activate_object_with_id(my_id, my_servant); // ???

Which exception is raised on the second call, ObjectAlreadyActive or
ServantAlreadyActive?

No Data Available

Summary: Latest 2.3, draft (98-10-10), page 13-17:

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

I am aware of more than one ORB that uses "IDL:omg.org/CORBA/Object:1.0".

I don"t understand why:

• a null ID should mean Object

• why a perfectly good repository ID for Object should be disallowed

Related to this is the fact that we made repository IDs mandatory in
reference TypeCodes with the 2.3 revision. Unless an implementation is
very careful, this could mean that, if it gets a reference that doesn"t
have the repository ID, it could present an illegal TypeCode (with an
empty ID) for that reference to the application.

closed in interop/2000-01-01

Summary: In the POA, we have

ObjectId activate_object(in Servant s) raises(...);
void activate_object_with_id(in ObjectId id, in Servant s) raises(...);

However, for deactivation, we have only one function:

void deactivate_object(in ObjectId id) raises(...);

This lacks symmetry. If I can use implicit activation of a servant,
why can"t I use implicit deactivation? For symmetry, I would have expected:

void deactivate_object() raises(...);
void deactivate_object_with_id(in ObjectId id) raises(...);

No Data Available

Summary: I"m sorry to reopen this can of worms, but I believe that the shutdown()
issue we voted on (1665) still only offers a partial solution. The problem
appears to be that terminating the event loop and ORB destruction must be
separate steps.

Consider a very simple application that uses RETAIN, NO_IMPLICIT_ACTIVATION,
and USER_ID. No servant manager is used.

This issue should be closed no change.

Summary: I have found inconsistent spellings of "policy" related identifiers:

"DomainManagersList" is used on pages 4-4 and 4-8

"DomainManagerList" is used on pages 4-17,20-87,20-88,20-110

Also, the operation identifer

"set_policy_override" is used on pages 20-87, 20-88, 20-110

However, this same operation identifier is consistently spelled as

"set_policy_overrides" on pages 15-52,15-61,15-65,15-66,15-103,
15-104,15-105,15-106,15-108,15-109,15-111,15-199,15-218,
and 15-219

in 98-12-03.pdf (Security Service Specification - Security Service
v1.5 15 December 1998 [FINAL]

So what is the "correct" spelling of these identifiers?

Close no change in 2.4

Summary: Jishnu has pointed out (very pointedly i might add that a whole slew of
upwardly incompatible changes have been made to the IR.

E.g. old structs that have been modified (e.g. full interface description),
new structs have been added, operations added to container, changed
tckind, etc., etc.

The question before us is how, if at all, to reflect this change.

We came up with several options (listed in no particular order and
with no particular recommendation.)

1. Do nothing. This is the traditional approach but probably becoming
less and less appropriate as we mature

2. Add a #pragma version name_of versioned_thingy major.minor
for every definition. (Jishnu thinks that in
principle all the #pragma version statements could go in one place,
say at the end of the CORBA module. [We leave it as exercise to the
reader to work out why they have to go at the end] )

3. Change the name of the enclosing module. say CORBA -> CORBA_2_3, gulp!!

incorporate changes in 2.4 and close issue.

Summary: There seems to be general consensus that the interceptor spec is
unimplementable fantasy material. Given this, it would seem advisable to
remove interceptors from the core.

Also, there is some doubt as to whether P&P rules were followed when
interceptors were added. My understanding is that an RTF cannot add
new features to a spec, yet interceptors definitely seem to fall into
that category.

Given that no RFP was ever issues and that the feature is obviously broken,
I suggest to remove the interceptor section until the outcome of the
Portable Interceptors RFP can be added.

Close in 2.4 with no change.

Summary: The text in the interface repository specification that describes FullInterfaceDescription is ambiguous. CORBA v2.3a draft, section 10.5.23.1, page 10-22 reads:

The describe_interface operation returns a FullInterfaceDescription
describing the interface, including its operations and attributes. The
inherited describe operation for an InterfaceDef returns an
InterfaceDescription.

It does not specify whether the elements of the FullInterfaceDescription should describe only items (e.g., operations, attributes) that where defined in the interface being described, or whether they should describe items inherited from base interfaces as well. My naive, assumed rationale is that the full description is intended to improve efficiency. It should allow a dynamic client to obtain all of the information it needs to invoke any operation supported by the interface in a single request, avoiding the need to traverse the graph of base interfaces. If this is the case, then the full description should include inherited items as well, and the spec should say so. I checked our implementation (VisiBroker) and this is what it does.

My suggested remedy is to add the following words to the paragraph cited above:

"The operations and attributes fields of the FullInterfaceDescription structure include descriptions of all of the operations and attributes in the transitive closure of the inheritance graph of the interface being described."

The bug (I think) is that the FullInterfaceDescription description doesn"t include the boolean is_abstract member. The abbreviated InterfaceDescription struct has been extended with this member, and the FullInterfaceDescription should be a superset of the InterfaceDescription.

The suggested fix is to add the the following member to the InterfaceDef::FullInterfaceDescription struct:

boolean is_abstract;

Incorporate changes in 2.4 and close issue

Summary: This comment uses examples from the chapter 3, but its idea concernes style of the all specification, as a general rule.
6) In the version CORBA 2.2, there were introduced new features and new simple data type. I understand, that such types like long long and/or long double may be key parts for some application. On the other hand, majority of applications need not such data types, and I see no reason to introduce them as obligatory to all CORBA implementations. For this reason, try to difference various features as obligatory for any CORBA compliant implementation and other ones as optional.
In general, it is good idea to specify advanced features of this system to unify various its implementators, but, on the other hand, why those features are made obligatory? For this reason, try to define obligatory and optional parts of the CORBA specification.

Close in 2.4 with no change.

Summary: During study of the ORBIX software, I analyzed structure of internal stubs generated by IDL compiler on the both client and server side of the CORBA connection. I appreciated, that for creation of the both sides are used the same constructions like Request object, not different objects Request on the client side and ServerRequest on the server side. Naturally, there was also possibility to use CORBA compliant ServerRequest object when requested, but generated stubs used "old" IONA logic. May be, there are some sophisticated reasons why OMG specification use various objects on both client and server sides which I do not know, but in general, I prefer more simple approach of IONA. Please, let application interface as simple as possible.

This issue is adequately dealt with in the POA specification.