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

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

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