This issue concerns the table 4.8 "exluding support for home finders" there
are still references to finder operations and home finders in the following
sections:
1.7.1 (§2), 1.7.1.1, 1.7.3, 1.7.3.3, 1.7.4 (§1), 1.7.5 (heterodox), 3.3.6
(point 5), 4.3.2.1 (get_CCM_home), 4.5, 4.5.1 (point 4, last §), 4.5.1.1
(last point), 4.5.1.2
The following sections have to be removed:
1.7.3.2, 4.5.1.3, 4.5.2.3

Proposed resolution:

Add a row in the table 4.8 with :
"Normative Exclusion" column : Exclude support for home finders and finder
operations
"Document Impact" column :
Section 1.7.1, paragraph 2: remove reference to home finders and
finder operations.
Section 1.7.1.1: remove reference to home finders and finder
operations.
Section 1.7.3: remove reference to home finders and finder
operations.
Section 1.7.3.3: remove reference to home finders and finder
operations.
Section 1.7.4 paragraph 1: remove reference to home finders and
finder operations.
Section 1.7.5 (heterodox): remove reference to home finders and
finder operations.
Section 3.3.6, point 5: remove reference to home finders and finder
operations.
Section 4.3.2.1 (get_CCM_home): remove reference to home finders and
finder operations.
Section 4.5: remove reference to home finders and finder operations.
Section 4.5.1, point 4 and last paragraph: remove reference to home
finders and finder operations.
Section 4.5.1.1, last point: remove reference to home finders and
finder operations.
Section 4.5.1.2: remove reference to home finders and finder
operations.
Section 1.7.3.2: remove
Section 4.5.1.3: remove
Section 4.5.2.3: remove

On page 11: The Normative Impact "Disable get_connections, get_all_receptacles, get_named_receptacles operations in the Receptacles interface" does not match the Document Impact: "Section 1.5.3: remove". Removal of section 1.5.3 removes the Receptacles interface in it entirety, including the description of the generic connect and disconnect operations, which are referred to by comment in the previous item. The Document Impact needs to be narrowed.

This issue concerns the table 4.1 "exluding support for Persistence", row 4;
there are still references to abstract storage type in the following
sections:
3.2.2 (§2), 3.2.6, 3.2.9 (point 4)

Proposed resolution:

Row 4 in the table 4.1, add in the "Document Impact" column :
Section 3.2.2, paragraph 2: remove references to abstract storage type
Section 3.2.6: remove references to abstract storage type
Section 3.2.9, point 4: remove references to abstract storage type

This issue concerns the table 4.1 "exluding support for Persistence", row 3;
there are still references to abstract storage homes in the following
sections:
1.7.4, 3.2.5 (§4), 3.2.6

Proposed resolution:

Row 3 in the table 4.1, add in the "Document Impact" column :
Section 1.7.4: remove references to storage home
Section 3.2.5, paragraph 4: remove references to abstract storage home
Section 3.2.6: remove references to abstract storage home

This issue concerns the table 4.2 "exluding support introspection,
navigation, ...", row 2; there are still references to these operations in
the following sections:
1.4.3, point 3 and 4, section 1.4.3.4, paragraph 1

Proposed resolution:

Row 2 in the table 4.2, in the "Document Impact", add:
Section 1.4.3, point 3 and 4: remove references to these operations
Section 1.4.3.4, paragraph 1: remove references to these operations

While reviewing Victor's issue on section 1.5.3, I noticed
that a similar problem exists with respect to the Events
interface.

While the normative exclusion "disable get_all_consumers
[...]" (8th row of section 10.3) retains the generic
get_consumer, subscribe, unsubscribe, connect_consumer
and disconnect_consumer operations, removing section 1.6.8
would remove the entire Events interface.

Proposed resolution:

In section 10.3, in the "Document Impact" column of the
8th row, replace the text

Section 1.6.8: remove

with

Section 1.6.8: remove these operations from the Events
interface. Also remove the ConsumerDescription,
EmitterDescription, SubscriberDescription and
PublisherDescription types.

While reviewing Victor's issue on section 1.5.3, I noticed
that a similar problem exists with respect to the Navigation
interface.

While the normative exclusion "disable get_all_facets, get_
named_facets, same_component operations in Navigation
interface" retains the generic provide_facet operation,
removing section 1.4.3.3 would remove the entire Navigation
interface.

On the other hand, the still-present section 1.4.3.4 references
the disabled operations.

Proposed resolution:

In section 10.3, in the "Document Impact" column of the second
row, replace the text

1.4.3.3: remove

with

1.4.3.3: remove these operations from the Navigation
interface. Also remove the PortDescription, FacetDescription
and FacetDescriptions types.

1.4.3.4: remove

This issue concerns the table 4.5 "exluding support for security", there are
still references to the security feature in the following sections:
4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 , 4.5.1.5, 4.5.2.5

Proposed resolution:

Add a row in the table 4.5 with :
"Normative Exclusion" column : Exclude support for security
"Document Impact" column : Section 4.2, paragraph 1: remove reference to
security
Section 4.2.1, paragraph 1: remove reference to security
Section 4.2.12: remove reference to security
Section 4.5.1.1: remove reference to security
Section 4.5.1.5: remove reference to security
Section 4.5.2.5: remove reference to security

This issue concerns the table 4.4 "exluding support for transaction", there
are still references to the transaction feature in the following sections:
4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 (point 2), 4.5.1.4, 4.5.2.4

Proposed resolution:

Add a row in the table 4.4 with :
"Normative Exclusion" column : Exclude support for transaction
"Document Impact" column : Section 4.2, paragraph 1: remove reference to
transaction
Section 4.2.1, paragraph 1: remove reference to transaction
Section 4.2.12: remove reference to transaction
Section 4.5.1.1, point 2: remove reference to transaction
Section 4.5.1.4: remove reference to transaction
Section 4.5.2.4: remove reference to transaction

This issue concerns the table 4.1 "exluding support for Persistence", row 7;
the section 4.1.2 doesn't have to be fully removed. Only the references to
entiy container have to.

Proposed resolution:

Row 7 in the table 4.1, add in the "Document Impact" column, replace
"Section 4.1.2: remove" by "Section 4.1.2: remove reference to entity
container API types".

This issue concerns the table 4.1 "exluding support for Persistence"; there
are still references to persistence in the following sections:
4.2 §1, 4.2.1 §1, 4.2.12

Proposed resolution:

Add a row in the table 4.1 with :
"Normative Exclusion" column : Exclude support for persistence
"Document Impact" column : Section 4.2, paragraph 1: remove reference to
persistence
Section 4.2.1, paragraph 1: remove reference to persistence
Section 4.2.12: remove reference to persistence

This issue concerns the table 4.1 "exluding support for Persistence", row 7;
there are still references to entity components in the following sections:
3.3.3.3, 4.5.1.3 (§1), 4.5.2.3 (point 3)

Proposed resolution:

Row 7 in the table 4.1, add in the "Document Impact" column :
Section 3.3.3.3: remove references to entity components
Section 4.5.1.3, paragraph 1: remove references to entity components
Section 4.5.2.3, point 3: remove references to entity components

This issue concerns the table 4.3 "exluding support for segmentation", there
are still references to segmentation in the following sections:
: 3.2.1.6 (§1), 3.2.11 (§1), 3.2.9 (point 2), 4.2.12 (extended)

This issue concerns the table 4.3 "exluding support for segmentation", row
3; there are still references to locator in the following sections:
3.3.3.5, paragraph 4 and last paragraph

Proposed resolution:

Row 3 in the table 4.3, in the "Document Impact", add:
Section 3.3.3.5, paragraph 4 and last paragraph: remove references to
locator

This issue concerns the table 4.1 "exluding support for Persistence", row 2;
and the table 4.3 "exluding support for segmentation", row 1: there are
still references to CIDL in the following sections:
1.5.2.1 (§1), 3.1 (§1)

Proposed resolution:

Row 2 in the table 4.1 and Row 1 in the table 4.3, add in the "Document
Impact" column :
Section 1.2.2.1, paragraph 1: remove references to CIDL
Section 3.1, paragraph 1: remove references to CIDL

This issue concerns the table 4.6 "exluding support for configurators";
there are still references to configurators in the following sections:
1.10.2 (second point), 1.10.2.1 (§2), 1.11.1 (configuration_complete)

This issue concerns the table 4.1 "exluding support for Persistence"; in the
"Document Impact" column, row 1, the § 3 doesn't exist in the section 1.1.4.

Proposed resolution:
Table 4.1, row 1, column "Document Impact": replace "Section 1.1.4,
paragraph 3: remove" by "Section 1.1.4, paragraph 2: remove"

This issue concerns the table 4.1 "exluding support for Persistence", row 1;
there are still references to primary key in the following sections:
1.7.1 (§1 & §3), 1.7.4, 1.7.5.1 (§1, §2), 1.7.5.2 (§1, §2)

Proposed resolution:

Row 1 in the table 4.1, add in the "Document Impact" column :
Section 1.7.1, paragraph 1 and 3: remove references to primary key
Section 1.7.4: remove references to primary key
Section 1.7.5.1, paragraph 1and 2: remove references to primary key
Section 1.7.5.2, paragraph 1and 2: remove references to primary key

This issue concerns the table 4.7 "exluding support for proxy homes", row 2
and 3 are not valid

Proposed resolution:

remove the rows 2 and 3 of the table 4.7

This issue concerns the table 4.7 "exluding support for proxy homes", row 1;
in section 3.2.5, the last paragraph should be removed.

Proposed resolution:

Row 1 in the table 4.7, in the "Document Impact", add:
Section 3.2.5 last paragraph:remove

This issue concerns the table 4.1 "exluding support for Persistence", row 7;
there are still references to Entity2Context in the following sections:
3.2.11 (§2)

Proposed resolution:

Row 7 in the table 4.1, in the "Document Impact", add:
Section 3.2.11, paragraph 2:remove reference to the Entity2Context
interface.

Summary: The OBV spec (orbos/98-01-18) does not specify which TypeCode operations apply
to Value and ValueBox types. For example, are id(), name(), member_name(),
member_count(), member_type(), etc. valid for Value and ValueBox or should they
raise BadKind exception?

I don"t see why they should not be valid. Normative text should be added in
CORBA 2.2 section 8.7.1 TypeCode Interface to reflect this and the comments in
the IDL should also be updated.

Summary: 1) Can a Value type inherit from a Value Box type (the Value Box is
described as been syntactic sugar for a Value type)? If so, what is the
implicit name of the Value Box"s single data member?

BTW I think the twiddle is incomplete because it is not reflected
in the BNF for Identifier. I think it is better if the BNF always
reflects the ultimate specification of a language's lexical
definition. Otherwise compiler writers are apt to miss the
subtleties.
I'll propose some BNF changes if others agree

There is a sentence in the first paragraph of 22.6 that should be fixed:

"The implementation of these methods must generate a method invocation
as described in Section 22.14, Message Routing, on page 22-50."

However, 22.2.5.3 allows asynchronous invocations to be delivered via
synchronous protocols if the RoutingPolicy is ROUTE_NONE.

This sentence should be changed to:

"The implementation of these methods may generate a method invocation as
described in Section 22.14, Message Routing, on page 22-50, depending
on the effective RoutingPolicy for the invocation."

For IDl4 the CDR marshaling should be described, optional could be described as a union with a boolean discriminant, with TRUE containing the value, map as a sequence of structs containing each key/value, other IDL4 extensions can also be described using IDL base types marshaling. That also enables interoperability of optional/map/others with an old implementation without IDL4 support, the IDL has to be rewritten to work, but at that moment an IDL3 app can talk with a IDL4 app (at least for CDR)

In chapter 11 'Unreliable Mulicast Inter-ORB Protocol' the struct PortableGroup::GroupInfo is discussed. However in the consolidated IDL and the IDL available from the OMG web site, this struct has been replaced by PortableGroup::TagGroupTaggedComponent. Which is correct?

Summary: The enum should be named CORBA_CompletionStatus instead of CORBA_ExceptionType

Summary: Enum CORBATCKind omits the boolean kind (p.4-123, section 4.1.12) I recommend adding it to the end of list to preserve backward compatibility. Also missing tk_char.

Summary: ODL which shows an extra, optional parameter for exception information on property-get or property-set method is erroneous, since MKTYPLIB doesn"t allow extra parameter on property accessor

Summary: Page 2-30, top of page, end of section 2.7.1: There is a label "Examples:" but no example follows

Summary: 1) ValueDefSeq is used in a couple of places but is never defined. A typedef
for it is missing.

Summary: 5.3.3: Is it possible to have a value inherit from (ie, support) a
boxed value ? If yes, the Java mapping of boxed values of type
string, sequence and arrays should be changed because String
and arrays can"t be extended in Java.

Summary: 2) Attribute "name" in interface ValueMemberDef clashes with attribute "name"
inherited from Contained. A different name should be used, something like
"value_member_name"

Summary: If a value type can inherit from a Boxed Value then what is the implicit name of
the Value Box"s single data member?

Summary: It is not clear whether the #pragma prefix is still part
of the repository Id. I think it should be.

Summary: Clarify the hash code algorithm

Summary: Why is the 64 bit hash code at the end of the string and
not at the beginning ? This can speed up the comparison
when two repository Ids are different.

Summary: 2) How does one find out a RepositoryID for registering a factory or a streaming
policy?

Summary: Section 5.6.3 Hashing Algorithm (and 5.6.2)

• It is not clear whether the hash value is translated
  into ascii or not.

• I assume the result is a long long:

long long hash = sha[1] << 32 + sha[0]

Summary: Clarify the exact semantics of computing the hash code and comparison semantics for type equivlanece. (lost email, paraphrase of issue)

Summary: The default ref-counting classes are said to be "fully concrete".
Is this really necessary?
What is the semantic of "_copy_value" for the ref-counting class?
=> suggest that "_copy_value" MUST NOT be implemented
(It is implemented by "_copy_value" of the real value type)

Summary: I have an important issue concerning the C++ mapping and the fact
that application developers need to define/implement the concrete
value class.

Summary: In the Java mapping example on page 6-64 the operations are mapped to
public operations of the Java class. However in the C++ mapping example on page
7-95, the operations are mapped to protected pure virtual functions of the
generated C++ class.

Summary: What is the rationale for making ValueBase a value and not a native type?
It seems strange to me that a ValueBase "value" maps to java.io.serializable
in Java. Isn"t that what native was invented for?

Summary: A typo: on page 8-107, interface Account should inherit ":" from Describable and
value Currency should support Describable.

Summary: 1) Can the "public" modifier be applied to value operations? What is the default?

Summary: Can the "public" modifier be applied to value operations? What is the default?
In the Java mapping example on page 6-64 the operations are mapped to
public operations of the Java class. However in the C++ mapping example on page
7-95, the operations are mapped to protected pure virtual functions of the generated
C++ class.

Summary: The Minimum CORBA submission describes exactly what should
be present in minimum CORBA (basically CORBA 2.2 including
the POA) in IDL/PIDL.

However, the Java language mapping in CORBA 2.2
does not include the POA -> just the APIs for registering
transient objects.

One cannot even take recourse to CORBA 2.3 to get the
language mapping, since much stuff (OBV, Java to IDL etc.)
was added in the intervening time. There does not seem to be
any existing document which documents a Java language mapping
of CORBA 2.2 including POA without lots of other stuff.

Summary: There are no typecodes for abstract interfaces. Does this mean
that abstract interfaces cannot be members of structs, unions,
or values? If so, I think this is a problem and we should add
typecodes for abstract interfaces.

Summary: The issue comes from the following configuration:

Client - Tcp Firewall - Giop Proxy Server - Server

The server"s IOR will contains a FirewallComponent, which includes two
FirewallMechanisms - a TcpFirewallMechanism and a GIOPProxy. The issue
comes when the GIOP Proxy has multiple profiles, which may have different
host/port, and the TcpFirewallMechanism can only have one host/port. Does
that mean for any host/port specified in one of the GIOP Proxy "s profiles,
you always to connect to the host/port specified in the
TcpFirewallMechanism? This seems unrealistic since the Tcp firewall usually
provide a one-to-one mapping.

Summary: The submission makes no mention of HTTP tunnelling. There are many
firewalls which filter HTTP, FTP and email related traffic. Is the
omission based on the assumption that such firewalls will comprise
a CORBA conformant GIOP proxy on a well-known IIOP port? The Bi-
directional GIOP specification suggests not (section 5-1,
paragraph 2).

Is tunnelling regarded as an implementation matter? If so there
will be important issues such as relaxing GIOP/HTTP mapping and
security which the specification should clarify.

Summary: Section number: 4.2.1

Problem: How can we bound the range of invoke ids in the IDL? Q773 requires
invoke ids in the range -128 to 127. ROS has no limits.

Summary: It should be possible to have negative invoke ids.

Summary: Section number: 4.2.1

Problem: Why is AssociationId a string? Should one explore the possibility of
using a combination of values supplied by both the initator and responder.
Strings do not seem to be the most scalable solution.

Summary: Problem: It is not necessary to have uniqueness of Invoke Ids within a dialog.
The invoke id can be reused as soon as it is no longer active.

Proposed solution: Put in text following the discussion of management of invoke
ids in the TC spec.

Summary: Section number: 4.2.1

Problem: The current text for DialogFlowCtr is for outgoing only. It should be
updated to reflect incoming messages from the legacy domain.

Summary: Section number: 4.3.1.2

Problem: Title and text should be changed to reflect that it is dealing with creating
an association rather than initiating a dialog.

Summary: Section number: 4.2.2

Problem: There is a difference between the responder and initiator interfaces
because the initator cannot support the new association operations.

Summary: Section number: 4.7.1

Problem: Is it necessary to indicate that RelativeRoundTripPolicy is not
propogated to the server? Also does TC interworking require the support of the
priority policies?

Summary: Section number: 5.2 and other sub-sections

Problem: The encapsulation BerData could potentially hold ASN.1 encoded via
other rules like PER. So is this name misleading, or too restrictive?

Proposed solution: One choice is EncodedData.

Summary: Section number: 5.4.1

Problem: DialogPortion should be a union rather than a struct. The complete IDL
is correct.

Summary: Section number: 7.1, page 108

Problem: Shouldn’t it be typedef string CORBA::ScopedName?

Summary: Section number: Fig. 27

Problem: Shouldn’t GwTcPduHandler be replaced by GwTcPduProvider?

Summary: Section number: 5.4.4

Problem: There is no way to send dialogue data in a continue confirm.