Issues for Core Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1139: constant decls broken
Issue 2299: No way to detect that ORB has outstanding deferred synchronous requests
Issue 2431: issue with ForwardRequest exception in POA
Issue 2629: Getting reply svc ctxts from PersistentRequests
Issue 2785: scheme name for IORs
Issue 3076: Implementing proper handling of CloseConnection
Issue 3318: Sending codeset context more than once?
Issue 3322: Portable Interceptors: object_to_string, string_to_object
Issue 3355: Question about routing policies
Issue 3403: PI needs the ORB to be available in IDL
Issue 3429: ORBInitInfo needs the ORB
Issue 3541: How correlate requests and replies when using pollable sets?
Issue 3599: Detail lacking in when request interceptors are called
Issue 3601: Portable Interceptors: 9.2.3 text describing `Arguments'
Issue 3609: Overriding POA policies
Issue 3615: Policy Management in Portable Interceptors
Issue 3672: Portable Interceptors / register_initial_reference()
Issue 3770: RoutingPolicy issue
Issue 3772: ORB accessor on POA?
Issue 3793: no way to register value factory from ORB initializer
Issue 3914: Missing minor codes in Messaging Chapter
Issue 3947: Portable interceptors and invocation timeouts
Issue 3989: No portable way to turn IOR components into object-reference policies
Issue 4008: wchar endianness
Issue 4156: Encodings of Sequences of Certificates are not standard.
Issue 4164: ORB::shutdown vs. ORB::destroy
Issue 4167: Stateful boolean causes all CSI mechanisms to operate the same way.
Issue 4173: Clarify that each interception point executes in a distinct logical thread
Issue 4236: X/Open Codeset registry is obsolete needs to be replaced
Issue 4284: 21.8.1 register_initial_reference
Issue 4290: Problem with CSIv2 and GIOP LocateRequest
Issue 4321: Interpretation of defined ServiceConfigurationSyntax constants is incomplet
Issue 4324: Note on page 15-43, OBJECT_FORWARD_PERM
Issue 4334: Repository ID in nil references
Issue 4337: rep_id() operation on Object?
Issue 4506: TypeCodes for custom marshaled valuetypes
Issue 4536: CORBA components requires new GIOP version?
Issue 4554: Detecting Recursion in Other Interceptors
Issue 4585: CORBA 2.5 and Portable Interceptors mismerged
Issue 4650: Alignment for empty sequence?
Issue 4723: ORBs using BOMs for UTF-16 (closely related to issue 4008)
Issue 4724: GIOP 1.2 encoding of wstring
Issue 4725: Chapters 13.10.1.9, and 13.10.1.12 -- issue
Issue 4796: TypeCode indirections
Issue 4806: Issue with chunking
Issue 4820: Potential problem using BiDir GIOP and codeset conversion service context
Issue 4822: 11.3.2.1 Processing States (end of second paragraph and third paragraph
Issue 4823: conflict between CORBA specification and C++ mapping (_this method
Issue 4824: Wide string in reply before codeset was negotiated
Issue 4825: IPv6 in corbaloc URLs
Issue 4835: interaction of #pragma and typeid, typeprefix
Issue 4846: The whole negotiation thing should be removed, Unicode should be mandated
Issue 4850: Codeset negotiation requires clarification
Issue 4851: IDL inheritance issue
Issue 4852: discussion on the create_union_tc operation could use some clarifications
Issue 4870: definition of the TypeCode interface (4.11.1)
Issue 4899: GIOP version in replies
Issue 4945: IOR processing performance
Issue 4982: Inconsitent exception handling with find_POA & unknown_adapter Generic operations for subscribing/unsubscribing at publishing ports
Issue 5100: Valuetypes supporting forward declared interfaces
Issue 5105: reference_to_servant
Issue 5232: Replace deprecated anonymous type declarations?
Issue 5270: Codeset negotiation and the CODESET_INCOMPATIBLE exception
Issue 5296: Avoiding Interceptors for colocated method requests
Issue 5322: DATA_CONVERSION minor code 2 not listed in Table 4-3
Issue 5327: pragma prefix syntax
Issue 5329: Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent
Issue 5333: OpaqueValue/add_arg never mapped to languages
Issue 5430: Serious backward compatibility issue in the PI
Issue 5448: BAD_INV_ORDER minor code 5 and 10 mean the same thing?
Issue 5449: Wrong minor code listed in POAManager::deactivate
Issue 5587: Inconsistent definition of semantics of RebindPolicy?
Issue 5592: Object::get_client_policy problem
Issue 5614: Sloppy text in CORBA 3.0, 4.3.8.1 get_policy
Issue 5619: Object::validate_connection()
Issue 5620: Who is responsible for generating the TIMEOUT exception
Issue 5622: Is a router allowed to pick any value in the range for a priority?
Issue 5623: determining TimeT or UtcT value
Issue 5626: Messaging time based policy enforcement?
Issue 5641: SyncScope for oneway invocations
Issue 5642: Messaging: bad example code for type specific poller
Issue 5660: Errors in definition of Messaging poller types
Issue 5661: Messaging type-specific poller valuetypes should be abstract
Issue 5663: potential name clash with Messaging type-specific poller timeout argument
Issue 5664: AMI vs abstract & local interfaces name disambiguation for AMI interface & poller names is confusing Messaging Poller generation is broken for interfaces with multiple inherite
Issue 5665: name disambiguation for AMI interface & poller names is confusing Messaging Poller generation is broken for interfaces with multiple inherite
Issue 5666: Messaging Poller generation is broken for interfaces with multiple inherite
Issue 5667: Bad example code in 22.11.4.3
Issue 5668: DII sendc reply delivery underspecified
Issue 5669: Oneway operations should not generate sendc_ and sendp_ variants
Issue 5672: Pollable in more than one PollableSet?
Issue 5673: Why does PollableSet::number_left() return unsigned short?
Issue 5674: Local types allowed as valuetype state?
Issue 5687: Derived component supported interface restriction (formal/2002-06-01)
Issue 5689: Exception handling in Interceptor initialization
Issue 5690: ORBInitInfo::arguments() underspecified
Issue 5691: What ORBInitInfo operations are legal during pre_init() and post_init()?
Issue 5692: What ORBInitInfo operations are legal during pre_init() and post_init()?
Issue 5726: How do Portable Interceptors interact with Messaging callbacks
Issue 5743: CORBA::WrongTransaction and Interceptors
Issue 5764: add a ClientInterceptor then create_POA() in the post_init() method?
Issue 5766: Unfortunate CDR Encapsulation of ASN.1 Encodings
Issue 5771: Type code creation
Issue 6912: Error in Chapter 21 of CORBA 3.0
Issue 7731: Codec Interface Deficiencies
Issue 11027: Section: exceptions

Issue 1139: constant decls broken (corba-rtf)

Summary: When the extended IDL types were added to CORBA, the semantics of IDL
 constant declarations seems to have been broken. In CORBA 2.0 (July
 1995) the third paragraph of section 3.7.2 page 3-18 states:
 
 "An integer constant expression is evaluated as unsigned long unless
 it contains a negated integer literal or the name of an integer
 constant with a negative value. In the latter case, the constant
 expression is evaluated as signed long. The computed value is coerced
 back to the target type in constant initializers. It is an error if
 the computed value exceeds the precision of the target type. It is an
 error if any intermediate value exceeds the range of the evaluated-as
 type (long or unsigned long)."
 
 The paragraph following the one quoted above explains the same for
 floating-point constants.
 
 Unfortunately, CORBA 2.2 has broken this. Section 3.7.2, page 3-20,
 of formal/98-02-01 tells us what to do if types are long, unsigned
 long, long long, unsigned long long, double, and long double, but the
 old text stating how general integer constants and floating point
 constants were evaluated has been completely removed! How should the
 following be evaluated?
 
 const short S = 1 + 2;
 

Resolution: 
1. For integer types evaluate the expression using the imputed type of each argument of a binary operator in turn.  So: 

a.  If either argument is unsigned long long, use unsigned long long. 

b.  If either argument is long long, use long long 

c.  If either argument is unsigned long, use unsigned long. 

d.  Otherwise use long. 

2. Constant integer literals are considered long unless the value is too large, then they are long long.  (Unary minus is considered an operator, not a part of an integer literal). 

3. For floating point types evaluate the expression using the imputed type of each argument of a binary operator in turn. So: 

a.  If either argument is long double, use long double. 

b.  Otherwise, use double 

4.   Constant floating point literals are of the smallest type that holds the number of decimal digits that the literal was specified with (Unary minus is considered an operator, not a part of an integer literal). 

5. Finally, we need a statement that the final result of an arithmetic expression must fit in the range of the declared type of the constant, otherwise it is an error.  Truncation on the right for floating point or fixed point is ok. 

Summary: Issue:  There is currently no way to detect that an ORB has outstanding
 deferred synchronous requests.  In the DII, this was possible via
 the blocking ORB::get_next_response operation.  A mechanism is needed so 
 that applications can (for example) shutdown gracefully
 only after all outstanding deferred synchronous operations have
 returned results.
 

Resolution: 
The ORB shutdown operation should wait for outstanding deferred synchronous "sendc" mode operations to have returned results before completing. If this is not done, sendc invocations invoked with a callback object on another ORB could be "terminated" prematurely during ORB::shutdown, and no response forwarded to the callback. 

One could claim that the paragraph cited from section 4.2.5.4 below says this already, but it is not clear. Clarification of the intent of the paragraph as suggested below fixes this problem

Summary: The ForwardRequest exception in the POA specification doesn"t allow the
 servant manager to specify whether the status of the GIOP reply is
 LOCATION_FORWARD or LOCATION_FORWARD_PERM.  If an application is designed
 to use ForwardRequest exceptions, then it should be able to state whether
 the new object reference is transient or permanent.  
 
 

Resolution: A quick read of the Fault Tolerance Chapter in 3.0, see: http://cgi.omg.org/docs/formal/02-06-59.pdf , I get the sense that a LOCATION_FORWARD_PERM never comes all the way upto a POA. So a ServantManager has no occasion to have to deal with it. Hence this issue can be closed no change

Summary: It does not appear that reply service contexts are maintained when retrieving
 polled requests from a Router.  Although the Router interfaces properly
 propogate the service contexts to the the untyped reply handler representing the
 PersistentRequest, there is no way for the client to retrieve these contexts
 from the PersistentRequest::get_reply.  This may make it impossible for the
 client to interpret the reply data (e.g. if the reply contained CodeSet
 contexts).
 

Resolution: This is indeed an outage. Add a new operation to PersistentRequest called get_reply_with_context, which is exactly like get_reply in every way except that it has an additional parameter for returning the service context associated with the reply. Since this is just an addition of an operation to an existing interface, there is no need to give a new RepId to it, as an attempt to invoke this operation on a legacy version of the interface is handled adequately by a system exception

Summary: The syntax for stringified IORs in section 13.6.6 shows:
 
 	<prefix> = "IOR:"
 
 The problem is that URL scheme names are supposed to be case insensitive.
 So, "Ior:" or "ioR:" should be allowed to.
 
 I would suggest to add a footnote to state that case for the scheme name 
 is ignored.
 

The CORBA 2.3 spec says in chapter 15.7.1:

"After receiving a CloseConnection message, an ORB must close the TCP/IP
connection. After sending a CloseConnection, an ORB may close the TCP/IP
connection immediately, or may delay closing the connection until it
receives an
indication that the other side has closed the connection. For maximum
interoperability with ORBs using TCP implementations which do not
properly implement orderly shutdown, an ORB may wish to only shutdown
the sending side of the connection, and then read any incoming data
until it receives an indication that the other side has also shutdown,
at which point the TCP connection can be closed completely."

Most (or all?) Unix TCP/IP implementations suffer from the problem
described above, i.e., with most Unix TCP/IP implementations the last
message sent is discarded if the connection is closed. The workaround,
to shut down the sending side only, and then to read data until EOF is
received, works fine for C++ ORBs.

However, there is no equivalent to shutdown() in Java, so I don't see
any way to reliably transmit the CloseConnection message from a Java ORB
running on Unix.

Questions:

- Is there perhaps some other way to reliably transmit the last message
before closing the connection, using Java running on Unix?

- If not, doesn't this mean that IIOP's connection closure strategy is
unimplementable in Java under most Unixes?

Resolution: As per the issue filers later note, the particular mis-feature of JDK has been fixed in 
JDK 1.3. There does not appear to be a pressing reason to complicate the standard in order to 
deal with the corner cases which use TCP implementations which do not properly implement 
orderly shutdown. So close this issue no change.

Question: Is it legal to send the same codeset context more than once
	  on the same connection?

The spec says:
 
        Codeset negotiation is not performed on a per-request basis,
        but only when a client initially connects to a server.

These words suggest that the codeset must be sent on the first request,
but don't say whether it's OK to send it more than once.

I would like to have clarification, and also a loose interpretation. Here
is why:

	A multithreaded client starts talking to a new object from
	multiple threads more or less simultaneously. If the codeset
	info must be sent only on the first request and is illegal on
	subsequent requests, we end up with rather complex locking
	logic in the connection management layer of the ORB. In effect,
	each request is no longer a stand-alone and context-free thing;
	instead, how to send a specific request now depends on what
	other threads may have done in the past.

	That's not very nice (even though it can be implemented) because
	it needlessly complicates things.

So, I would like to change things such that it is legal to send the
codeset context even if it was sent previously on the same connection.
When that happens, the server should simply and silently ignore all
but the first context (even if the subsequent contexts have different
codeset information from earlier ones). That way, requests remain
context-free. [ Yet again, we see a sterling demonstration that attaching
semantics to the duration of a connection was a very bad idea, especially
in a model that is connectionless :-( ]

Further, it seems pointless to send codeset info at all unless the client
actually uses an operation that involves a wchar or wstring parameter.
So, I think it would make sense to relax things such that the codeset
need not be sent until the first request is made that requires sending it.

Resolution: After much email discussion there appears to be a consensus that has evolved that it is OK to send additional codeset service context, but if subsequent codeset service contexts on a link contain something different from the one contained in the first one then the behavior is undefined

 object_to_string and string_to_object are missing on ORBInitInfo.

Resolution: Adding an ORB accessor to the Object interface as proposed in the resolution for Issue 3772 together with making that operation return the relevant ORB for local objects of relevance automatically provides access to these operations from ORBInitInfo. So resolve this issue in conjunction with the resoltuion for issue 3772. 

How are the routing policies e.g.ImmediateSuspend, LimitedPing, UnlimitedPing,
etc. created. It is not clear that these can be created using the standard
create_policy operation since these policies are valuetypes that support the
CORBA::Policy interface.

Also what are the Policy Type tag values for these policies?

Resolution: The Policy Type tags have been fixed for this earlier. The fact that CORBA::Policy interfaces are supported by the policy valuetypes is probably because someday someone might want to integrate this into the general policy management architecture, and this by itself causes no harm. The fact there there are no factories specified for these is OK because the only place where these need to be created are within an ORB, and can hence be done using internal mechanisms and interfaces that need not be standardized. So close this issue no change

Portable interceptor implementations need access to the ORB.  In order to
accomplish this, the ORB must be defined in IDL  There are four
possibilities that have been opined:

1.  Define the ORB as "native ORB;"

This puts the ORB into the IDL namespace.  However, the ORB is still
described in PIDL.  This doesn't really help us to remove PIDL, some folks
feel this is a misuse of native, but it would be sufficient for the
requirements of PI.

2.  Define an IDL wrapper for the ORB, call it proxyORB for now.

proxyORB would contain exactly the same items that the PIDL ORB does, only
defined in pure IDL.  Advantages:  this is a migration step toward getting
rid of ORB PIDL if we encourage folks to use proxyORB rather than ORB.
Disadvantages:  dual maintenance; lots of work - too much for this FTF?; I
don't think we know all the ramifications; where do you get a proxyORB?
from the ORB?

3.  Make the leap and redefine ORB in IDL now.

This option is similar to option 2, but the IDL is not a wrapper, it's the
real ORB.  Advantages:  no dual maintenance; we get rid of ORB PIDL right
now.  Disadvantages:  BIG step - too big for this FTF?; lots of work; I
don't think we know all the ramifications.

4.  Make the ORB a primitive type like TypeCode.

This seems to be generally undesired.  It requires all compilers to change.
Unless someone really likes this approach, I don't think we should even
consider it.

Resolution: Adding an accessor to the ORB in the Object interface together with having that accessor return the relevant ORB for relevant local objects  provides the least obtrusive way of providing this facility. This is proposed as resolution for issue 3772. So this issue is simultaneously resolved with issue 3772. While the resolution for 3772 explicitly excludes Interceptor and its derived interfaces from the local interface in which get_ORB returns the ORB, any likely point where the Interceptor is available to call get_ORB(), an ORB provided local object (such as IORInfo, ClientRequestInfo, etc) is also available to call get_ORB() on.

Portable interceptor implementations need access to the ORB.  The presumed
place to put the ORB would be on ORBInitInfo since at least one
implementation needs the ORB at initialization time.  Is that sufficient?
Or is it also needed in RequestInfo and IORInfo?  My guess is that having
ORB only on ORBInitInfo is sufficient.  All interceptors begin here.  If
the ORB is needed at other points, the implementations can assure that it
is available where it's needed.

Since ORB is PIDL and we don't want to pollute the interceptor interfaces
with PIDL, we have to create IDL access to the ORB, but that's another
issue.

When using the pollable sets, pollers are registered with 
PollableSet::add_pollable() and retrieved using 
PollableSet::get_ready_pollable(). As pollers are valuetypes they are passed by 
copy, thus portable applications must assume that get_ready_pollable() returns 
a different poller instance than the one passed to add_pollable(). Thus, with 
non-TII, currently there is no portable way to find out how requests 
(represented by the pollers returned from sendp) and replies (represented by 
the pollers returned from get_ready_pollable ) correlate.

Consider the following IDL:

    module Stock
    {
        interface Quoter { long get_quote(in string stock_name); }
    };

and a client that does a 1000 invocations in the style

    poller = quoter->sendp_get_quote(portfolio[i].stock_name);
    poll_set->add_pollable(poller); 

Now, the client could retrieve the 1000 replies in the order:

    while(poll_set->number_left() > 0)
    {
        pollable = poll_set->get_ready_pollable(timeout);
        ...
    };
  
But how can the client find out which returned quote belongs to which 
stock_name? 



Possible resolutions:
---------------------
(a) Reconsider the introduction of a correlation id on pollers which can be 
used to compare if two pollers are referring to the same request/reply. 

(b) Based on the fact that pollable set is locality-constrained and that 
valuetypes support sharing semantics (see CORBA 2.3, 5.2.4.2 Sharing 
Semantics), it could be required that PollableSet::get_ready_pollable() returns 
a pointer to the same valuetype instance as the one passed as argument of 
PollableSet::add_pollable().

(c) Close without action, i.e. has to be solved at the application level, e.g. 
in our example the application would have to solve this by changing get_quote to

    long get_quote(in string stock_name, out string stock_name);


Discussion:
-----------
(c) contradicts with the CORBA Messaging Philosophy that AMI is a mere 
client-side issue and that in principle any existing target can be called 
asynchronously.

(b) means that we would have two different polling-related correlation 
mechanisms:
- one for correlating requests and replies in different processes based on the 
PersistentRequest objref
- one for correlating requests and replies in the same process based on poller 
pointers 

(a) means that a generic correlation mechanism is defined that covers both: 
intra- and inter-process correlation. This was variant (a) of issue 2803 in the 
latest vote. It failed with 5 NO : 4 YES : 3 ABSTAIN.

I could work out two straw men for (a) and (b) for the next vote, or much 
better, we could try to discuss this before the next vote and just work out a 
straw man for the variant that has better acceptance.

Resolution: This issue is obsolete, since PollableSet is now a local object, and valuetype arguments are not copied when passed to local objects.  So the exact same valuetype instance registered with add_pollable() will be returned by get_ready_pollable(). So close no change with this explanation 

I set out reading ptc/2000-04-05 to answer a question: how could a
client interceptor for the OTS implement the proper behavior for the DII
get_response or get_next_response operations that require the
WrongTransaction to be raised if the current thread is not properly
associated with the same transaction as the request.

I wasn't able to answer this question authoritatively, because there is
nothing in the Portable Interceptors Chapter that indicates the proper
time sequencing of when the client side request interceptor operations
are invoked in relation to the use of the DII (or the AMI_ messaging
interfaces either.)

By inference, it appears to me that the only way to allow an OTS client
request interceptor to exhibit the proper semantics is for the ORB to
not make calls to receive_{reply,exception,other} when the response is
received from the protocol stack, but instead to make them when
get_response or get_next_response is called by the application.

This paragraph in 21.3.7.2:

"Asynchronous requests are simply two separate requests. The first
request receives no reply. The second receives a normal reply. So the
normal (no exceptions) flow is: first request - send_request followed by
receive_other; second request - send_request followed by receive_reply."

is also not particularly useful, since it doesn't give any indication
how the interceptor can distinguish the "first request" from the "second
request".

So, to sum up, the PI chapter needs explicit information showing the
time sequencing of when the request interceptor operations are invoked
in relationship to a static call, a DII call, and AMI_ calls.

Resolution: Clarify as suggested in the archive. Also fix 5743 with this 

The basic fix for this issue consisting of items 1 through 5 below fixes item 2 of 5743 since the interceptor can now check inside the send_poll interception point that the RSC transaction context is compatible with the TSC transaction context. 

Items 6 through 9 fixes item 1 of issue 5743. 

The text in section 9.2.3 / page 9-71 describing the
arguments attribute to ORBInitInfo could use some
more precise wording. It reads:

"This attribute contains the arguments passed to ORB_init.
 They may or may not contain the ORB's arguments."

I take this to mean that any ORB_init arguments that 
applied to the ORB instance being created may not be 
present. All other strings passed to ORB_init will be 
present so initialisation strings can be passed to 
the interceptors through ORB_init.

With the current text it is possible to think that 
you may not get *any* of the arguments to ORB_init.

Resolution: Issue 5690 addresses this in a more specific focused way. So close this issue and merge its discussion into 5690. 

it appears to be impossible to portably attach OTS policies
to POAs with the machinery that is currently in place. We need a fix for
that, otherwise OTS ends up getting hamstrung...

Resolution: No problem in doing that. A policy is created which is handed in the PolicyList tocreate_POA. When the IORInterceptor is called get_server_policy (or whatever the API call is) retrieves the policy, if present, and establish_component is called with the REQUIRES_SHARED component. 

Now, a couple of anciliary things need to be fixed: 

1. Remove the requirement for the registration of policy factory in section 21.5.5.1 "get_effective_policy". 

2. Clarify in an appropriate place that the source of server side policies that get placed in a IOR is the POA that the IOR is created from. 

Both of these have already been taken care of by resolution of other issues and the current text in section 21.5.5.1 already fixes these concerns. So close this issue no change

(All document refs to ptc/00-04-05)

Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in
the IOR".  Policies get translated to IOR components, but AFAIK there's no
general way that a component can be unscrambled to give a Policy.  This
suggests that we need another interception point, effectively the inverse of
the existing IORInterceptor (sec. 21.5), that allows an IOR component to be
converted into a Policy on the client side.

I suggest something like:

  local interface ReceiveIORInterceptor : Interceptor {
    void establish_policies (in ReceiveIORInfo info);
  };

  local interface ReceiveIORInfo {
    CORBA::Policy set_policy (in CORBA::Policy policy);
    IOP::TaggedComponent get_ior_component ();
    IOP::TaggedComponent get_ior_component_from_profile (
      in IOP::ProfileId profile_id);
  };

and an extra operation add_receive_ior_interceptor in ORBInitInfo.

ReceiveIORInterceptor::establish_policies provides the opportunity for an
interceptor to turn IOR components back into Policies, using the
interceptor's Policy Factories directly or indirectly via
ORB::create_policy.

The ORB will call this method on all registered ReceiveIORInterceptor
objects during or before the first call of Object::get_policy (we needn't be
more specific - this would allow eager calls on unmarshalling or lazy calls
within Object::get_policy).

Issue 4065 covers this issue in greater generality. Merge this issue into 4065 and close this issue

I am in the process of implementing Portable Interceptors within a C++
ORB,
and I would like to raise an issue for resolution regarding the semantics
of the
"register_initial_reference()" function, particularly with respect to the
memory
management of  the object being registered.

The interface for this function is as follows:

    void register_initial_reference (
      ObjectId id,
      Object_ptr obj
   );

Within the Portable Interceptors specification, there is really no
information about
how the memory for the object should be managed.   For example, does the
caller of
"register_initial_reference()" pass ownership of the object to the ORB, or
not?
Also, does the caller of "resolve_initial_references()" gain ownership of
the object
which is returned, or not?


Here is my proposed resolution:

The fact that the "obj" parameter is a CORBA::Object implies that it is a
reference-counted
object.   Therefore, it would make sense that when
"register_initial_reference()" is called, the
ORB performs a "_duplicate()" on the object to increment its reference
count (the ORB would
then hold its own reference count).   The caller of
"register_initial_reference()" can decide
whether to call "release()" or retain its own reference count.

Later, when "resolve_initial_references()" is called, the ORB would call
"_duplicate()" on the
object prior to returning it to the caller, thereby giving the caller its
own reference count.
The caller would then need to call "release()" when it is finished with
the object.

When the ORB is deleted, it must clean up the lookup table of registered
objects.   To do this,
it simply calls "release()" on each one, and if no one else holds a
reference count, then
the object is simply deleted.

I would like the hear other people's thoughts on this, particularly those
who have done or are
working on a C++ implementation of PI.

Resolution: No need to say anything regarding this in the Core spec. As for language mapping specs 
traditionally, when no special mapping is provided for something in a PIDL it is assumed that it uses 
the general language mapping. So most likely nothing needs to be said there either. So close no change.

This problem comes from the fact that RoutingPolicy is actually a range: min and max. Basically, Messaging defines this range of Routing QoS: 

ROUTE_NONE(0) ---> ROUTE_FORWARD(1) ---> ROUTE_STORE_AND_FORWARD(2) 

You can set your min and max to any of the values, with the caveat that min must be <= max. The issue that concerns us is when the min is ROUTE_NONE(0) and the max is either ROUTE_FORWARD(1) or ROUTE_STORE_AND_FORWARD(2). 

If you look at the Messaging spec (orbos/98-05-06) in section 5.3.5.3, it says: 

"If, for example, the min is ROUTE_NONE and the max is ROUTE_FORWARD, the Routing protocol will normally be used but a direct connection may be used if available." 

Of course, we've left in "usually" just to make sure we could screw up OTS for you :) 

Reading the text in section 3.3 makes me believe that an issue should really be raised in the Messaging-RTF to clarify this. Here's what I BELIEVE the results would be for all of the combinations. 

min maxresultconfidence ----------- ---------- -------------------- ROUTE_NONEROUTE_NONEDirect Call100% ROUTE_NONEROUTE_FORWARDTII if possible50% direct if not ROUTE_NONEROUTE_STORE_AND_FORWARDTII if possible50% direct if not ROUTE_FORWARDROUTE_FORWARDTII Only100% ROUTE_FORWARDROUTE_STORE_AND_FORWARDTII Only100% ROUTE_STORE_AND_FORWARDROUTE_STORE_AND_FORWARDTII Only100% 

Obviously, the problem is with cases #2 and #3. 

How should an ORB determine which to use: what priority is given to each of the RoutingType values?

Resolution: It is not clear that the exact algorithm needs to be specified in the standard, and it appears to be the case that it was left intentionally open. Absent a strong reason for specifying more details in this area, close this issue no change. 

looking at the POA IDL, I get the impression that it was written at a time
where the use of multiple ORBs in a process wasn't anticipated. With
the advent of messaging, OTS, QoS policies, etc, it is more and more common
for one application to use several ORBs simultaneously.

When writing code, it becomes an endless pain dealing with multiple ORBs.
That's because I have to endlessly pass the ORB around in my program, just
so I can do things like call object_to_string() or string_to_object(), etc.

I think it would be really useful to have an ORB() accessor on the POA
interface:

	interface POA {
		CORBA::ORB ORB();
		// ...
	};

The accessor would return the ORB for this POA. Doing this would eliminate
most of the cases in my code where I have to pass the ORB around. For
example, in a servant, I can call _default_POA(), and then call ORB() to
get at the ORB.

Adding the operation would cause any compatibility problems, I believe.

Opinions?

Resolution: Access to ORB is to be provided by adding an ORB accessor operation to the Object interface. This has the virtue of keeping the PIDL-ness of the ORB contained by the PIDL-ness of the Object interface, and yet allows straightforward way of providing access to the ORB from any object local or otherwise. 

Since both PI and POA are local interfaces, this automatically provides a means of accessing the ORB from these, and consequently also provides a means for getting access to all ORB operations from these local objects and hence addresses the concerns raised in issues 3403, 3793 and 3322. So all these issues should be resolved in a single block and closed simultaneously with this issue. 

This resolution will require the definition f language mapping of the new extended Object interface. The resolution of this issue shall be conditional upon the availability of at least one language mapping for the extended Object interface. 

There is currently no way to register a value factory from an ORB
  initializer.

Resolution: Adding an accessor to the ORB in the Object interface together with having that accessor return the relevant ORB for relevant local objects like the ORB initializer provides the least obtrusive way to give access to the value factory regstration facility of the ORB. This is proposed as resolution for issue 3772. So this issue is simultaneously resolved with issue 3772. Care must be taken in the resolution of 3773 to define precisely which ones of the ORB's operations will be available from the ORB initializer. The rest will return the NO_IMPLEMENT exception.

Minor codes specifications are missing in all the places where the
specifications states that a system exception is to be raised. The minor
codes need to be specifiedto complete the specification of exceptional
beahivior.

Resolution: In formal/02-06-01 there are the following occurences of rasing of a standard system exception that do not mention any minor code: 
1. Section 22.9  OBJECT_NOT_EXIST 
2. Section 22.10.1.1 TIMEOUT and NO_RESPONSE 
3. Section 22-10.1.2 TIMEOUT and NO_RESPONSE 
4. Near the top of page 22-31 TIMEOUT and NO_RESPONSE 
5. Near bottom page 22-30 OBJECT_NOT_EXIST 
6. 22.14.2.9 OBJECT_NOT_EXIST 
7. Page 22-60 TRANSACTION_ROLLEDBACK (twice) 
8. Page 22-62 
9. Section 22.9 BAD_INV_ORDER 

The following are the description of conditions that these exceptions represent: 

1. The is_ready operation of the Poller object is invoked after the reply has already been picked up from the Poller. 

This needs a new minor code. 

2. TIMEOUT when the reply is not available in the Poller by the timeout set for it. 
    NO_RESPONSE reply is not available immediately in a non-blocking call 

These need new minor code, and same ones apply for items 3 and 4. 

3. TIMEOUT and NO_RESPONSE same as for 2 above but applies to the read/write attributes of Poller. 2 refers to operations of the Poller. 

Same minor code as for item 2. 

4. TIMEOUT and NO_RESPONSE same as for 2 above but applies to the read only attributes of Poller. 

Same minor code as for item 2. 

5. The same as 1. 

6. The same as 1. 

7.The Router raise TRANSACTION_ROLLEDBACK to reflect that a deferred transaction was rolled back. 

New minor code. 

8. ReplyHandler raises TRANSACTION_ROLLEDBACK when it wishes to rollback the Router's transaction. 

Don't need a new minor code. the ReplyHandler is implemented by the user, so it should be allowed to provide its own unique minor code. 

9. is_from_poller raises BAD_INV_ORDER if the Poller has not returned any response yet. 

New minor code. 

I'd like to raise an issue and garner feedback on the interaction of the
Messaging timeout QoS policies (or indeed any proprietary invocation
timeout mechanism) and portable interceptors. 

Where a bound is being imposed on request and/or reply delivery, and
portable interceptors are present in the client- and/or server-side
binding, these interceptors surely must be made aware of the relevant
timeout(s) so that they may bound any potentially blocking activities
they engage in. Assuming that it would be unacceptable to dictate that
potentially blocking activity (such as making a subsidiary invocation)
may not be undertaken in interception point operations, it appears some
addition to the PortableInterceptor::RequestInfo interface is required
to facilitate the Messaging timeout policies at least. For instance, the
absolute request and reply expiry times could be passed as additional
attributes:

  module PortableInterceptor
  {
    interface RequestInfo 
    {
      // ...
      readonly attribute TimeBase::UtcT request_end_time;
      readonly attribute TimeBase::UtcT reply_end_time;
    };
  };

the former bounding the send_request, send_poll,
receive_request_service_contexts and receive_request interception points
and the latter bounding the send_reply, send_exception, send_other,
receive_reply, receive_exception and receive_other interception points.
Of course this all relies on the discipline of the portable interceptor
implementor, i.e. that they do not ignore the constraints imposed by the
timeouts.

Resolution: a PI implementation can just use ClientRequestInfo::get_request_policy on the client side or RequestInfo::get_request_service_context on the server side to query the timeout policy values directly if it needs to. Close no change 

  For instance, OTS has a policy called OTSPolicy. This policy is
  encoded in an IOR component with component id TAG_OTS_POLICY. This
  policy governs how transactions are handled when invocations are made
  on the object reference.

  Problem:

  As an end user I would like to be able to interrogate the value of this
  policy. I would expect to be able to call CORBA::Object::_get_policy
  with the OTS PolicyType identifier to retrieve the OTSPolicy and
  subsequently determine the value. However, at present there is no
  portable way to turn this IOR component into a policy.

In a similar vein to Vishy's question about alignment, what should the
endianness of a word-oriented wchar be?  This applies both to single
wchars, and the separate code points in a wstring. With the 2.3 spec,
it seemed quite obvious to me that word-oriented wide characters
should have the same endianness as the rest of the stream. After all,
they are no different from any other word-oriented type.

However, with the new 2.4 spec, there is now a bizarre section saying
that if, and only if, the TCS-W is UTF-16, all wchar values are
marshalled big-endian unless there is a byte-order-mark telling you
otherwise. I don't understand the point of this. Section 2.7 of the
Unicode Standard, version 3.0 says [emphasis mine]:

  "Data streams that begin with U+FEFF byte order mark are likely to
   contain Unicode values. It is recommended that applications sending
   or receiving _untyped_ data streams of coded characters use this
   signature. _If other signaling methods are used, signatures should
   not be employed._"

It seems quite clear to me that a GIOP stream is a _typed_ data stream
which uses its own signalling methods. The Unicode standard therefore
says that a BOM should _not_ be used.

I guess it's too late to clean up the UTF-16 encoding, but what about
other word-oriented code sets?  What if the end-points have negotiated
the use of UCS-4?  Should that be big-endian unless there's a BOM?
The spec doesn't say. Even worse, what if the negotiated encoding is
something like Big5?  That doesn't _have_ byte order marks. Big5
doesn't have a one-to-one Unicode mapping, so it's not sensible to
always translate to UTF-16.

GIOP already has a perfectly good mechanism for sorting out this kind
of issue. Please can wchar be considered on equal footing with all
other types, and use the stream's endianness?

resolved in previous RTF (issue 3405b). Resolution: 
UCS-2 and UCS-4 are native codesets, and in newer Unicode Forum versions of the standard, 
they are not intended for transfer syntaxes. 
For backward Compatibility with Java ORB, UCS-2 and UCS-2 will be treated like Integer, 
i.e., marshaling shall use the endianness of the message. 

For giop 1.4 onward, we should have the same interpretation for UCS-2 as with UTF.

Explicit ASN.1 definitions of a sequence of certificates make a single
ASN.1 object out of the certificates. This approach is not what most
systems use today. 

Discussion:

The CSI::ITTX509CertChain and the CSI::X509AttributeCertChain both
stipulate that the encodings of these "chains" be a single ASN.1 encoded
object. Sequences of certificates usually come in the form of a byte
stream of either ASN.1 DER encoded objects, or PEM encoded objects, (i.e.
Base64 encodings wrapped with "----BEGIN CERTIFICATE----", "----END
CERTIFICATE---" lines). It would be ideal to be able to handle both of
kinds these sequences, since many toolkits work this way already.

Tool kits that are provided in OpenSSL and Java, namely,
java.security.cert.CertificateFactory will not be able to handle the
encoding brought forth by the CSIv2 specification. However, the toolkits
will be able to handle a stream sequence of ASN.1 or even PEM encoded
objects, i.e. without the ASN.1 SEQUENCE wrapper.

Proposed Solution:

Eliminate the ASN.1 definitions in the specification, namely para 50 that
defines ASN.1 syntax for a certificate chain (i.e. "CertificateChain"),
and para 33 thru 34 for the corresponding one that fits the
AttributeCertificate(i.e. AttributeCertChain and VerifyingChain).

Furthermore, I believe, that the definition of CSI:ITTX509CertChain be
eliminated in favor of a single OID that forms a GSS_NT_ExportedName type,
in which it's name component is simply a non-empty sequence of
certificates (in any form), as well as creating an OID that stipulates a
supported name type is a DN, ASN.1 encoded or string form.

A stream of certificates is the lowest common denominator as it is
the inside of an ASN.1 encoded SEQUENCE OF Certificate. Furthermore,
many Certificate and Security toolkits currently handle this encoding,
or can easily be made to handle this encoding by reading one certificate
at a time from the stream. This reason gives the standard a greater viability
for implementation, and also contributes to code reduction by not having
to handle the special case and an ASN.1 SEQUENCE HEADER. Furthermore,
it cuts down on the size of the identity token, as all of the
ASN.1 SEQUENCE header contains redudant information.

The CORBA 2.3 spec says under ORB shutdown:

    Once an ORB has shutdown, only object reference management
    operations(duplicate, release and is_nil) may be invoked on the ORB or
    any object reference obtained from it. An application may also invoke
    the destroy operation on the ORB itself.  Invoking any other operation
    will raise the BAD_INV_ORDER system exception with the OMG minor code 4.

  This implies that calling ORB::shutdown also terminates the client
  side processing. I think that this wrong. I believe that ORB::shutdown
  should terminate server side processing. ORB::destroy should terminate
  the client side processing.

Resolution: 
If you need to shutdown the server side processing without stopping client side processing, all you have to do is destroy the root POA.  Then you can shutdown the client side later by calling ORB::shutdown. 

The modifications to CORBA needed to fix the problem of dealing with third party frameworks is too severe for an RTF to handle. Close no change. 

The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI
mechanisms to behave the same way with respect to state retention. This is
problematic and makes mechanisms parametric on the POA they are
supporting.  The retention of state is actually a function of an
established transport, not a POA.

Discussion:

In the architecture (OMA) POA's are the 'owners' of object references.
Therefore, the state retention boolean must be set there, as there is only
one CompundSecMecList per object reference.

You may have cases where multiple CSI mechanisms must support one POA.

These mechanisms may span POA's as they may be defaults for many POA's. If
state retention is parameterized on the particular mechanism, then
negotiating the state retention for each mechanism becomes easier to
handle, as the state retention algorithm is mechanism specific. Therefore,
that mechanism may operate independently of knowing the POA. 

This makes the TSS mechanisms to be able to work independently of the POA
policy.

Also, for another reason, CSI state retention is based on the established
transport, which has nothing to do with a POA, therefore it is part of the
CSI mechanism over which the transport it is working.

I think the purpose for the "stateful" boolean was ill conceived. It was
thought of by some as a deficiency in your implementation and you needed
to provide a single boolean so one could RED FLAG a security service
"inferior" in some sense.

The fact is that state retention can be inefficient in some cases. State
retention is actually parameter that is a function of the mechanism over a
particular transport mechanism. One may want to use mechanisms that retain
their state where one makes lots of invocations over a single transport
(long live connections). (State retention is a function of transport).
Short lived connections need not incur the overhead. 

Proposed Solution:

Move the stateful field, as follows:

module CSIIOP {
    // type used in the body of a TAG_CSI_SEC_MECH_LIST component to describe a
    // compound mechanism

    struct CompoundSecMech {
        AssociationOptions           target_requires;
        IOP::TaggedComponent         transport_mech;
        AS_ContextSec                as_context_mech;
        SAS_ContextSec               sas_context_mech;
        boolean                      stateful;
    };

    // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST component

    struct CompoundSecMechList {
        sequence <CompoundSecMech> mechanism_list;
    };

};

For the reasons brought forth in this issue, this resolution moves the
"stateful" field into the  CompoundSecMech structure. It also takes care of an 
"anonymous" sequence contained in the CompoundSecMechList structure.
The proposed change is backward incompatible and contrary to the intent of the original submission.

To me the key word is "EACH" - in other words values set via
PICurrent.set_slot in send_request are visible to other interceptors in
that point and go into the RSC of client interceptors serving any
requests made from within the interceptor(s).  However, the TSC for
receive_reply (etc) would have a clean PICurrent since it runs in its
own logical thread.

We should clarify this.

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.

Resolution: The enum values from the IANA character set registry (http://www.iana.org/assignments/character-sets) are all of a lower value than the OSF codeset registry values (ftp://ftp.opengroup.org/pub/code_set_registry/cs_registry1.2h) 
The OSF registry is closed, the IANA character set registry is open. They have non-overlapping integer codepoint ranges. 

We need to allow the use of IANA codepoints along with the OSF codesets.  This will allow use of UTF16BE and UTF16LE, as well as future codesets which cannot be added to the closed OSF registry. 

Both should be available for use with GIOP 1.x codeset negotiation. where <x> is minor version of GIOP which includes this change> 

Allowing both eliminates the need to map from the IANA codepoints to the OSF codepoints. New orbs can post both IANA values and OSF values in their IORs, or they can post only IANA values, relying on the default TCS if negotiation fails. 

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.

Resolution: Allow replacement of object reference associated with OMG specified default names. There appears to be no reason to disallow substitution of any object reference for any registered name, OMG specified standard names or otherwise.

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.

Resolution: From the archive the bottom line concern appears to be that rejecting LocateRequests is bad, since that breaks clients that use 
the RebindPolicy and validate_connection().  If a client does that, it must use a LocateRequest in order to validate the connection, and if the server rejects LocateRequests, the client can't communicate. 

A feasible fix to this problem is to have the spec say that if the target requires client authentication, and the transport does not provide that authentication, then the target should always respond with OBJECT_HERE to LocateRequest messages and defer the real forwarding response until it receives a GIOP Request message. 

This will annoy the client, since it will have to explicitly rebind the connection, but clients have to be coded to do that anyway. 

This change is a compatible one and pretty much silently improves the usability of the standard. Server sides that are yet to incorporate this change will simply fail to communicate with some clients under the circumstances described in the archive. Servers with the fix will succeed in those cases. 

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.

Resolution: The changes proposed here was vetoed in the FTF. There is no reason to believe that this change would be any more acceptable now that there is a large deployed base of CSIv2. Perhaps can be fixed in some later major version of CSI if absolutely essential. So 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.

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.

Resolution: The offending sentence has already been removed from CORBA 3.0. 
In this section the term type  ID seems to be tied to the IDL field name type_id, as evidenced 
by the sentence which says "The type ID is a Repository ID.........", so it may not be appropriate 
to substitute Repository ID for all occurences of type ID in this section. So we will leave that alone 
and close this issue no change. 

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 {
		// ...
		string rep_id();
	};

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?