What is the RSC when
> using a PersistentPoller? Since it is a valuetype that can be passed
> from one process to another, the RSC obviously can't be the same in the
> other process as at the original invocation point.
>
> Anybody have any bright ideas for this one? Should it be empty? A copy
> of the TSC at the poll point? Change MessageRouting:PersistentRequest
> to have an attribute that provides access to a copy of the RSC, and
> PersistentRequestRouter::create_persistent_request to have the RSC as an
> "in" argument?

Deferred

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

What is the RSC when
> using a PersistentPoller? Since it is a valuetype that can be passed
> from one process to another, the RSC obviously can't be the same in the
> other process as at the original invocation point.
>
> Anybody have any bright ideas for this one? Should it be empty? A copy
> of the TSC at the poll point? Change MessageRouting:PersistentRequest
> to have an attribute that provides access to a copy of the RSC, and
> PersistentRequestRouter::create_persistent_request to have the RSC as an
> "in" argument?

Isit possible to add a ClientInterceptor then create_POA() in the
post_init()
method? It seems that the ClientInterceptor is not called after that. Do
you know the
reason why?

My Investigation:
If the post_init method in SampleClientLoader.C creates the new POA
using create_POA method, the client side PI will not be called. Even if
an ORB-mediated call is made from within post_init(), ServerInterceptor
is called beyond the scope of post_init(). Moreover, even if an
ORB-mediated call is made from within post_init() in VisiBroker for
Java, ClientInterceptor and ServerInterceptor are called beyond the
scope of post_init(). However, in Visibroker for C++, the
ClientInterceptor of VBC is not called. Please see the attachments for
the difference in results of VBC & VBJ. A testcase is also attached.

Any comments will be greatly appreciated.

close no change

The core spec says in section 4.11.3:

Typecode creation operations that take name as an argument shall check that
the name
is a valid IDL name or is a null string.

This is oxymoronic: we are talking about IDL here; IDL does not have the
concept of
a null string. If anything, we can say "empty string".

Looking at this bit of spec, it would appear that a call such as

orb->create_interface_tc(someRepId, 0);

is legal. But that doesn't make sense because it's illegal to pass null
pointers
across IDL interfaces in C++ (or null references as strings in Java).

Fix as suggested

Document: Chapter 24 Corba, CSIv2

There is a misinterpretation in the current JDK implementations as to the
interpretation of the word of "encapsulation" in the CSIv2 specification
in relation to the encoding of the fields within the CSI Identity Token.

The issue is that the JDK and already certified implementations have
performed a CDR encapsulation of the byte arrays within the Identity
Token. This CDR encapsulation is not needed as the the Identity Token is
already a CDR encapsulation, so further CDR encapsulating the byte array
containing the ASN.1 encodings is inefficient.

We can suggest that current implementations do not generate CDR
encapsulation for these fields, yet accept them to be compatible with
misaligned implementations.

Proposed Fix:

Remove the word "encapsulation" before "octet stream" from the rows of the
table 24-2 "Identity Token Types".

Remove the word "encapsulation" in the paragraph in section 24.2.3
"Authorization Token Format".

Remove the word "encapsulated" in the comments in the IDL section for the
definition of the X509CertifcateChain.

Remove the sentence "The two-part SEQUENCE is encapsulated in an octet
stream." in the IDL definition for "const AuthorizationElementType
X509AttributeCertChain".

Add paragraph to section 24.2.5 "Identity Token Formats".

The identity token for ITTPrincipalName, ITTDistinguishedName,
ITTX509CertChain should contain their respective ASN.1 encodings of the
name directly. However, the token may contain a CDR encapsulation of the
octet stream that contains the ASN.1 encoding of the name. The TSS shall
distinguish the difference by the first octet of the field. The values of
0x00 or 0x01 shall indicate that the field contains a CDR encapsulation.
Any other value indicates the field for these identity token types
contains the ASN.1 encoded value. For instance, the ASN.1 encoding for
ITTPrincipalName starts with 0x04, and ITTDistinguishedName and
ITTX509CertChain each start with 0x30. The TSS shall accept both the CDR
encapsulation form and the direct ASN.1 encoding for these identity token
types.

Indeed a severe interoperability problem. Fix as suggested.