Issues for Core Revision Task Force

To comment on any of these issues, send email to corba-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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 (corba-rtf)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Revision
Severity:
Summary:

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: see above
Revised Text: In formal/02-06-01 section 3.10.2 make the following changes: 1. In section 3.10.2 insert the following paragraph immediately following the first paragraph: "Octet literals have integer value in the range 0..255. If the right hand side of an octet constant declaration is outside this range it shall be flagged as a compile time error." 2. Insert the following sentence immediately following the first sentence of the current second paragraph of section 3.10.2: "Constant integer literals are considered unsigned long unless the value is too large, then they are considered unsigned long long. Unary minus is considered an operator, not a part of an integer literal." 3. Append the following phrase to the current second sentence of the second paragraph of section 3.10.2: "constants, and octet constants" 4. In the paragraph in section 3.10.2 that begins with: "Floating point literals have floating point values." Insert the following immediately following the second sentence of this paragraph: "Constant floating point literals are considered double unless the value is too large, then they are considered long double." 5. In the same paragraph as item 4, append the following sentence to the paragraph: "Truncation on the right for floating point types is OK." 6. In the paragraph immediately following the one referred to in items 4 and 5, append the following sentence: "Truncation on the right for fixed point types is OK." 7. Replace the 5 paragraphs that immediately follows the paragraph referred to in item 6 above, with: "An infix operator can combine two integer types, floating point types or fixed point types, but not mixtures of these. Infix operators are applicable only to integer, floating point and fixed point types. Integer expressions are evaluated using the imputed type of each argument of a binary operator in turn. If either argument is unsigned long long, use unsigned long long. If either argument is long long, use long long. If either argument is unsigned long., use unsigned long. Otherwise use long. The final result of an integer arithmetic expression must fit in the range of the declared type of the constant, otherwise an error shall be flagged by the compiler. In addition to the integer types, the final result of an integer arithmetic expression can be assigned to an octet constant, subject to it fitting in the range for octet type. Floating point expressions are evaluated using the imputed type of each argument of a binary operator in turn. If either argument is long double, use long double. Otherwise use double. The final result of a floating point arithmetic expression must fit in the range of the declared type of the constant, otherwise an error shall be flagged by the compiler." 8. Remove the paragraphs and examples that read as follows: "An octet constant can be defined using an integer literal or an integer constant expression, for example: const octet O1 = 0x1; const long L = 3; const octet O2 = 5 + L; Values for an octet constant outside the range 0 - 255 shall cause a compile-time error."
Actions taken:
April 15, 1998: received issue
April 28, 2003: closed issue

Discussion:

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.

Issue 2299: No way to detect that ORB has outstanding deferred synchronous requests (corba-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: In formal/02-06-01 make the following change: Replace the paragraph in section 4.2.5.4 shutdown in CORBA 3.0.1 spec "Shut down is complete when all ORB processing (including request processing and object deactivation or other operations associated with object adapters) has completed and the object adapters have been destroyed. In the case of the POA, this means that all object etherealizations have finished and root POA has been destroyed (implying that all descendent POAs have also been destroyed)." with "Shut down is complete when all ORB processing has completed and the object adapters have been destroyed. ORB processing is defined as including request processing and object deactivation or other operations associated with object adapters, and the forwarding of the responses from deferred synchronous invocations to their associated reply handlers. In the case of the POA, this means that all object etherealizations have finished and root POA has been destroyed (implying that all descendent POAs have also been destroyed)."
Actions taken:
January 7, 1999: received issue
April 28, 2003: closed issue

Discussion:

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

Issue 2431: issue with ForwardRequest exception in POA (corba-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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: close no change
Revised Text:
Actions taken:
February 2, 1999: received issue
April 28, 2003: closed issue

Discussion:

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

Issue 2629: Getting reply svc ctxts from PersistentRequests (corba-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: In formal/02-06-01 make the following changes: 1. In the IDL for PersistentRequest on page 22-51 and 22-74, and also in the machine readable source file MessageRouting.idl, append the following additional operation to give access to the service context: GIOP::ReplyStatusType get_reply_with_context( in boolean blocking, in unsigned long timeout, out MessageBody reply_body, out IOP::ServiceContextList service_contexts) raises (ReplyNotAvailable); This is a compatible extension of the interface so no new RepID is necessary. 2. Replace section 22.14.2.9 "get_reply" with: 22.14.2.9 "get_reply and get_reply_with_context": The get_reply and get_reply_with_context operation is invoked to poll or block for a reply to a PersistentRequest. The operation returns the status of the reply (either NO_EXCEPTION, USER_EXCEPTION, or SYSTEM_EXCEPTION) or raises the ReplyNotAvailable exception if no reply is obtained before the specified timeout occurs. If the response is returned to the caller, the PersistentRequest is deactivated so that future invocations of get_reply or get_reply_with_context raise the system exception OBJECT_NOT_EXIST. The get_reply and get_reply_with_context operation have the following arguments in common: � blocking - if set, the operation does not return until either a reply can be returned or the PersistentRequest becomes invalid (due to an expired time-to-live). � timeout - ignored if blocking is TRUE. Otherwise, the request blocks for the specified number of seconds or until a reply is available. If no reply becomes available after the specified timeout has expired, the ReplyNotAvailable exception is raised. � reply_body - the data of the reply as originally marshaled by the target. The get_reply_with_context operation has the following additional argument: � service_contexts - the list of service contexts that is associated with the reply message, in the form of a SeviceContextList.
Actions taken:
May 4, 1999: received issue
April 28, 2003: closed issue

Discussion:

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

Issue 2772: Potential deadlock with POA::deactivate_object() (corba-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The draft CORBA 2.3 spec (ptc/99-03-07) does not deal with a potential deadlock situation. If an object is explicitly deactivated with POA::deactivate_object(), the object remains in the active object map until all operations pending on the object have completed. Any attempts to reactivate the object (implicitly via a ServantActivator, or explicitly via activate_object_with_id()) must block until the pending invocations have completed. However, if a servant's implementation of an object deactivates the object and then (directly or indirectly through a call to another collocated object) reactivates the object, the invocation will deadlock.

Resolution: Deferred to next RTF
Revised Text:
Actions taken:
June 28, 1999: received issue
April 11, 2012: Deferred to next RTF

Discussion:

Issue 2785: scheme name for IORs (corba-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Already fixed in CORBA 3.0, close no change
Revised Text:
Actions taken:
July 1, 1999: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Discussion:

Issue 3076: Implementing proper handling of CloseConnection (corba-rtf)

Click here for this issue's archive.
Source: ZeroC (Mr. Marc Laukien, marc(at)zeroc.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above, close, no change
Revised Text:
Actions taken:
December 3, 1999: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Discussion:

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.

Issue 3097: Custom Value Marshaling Issue (corba-rtf)

Click here for this issue's archive.
Source: Camros Corporation (Mr. Jeffrey A. Marshall, jam(at)camros.com)
Nature: Uncategorized Issue
Severity:
Summary:

Due to the way that custom values are marshaled it is
nearly impossible for a bridge (or other process) to
process/forward GIOP messages which contain custom
marshaled values (which the bridge has no compile/run-time
knowledge of).

The main issue is that the "alignment" of the
custom marshaled data is unknown, other than the
data will always start on a four byte boundry due
to the presence of chunking.

Should/could the value encoding format be changed to
enforce eight byte alignment for all custom marshaled
data (chunks)? This would allow bridges and other 
tools to process->[store]->forward messages containing
custom values.

Resolution: Deferred to next RTF
Revised Text:
Actions taken:
December 7, 1999: received issue
March 7, 2002: moved to Core RTF
April 11, 2012: Deferred to next RTF

Issue 3318: Sending codeset context more than once? (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: 1. In orbrev/02-02-01 in section 13.10.2.6 "Code Set Negotiation" insert the following as the third from last paragraph of the section, immediately preceding the para that begins: "To guarantee "out of the box" interoperability......": If the client (or the server if Bi-Directional GIOP is in use) sends multiple codeset service contexts on the same connection, with different paramter values, then the behavior is undefined. The reciever of a codeset service context with different values from those recieved on the same connection and processed previously may return a MARSHAL system exception with the standard minor code j. 2. Add the following minor code to the MARSHAL system exception. minor code: j description: codeset service contexts with different values recieved on the same connection.
Actions taken:
March 14, 2000: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Discussion:

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

Issue 3322: Portable Interceptors: object_to_string, string_to_object (corba-rtf)

Click here for this issue's archive.
Source: IONA (Mr. Matthew Newhook, )
Nature: Uncategorized Issue
Severity:
Summary:

 object_to_string and string_to_object are missing on ORBInitInfo.

Resolution: Resolve in conjunction with 3772 and close this issue when 3772 is resolved
Revised Text:
Actions taken:
January 17, 2000: receive dissue
April 28, 2003: closed issue

Discussion:

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.

Issue 3355: Question about routing policies (corba-rtf)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Clarification
Severity:
Summary:

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: close no change
Revised Text:
Actions taken:
February 22, 2000: received issue
April 28, 2003: closed issue

Discussion:

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

Issue 3403: PI needs the ORB to be available in IDL (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Russell Butek, )
Nature: Uncategorized Issue
Severity:
Summary:

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: Resolve this issue simultaneously with 3772 and close it as soon as 3772 is resolved and closed
Revised Text:
Actions taken:
March 16, 2000: received issue
April 28, 2003: closed issue

Discussion:

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.

Issue 3429: ORBInitInfo needs the ORB (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Russell Butek, )
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: This issue is a restatement of issue 3403. Merge with issue 3403 and close this issue
Revised Text:
Actions taken:
March 16, 2000: received issue
December 11, 2002: closed issue

Issue 3459: DynValue & custom valuetypes (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The CORBA 2.3.1 specification does not cover the interaction between the
DynValue interface and custom valuetypes.

I frankly don't see any way that the DynValue interface can possibly
correctly handle a custom valuetype when the ORB does not have a factory
for the type.  It is theoretically possible for DynValue to properly
work with a known custom type, but the implementation strategy could not
be based on parsing the marshalled form of the valuetype.

So, there are two issues that need to be addressed:

1.  Should DynValue handle custom valuetypes at all?

2.  For the set of custom valuetypes that it cannot handle, what
exceptions should be raised by each operations?

Resolution: Deferred to next RTF
Revised Text:
Actions taken:
March 25, 2000: received issue
April 11, 2012: Deferred to next RTF

Issue 3541: How correlate requests and replies when using pollable sets? (corba-rtf)

Click here for this issue's archive.
Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: close no change
Revised Text:
Actions taken:
April 10, 2000: received issue
April 28, 2003: closed issue

Discussion:

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

Issue 3599: Detail lacking in when request interceptors are called (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: In formal/02-06-01 make the following changes: 1. Replace the last sentence of the second paragraph of section 21.4.4.5, currently: "On an operation invocation, the flow proceeds as follows:" by "On a synchronous operation invocation, the flow proceeds as follows:" 2. In section 21.3.7.3 insert the following as the third bullet item in the first bullet list: "o For a DII deferred synchronous invocation or AMI invocation using the polling model, send_request is followed by receive_other (when the invocation is successfully initiated) or receive_exception (if the invocation could not be initiated)." 3. In the two following bullets replace the phrase "TII polls" by: "DII polls (using Request::get_response or ORB::get_next_response) or AMI polls (using valuetypes derived from Messaging::Poller)" 4. Append the following bullet to the first bullet list (i.e. in the new first bullet list this will be the sixth bullet): "o for AMI invocations using the callback model, send_request is followed by receive_other (when the invocation is succesfully initiated) or receive_exception (if the invocation could not be initiated). Any reply is treated as a separate invocation on the callback handler object." 5. In section 21.3.12.10 in the bullet for receive_other replace the phrase that reads: "SUCCESSFUL means an asynchronous request returned successfully." by "SUCCESSFUL means an asychronous request has been successfully initiated." 6. For fixing 5743 item 1. define a new minor code X3599 for BAD_INV_ORDER which says: "Transaction context of request and client threads do not match in interceptor." 7. Append the following paragraph to section 21.3.7.2 "Additional Client-side details": "If during receive_reply the transaction contexts in the TSC and RSC do not match then raise the system exception BAD_INV_ORDER with standard minor code X3599". 8. Append the following to the second paragraph in section 7.2.7 "get_response": "If a BAD_INV_ORDER exception with standard minor code X3599 is recieved it shall be trapped and a WrongTransaction shall be returned to the caller." 9. Append the following to the third paragraph in section 7.3.2 "get_next_response": "If a BAD_INV_ORDER exception with standard minor code X3599 is recieved it shall be trapped and a WrongTransaction shall be returned to the caller." 10. Fix an old pre-exisitng bug in section 4.2 IDL for ORB. Change the IDL specification for get_next_response to read: void get_next_response ( out Request req ) raises (WrongTransaction); This is just an editorial change since the IDL is correct in section 7.3.2.
Actions taken:
May 9, 2000: received issue
April 28, 2003: closed issue

Discussion:

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.

Issue 3601: Portable Interceptors: 9.2.3 text describing `Arguments' (corba-rtf)

Click here for this issue's archive.
Source: DSTC (Mr. Ted McFadden, mcfadden(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity: Minor
Summary:

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: see above
Revised Text:
Actions taken:
May 3, 2000: received issue
April 28, 2003: closed issue

Discussion:

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

Issue 3609: Overriding POA policies (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: close no change
Revised Text:
Actions taken:
May 15, 2000: received issue
April 28, 2003: closed issue
April 11, 2005: received issue
November 1, 2005: closed issue

Discussion:

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

Issue 3615: Policy Management in Portable Interceptors (corba-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

(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).

Resolution: see above
Revised Text:
Actions taken:
May 15, 2000: received issue
April 28, 2003: closed issue

Discussion:

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

Issue 3672: Portable Interceptors / register_initial_reference() (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Phil Adams, pcadams(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text:
Actions taken:
June 6, 2000: received issue
December 11, 2002: closed issue

Discussion:

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.

Issue 3674: Polymorphic Valuetypes and the DII (corba-rtf)

Click here for this issue's archive.
Source: Humboldt-Universitaet (Mr. Martin von Loewis, loewis(at)informatik.hu-berlin.de)
Nature: Uncategorized Issue
Severity:
Summary:

Using the static invocation interfaces, it is possible to receive a
valuetype that derives from the one declared in an operation, as long
as a valuetype factory is known in the receiver (truncation is not the
issue here).

The same is not possible at the DII: When creating the request, the
caller must indicate what type it expects, by forming a named value.
Conceptually, the typecode in the named value should be the typecode
of the base of all acceptable value types. However, if the ORB
receives a derived type, it has no means of unmarshalling it - even if
the application has knowledge about the derived type.

What is missing is an interface to make typecodes of value types known
to the ORB; with those, the ORB could then understand the CDR of the
valuetype, and create a DynAny when asked to.

Resolution:
Revised Text:
Actions taken:
June 7, 2000: received issue
April 11, 2012: Deferred to next RTF

Issue 3770: RoutingPolicy issue (corba-rtf)

Click here for this issue's archive.
Source: Perot Systems (Mr. Charles W. Binko, nobody)
Nature: Clarification
Severity: Significant
Summary:

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: close no change
Revised Text:
Actions taken:
July 31, 2000: received issue
April 28, 2003: closed issue

Discussion:

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.

Issue 3772: ORB accessor on POA? (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: In formal/02-06-01 make the following changes: 1. In the IDL for interface Object at its end on page 4-14 1.a Immediately preceding the IDL line that reads: "interface Object { // PIDL" insert the line of forward declaration "interface ORB; // PIDL" 1.b In the IDL for interface Object at its end on page 4-14 immediately following the line that reads: "Object get_component ();" insert the following line of IDL: "ORB get_orb();" 2. Insert the following section immediately following section 4.3.12, and bumping the following section numbers up by one: "4.3.13 Getting the ORB ORB get_orb(); This operation returns the local ORB that is handling this particular Object Reference. 3. In old section 4.3.13 (i.e. new section 4.3.14 "LocalObject", in the bullet list under the second bullet add the line: " o get_orb - The default behavior of this operation when invoked on a reference to a local object is to return the system exception NO_IMPLEMENT with standard minor code X5329 (Ed: where X5329 is defined in the resolution of issue 5329). Certain local objects that have close association with an ORB, like POAs, Current objects and certain portable interceptors related local objects override the default behavior and return a reference to the ORB that they are associated with. These are documented in the sections where these local objects are specified " 5. In section 11.3 insert the following paragraph immediately preceding section 11.3.1: "All local objects specified in this chapter except for AdapterActivator, ServantManager, ServantActivator and ServantLocator override the default behavior of the Object::get_orb operation and return the ORB that is associated with the root POA local object." 6. In Chapter 21 insert the new section 21.2 immediately preceding the current section 21.2: "21.2 General Behavior of Local Objects All local objects specified in this chapter except for Interceptor and local interfaces derived from it, PolicyFactory and ORBInitializer override the default behavior of the Object::get_orb operation and return the ORB that the portable interceptor facility is associated with." Actions taken: Resolve and close this issue simultaneously with 3403, 3793 and 3322 subject to the availability of at least one language mapping for the new accessor operation. August 15, 2000: received issue
Actions taken:
August 15, 2000: received issue
April 28, 2003: closed issue

Discussion:

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.

Issue 3793: no way to register value factory from ORB initializer (corba-rtf)

Click here for this issue's archive.
Source: IONA (Mr. Matthew Newhook, )
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: see above.
Revised Text:
Actions taken:
August 28, 2000: received issue
April 28, 2003: closed issue

Discussion:

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.

Issue 3907: Issue: CSIv2 Identity Assertion (corba-rtf)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

Issue on Document orbos/2000-08-04, CSIv2 Joint Submission

Document: orbos/2000-08-04, CSIv2 Joint Submission
Subject: Identity Assertion of X.501 Distinguished Name is not good enough
Severity: Critical

Summary:

The Identity Token union contains a branch that is labled
X501DistinguishedName. A single DN is insufficient to identify an entity.
A path of X501Distinguished Names is needed instead. Also, other concerns
about naming types are raised.

Discussion:

An X.501 Distinguished Name is insufficient to identify a single entity.
The name must be accompanied by the name of its defining authority. In the
case of public key certificates, the names certificate authority must be
included. 

The chain of DNs in this manner must be included up to a root authority
to have any definitive meaning.

This approach will be consistent with the client sending a X.509
Certificate Chain. A DN path is actually defined by the certificate chain.

Furthermore, the DN path should only come from an authority that is
acceptable to the server, whether it be a DN path, or an X.509
Certificate Chain.

The IOR should list the acceptable authorities and their name types.

It is becoming more an more evident that we must invent GSS_NT_Export_Name
types for X.509 Certificate Chain and X.501 DN path.

The SAS_ContextSec structure should list, instead of the naming types, 
the naming authorities!

We shall assume that the name types of the asserted identities shall be
the same as the name types of listed naming authorities in the IOR.

This is the only way this procedure can work Interoperable and without
the client Guessing what it should do.

Suggestions:

An OID for an X.509 Public Key Certificate Chain shall be defined for a
GSS Export Name, and its encoding will be a ASN1 sequence of and X.509
certificate with the least significant certificate first.

An OID for an X.501 Distinguished Name Path shall be defined for a GSS
Exported Name, and its encoding shall be an ASN1 sequence of an X.501
Distinguished Name with the least significant name first.

To avoid having the target put a whole certificate chain in its IOR,
a new OID shall be allocated in which its GSS Exported Name encoding is a
X.501 DN path, but stipulates that the client should send a certificate
chain from that named authority. This GSS Exported Name shall only be
used in IORs and not for transmission in the Identity Token.

typedef Security::GSS_NT_ExportedName NamingAuthority;

struct CompoundSecMech {
	Security::AssociationOptions   target_requires;
	IOP::TaggedComponent           transport_mech;
	sequence<ServiceConfiguration> privilege_authorities;
	sequence<NamingAuthority>      naming_authorities;
};

Resolution:
Revised Text:
Actions taken:
September 20, 2000: received issue
April 11, 2012: Deferred to next RTF

Issue 3914: Missing minor codes in Messaging Chapter (corba-rtf)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: In formal/02-06-01 make the following changes: 1. Add the following minor codes to Appendix A: 1.1 Add minor code 3914X1 for OBJECT_NOT_EXIST with the description: "This Poller has already delivered a reply to some client" 1.2 Add minor code 3914X2 for TIMEOUT with the description: "Reply is not available in the Poller by the timeout set for it" 1.3 Add minor code 3914X3 for NO_RESPONSE with the description: "Reply is not available immediately in a non-blocking call" 1.4 Add minor code 3914X4 for TRANSACTION_ROLLEDBACK with the description: "Deferred transaction rolled back" 1.5 Add minor code 3914X5 for BAD_INV_ORDER with the description: "Poller has not returned any response yet" 2. In the first paragraph of section 22.9 replace the phrase: "This operation raises the system exception OBJECT_NOT_EXIST..." by: "This operation raises the system exception OBJECT_NOT_EXIST with standard minor code 3914X1...." 3. In section 22.10.1.1 make the following changes: 3.1 In item 3 of the first numbered list in the section replace the phrase that reads: "the operation raises the system exception CORBA:TIMEOUT" by "the operation raises the system exception TIMEOUT with standard minor code 3914X2" 3.2 In the first bullet under item 3 of the first numbered list in the section replace the phrase that reads: "which raises the exception CORBA::NO_RESPONSE" by "which raises the system exception NO_RESPONSE with the standard minor code 3914X3" 3.3 In the first bullet under item 3 of the numbered list in the section replace the phrase that reads: "this system exception is raised to indicate" by: "this system exception is raised with standard minor code 3914X2 to indicate" 3.4 In the second bullet under item 3 of the numbered list in the section replace the phrase that reads: "this system exception is raised to indicate" by: "this system exception is raised with standard minor code 3914X3 to indicate" 3.5 In the second numbered list in the section in items 1 and 2 replace the phrase that reads: "raise the standard exception OBJECT_NOT_EXIST." by: "raise the system exception OBJECT_NOT_EXIST with standard minor code 3914X1." 4. In section 22.10.1.2 make the following changes 4.1 In the second paragraph replace the phrase that reads: "the operation raises the system exception CORBA::TIMEOUT." by "the operation raises the system exception TIMEOUT with the standard minor code 3914X2." 4.2 In the first bullet of the second set of bullets replace the phrase that reads: "raises the exception CORBA::NO_RESPONSE" by: "raises the system exception NO_RESPONSE with the standard minor code 3914X2" 4.3 In the first bullet under the last bullet of the section replace the phrase that reads: "this system exception is raised to indicate" by: "this system exception is raised with standard minor code 3914X2 to indicate" 4.4 In the second bullet under the last bullet of the section replace the phrase that reads: "this system exception is raised to indicate" by: "this system exception is raised with standard minor code 3914X3 to indicate" 4.5 In the third set of bullets in the section in bullets 1 and 2 replace the phrase that reads: "raise the standard exception OBJECT_NOT_EXIST." by: "raise the system exception OBJECT_NOT_EXIST with standard minor code 3914X1." 5. Insection 22.14.2.9 in the first paragraph replace the phrase that reads: " get_reply raise the system exception OBJECT_NOT_EXIST." by " get_reply raise the system exception OBJECT_NOT_EXIST with standard minor code 3914X1." 6. On page 22-60 replace the first two occurences of "TRANSACTION_ROLLEDBACK" by: "TRANSACTION_ROLLEDBACK with standard minor code 3914X4" 7. In the last paragraph of section 22.9 replace the phrase: "the BAD_INV_ORDER system exception is raised." by: "the BAD_INV_ORDER system exception with standard minor code 3914X5 is raised."
Actions taken:
September 14, 2000: received issue
April 28, 2003: closed issue

Discussion:

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.

Issue 3947: Portable interceptors and invocation timeouts (corba-rtf)

Click here for this issue's archive.
Source: Progress Software (Mr. Eoghan Glynn, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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: close no change
Revised Text:
Actions taken:
October 12, 2000: received issue
April 28, 2003: closed issue

Discussion:

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

Issue 3989: No portable way to turn IOR components into object-reference policies (corba-rtf)

Click here for this issue's archive.
Source: IONA (Mr. Matthew Newhook, )
Nature: Uncategorized Issue
Severity:
Summary:

  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.

Resolution: This is in essence the same as issue 3615. Merge with 3615 and close this issue
Revised Text:
Actions taken:
October 24, 2000: received issue
December 11, 2002: closed issue

Issue 4008: wchar endianness (corba-rtf)

Click here for this issue's archive.
Source: AT&T (Dr. Duncan Grisby, )
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: see above
Revised Text: In orbrev/02-02-01 1. Delete the following text from the second bullet item in 15.3.1.6 "For example, if the TCS-W is ISO 10646 UCS-2 (Universal Character Set containing 2 bytes), then wide characters are represented as unsigned shorts. For ISO 10646 UCS-4, they are represented as unsigned longs." 2. Add the following paragraphs at end of 15.3.1.6: "For GIOP 1.1, 1.2 and 1.3, UCS-2 and UCS-4 should be encoded using the endianess of the GIOP message, for backward compatibility. For GIOP 1.4, the byte order rules for UCS-2 and UCS-4 are the same as for UTF-16. UTF-16LE and UTF-16BE, from IANA codeset registry, have their own endianess definition. Thus these should be encoded using the endianess specified by their endianness definition."
Actions taken:
October 31, 2000: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Discussion:

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.

Issue 4065: How does an ORB implement Object::get_policy for PI defined policies? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The description for Object::get_policy (in the Core, section 4.3.7.1)
states:

"The get_policy operation returns the policy object of the specified
type (see Policy Object on page 4-32), which applies to this object. It
returns the effective Policy for the object reference. The effective
Policy is the one that would be used if a request were made."

For a policy defined by PI, I don't see anyway for the ORB to implement
this operation correctly, since there isn't any way for it to know how
to properly resolve any client override policies with the policy
information stored in the IOR.

When a invocation is actually in process, the ClientRequestInterceptor
can use the information available in the ClientRequestInfo interface to
get the client override and the IOR policy data and do the correct
resolution before continuing with the request.  However,
Object::get_policy() needs to do the same type of thing, but it has no
invocation context to do it in.

I think the same problem also applies to the implementation of
ClientRequestInfo::get_request_policy().  

I think we need a new interception point to do this work.  Something
like:

local interface PolicyInterceptor {
    any determine_effective_policy(in PolicyInfo pi);
};

local interface PolicyInfo {
    readonly attribute Object			target;
    readonly attribute Object			effective_target;
    readonly attribute IOP::TaggedProfile	effective_profile;

    IOR::TaggedComponent get_effective_component (in IOP::ComponentId
id);
    IOP_N::TaggedComponentSeq get_effective_components (in
IOP::ComponentId id);
};

If this turns out to be an acceptable solution, then we should also
change ClientRequestInfo to:

local interface ClientRequestInfo : RequestInfo, PolicyInfo {
    ...
};

and remove the redundant operations.

Resolution:
Revised Text:
Actions taken:
November 18, 2000: received issue
April 11, 2012: Deferred to next RTF

Issue 4137: Implications of any/valuetype marshalling (corba-rtf)

Click here for this issue's archive.
Source: Iconixx (Mr. Thomas S. Hawker, )
Nature: Uncategorized Issue
Severity:
Summary:

RE: CCM chapters document [orbrev] 99-10-04, section 61.6.2, page 61-45.
The document citation indicates that the integrity of the valuetype --
that is, the received marshalled state -- is to be preserved in an
ORB-mediated operation, even if that valuetype cannot be unmarshalled,
either partially (truncated) or at all.  If this value is then passed to
another operation, the original marshalled state is to be transmitted. 
This preserves the transmitted object in its entirety, regardless of
local implementation concerns.  This is obviously necessary for bridges
or event processing, such as through the notification service.

So the question arises, what happens if you have a partial (truncated)
unmarshall and the recipient application changes the local state of the
valuetype through its attributes or local operations?  How can/will you
even know the state was changed?  Do you ignore the changes and send the
originally received marshalled stream, send only the new valuetype even
though it is a truncation of the original, or "merge" the new values for
the unmarshalled part followed by the original appended data for the
truncated part?  Should this third option be possible through an
explicit ORB call -- that is, the application is responsible to identify
the change in state to the ORB?  I assume that the semantics of
"truncatable" must come to include the understanding that data in the
truncatable portions may not be contextually dependent on the inherited
parent of the valuetype.

As a further question, is there a reason why this semantic
interpretation should not be extended to be a general requirement rather
than only with respect to transmission of anys?  My experience has found
that passing anys tends to be expensive and is avoided where it can be. 
A more general interpretation permits transmission of a comprehensive
data structure among intermediate agents that only use (unmarshall) the
information they need.

Resolution:
Revised Text: In ptc/99-10-04, remove section 61.2.2, �Integrity of value types contained in anys� on page 61-45.
Actions taken:
January 5, 2001: received issue
May 13, 2002: closed issue
June 17, 2002: issue re-opened as Core RTF issue
April 11, 2012: Deferred to next RTF

Discussion:

The integrity of value types contained in anys is a requirement on the ORB core,
and an appropriate paragraph should be added to the Value Type Semantics
chapter. This requirement is not limited to Components. The paragraph in the Components specification that mentions this requirement should be removed.
This issue should then be moved to the Core RTF.

Issue 4156: Encodings of Sequences of Certificates are not standard. (corba-rtf)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The proposed change is backward incompatible. Close no change
Revised Text:
Actions taken:
January 18, 2001: received issue
December 11, 2002: closed issue

Discussion:

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.

Issue 4164: ORB::shutdown vs. ORB::destroy (corba-rtf)

Click here for this issue's archive.
Source: IONA (Mr. Matthew Newhook, )
Nature: Uncategorized Issue
Severity:
Summary:

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: close no change
Revised Text:
Actions taken:
January 20, 2001: received issue
April 28, 2003: closed issue

Discussion:

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.

Issue 4167: Stateful boolean causes all CSI mechanisms to operate the same way. (corba-rtf)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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;
    };

};

Resolution: CLOSE NO CHANGE
Revised Text:
Actions taken:
January 22, 2001: received issue
December 11, 2002: closed issue

Discussion:

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.

Issue 4169: Avoiding RSC/TSC copy on server side (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
Summary:

During the interceptor FTF we changed the server-side threading
requirements such that all server-side points run in the same thread
as the ServantManager and servant except receive_request_service_contexts.

We attempted to update 21.4.4.4 "Request Scope vs Thread Scope"
accordingly but knew we screwed the picture and wording up.  So we
punted to the RTF.

The main problem with the current wording is that is forces a copy of
of TSC/RSC before the servant manager and then receive_request are
called.  This is necessary because 21.4.4.5 item 5 says: "The
receive_request points may modify the RSC, but this no longer affects
the TSC."

The only way to make RSC identical to TSC in receive_request with
respect to reading but also have them be independent with respect to
writing is to make a copy (which could be optimized to copy-on-write,
but why?).

I suggest we just state they are equivalent after 
receive_request_service_contexts.

Here is a proposed revision to ptc/00-08-06 along these lines.

Comments?
Harold

21.4.4.4 Request Scope vs Thread Scope

... On the server-side, the request scope PICurrent is attached to
the ServerRequestInfo and follows the request processing. It is
logically equivalent to the thread scope PICurrent after the list of
receive_request_service_contexts interception points are processed.

21.4.4.5 Flow of PICurrent between Scopes

5. The ORB logically makes the RSC equivalent to the server-side TSC
after the receive_request_service_contexts points are processed and
before the servant manager is called. This TSC is within the context
for both the receive_request points, the invocation of the servant
manager, and the invocation of the target operation.

The receive_request points are called. These points have access to the
RSC.  Modifying the RSC at this point makes corresponding
modifications on the TSC. Since these points execute in the same
thread as the target operation invocation, these points may modify the
server-side TSC which makes corresponding modifications on the RSC.


6. After the receive_request points are called, control transfers to
the server threads which may also read and write this server-side TSC.
Any modifications to the TSC makes corresponding modifications on the
RSC.

7. <No change>

8. <DELETE THIS ITEM>

9. The send interception points have access to the RSC (and the
equivalent TSC) from which they may populate the reply service context
list. After the invocation result is sent back to the client, the
server-side RSC is logically destroyed.


...

The picture would also need updating, but let's agree on wording first.

Resolution:
Revised Text:
Actions taken:
January 23, 2001: received issue
April 11, 2012: Deferred to next RTF

Issue 4173: Clarify that each interception point executes in a distinct logical thread (corba-rtf)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Clarify as shown below
Revised Text: The last two paragraphs in orbrev/02-02-01 section 21.4.4.6 state: ------------------------- "Interceptors shall assume that each client-side interception point logically runs in its own thread, with no context relationship between it and any other thread. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Interceptors shall assume that all server-side interception points except receive_request_service_contexts run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_contexts, like all client-side interception points, logically runs in its own thread, with no context relationship between it and any other thread." ------------------------- To clarify the sharing of logical TSC threads at each interception point change the last two paragraphs of orbrev/02-02-01 section 21.4.4.6 to (the changes shown in italics): "Interceptors shall assume that each client-side interception point logically runs in its own TSC thread, with no context relationship between it and any other thread. Each point's logical TSC thread is shared by all registered ClientRequestInterceptors executing in that point. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did. Interceptors shall assume that all server-side interception points except receive_request_service_contexts run in the same thread as the target operation invocation, thereby sharing thread context information. receive_request_service_contexts, like all client-side interception points, logically runs in its own TSC thread, with no context relationship between it and any other thread. The receive_request_service_contexts interception point logical TSC thread is shared by all registered ServerRequestInterceptors executing in that point. While an ORB implementation may not actually behave in this manner, it is up to the ORB implementation to treat PICurrent as if it did."
Actions taken:
January 24, 2001: received issue
December 11, 2002: closed issue

Issue 4236: X/Open Codeset registry is obsolete needs to be replaced (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: In orbrev/02-02-01 1. In Section 13.10.2.5 "GIOP Code Set Service Context", change the last paragraph of the section (immedeately preceding the Note:) from: "Code sets are identified by a 32-bit integer id from the OSF Character and Code Set Registry (See "Character and Code Set Registry" on page 13-52 for further information). " to the following: "For GIOP versions 1.1, 1.2 and 1.3, Code sets are identified by a 32-bit integer id from the OSF Character and Code Set Registry (See "Character and Code Set Registry" on page 13-52 for further information). For GIOP versions greater than 1.3, Code sets are identified by a 32 bit integer id, from either the OSF Character and Code set registry (See "Character and Code Set Registry" on page 13-52 for further information) or the IANA Character Set registry (current version at http://www.iana.org/assignments/character-sets). The OSF Registry and the IANA Registry have non-overlapping ranges, so there is no need for mapping values from one codeset registry to the other." 2. Modify the paragraph in 13.10.2 that starts: "If none of these conversions is possible, then the fallback code set..." by appending the following to it: "If either the CNCS or SNCS is from the IANA Character Set registry, then the codesets are automatically assumed to be compatible and the fallback codeset is used."
Actions taken:
March 26, 2001: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Discussion:

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.

Issue 4284: 21.8.1 register_initial_reference (corba-rtf)

Click here for this issue's archive.
Source: SeeBeyond Technology Corp. (Tom Urquhart, TUrquhart(at)SeeBeyond.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: In formal/02-06-01 in section 21.8.1 1. Immediately following the second paragraph of the section insert the following paragraphs: "This operation can be used to replace the object reference corresponding to any of the OMG specified Ids. For example: register_initial_reference ("NameService", Z) will cause Z to be substituted as the object reference that will be used to get to the Name Service instead of the ORB vendor supplied built in Name Service. This facility should be used with care since subsitution of certain OMG specified ids is unlikely to work at all. Implementions are allowed to restrict substituability of references corresponding to the following ObjectIds: RootPOA, POACurrent, DynAnyFactory, ORBPolicyManager, PolicyCurrent, CodecFactory, and PICurrent. When substitutability is restricted it shall be clearly docmented. InvalidName exception is raised when any of these restricted ObjectIds are passed in as a parameter to resolve_initial_reference." 2. Remove the bullets that follow the line that reads "InvalidName is raised if:" and replace the line with: "InvalidName is raised if this operation is called with an empty string id."
Actions taken:
April 25, 2001: received issue
April 28, 2003: closed issue

Discussion:

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.

Issue 4290: Problem with CSIv2 and GIOP LocateRequest (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: In formal/02-06-01 insert the following section immediately following section 24.5.3: 1. 24.5.4 Server Side Consideration 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. 2. Replace the text in Footnote 11 on page 24-44 by: "CSS can use the Object::validate_connection operation to get the ORB to issue a locate request."
Actions taken:
April 20, 2001: received issue
April 28, 2003: closed issue

Discussion:

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.

Issue 4321: Interpretation of defined ServiceConfigurationSyntax constants is incomplet (corba-rtf)

Click here for this issue's archive.
Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: close no change
Revised Text:
Actions taken:
May 24, 2001: received issue
April 28, 2003: closed issue

Discussion:

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

Issue 4324: Note on page 15-43, OBJECT_FORWARD_PERM (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Good catch. The note is simply wrong and should be removed
Revised Text: Remove the note near the end of section 15.4.6.2 that reads: 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
Actions taken:
May 29, 2001: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Issue 4334: Repository ID in nil references (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above Close no change
Revised Text:
Actions taken:
June 5, 2001: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Discussion:

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.

Issue 4337: rep_id() operation on Object? (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: see above
Revised Text: 1. Page 3-23, first bullet at the top of the page: Add repository_id() to the list of operations. 2. Page 3-23, bullet list beginning with is_a: Add repository_id() to the list of operations, following the get_interface() operation. 3. Section 4.3, "Object Reference Operations", page 4-12: Add the following to the ORB interface, following get_interface(): string repository_id(); 4. Add a new section 4.3.1.2 (following 4.3.1.1) as follows: 4.3.1.2 repository_id repository_id returns the repository ID of an object (see section 10.6 for details of repository IDs). The implementation of this operation must contact the ORB that implements the target object. 5. Section 7.2.1, second last paragraph: Add repository_id to the list of operations that may be invoked using the DII. 6. Section 11.3.1, third-last bullet: Add repository_id to the list of operations for which Servant provides a default implementation. Same paragraph: Add repository_id to the list of operations that use the most-derived interface of a servant. 7. Section 15.4.2, first para: Add repository_id to the list of operations. 8. Section 15.4.2.1, page 15-35, last bullet, second para of bullet: Add _repository_id to the list of operation names. 9. Section 21.3.1, point 1: Add repository_id to the list of operations.
Actions taken:
June 5, 2001: received issue
December 11, 2002: closed issue

Discussion:

Resolution: Accept this proposal subject to inclusion at the point that 
Components FTF material is integrated into Core and consequently 
IIOP minor version is revved

Issue 4506: TypeCodes for custom marshaled valuetypes (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Mr. Everett Anderson, )
Nature: Uncategorized Issue
Severity:
Summary:

It is underspecified what value member information for custom
marshaled valuetypes an ORB must provide.

Users of custom marshaled valuetypes must provide their own marshaling
code, and the ORB has no way of knowing what it does before executing
it.

This comes into play for custom marshaled valuetypes inside of Anys,
as well as the ValueMemberSeq in the FullValueDescription of a custom
marshaled valuetype.

In both cases, one can query whether or not the valuetype is custom
marshaled.  With Anys, the TypeCode has a ValueModifier type_modifier
which is set to VM_CUSTOM.  The FullValueDescription includes a
boolean is_custom.

I can see two possible solutions:

1.  TypeCodes for custom marshaled valuetypes will encode no value
member information, so the member_count will be 0.  The
FullValueDescription will have a zero length sequence for the
ValueMemberSeq members.

or

2.  Value member information for the TypeCode or FullValueDescription
for a custom marshaled valuetype is the state defined in the
valuetype's IDL in the same way as if it were not custom marshaled.

I propose #1 as the solution.  This member information is only useful
for finding out what is encoded, and solution #2 doesn't provide
that.  Plus, it can be very expensive to create and transmit if many
repository IDs are involved.

Resolution: see above
Revised Text:
Actions taken:
August 16, 2001: received issue
March 7, 2002: moved to Core RTF
April 28, 2003: closed issue

Discussion:

Resolution: Scanning through the archive for this issue indicates that the case for making the proposed change was weak at best and the change does break existing clients potentially. So it would be prudent not to make this change for very minor gains. Close no change

Issue 4536: CORBA components requires new GIOP version? (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Mr. Everett Anderson, )
Nature: Uncategorized Issue
Severity:
Summary:

Please forgive me if this is old news.  I was trying to find a recent
CORBA Components spec to see what changes it has had on the core spec.

It looks like several new TypeCode kinds have been added (two from
CCM?), but doesn't that require a new GIOP version?  Even if the specs
did declare the wire formats in new versions of Chapter 15, how could
older GIOP 1.2 ORBs handle them?

Specs:

CCM FTF drafts of modified CORBA Core chapters
Adds tk_component and tk_home in 10.7.1.  No update to 15.
http://www.omg.org/cgi-bin/doc?ptc/99-10-03

CORBA 2.4.2 complete specification
Adds tk_local_interface in 10.7.1.  No update to 15.
http://www.omg.org/cgi-bin/doc?formal/01-02-01

Resolution: close no change, see above
Revised Text:
Actions taken:
August 27, 2001: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Discussion:

Resolution: Fixed in CORBA 3.0. GIOP version is 1.3 and all additional CCM 
features are handled in GIOP 1.3

Issue 4554: Detecting Recursion in Other Interceptors (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Tim Baldwin, tim_baldwin(at)uk.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

We have identified a requirement where the interceptors for one service
need to be able to detect recursive invocations made by some other
interceptor during the processing of a request.  As far as we have been
able to determine there is no way to achieve this using the
Request-scope/Thread-scope Current mechanism described in the spec.

It is probably easiest to explain this using a specific example.  Start
with some form of "transaction" service that registers client-side
interceptors so it can detect all new request invocations and add service
contexts that perform some form of "begin transaction" processing at the
server.   This transaction service must only perform this "begin
transaction" once per application-level request, so it allocates a
PICurrent slot and performs the processing described in section 21.4.4.2 to
ensure that any recursive calls it makes itself will form part of the same
transaction and not begin a new one.

However a problem now occurs if we introduce some other service, say a
"security" service that has its own interceptors registered.  The order in
which these two service's interceptors run can affect what happens, but
since interceptor ordering is undefined assume that the security
interceptor runs first.

An application makes a request on its own thread A.  The send_request
interceptors start to run on thread B and the security interceptor runs
first, at this point both the RSC and TSC slots for the transaction service
are empty.  The security interceptor makes a recursive request so the
send_request interceptors run again on a new thread C.  The security
interceptor runs again and this time doesn't recurse so the transaction
interceptor now runs on thread C.  At this point it finds its RSC slot
empty so does a "begin transaction" and sets its TSC for thread C.  We've
now finished interceptors on thread C and return to thread B and invoke
send_request for the transaction service.  Once again it finds its RSC slot
empty and will try to "begin transaction" again.  Now we have a problem as
we have issued two "begin transactions" for the same application request.

In fact it as actually the second of those two "begin transactions" that we
really want to do, as that represents the true start of the application's
transaction.  The first one (caused by the recursive call in the other
interceptor) is at best redundant and wasteful and at worst wrong and
problematic.

Does anyone have any comments on this problem?

Resolution: close no change
Revised Text:
Actions taken:
September 4, 2001: received issue
April 28, 2003: closed issue

Discussion:

Resolution: This issue is based on faulty premises.  It states that the transaction interceptor does a begin transaction.  This is not the transaction model nor the model supported by the design of Portable Interceptors.  The application code is responsible for marking the begin and end of the transaction. When the begin/end is marked outside of interceptors there is no problem with recursion. Close no change.

Issue 4585: CORBA 2.5 and Portable Interceptors mismerged (corba-rtf)

Click here for this issue's archive.
Source: Vanderbilt University (Mr. Ossama Othman, ossama(at)dre.vanderbilt.edu)
Nature: Uncategorized Issue
Severity:
Summary:

The new Portable Interceptor chapter in the CORBA 2.5 specification
has apparently been mismerged.  Section 13.8 "Coder/Decoder
Interfaces," the Codec related interfaces added to the "IOP" module,
should supercede those in the deprecated "IOP_N" module that is listed
in section 21.10 "Portable Interceptor IDL."

Suggested changes include:
- Remove the IOP_N module from Section 21.10 "Portable Interceptor
  IDL."
- Change all instances of "IOP_N" to "IOP."  In particular, methods
  listed in sections 21.3.13 (ClientRequestInfo IDL) and 21.10 refer
  to the "IOP_N" module.  The following methods in section 21.10 must
  be updated:

	module PortableInterceptor {

		// ...
		local interface ClientRequestInfo {
		  // ...
		  IOP_N::TaggedComponent get_effective_component (...)
		  IOP_N::TaggedComponentSeq get_effective_components (...)
		  // ...
		};
		// ...

		local interface ORBInitInfo {
		  readonly attribute IOP_N::CodecFactory codec_factory;
		};

	};

Resolution: Fixed in CORBA 3.0 (ptc/02-01-14). Close no change
Revised Text:
Actions taken:
October 1, 2001: received issue
October 8, 2001: moved from orb_revison to the interceptors RTF
December 11, 2002: closed issue

Issue 4650: Alignment for empty sequence? (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

struct X {
   long			long_1;
   sequence<double>	double_seq;
   long			long_2;
};

The question is, how should things be padded if double_seq is empty?
(Assume that we are starting at byte offset 0 for marshaling this structure.)

Approach taken by ORB 1:

	- long_1 is aligned on a four-byte boundary (offset 0).

	- The length of double_seq is aligned on a four-byte boundary,
	  immediately following long_1 (offset 4).

	- long_2 is aligned on a four-byte boundary. Because double_seq is
	  empty, this means that long_2 immediately follows the length of
	  double_seq on the wire, so long_2 begins at offset 8 and the total
	  number of bytes for the struct is 12.

Approach taken by ORB 2:

	- long_1 is aligned on a four-byte boundary (offset 0).

	- The length of double_seq is aligned on a four-byte boundary,
	  immediately following long_1 (offset 4).
	
	- Now four bytes of padding are inserted because the sequence element
	  type is double, so the next data item is expected to start on
	  an eight-byte boundary.

	- long_2 is aligned on that eight-byte boundary, so long_2 begins at
	  offset 12 and the total number of bytes for the struct is 16.

The spec isn't clear on what should happen:

	Sequences are encoded as an unsigned long value, followed by the
	elements of the sequence. The initial unsigned lon gcontains the
	number of elements in the sequence. The elements of the sequence
	are encoded as specified for their type.

>From this, I cannot infer unambiguously which interpretation is correct.

Both approaches seem reasonable. (Personally, I have a slight preference
toward approach 2 because it's more consistent: after consuming the sequence,
the next data item will always start on an 8-byte boundary, which is more
consistent than approach 1, because the padding rules don't depend on the
length of the sequence at run time.)

I suspect that the best way to resolve this might be to take a majority vote
in line with the behavior of current implementations. And, of course,
the question now is what do we do with the GIOP version? We probably should
increment it, but I don't see what that would achieve for already existing
implementations, sigh...

Resolution: see above, no change necessary
Revised Text:
Actions taken:
October 30, 2001: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Discussion:

Resolution: Approach 1 is the only correct one.  The philosophy of CDR is to pad if necessary immediately before marshalling an item. 15.3.1.1 says: 
"Where necessary, an alignment gap precedes the representation of a primitive datum." 

There is no item of type double that gets marshalled, so there is no opportunity to do the padding for a double. 

No change necessary

Issue 4723: ORBs using BOMs for UTF-16 (closely related to issue 4008) (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Richard Sitze, nobody)
Nature: Uncategorized Issue
Severity: Critical
Summary:

[3, Chapter 15.3.1.6] mentions the use of BOM to indicate (and override the
OMG byte order indicator flag [3, Chapter 15.2.1]) the endian-ness of the
UTF-16 encoded wchar or wstring data.

This is incorrect and goes against the Unicode recommendations [1]?refer to
the Unicode conformance clause C3 [4, Chapter 3.1], and the discussion
related to the use of BOM [4, Chapter 2.7].

[4, Chapter 3.1] unambiguously implies that a BOM is not necessary if a
higher-level protocol indicates the endian-ness. [4, Chapter 2.7]
categorically states: "if other signaling methods (the OMG byte order flag
in this context) are used, signatures (BOM) should not be employed".

The UTF-16 endian rules of [3, Chapter 15.3.1.6] are clearly influenced by
[2]. In the MIME world, an initial U+FEFF or U+FFFE is interpreted as BOMs.
The BOM (or its absence) indicates the endian-ness of UTF-16 encoded data
in the internet MIME world. But for CORBA messages or CDR encapsulations,
the OMG byte order flag is already explicitly marking the UTF-16 encoded
data as UTF-16BE or as UTF-16LE. U+FEFF or U+FFFE should not be used as
BOMs for UTF-16 encoded data in the CORBA domain.

Therefore, it is proposed that any U+FEFF or U+FFFE, regardless of their
positions in the marshalled data, must be interpreted as ZERO WIDTH
NO-BREAK SPACE characters, and not as BOMs.  All the references to BOM in
[3, Chapter 15.3.1.6] must be removed altogether.

Adoption of the above Unicode conformant rule will
-- result in more efficient encoding of wchar/wstring data?no need to place
U+FFFE for little-endian UTF-16/UTF-32 wchars/wstrings,
-- eliminate the ugly situation, where the BOM of an UTF-16/UTF-32 encoded
wchar/wstring data contained in a message or CDR encapsulation indicate a
different byte order than that specified by the OMG byte order flag for the
same message or CDR encapsulation.

Resolution: This proposal results in a complete reversal of an earlier adopted resolution, and hence would be in
Revised Text:
Actions taken:
December 4, 2001: received issue
March 7, 2002: moved to Core TF
December 11, 2002: closed issue

Discussion:

This proposal results in a complete reversal of an earlier adopted resolution, and hence would be inappropriate

Issue 4724: GIOP 1.2 encoding of wstring (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Richard Sitze, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

[3, Chapter 3.10.3.2] defines an IDL  wstring data type to be a sequence of
wchars. But the GIOP 1.2 encoding of wstring is defined differently [3,
Chapter 15.3.2.7]. A GIOP 1.2 encoded wstring is not a sequence of GIOP 1.2
encoded wchars.

Each individually encoded wchar is associated with an octet containing the
size of the encoded wchar in octets [3, Chapter 15.3.1.6], whereas an
encoded wstring is associated with an unsigned long containing the length
of the entire wstring in octets. Probably [3, Chapter 15.3.2.7] should
clearly mention and explain this point with sample layout diagrams of
appropriately encoded wchars and wstrings.

Resolution: see above
Revised Text: 1. Replace paragraphs 3 and 4 by the following in section 15.3: "GIOP defines two distinct kinds of octet streams: o Message - an octet stream constituting the basic unit of information exchange in GIOP, described in detail in Section 15.4, "GIOP Message Format", on page 15-31. o Encapsulation - an octet stream into which OMG IDL data structures may be marsheled independently, apart from any particular message context, described in detail in Section 15.3.3, "Encapsulation", on page 15-14." 2. Replace the first paragraph of section 15.3.3 with what used to be paragraph 4 in section 15.3 before item 1 is applied 15.3.3. This removes the decoupled and incomplete description of encapsulations from section 15.3, and replaces it with a reference to the description, and the full description in 15.3.3 contains all of the additional clarifications about code sets, byte orders, alignments etc.
Actions taken:
December 4, 2001: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Discussion:

Resolution: The definition of IDL type and the details of how it is marshaled is not necessarily always as closely related as the first issue would seem to suggest. 
As for the confusion about what is and what is not included in an encapsulation containing something like a wstring, the confusion arises mainly because the pargraphs are poorly organized in section 15.3. Fixing them as follows should remove any residual ambiguity

Issue 4725: Chapters 13.10.1.9, and 13.10.1.12 -- issue (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Richard Sitze, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

[3, Chapters 13.10.1.9, and 13.10.1.12] apparently indicate that both TCS-C
and TCS-W can be byte-oriented or non-byte-oriented.

Assume the following configurations for two communicating ORBs.

CNCS-C = windows-1252, SNCS-C = ISO-8859-1, and CCCS-C = SCCS-C = {UTF-16}.

The execution of the OMG code set negotiation algorithm [3, Chapter
13.10.2.6] in this case will result in the value of the TCS-C as UTF-16!

An IDL string will then be marshalled as UTF-16 encoded data, which may
have embedded single-octet NULLs. This point should be mentioned explicitly
somewhere in [3, Chapter 15.3.1.6], especially when IDL string data types
are not allowed to contain any embedded NULLs [3, Chapter 3.10.3.2]. [3,
Chapter 15.3.1.6] states that "Both the string length and contents include
a terminating null". If TCS-C is selected to be UTF-16, this 'null' should
be a null of two-octet size. [3, Chapter 15.3.1.6] should be explicit in
stating that the concrete representation of the 'terminating null' is
dependent on the TCS-C.

Similarly, for the following configuration
CNCS-W = UCS-2, SNCS-W = UCS-4, and CCCS-W = SCCS-W = {UTF-8}
TCS-W will be selected as UTF-8!

Are these configurations valid? Regardless of the answer to this question,
[3, Chapters 13.10.1.9, and 13.10.1.12] should clarify the issue of the
orthogonality of TCS with respect to the byte-oriented and
non-byte-oriented code sets with appropriate examples.

Resolution: see above
Revised Text: In formal/02-06-01 section 15.3.2.7 Change: "The string length includes the null character, so an empty string has a length of 1." to: "The string length includes the null character, so an empty string has the length of the encoding of the null character in the transmission character set."
Actions taken:
December 4, 2001: received issue
March 7, 2002: moved to Core RTF
April 28, 2003: closed issue

Discussion:

Resolution:
From GIOP section 15.3.2.7:

"Strings andWide Strings A string is encoded as an unsigned long indicating the length of the string in octets, followed by the string value in single- or multi-byte form represented as a sequence of octets. The string contents include a single terminating null character. The string length includes the null character, so an empty string has a length of 1.

For GIOP version 1.1, 1.2, and 1.3, when encoding a string, always encode the length as the total number of bytes used by the encoding string, regardless of whether the encoding is byte-oriented or not.

For GIOP version 1.1, a wide string is encoded as an unsigned long indicating the length of the string in octets or unsigned integers (determined by the transfer syntax for wchar) followed by the individual wide characters. The string contents include a single terminating null character. The string length includes the null character. The terminating null character for a wstring is also a wide character.

For GIOP version 1.2 and 1.3, when encoding a wstring, always encode the length as the total number of octets used by the encoded value, regardless of whether the encoding is byte-oriented or not. For GIOP version 1.2 and 1.3 a wstring is not terminated by a null character. In particular, in GIOP version 1.2 and 1.3 a length of 0 is legal for wstring. Note � For GIOP versions prior to 1.2 and 1.3, interoperability for wstring is limited to the use of two-octet fixed-length encoding. Wstring values in encapsulations are assumed to be encoded using GIOP version 1.2 and 1.3 CDR."

This text accommodates the concerns raised in the issue, except for the last sentence of the first para:

�The string length includes the null character, so an empty string has a length of 1.�

Fix the sentence to be correct with any encoding for string.

Issue 4796: TypeCode indirections (corba-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This issues was previously raised as issue 4294, and was deferred to the
GIOP 1.3 wishlist.  Now that GIOP 1.3 is about to become a reality, I am
re-raising the issue because of its importance for efficient RMI-IIOP
communications.  This is an interop issue, but I am also copying the
Java to IDL list because of its impact on RMI-IIOP performance.

CDR should allow TypeCode indirections that refer to top-level TypeCodes.
The current prohibition of this causes servere performance penalties for
RMI-IIOP because the Java to IDL mapping requires that Java objects of
declared type java.lang.Object are marshalled as CORBA anys.  In the case
of a Vector or HashTable with 100 elements, this means that 100 anys must
be marshalled.  If all of these are of actual type foo, the restriction
on TypeCode indirections means that all 100 of these data values must repeat
the TypeCode for foo, which could be very large.  This causes very substantial
overheads, since the space and time needed to marshal the TypeCode for foo
can greatly exceed that needed to marshal the data for foo.

I understand why a nested indirection cannot refer to any TypeCode outside
the scope of its enclosing top-level TypeCode.  However, this restriction
does not need to apply to a top-level TypeCode.  We have made this change
experimentally without any adverse effects and we have discovered that
using indirections for all repeated top-level TypeCodes can speed up some
common scenarios by at least a factor of 5 on end-to-end measurements.
There appears to be no downside to making this change.

Proposed Resolution:

In the section headed "Indirection: Recursive and Repeated TypeCodes" within
section 15.3.5.1, replace the current first bullet:

 The indirection applies only to TypeCodes nested within some �top-level�
 TypeCode. Indirected TypeCodes are not �freestanding,� but only exist inside
 some other encoded TypeCode.

by the following two bullets:

 For GIOP 1.2 and below, the indirection applies only to TypeCodes nested
 within some �top-level� TypeCode. Indirected TypeCodes are not �freestanding,�
 but only exist inside some other encoded TypeCode.

 For GIOP 1.3 and above, the indirection applies only to TypeCodes nested
 within some �top-level� TypeCode, or from one top-level TypeCode to another.
 Indirected TypeCodes nested within a top-level TypeCode can only reference
 TypeCodes that are part of the same top-level TypeCode, including the
 top-level TypeCode itself. Indirected top-level TypeCodes can reference
 other top-level TypeCodes but cannot reference TypeCodes nested within
 some other top-level TypeCode.

Resolution: see above
Revised Text: In the section headed "Indirection: Recursive and Repeated TypeCodes" within section 15.3.5.1, replace the current first bullet: The indirection applies only to TypeCodes nested within some �top-level� TypeCode. Indirected TypeCodes are not �freestanding,� but only exist inside some other encoded TypeCode. by the following two bullets: For GIOP 1.2 and below, the indirection applies only to TypeCodes nested within some �top-level� TypeCode. Indirected TypeCodes are not �freestanding,� but only exist inside some other encoded TypeCode. For GIOP 1.3 and above, the indirection applies only to TypeCodes nested within some �top-level� TypeCode, or from one top-level TypeCode to another. Indirected TypeCodes nested within a top-level TypeCode can only reference TypeCodes that are part of the same top-level TypeCode, including the top-level TypeCode itself. Indirected top-level TypeCodes can reference other top-level TypeCodes but cannot reference TypeCodes nested within some other top-level TypeCode.
Actions taken:
December 21, 2001: received issue
March 7, 2002: moved to Core RTF
December 11, 2002: closed issue

Discussion:

Resolution: 
This is a desirable change. Incorporate the text changes shown below and close issue. This change 
will become part of GIOP 1.4 upon the completion of the new Firewall specification finalization

Issue 4806: Issue with chunking (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
Summary:

15.3.4 is silent on the treatment of encapsulations containing chunked valuetypes and in particular chunked valuetypes containing encapsulations containing chunked valuetypes. My understanding of encapsulations leads me to believe that the encapsulation should ignore the current nesting level and chunk length and start from scratch, i.e. chunks within an encapsulation are calculated relative to the start of the encapsulation rather than relative to the stream.

The reason this needs clarification is because the spec goes to great lengths to make sure chunks are *not* nested so I think that it would be clearer if this case was specifically discussed. Additionally I don't know whether 15.3.4.6 should include encapsulations in the list of data types that cannot be split across a chunk. In general you would probably have to read the entire encapsulation before you can decode it, so allowing it to be split across chunks might be problematic.

Resolution: Clarify as shown below
Revised Text: In document orbrev/02-02-01, in section 15.3.4.6 Change the bullets which read: "- Chunks are never nested. When a value is nested within another value, the outer value's chunk ends at the place in the stream where the inner value starts. If the outer value has non-value data to be marshaled following the inner value, the end tag for the inner value is followed by a continuation chunk for the remainder of the outer value. Regardless of the above rules, any value nested within a chunked value is always chunked. Furthermore, any such nested value that is truncatable must encode its type information as a list of RepositoryIDs (see Section 15.3.4.1, "Partial Type Information and Versioning," on page 15-16)." To these bullets: "- The scope of an encoded valuetype is a complete GIOP message or an encapsulation. Starting a new encapsulation starts a new scope. Ending an encapsulation ends the current scope and restores the previous scope. Starting a new scope starts a new count of end tag nesting (initially 0), chunking status (initially false) and chunk position (initially 0)." - Chunks in the same scope are never nested. When a value is nested within another value, the outer value's chunk ends at the place in the stream where the inner value starts. If the outer value has non-value data to be marshaled following the inner value, the end tag for the inner value is followed by a continuation chunk for the remainder of the outer value. - Regardless of the above rules, any value nested within a chunked value in the same scope is always chunked. Furthermore, any such nested value that is truncatable must encode its type information as a list of RepositoryIDs (see Section 15.3.4.1, "Partial Type Information and Versioning", on page 15-16)."
Actions taken:
January 15, 2002: received issue
December 11, 2002: closed issue

Discussion:

Issue 4820: Potential problem using BiDir GIOP and codeset conversion service context (corba-rtf)

Click here for this issue's archive.
Source: ICL (Mr. Chris Wood, )
Nature: Clarification
Severity: Significant
Summary:

I've just noticed there's a potential problem when using BiDir GIOP and the codeset conversion service context, or in fact any service context that has connection rather than request scope. 

Take the following example: 

A opens connection to B 

A issues a request 1 (R1) containing the bidir service context, but not the codeset conversion service context. 

B processes R1, marking the connection as bidirectional. 

B invokes a callback object with a request (R2), this request does contain the codeset conversion service context, since B has noticed A has not set one for the request. 

A symultaniously issues another request (R3), this one does contain the codeset service context, however the codesets it selects are different. 

So we have a problem, which codesets should be used for the connection? 

The obvious solution is to force each direction to negotiate it's own character encodings, however this is not stated anywhere in the spec AFAICS. This problem will also occour for any connection specific state as set up by service contexts. 

Suggested resolution: add to the BiDir part of chapter 15 the following: 

"For any connection level state negotiated by exchange of service contexts, each direction of a bidirectional connection should be negotiated independently. For example, the codeset negotiation process shall produce independent transmission codesets for each direction"

Resolution: see above, close no change
Revised Text:
Actions taken:
February 1, 2002: received issue
December 11, 2002: closed issue

Discussion:

Resolution: 
Both directions have same TCS and TCW.  This is accomodated by resolution to Issue 4824. and 3318.  A codeset service context must be sent before any international data may be sent, and if sent it must be sent in the first message sent on that connection.  Sending codeset service context more than once produces undefined behaviour.

Issue 4822: 11.3.2.1 Processing States (end of second paragraph and third paragraph (corba-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Hello, I think I've found inconsistency (or slips of the pen) in CORBA specification.

----------------------------------------- 11.3.2.1 Processing States (end of second paragraph and third paragraph):

For example, if a POA is in active state, it does not change state due to an activate operation. Such operations complete successfully with no special notice.

The only exception is the inactive state: a deactivate operation raises an exception just the same as every other attempted state change operation.

Probably incosistent to:

11.3.2.5 deactivate (first paragraph):

This operation changes the state of the POA manager to inactive. This operation has no affect on the POA manager's state if it is already in the inactive state. (no more explanation about AdapterInactive exception)

------------------------------------------ So, each POAManager state changing operation do nothing if it will not really change the state of the POAManager (activate call on already active POAManager, for example)

On the other hand:

Each POAManager state changing operation raises the AdapterInactive exception if issued while the POA manager is in the inactive state.

CORBA 2.5 specification was the first in which explanation about AdapterInactive exception during deactivate operation was removed (but third paragraph of 11.3.2.1 was not changed respectively).

Probably, the third paragraph of 11.3.2.1 should be removed.

Could you please provide some explanation about this problem (even if I am not right).

Resolution: see above
Revised Text: In formal/02-06-01 1. In section 11.3.2.5 in the IDL for the opeation "deactivate" remove the line that reads: raises(AdapterInactive); 2. In section 11.4 in the IDL for "deactivate" on page 11-49 remove the line that reads: raises(AdapterInactive); and append a ";" to the line immediately preceding it. 3. In the machine readable IDL for CORBA Core remove the corresponding raises clause in the IDL for POAManager. 4. In section 11.3.2.1 at the top of page 11-17 replace the paragraph that reads: "The only exception is the inactive state: a �deactivate� operation raises an exception just the same as every other attempted state change operation." by: "The only exception is the inactive state: a �deactivate� operation invoked in the inactive state may block under certain circumstances. See Section 11.3.2.5 for details."
Actions taken:
February 4, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: Deactivate when called in the "inactive" can never raise AdapterInactive as a resut of the resolution of issue 2911 in CORBA 2.5. Sice it has been illegal to raise this exception sinc 2.5, it should be safe to simply remov the AdapterInactive exception rom the raises clause of this operation. Any client (i.e. user code) that was designed to handle this exception will be unaffected by this change. Any POAManager that still raises this exception is non-compliant with CORBA 3.0 and hence needs tpo be fixed anyway.

Issue 4823: conflict between CORBA specification and C++ mapping (_this method (corba-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

I think that there is conflict between CORBA specification and C++ mapping (_this method). May be it relates both to CORBA specification and C++ mapping.

The Portable Object Adapter chapter of CORBA 2.6 specification 11.2.7 Implicit Activation (last paragraph - before Note)

If the POA has the MULTIPLE_ID policy, the servant_to_reference and servant_to_id operations will always perform implicit activation, even if the servant is already associated with an Object Id. The behavior of language mapping operations in the MULTIPLE_ID case is specified by the language mapping. For example, in C++, the _this() servant member function will not implicitly activate a MULTIPLE_ID servant if the invocation of _this() is immediately within the dynamic context of a request invocation directed by the POA to that servant; instead, it returns the object reference used to issue the request.

If I am right, author thinks that _this operation can be called on servant (related to POA with MULTIPLE_ID policy) multiple times (and it will not raise PortableServer::WrongPolicy exception).

But C++ mapping provides the following semantics of _this:

1.36.5 Skeleton Operations 3. ... This requires the POA with which the servant was activated to have been created with the UNIQUE_ID and RETAIN policies. If the POA was created with the MULTIPLE_ID or NON_RETAIN policies, the PortableServer::WrongPolicy exception is thrown.

Moreover CORBA specification provides the following semantics for servant_to_reference method: 11.3.8.20 servant_to_reference 2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and either the POA has the MULTIPLE_ID policy or the specified servant is not active, the servant is activated using a POA-generated Object Id and the Interface Id associated with the servant, and a corresponding object reference is returned.

If I am right, _this and servant_to_reference are very close by their semantics (sometimes _this can be implemented using servant_to_reference invocation on appropriate POA). That's why I think that C++ mapping conflicts with CORBA specification.

Could you please provide some explanation about this problem (even if I am not right).

Resolution: see above, close no change
Revised Text:
Actions taken:
February 4, 2002: received issue
December 11, 2002: closed issue

Discussion:

Resolution: The submitter simply misunderstood the text in section  1.36.5 of the C++ Language Mapping specification. There is no conflict between the C++ mapping and CORBA Core specification in this area. Close issue no change

Issue 4824: Wide string in reply before codeset was negotiated (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

Martin von Loewis posed the following rather intersting question in
comp.object.corba:

> Also notice that you *must* perform character set negotiation to
> communicate wstring values, unlike string values. You don't have to do
> that in the first message, though, but sometime before the first wide
> string is transmitted (I wonder what happens if the client does not
> negotiate a character set in its first message but the server wants to
> sent back a wstring response, e.g. inside an any).

The current codeset negotiation rules don't address this problem.

Resolution: see above
Revised Text: 1. In orbrev/02-02-01 Chapter 13 section 13.10.2.6 "Code Set Negotiation" insert the following paragraphs immediately following paragraph 2 of this section : "A codeset service context must be sent by the client (i.e., codeset negotiation must be completed) over a specific transport connection, before the client or the server may send international character values (i.e., char or string values with non Latin-1 encodings, or Wchar or Wstring values) in messages on that transport connection. If used, the codeset service context shall be sent before, or included with, the first request message sent on that transport connection. A request sent by the client before sending a codeset service context or not containing a service context itself, implies the client is using the default codesets on that connection (i.e., Latin-1 for string, and no ability to send Wstring on any message over that connection). Some existing Standard Service contexts have defined their encapsulated data content including International Character information, and have also specified that the codeset used is that which is negotiated using codeset negotiation. Such service contexts may not be sent until after the Codeset Service context is sent (i.e., in the GIOP message, the codeset service context must preceed any service context which depends on it being present.). Such Service Contexts that exists today are grandfathered in. Barring that exception, since all encapsulation definitions need to specify the Codeset used for their encodings it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it."
Actions taken:
February 12, 2002: received issue
December 11, 2002: closed issue

Discussion:

Resolution: There is consensus that the codeset service context must be 
sent before any international character encodings (i.e., strings with 
non Latin-1 encodings or the use of Wstring) are sent in any message on 
a transport connection. 

In addition, if a request is sent by the client before sending a codeset service context, 
that implies that the client is using the default codesets on that connection (i.e., Latin 1 
for string, and no ability to sent WSTRING on any message on that connection). 

Thus it is our interpretation that if any international characters are 
to be sent on a transport connection (i.e., strings with other than 
Latin-1 or Wstrings or Wchar) the Codeset service context must be 
included in the first message sent on that transport connection.

Issue 4825: IPv6 in corbaloc URLs (corba-rtf)

Click here for this issue's archive.
Source: Progress Software (Mr. Markus Heichel, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

is there any recent specification for IPv6 addresses in corbaloc
URLs? I could not find any hint.

Since it is not possible to unambiguously determine the meaning
of something like:

corbaloc::10:5::5:6/Hello

there should be an escape for the colons or a delimiter for
the IP address.

Resolution: see above
Revised Text: Changes to orbrev-02-02-01 13.6.10.1 (middle of page 13-25), new examples: corbaloc:iiop:192.168.14.25:555/NameService corbaloc::[1080::8:800:200C:417A]:88/DefaultEventChannel 13.6.10.1 (bottom of page 13-25), new definition of <host>: <host> = DNS_style_host_name | IPv4_address | "[" IPv6_address "]" 13.6.10.3 (middle of page 13-27), new definition of <host>: <host> = DNS_style_host_name | IPv4_address | "[" IPv6_address "]" 13.6.10.3 (top of page 13-28), replacement for ip_address: IPv4_address: numeric IPv4 address (dotted decimal notation) IPv6_address: numeric IPv6 address (colon separated hexadecimal or mixed hexadecimal/decimal notation as described in RFC 2373)
Actions taken:
February 12, 2002: received issue
December 11, 2002: closed issue

Discussion:

Resolution: 
Following RFC 2732 (IPv6 Literal Addresses in URL's) IPv6 
addresses should be enclosed in square brackets ([ ]). 
Though it would be easier for corbaloc parsers to allow square 
brackets also for hostnames and IPv4 addresses, this is probably 
not a good idea, since it would needlessly introduce a new type 
of non-IPv6 URL's, which is incompatible to the old spec. 

This will be incorporated into GIOP 1.4 upon the completion of the 
finalization process of the new Firewall specification.

Issue 4835: interaction of #pragma and typeid, typeprefix (corba-rtf)

Click here for this issue's archive.
Source: Memorial University of Newfoundland (Jeffrey Parsons, Ph.D., jeffreyp(at)mun.ca)
Nature: Uncategorized Issue
Severity:
Summary:

The CCM final draft has a section on repository identity
related declarations (3.15), and the rules for which trumps
which and what may be reset a second time are clear. Likewise
for the #pragma prefix, version and ID directives in section
10.7.5. But I'm still confused about how these two things
interact -- I haven't been able to find anywhere where this is
addressed.

Resolution: see above
Revised Text: In orbrev/02-02-01 make the following changes: 1. In section 3.15 append the following subsection: "3.15.3 Repository Id Conflict In IDL that contains both pragma prefix/ID declarations (as defined in section 10.7.5) and typeprefix/typeid declarations (as defined in sections 3.15.1 and 3.15.2), if the repository id for an IDL element computed by using pragmas and typeid/typeprefix are not identical it is an error. Note that this rule applies only when the repository id value computation uses explicitly declared values from declarations of both kinds. If the repository id computed using explicitly declared values of one kind conflicts with 9ne computed with implicit values of the other kind, the repository id based on explicitly declared values shall prevail." Actions taken: Incorporate changes and close issue
Actions taken:
February 18, 2002: received issue
February 20, 2002: moved from Components xTF to Core RTF
December 11, 2002: closed issue

Discussion:

Resolution: Clarify that in the rare cases where the same IDL entity lands up with conflicting repids using the #pragma method and the typeid/typrefix method, if both repid calculations are based on explicit declarations then it is an error, and if one of them is based on implicit values and the other based on explicit declaration the the repid obtained from the explicit declaration prevails.

Issue 4846: The whole negotiation thing should be removed, Unicode should be mandated (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

The whole negotiation  thing should be removed  from the spec and Unicode should be mandated"

Resolution: see above, close no change
Revised Text:
Actions taken:
February 27, 2002: received issue
December 11, 2002: closed issue

Discussion:

Resolution: Since there are several exisitng implementations of code set negotiation deployed in products, even an RFR could not be issued for doing this. So thisis way beyond anything that an RTF can do. Out of scope, close no change.

Issue 4850: Codeset negotiation requires clarification (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

We need to analyze this problem in pieces, because our discussions have been all
over
the map.

I have identified some legitimate needs for clarification though this discussion.
To help
we should target each discussion to be within one or more of these scenarios:


Lets look at a few typical scenarios a, b, and c:

a) server does not support international Strings

    Server cannot support Objects which use WSTRING in their IDL.  It does not use
codeset component in IORs, thus closing off Client�s use of international strings
on the connection.

We have a problem as to what to do with an ANY which may have WSRING in it for
this case (we could mandate the orb to consider this a failed negotiation and go
to the fallback of UTF-16).


b) Server supports only Latin 1 for string, and Unicode UCS-2 for Wstring

    Server places a Codeset component in the IOR with TCS-W indicated.

  There may be a need for clarification as to what Native Code Sets should be used
for Unicode.
- If we view the GIOP negotiation mechanism as transport oriented, then the Server
should put in UTF-16 as the Native Code set.in the IOR component
- If we view it as a presentation mechanism, then the Server might put UCS-2 as
Native code set, and UTF-16 as Conversion Code Set in the IOR component.

What can the server legally put in the IOR component for TCS-C in this case.  Is
Null allowed?  Should ISO 8859-1 be explicitly called out in the TCS-C portion of
the codeset component?

c) Server supports ShiftJISC for string and Unicode UCS-2 for Wstring

There might be an issue on whether the server may also place UTF-8 in as an
explicit Conversion code set in the TCS-C portion of the IOR component?

If the client does not support ShiftJISC, it should assert UTF-8 in the Codeset
Service context for the TCS-C.

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes: 1. Add the following to the end of Section 13.10.2.4 on Codeset component for IOR: "Non presence of a codeset component in an IOR means that: - the server and/or server-side ORB support only ISO 8850-1 for char/string, and - the server and/or server-side ORB don't support wchar/wstring Thus if client tries to send wchar or wstring data on an any type, and there is no codeset component in target server's IOR, the client-side ORB can raise an exception BAD_PARAM, with standard minor code set to X4850." 2. In Appendix A.5 add the followoing standard minor code for BAD_PARAM: BAD_PARAM X4850 "Character support limited to ISO 8859-1 for this object reference"
Actions taken:
February 28, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution:
We cannot change the rules regarding default codesets for backwards compatibility reasons
Consider the following case regarding TCS-C:
Client application: *existing* application using ISO Latin-1
Server application: new application using UTF-8
ORB: GIOP 1.4. Its default codeset for char/string is UTF-8, rather than Latin-1.

The Client application believes that ISO Latin-1 is the default codeset, and the Server application believes that UTF-8 is the default codeset.. The client ORB will transfers char/string data without codeset conversion. As the result, ISO Latin-1 data is processed as UTF-8 on the Server application. It causes serious bug when the Client application
sends 8bit data in char/string.

Consider another case regarding TCS-W. If we change the GIOP 1.4 rules for default TCS-W as suggested above, a missing Codeset Component in a 1.4 IOR would be equivalent to the server selecting UTF-16 as its native

Codeset for Wstring. If a GIOP 1.2 client receives a 1.4 IOR with no Codeset Component included, it will use the old negotiation rules, and will assume it cannot send Wstring data to that object.

Thus, we cannot change the rules for 1.4 to state that "no Codeset component in an IOR is equivalent to the fallback codeset".

In summary, an orb which may send parameters of type "Any" needs to put a codeset component into every IOR which is associated with a CORBA interface using an "Any" type.

Non presence of a codeset component in an IOR means that:
- the server and/or server-side ORB support only ISO 8850-1 for char/string, and
- the server and/or server-side ORB don't support wchar/wstring

Thus if client tries to send wchar or wstring data on an any type, and there is no codeset component in target server's IOR, the client-side ORB can raise an exception BAD_PARAM, with standar minor code set to XX.

New minor code
Exception minor Description
BAD_PARAM j Character support limited to ISO 8859-1 for this object reference

If we add this clarification, we don't need to define default codeset for wchar/wstring. The clarification is natural extension of following existing rules:

" ["13.10.2.6 Code Set Negotiation", page 13-47, CORBA 2.6] If a server's native char code set is not specified in the IOR multi-component profile, then it is considered to be ISO 8859-1 for backward compatibility. However, a server that supports interfaces that use wide character data is required to specify its native wchar code set; if one is not specified, then the client-side ORB raises exception INV_OBJREF, with standard minor code set to 1.

Similarly, if no char transmission code set is specified in the code set service context, then the char transmission code set is considered to be ISO 8859-1 for backward compatibility. If a client transmits wide character data and does not specify its wchar transmission code set in the service context, then the server-side ORB raises exception BAD_PARAM, with standard minor code set to 23."

Issue 4851: IDL inheritance issue (corba-rtf)

Click here for this issue's archive.
Source: AT&T (Dr. Duncan Grisby, )
Nature: Uncategorized Issue
Severity:
Summary:

The IDL specification is unclear about the names that can be used to
denote a base interface. Section 3.7.2 says

  "Each <scoped_name> in an <interface_inheritance_spec> must denote a
   previously defined interface."

but the word "denote" is not defined. In particular, is the following
legal?

  interface I { };
  typedef I J;
  interface K : J { };

There is real IDL in use in the world that assumes that inheriting
from a typedef is permitted. I therefore suggest re-wording the part
of section 3.7.2 to be

  "Each <scoped_name> in an <interface_inheritance_spec> must be the
   name of a previously defined interface or an alias to a previously
   defined interface."

A similar clarification is required in section 3.8.1.3, regarding
valuetype inheritance.

Resolution: Good point. Incorporate the clarification
Revised Text: Relative to document orbrev/02-02-01 1. In section 3.8.2 replace the sentence: "Each <scoped_name> in an <interface_inheritance_spec> must denote a previously defined interface." by "Each <scoped_name> in an <interface_inheritance_spec> must be the name of a previously defined interface or an alias to a previously defined interface." 2. In section 3.9.1.3 replace: "Each <value_name> and <interface_name> in a <value_inheritance_spec> must denote previously defined value type or interface." by: "Each <value_name> in a <value_inheritance_spec>must be the name of a previously defined value type or an alias to a previously defined value type. Each <interface_name> in a <value_inheritance_spec> must be the name of a previously defined interface or an alias to a previously defined interface."
Actions taken:
February 20, 2002: received issue
December 11, 2002: closed issue

Issue 4852: discussion on the create_union_tc operation could use some clarifications (corba-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The discussion on the create_union_tc operation could use some clarifications to prevent implementation errors. 

Firstly, in the previous paragraph of the spec it states that member names must be unique, but this is not true for unions: only the member (label) values need to be unique, not the member names. 

Secondly, there is a check that each member (label) type matches the discriminator type, but this will not hold for the default label, because according to the typecode spec (section 4.11.1) the default label type of a union will be octet so it will never match the discriminator type.

Resolution: There is indeed a defect that should be fixed by replacing a single sentence as shown below
Revised Text: In orbrev/02-02-01 in section 4.11.3 "Creating Type Codes" in the last paragraph at the bottom of page 4-65 Replace the sentence: "If incompatible TypeCode of label and discriminator is found, raise BAD_PARAM with standard minor code 19." by:: "If the TypeCode of a label is not equivalent to the TypeCode of the discriminator (other than the octet TypeCode to indicate the default label), the operation shall raise BAD_PARAM with standard minor code 19."
Actions taken:
February 20, 2002: received issue
December 11, 2002: closed issue

Issue 4870: definition of the TypeCode interface (4.11.1) (corba-rtf)

Click here for this issue's archive.
Source: PrismTech (Mr. Jason Courage, )
Nature: Clarification
Severity: Minor
Summary:

In the definition of the TypeCode interface (4.11.1) the length operation is defined as: 

// for tk_string, tk_sequence, and tk_array unsigned long length () raises (BadKind); 

The comment for this operation should include tk_wstring.

Resolution: Fixed editorially in CORBA 3.0, close no change
Revised Text:
Actions taken:
February 27, 2002: received issue
December 11, 2002: closed issue

Issue 4899: GIOP version in replies (corba-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

is it allowed to return a reply with a GIOP version number of 1.0 for a
request with GIOP version number 1.1 or 1.2, as long as the reply can be
correctly encoded with GIOP 1.0? IMO the spec is not clear about that, i.e.
it does not explicity state that the version numbers of request and reply
must match. This should be clarified.

Resolution: Clarify that the reply message must have the same GIOP version as the request message
Revised Text: In orbrev/02-02-01 append a bullet to the bullet list in section 15.2.3 "GIOP Message Transfer" which says (change from previous version in italics): " GIOP versions for requests and replies - The GIOP version of the message carrying a response to a request shall be the same as the GIOP version of the message carrying the request. This rule does not apply when the server is responding with a MessageError because it does not support the GIOP minor version in the request."
Actions taken:
March 1, 2002: received issue
December 11, 2002: closed issue

Issue 4945: IOR processing performance (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Collins, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

The overhead of processing TaggedComponents within an IOR becomes
significant when done many times, as in the case of J2EE implementations
where multiple request interceptors are used. IOR access and creation
performance could be improved by making better use of Java facilities to
provide access to an IOR's components without the overhead of CDR encoding,
and by recognising that many of the constituent parts of an IOR are
identical for all objects within an object adapter.

I would like to propose that we introduce a Java API for IOR, along the
following lines:-

An abstract model of an IOR could be defined as follows:
     an IOR has a type ID string, and contains TaggedProfile instances
     an IIOPProfile is a TaggedProfile
     an IIOPProfile is composed of an IIOPProfileTemplate and an object ID
     an IIOPProfileTemplate has an ObjectKeyTemplate, and contains
     TaggedComponents
     a TaggedComponent has an ID, and can be written to an OuputStream.
     a TaggedComponentFactory reads a TaggedComponent from an InputStream.

It should be possible to manipulate IOR TaggedProfiles and
IIOPProfileTemplate TaggedComponents using all of the facilities in the
Java collections framework.

Templates can be used to create IIOPProfile and ObjectKey because the basic
object adapter model for object creation is to establish all properties of
an IOR (except for type and object ID) when the object adapter is created.
This has been present for the POA essentially from the beginning, since
policies can only be passed to create_POA, and cannot be changed on an
existing POA. The Portable Interceptors work has also made this clear,
since the IOR interceptor runs only when an object adapter is created,
which is the only time that user code can add tagged components to an IOR.

TaggedComponent is a framework that may be extended to support application
defined TaggedComponents. It would be necessary to be able to register
TaggedComponentFactory instances with an ORB, in which case any IOR
unmarshalled by that ORB instance would use the registered
TaggedComponentFactory to unmarshal the TaggedComponent.

In order to use the IOR API, a method would be needed, probably on ORB,
to obtain an abstract IOR from an object reference.

Resolution:
Revised Text:
Actions taken:
March 6, 2002: received issue
February 24, 2003: moved to Core RTF
April 28, 2003: closed issue

Discussion:

Resolution: 
A long discussion in the RTF concluded that this issue was language indepedent, and so belonged in the core RTF (see core issue 5439).

Issue 4982: Inconsitent exception handling with find_POA & unknown_adapter (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

I think we totally messed up the resolution to issue 3740.  We added the
following text (circa CORBA 2.5) to 11.3.3.2:

"If unknown_adapter returns FALSE then find_POA raises
AdapterNonExistent. If
unknow_adapter raises any system exception then find_POA passes through
the
system exception it gets back from unknown_adapter."

[ There is also a typo in this text: "unkown_adapter".]

and this text to 11.3.8.3:

"If find_POA receives a system exception in response to a call to
unknown_adapter
on a POA, find_POA raises OBJ_ADAPTER system exception with standard
minor
code 1."

In the former, system exceptions raised by unknown_adapter are to be
passed through unchanged by find_POA.  In the latter, system exceptions
raised by unknown_adapter are to be replaced with OBJ_ADAPTER(1).

I think the former behavior is more correct, since it preserves the
original exception and doesn't throw away useful debugging information.

Resolution: The former (i.e. 11.3.3.2) is right. Change the latter to match the former
Revised Text: In orbrev/02-02-01 1. In section 11.3.4.2 "unknown_adapter" last para on page 11-23 change the single occurence of "unknow_adapter" to "unknown_adapter". 2. In section 11.3.9.2 "find_POA" on page 11-36 replace the last paragraph of the section by: "If find_POA receives a system exception in response to a call to unknown_adapter on a POA, then find_POA passes through the system exception it received from unknown_adapter."
Actions taken:
March 14, 2002: received issue
December 11, 2002: closed issue

Issue 5100: Valuetypes supporting forward declared interfaces (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Interfaces cannot inherit from forward declared interfaces and
valuetypes cannot inherit from forward declared valuetypes, but there is
no specific prohibition against a valuetype supporting a forward
declared interface.  There should be.

Proposed resolution:

Add the following sentence to section 3.8.4:

"It is illegal for a value type to support a forward-declared interface
whose definition has not yet been seen."

Resolution: Do as suggested
Revised Text: In orbrev/02-02-01 in section 3.9.4 "Value Forward Declaration" append the following paragraph to this section "It is illegal for a value type to support a forward-declared interface whose definition has not yet been seen."
Actions taken:
March 29, 2002: received issue
December 11, 2002: closed issue

Issue 5105: reference_to_servant (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

For reference_to_servant(), the spec says:


> This operation requires the RETAIN policy or the USE_DEFAULT_SERVANT
policy.
> If neither policy is present, the WrongPolicy exception is raised.
>
> If the POA has the RETAIN policy and the specified object is present in
the Active
> Object Map, this operation returns the servant associated with that object
in the Active
> Object Map. Otherwise, if the POA has the USE_DEFAULT_SERVANT policy and a
> default servant has been registered with the POA, this operation returns
the default
> servant. Otherwise, the ObjectNotActive exception is raised.


This says that, if I use USE_DEFAULT_SERVANT, reference_to_servant() always
and unconditionally returns the default servant.


This appears to be wrong. In particular, I can have USE_DEFAULT_SERVANT but
still add other servants explicitly to the AOM. If I do that, I can have,
for example,
servant X with object ID 1 as an explicitly activated servant, in addition
to the default
servant. In this situation, if I call reference_to_servant() with a
reference with object ID 1,
it should return servant X instead of the default servant.


The exact same reasoning applies to id_to_servant(), which also
unconditionally returns
the default servant with USE_DEFAULT_SERVANT().


I think we need to fix this -- it appears that the current words are simply
wrong.

Resolution: see above
Revised Text: In formal/02-06-01 in section 11.3.9.22 replace the first and the second paragrpah by: Table x.y below summarizes the behavior of this operation based on the RETAIN policy, the USE_DEFAULT_POLICY and the Object in question: RETAIN USE_DEFAULT_SERVANT Object Action Present Present In AOM Return Servant from AOM Present Absent In AOM Return Servant from AOM Present Present Not in AOM Return Default Servant Present Absent Not in AOM Raise ObjectNotActive Absent Present Return Default Servant Absent Absent Raise Wrong Policy
Actions taken:
April 2, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: Extensive discussions in the archive arrived at the conclusions that a clarification is in order. Clarify the behavior by representing all cases in a table

Issue 5214: Proposal for extension to CosNaming (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
Summary:

Since there doesn't appear to be a CosNaming mailing list this seems like as good a forum as any this discussion.


It has long struck me that the use of CosNaming for JNDI in J2EE applications creates a significant outage in being able to bind and retrieve objects that are not remote (see the EJB 2.0 spec for details). In JNDI you can bind pretty much anything that is Remote (aka an Object reference) or Serializable (aka a valuetype), however CosNaming only allows you to do the former.


One easy way to solve this would be to create a new NamingContext extension that allows one to bind and resolve Any's. This is in keeping with the Java-to-IDL spec's treatment of untyped Java objects and at the same time would not compromise non-java implementations. For JNDI it would only be necessary to support Any's containing:


1. Object references
2. valuetypes
3. valueboxes


An exception could be thrown for any other types. The candidate interface might look something like this:


module CosNaming {
  interface NamingContextAny : NamingContextExt {
    exception TypeNotSupported {};


    void    bind_any(in Name n, in any obj)
      raises (NotFound, CannotProceed,
              InvalidName, AlreadyBound, TypeNotSupported);


    void    rebind_any(in Name n, in any obj)
      raises(NotFound, CannotProceed, InvalidName, TypeNotSupported);


    any  resolve_any (in Name n)
      raises (NotFound, CannotProceed, InvalidName);


    any resolve_str_any(in StringName n)
      raises (NotFound, CannotProceed,
              InvalidName, AlreadyBound);
  };
};


The implementation of this interface in Java is trivial, although perhaps less so in other languages. Whether or not that matters is open to question.

Resolution:
Revised Text:
Actions taken:
April 10, 2002: received issue
April 11, 2012: Deferred to next RTF

Issue 5231: New issue: ForwardRequest(<local object>) (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity:
Summary:

The Portable Object Adapter and Portable Interceptors both are able to
raise a ForwardRequest exception to allow redirection to another
object.


What happens if the ForwardRequest is to a local object?


Is this even possible?


Should it be allowed?


I suggest we change the specification to make this illegal.

Resolution:
Revised Text:
Actions taken:
April 25, 2002: received issue
April 11, 2012: Deferred to next RTF

Issue 5232: Replace deprecated anonymous type declarations? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Now that we've deprecated defining types anonymously with bounded
strings, fixed, sequences and arrays, should we take the next step and
deliberately purge them from the Core IDL?


Here are the offenders that I've identified and the edits that should
occur:


In module CORBA:


1.  the service_detail member of struct ServiceDetail


    Fix:  Add 'typedef sequence<octet> ServiceDetailData' and replace
member type


2.  the service_options & service_details members of struct
ServiceInformation


    Fix:  Add 'typedef sequence<ServiceOption> ServiceOptionSeq' and
              'typedef sequence<ServiceDetail> ServiceDetailSeq' and replace
          member type


In module GIOP:


3.  the magic member in the various struct MessageHeader_1_X types


    Fix:  Add 'typedef char Magic[4]' and replace member types


4.  the reserved member in the struct RequestHeader_1_1 and
RequestHeader_1_2 types


    Fix:  Add 'typedef octet RequestReserved[3]' and replace member
types


5.  the object_key member in various Header structures


    Fix:  replace member types with IOP::ObjectKey


In module IIOP:


6.  the object_key member in various struct ProfileBody_1_X types


    Fix:  replace member types with IOP::ObjectKey


7.  the components member in struct ProfileBody_1_1


    Fix:  replace member type with IOP::ComponentSeq


In module IOP:


8.  the profile_data member in struct TaggedProfile


    Fix:  Add 'typedef sequence<octet> ProfileData' and replace member
type


9.  the profiles member in struct IOR


    Fix:  Add 'typedef sequence<TaggedProfile> TaggedProfileSeq' and
replace
          member type


10.  the component_data member in struct TaggedComponent


    Fix:  Add 'typedef sequence<octet> ComponentData' and replace member
type


11.  the context_data in struct ServiceContext


    Fix:  Add 'typedef sequence<octet> ContextData' and replace member
type


also to complete fixes for cases 5, 6, and 20:


    Fix:  Add 'typedef sequence<octet> ObjectKey' and
              'typedef sequence<TaggedComponent> TaggedComponentList'


In module MessageRouting:


12.  the body member in struct MessageBody


    Fix:  Add 'typedef sequence<octet> BodyData' and replace member type


13.  the object_key member in struct RequestMessage


    Fix:  replace member type with 'IOP::ObjectKey'


14.  the reserved member in struct RequestMessage


    Fix:  replace member type with 'GIOP::RequestReserved'


15.  the typed_excep_holder_repids in struct ReplyDestination


    Fix:  replace member type with 'CORBA::RepositoryIdSeq'


In module Messaging:


16.  the pvalue member in struct PolicyValue


    Fix:  Add 'typedef sequence<octet> PolicyData' and replace member
type


17.  the marshaled_exception member in valuetype ExceptionHolder


    Fix:  Add 'typedef sequence<octet> MarshalledException' and replace
member
          type


In module CONV_FRAME:


18.  the conversion_code_sets member in struct CodeSetComponent


    Fix:  Add 'typedef sequence<CodeSetId> CodeSetIdSeq' and replace
member type


In module DCE_CIOP:


19.  the object_key member in struct InvokeRequestHeader and struct
     LocateRequestHeader


    Fix:  replace member type with 'IOP::ObjectKey'


In module DCE_CIOPSecurity.idl:


20.  the components member in struct DCESecurityMechanismInfo


    Fix:  replace member type with 'IOP::TaggedComponentList'

Resolution: see above
Revised Text: In formal/02-06-01 as well as in the corresponding IDL text files make the ollowing changes: In module CORBA: 1. the service_detail member of struct ServiceDetail Fix: Add 'typedef CORBA::OctetSeq ServiceDetailData' and replace member type 2. the service_options & service_details members of struct ServiceInformation Fix: Add 'typedef sequence<ServiceOption> ServiceOptionSeq' and 'typedef sequence<ServiceDetail> ServiceDetailSeq' and replace member type In module GIOP: 3. the magic member in the various struct MessageHeader_1_X types Fix: Add 'typedef char Magicn[4]' and replace member types 4. the reserved member in the struct RequestHeader_1_1 and RequestHeader_1_2 types Fix: Add 'typedef octet RequestReserved[3]' and replace member types 5. the object_key member in various Header structures Fix: replace member types with IOP::ObjectKey In module IIOP: 6. the object_key member in various struct ProfileBody_1_X types Fix: replace member types with IOP::ObjectKey 7. the components member in struct ProfileBody_1_1 Fix: replace member type with IOP::TaggedComponentSeq In module IOP: 8. the profile_data member in struct TaggedProfile Fix: Add 'typedef CORBA::OctetSeq ProfileData' and replace member type 9. the profiles member in struct IOR Fix: replace declaration of "member" using TaggedProfileSeq instead of the present sequence<TaggedProfile> 10. the component_data member in struct TaggedComponent Fix: Add 'typedef CORBA::OctetSeq ComponentData' and replace member type 11. the context_data in struct ServiceContext Fix: Add 'typedef CORBA::OctetSeq ContextData' and replace member type also to complete fixes for cases 5, and 6: Fix: Add 'typedef CORBA::OctetSeq ObjectKey' _____________________________________________________________________ In module MessageRouting: 12. the body member in struct MessageBody Fix: Add 'typedef CORBA::OctetSeq BodyData' and replace member type 13. the object_key member in struct RequestMessage Fix: replace member type with 'IOP::ObjectKey' 14. the reserved member in struct RequestMessage Fix: replace member type with 'GIOP::RequestReserved' In module Messaging: 15. the pvalue member in struct PolicyValue Fix: Add 'typedef CORBA::OctetSeq PolicyData' and replace member type 16. the marshaled_exception member in valuetype ExceptionHolder Fix: Add 'typedef CORBA::OctetSeq MarshaledException' and replace member type In module CONV_FRAME: 17. the conversion_code_sets member in struct CodeSetComponent Fix: Add 'typedef sequence<CodeSetId> CodeSetIdSeq' and replace member type In module DCE_CIOP: 18. the object_key member in struct InvokeRequestHeader and struct LocateRequestHeader Fix: replace member type with 'IOP::ObjectKey' In module DCE_CIOPSecurity.idl:** 19. the components member in struct DCESecurityMechanismInfo Fix: replace member type with 'IOP::TaggedComponentSeq'
Actions taken:
April 30, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: Make the changes as suggested in the archive. 
There should be no on the wire CDR encoding differences.  However, there would be differences in the Repository and TypeCode information of the affected types, which could possibly affect clients using the DII or otherwise storing these types in an any if they rely on TypeCode equal(), rather than equivalent().

Issue 5266: ForwardRequest is impossible to detect in clients (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
Summary:

REQUIREMENT

To be able to use interceptors, and in particular ForwardRequest, in a client to perform active, per-request, load-balancing.

PROBLEM

It is not possible to detect in an interceptor whether ForwardRequest has previously been thrown for the same client request. Thus it is possible for a client to go into an infinite loop throwing ForwardRequest.

DISCUSSION

The basic problem is that although for a single client request the request-scoped PICurrent is shared across across interceptor invocations - even when ForwardRequest is thrown - it is not possible to *modify* this information in an interceptor to indicate to a future invocation that the invocation has been seen. The two relevant parts of the spec here are:

21.3.6.5

For retries, depending on the policies in effect, a new request may or may not follow
when a retry has been indicated. If a new request does follow, while this request is a
new request, with respect to Interceptors, there is one point of correlation between the
original request and the retry: because control has not returned to the client, the request
scoped PortableInterceptor::Current for both the original request and the retrying
request is the same (see Chapter 21, Portable Interceptors on page 21-32).

21.4.2

Before an invocation is made, PICurrent is obtained via a call to
ORB::resolve_initial_references ("PICurrent")
From within the interception points, the data on PICurrent that has moved from the
thread scope to the request scope is available via the get_slot operation on the
RequestInfo object. A PICurrent can still be obtained via
resolve_initial_references, but that is the Interceptor's thread scope PICurrent.
See section 21.4.4.4, Request Scope vs Thread Scope on page 21-36 for a detailed
discussion of the scope of PICurrent.

Thus modifications to the thread's PICurrent are lost on retries and modifications to the request's PICurrent are not possible.

PROPOSED RESOLUTION

I have made several different attempts at coming up with a portable way of solving this problem without changing the spec, but have failed. It seems to me that it really should be possible for the interceptor to know that a retry is in effect and I can think of a number of different solutions to this:

1. add:
void set_slot (in SlotId id, in any data) raises (InvalidSlot);
to RequestInfo. This would allow interceptors to transfer information between invokes of the same client request and thus a retry could be detected.

2. Add a new function to RequestInfo to indicate that a forward is in operation. The minimalist fix here would be to allow forward_reference() to be accessed in send_request() as well as in receive_other(). i.e. returning the object from the previous ForwardRequest if that has been thrown.

I'm ambivalent about which of these is best but for the sake of simplicity I'm going to plump for (1) because this is already allowed in ServerRequestInfo.

So:

- Change the IDL in 21.3.12 to include
void set_slot (in SlotId id, in any data) raises (InvalidSlot);

- After 21.3.12.12 move in the text from 21.3.14.6

- Change the IDL in 21.3.14 to remove set_slot()

Resolution:
Revised Text:
Actions taken:
May 2, 2002: received issue
April 11, 2012: Deferred to next RTF

Issue 5270: Codeset negotiation and the CODESET_INCOMPATIBLE exception (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

1.  There's no minor code assigned to the use of CODESET_INCOMPATIBLE
for a failed codeset negotiation in 13.10.2.6.


2.  There's no indication of what a server should do if the client
delivers a codeset via a CodeSetContext that the server does not support
as a transmission codeset).  This isn't likely to happen, but we ought
to close the hole.  I propose that we have the server raise
CODESET_INCOMPATIBLE (with a different minor code from 1) in this case
too.


3.  Would it be a good idea for us to include recommendations on how to
change a persistent server's native codeset while remaining backwards
compatible with existing IORs floating around the world with obsolete
CodeSetComponent data?  Or is it too obvious?  (Just make sure the new
server advertises (or at least continues to support) the old native
codeset as a transmission codeset.)

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes: 1. In the appendix add the following new minor codes for CODESET_INCOMPATIBLE: 5270X1 Codeset negotiation failed. 5270X2 Codeset delivered in CodeSetContext is not supported by server as transmission codeset. 2. In section 13.10.2.6 in the last para of page 13-48 replace the phrase: "CODESET_INCOMPATIBLE exception is raised" by: "CODESET_INCOMPATIBLE exception with standard minor code 5270X1 is raised. 3. In section 13.10.2.6, on page 13-49 immediately following the paragraph that begins: "Similarly, if no char transmission code set is specified in the code set service context,....." insert the following paragraph: "If the client delivers a codeset via a CodeSetContext that the server does not support as a transmission codeset then the server returns a CODESET_INCOMPATIBLE exception with the standard minor code 5270X2."
Actions taken:
May 7, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: 
1. Add a new minor code to CODESET_INCOMPATIBLE to cover this case and document in section 13.10.2.6. 
2. Add a new minor code to CODESET_INCOMPATIBLE for this case and find a suitable place in Section 13.10 or one of its subsections to document this. 

3. Dont' do anything about his. This details belongs in a textbook/user guide, not the standard specification, since there is no reason to make this the normative way of doing this.

Issue 5296: Avoiding Interceptors for colocated method requests (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Collins, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

Could we please discuss the possibility of introducing a performance
optimization for Interceptors.


There may be considerable overhead involved in invoking Portable
Interceptors. While some interceptors need to be invoked when caller
and target are colocated (the locally optimized path), many do not.
I think it would be useful to introduce a mechanism to allow this
unnecessary overhead to be avoided for interceptors that do not need
to be invoked on the colocated path, for example by adding a
'run_local' parameter to the add_xxx_request_interceptor methods of
the ORBInitInfo interface.


I realise that this issue was touched upon during discussion of interop
issue 4291 but, at the time, the focus was on getting the interceptor
mechanism to work correctly in the colocated case; the performance
aspect of the issue seems to have been lost.

Resolution: Provide means for the optimization as shown below
Revised Text: In formal/02-06-01 make the following changes: 1. Add the following section between sections 21.6 and 21.7 (Labelled 21.x so that references to 21.7 refer to the existing 21.7) 21.x Interceptor Policy Objects An Interceptor's behaviour may itself be modified by one or more Interceptor Policies. These Policy objects are created using a call to ORB::create_policy and are associated with an Interceptor during registration (see Section 21.7.2, ORBInitInfo Interface). All Policy interfaces defined in this section are local. The ORB can be accesed via the implicit get_orb operation of ORBInitInfo. 21.x.1 ProcessingMode Policy Request interceptor performance may be improved by applying a ProcessingMode policy to limit the conditions under which the interceptor shall be invoked. The following values can be supplied. . LOCAL_AND_REMOTE - Request interceptors with this policy are invoked whether the method is executed locally or remotely. This is the default behaviour if no ProcessingMode Policy is associated with a request Interceptor. . REMOTE_ONLY - Request interceptors with this policy are not invoked when the method is executed using the optimized collocated path. . LOCAL_ONLY - Request interceptors with this policy are only invoked when the method is executed using the optimized collocated path. module PortableInterceptor { typedef short ProcessingMode; const ProcessingMode LOCAL_AND_REMOTE = 0; const ProcessingMode REMOTE_ONLY = 1; const ProcessingMode LOCAL_ONLY = 2; // ProcessingMode Policy (default = LOCAL_AND_REMOTE) const CORBA::PolicyType PROCESSING_MODE_POLICY_TYPE = p // assigned by OMG; local interface ProcessingModePolicy : CORBA::Policy { readonly attribute ProcessingMode processing_mode; }; }; also append the IDL above to the consolidated IDL for module PortableInterceptor in section 21.10.3. 2. In section 21.7.2 and in section 21.10.3 page 21-65 Insert the following after the declaration of the ORBInitInfo Interface (Note: 21.7.2 becomes 21.9.2 and 21.10.3 becomes 21.12.3 in the revised chapter) local interface ORBInitInfo_3_1 : ORBInitInfo { void add_client_request_interceptor_with_policy( in ClientRequestInterceptor interceptor, in CORBA::PolicyList policies) raises (DuplicateName, CORBA::PolicyError); void add_server_request_interceptor_with_policy( in ServerRequestInterceptor interceptor, in CORBA::PolicyList policies) raises (DuplicateName, CORBA::PolicyError); void add_ior_interceptor_with_policy( in IORInterceptor interceptor, in CORBA::PolicyList policies) raises (DuplicateName, CORBA::PolicyError); }; 3. Add the following after section 21.7.2.10 [21.9.2.10] and move sections 21.7.2.11 through 21.7.2.12 to become new sections 21.9.2.14 through 21.9.2.15. 21.9.2.11 add_client_request_interceptor_with_policy This form of registration allows interceptor behavior to be modified by one or more Policies. The policy objects are effectively copied before the operation returns, so the caller is free to destroy them while the Interceptor is in use. CORBA::PolicyError is raised if one or more of the policies is invalid. If a server-side request Interceptor has already been registered with this Interceptor�s name, DuplicateName is raised. interceptor the client request interceptor to be added policies A sequence of interceptor policies to be used to control the behavior of the interceptor being registered. 21.9.2.12 add_server_request_interceptor_with_policy This form of registration allows interceptor behavior to be modified by one or more Policies. The policy objects are effectively copied before the operation returns, so the caller is free to destroy them while the Interceptor is in use. CORBA::PolicyError is raised if one or more of the policies is invalid. If a server-side request Interceptor has already been registered with this Interceptor�s name, DuplicateName is raised. interceptor the serveer request interceotor to be added policies A sequence of interceptor policies to be used to control the behavior of the interceptor being registered. 21.9.2.13 add_ior_interceptor_with_policy This form of registration allows interceptor behavior to be modified by one or more Policies. The policy objects are effectively copied before the operation returns, so the caller is free to destroy them while the Interceptor is in use. CORBA::PolicyError is raised if one or more of the policies is invalid. If a server-side request Interceptor has already been registered with this Interceptor�s name, DuplicateName is raised. interceptor the ior interceptor to be added policies A sequence of interceptor policies to be used to control the behavior of the interceptor being registered.
Actions taken:
May 13, 2002: received issue
April 28, 2003: closed issue

Issue 5322: DATA_CONVERSION minor code 2 not listed in Table 4-3 (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

It is used by RealTime CORBA as documented in 24.17.2

Resolution: non issue...editorial, issue withdrawn
Revised Text:
Actions taken:
May 23, 2002: received issue
May 23, 2002: closed issue

Issue 5327: pragma prefix syntax (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

suppose the following [pseudo-]idl:


#pragma prefix "2abc.def"


module xyz {
    interface q {...};
};


It would generate a Java class 'q' within package 'def.2abc.xyz'.
The package name '2abc' is not that popular with the java compiler
since it starts with a digit.


 From what I could see in CORBA 2.6.1, identifiers have to start
with a character (or at least not a digit). So, I guess that the
prefix pragma is erroneous here, right ?


The OpenORB IDL parser 1.2.0 did though generate Java code without any
complaints, which confuses me ...

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes: 1. In section 10.7.5.2 insert the following paragraph immediately following the second line of the section, the line that reads: #pragma prefix �<string>� Para to be inserted: "Since the "prefix" pragma applies to Repositry Ids of the IDL format, the <string> above shall be a list of one or more identifiers, separated by the �/� characters. These identifiers are arbitrarily long sequences of alphabetic, digit, underscore (�_�), hyphen (�-�), and period (�.�) characters. The string shall not contain a trailing slash ("/") and it shall not begin with the characters underscore ("_"), hyphen ("-") or period (".")." 2. In section 3.15.2 insert the following imediately preceding the sentence "To elaborate:" in the last paragraph of page 3-57 that begins "The specified string....": "The specified string shall be a list of one or more identifiers, separated by the �/� characters. These identifiers are arbitrarily long sequences of alphabetic, digit, underscore (�_�), hyphen (�-�), and period (�.�) characters. The string shall not contain a trailing slash ("/"), and it shall not begin with the characters underscore ("_"), hyphen ("-") or period (".")." 3. In section 10.7.1 append the following to item 2 in this section: "The second component shall not contain a trailing slash ("/") and it shall not begin with the characters underscore ("_"), hyphen ("-") or period (".")."
Actions taken:
May 25, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: This is more of a language mapping issue. Repository Ids do not have any requirement to be of the same shape as a valid IDL identifier. It would be kind of hard to have GUIDs as RepId if that were the case.
Afterall 12345.com seems to be a perfectly good domain name as is 2ab.com. I don't see why these perfectly valid domain names should be disallowed because the Java language mapping is unable to deal with them.

The Core aspect of this issue is already handled almost adequately as far as the pragmas are concerned, in Section 10.7.1 (formal/02-06-01) for OMG IDL type RepIds, which are the ones of primary concern here, since that is the one that gets mapped to package names in Java. Since prefix and version pragmas and typeprefix applies only to IDL RepIds as stated in 10.7.5, the Prefix pragma is automatically taken care of. But we should add clarifying text to section 10.7.5.2 emphasizing that the prefix specified must abide by rule 2 of section 10.7.1. That should take care of that.

Section 10.7.5.1 for ID pragma says that the only valid IDs are those that conform to the forms described in 10.7, which includes all of the restrictions for IDL type etc. This is fully overed as far as this pragma is concerned.

As for sections 3.15.1 and 3.15.2 which describe the typeprefix and typeid constructs I think all that needs to be done is to state that the
specified prefix must abide by rule 2 of section 10.7.1.

Incorporate some clarifying text as identified below and raise an issue with Java RTF to fix the primary problem in the Java language mapping (Issue raised).

Issue 5329: Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent (corba-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The minor codes in the specified NO_IMPLEMENT exceptions are incomplete/inconsistent. 

In particular: 

1) In 3.7.6.1 "Semantics", minor code 3 is mentioned for DII support pseudo-operations, but 3.7.6.2 seems to specify minor code 4 for these (though it uses different wording). 

2) 3.7.6.2 "LocalObject" doesn't specify the minor code for "is_a" etc, though presumably it should be 3 as in 3.7.6.2. 

3) The explanation for minor code 3 is "Unable to use any profile in IOR." but that isn't particular clear for local objects, which probably don't have an IOR at all.

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes: 1. In appendix A add a new minor code X5329 for NO_IMPLEMENT saying "Operation not implemented in local object". 2. In section 4.3.13 in the first bullet replace the phrase "minor code 3" by "minor code X5329".
Actions taken:
May 28, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: The minor code 3 for is_a etc. is indeed quite odd. Best fix would be to define a new minor code of NO_IMPLEMENT which says something like "Operation not implemeneted in Local object" or some such.

Issue 5333: OpaqueValue/add_arg never mapped to languages (corba-rtf)

Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Bill Beckwith, bill.beckwith(at)ois.com)
Nature: Uncategorized Issue
Severity:
Summary:

As far as I can tell, OpaqueValue, a new native type
introduced in Issue 2162 (void * in DII Chapter) for
add_arg, was never documented in any of the language
mappings.


Also, the len parameter of add_arg is underspecified.

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes: In section 7.2.2 insert the following after the first sentence of the second paragraph: ""len" is the length in octets, of the thing that the "value" parameter refers to."
Actions taken:
June 3, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: 
1. The intention was that the language mapping should remain exactly what it was for the original "void *". If the language mappings had 
provided a mapping for the PIDL as they are supposed to, then the mapped version of this PIDL for all languages should remain quite unchanged and this should be a non-issue, and indeed is for every language binding except for the following. 

There is a potential problem in the C language mapping, but then there is a huge problem of the relatively complete lack of precise specification of PIDL mappings in the C language binding, So raise an issue for the C Language Binding RTF pointing this out. 

The Python and Smalltalk mapping may require some clarification, although the fact remains that the end result is no change in the actual binding. So raise issue for those RTFs too. 

2. Considering that the original thing was "void *", I suspect that len was meant to state the length of the "value" in octets. This should be 
stated explicitly  in section 7.2.2.

Issue 5430: Serious backward compatibility issue in the PI (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

I have recently realized that there is a serious backward compatibility
issue in the PI changes introduced by the Object Reference Template.
The problem is in the IORInterceptor.  The original PI specification 
defined only the establish_components method on IORInterceptor.
ORT added 3 new methods to this interface: components_established,
adapter_state_changed, and adapter_manager_state_changed.


The compatibility problem arises with the Java mapping.  Prior to
the CORBA 3.0 IDL to Java mapping, local interfaces were simply
mapped to interfaces.  The mapping for the CORBA 3.0 IORInterceptor 
is then simply:


public interface IORInterceptorOperations  
  extends org.omg.PortableInterceptor.InterceptorOperations
{
  void establish_components (org.omg.PortableInterceptor.IORInfo info);


  void components_established (org.omg.PortableInterceptor.IORInfo info);


  void adapter_manager_state_changed (int id, short state);


  void adapter_state_changed (
    org.omg.PortableInterceptor.ObjectReferenceTemplate[] templates, short state);
} 


public interface IORInterceptor extends IORInterceptorOperations, 
    org.omg.PortableInterceptor.Interceptor, org.omg.CORBA.portable.IDLEntity
{
} 


Any client of PI that implements IORInterceptor from CORBA 2.6 defines only the
establish_components method, so that client will fail on a CORBA 3.0 version of PI.


I propose the following changes to the draft CORBA 3.0 spec to fix this problem:


In Section 21.5.4, replace the definition of IORInterceptor with:


local interface IORInterceptor : Interceptor {
    void establish_components( in IORInfo info ) ;
} ;


local interface IORInterceptor_3_0 : IORInterceptor {
    void components_established( in IORInfo info ) ;


    void adapter_manager_state_changed( in AdapterManagerId id, 
        in AdapterState state ) ;


    void adapter_state_changed( in ObjectReferenceTemplateSeq templates,
        in AdapterState state ) ;
} ;


Replace the first sentence in 21.5.4.2 with:


After all of the establish_components methods have been called, the 
components_established methods are called on all registered IORInterceptor_3_0
instances.


Replace the first sentence in 21.5.4.3 with:


Any time the state of an adapter manager changes, the adapter_manager_state_changed
method is invoked on all registered IORInterceptor_3_0 instances.


Replace the first sentence in 21.5.4.4 with:


Adapter state changes unrelated to adapter manager state changes are reported by
invoking the adapter_state_changed method on all registered IORInterceptor_3_0 
instances.

Resolution: Resolve urgently as suggested
Revised Text: This issue has been declared urgent. Revised Text: All changes relative to Draft CORBA 3.0 Chapters as in ptc/02-06-10 1. In Section 21.5.4, replace the definition of IORInterceptor with: local interface IORInterceptor : Interceptor { void establish_components( in IORInfo info ) ; } ; local interface IORInterceptor_3_0 : IORInterceptor { void components_established( in IORInfo info ) ; void adapter_manager_state_changed( in AdapterManagerId id, in AdapterState state ) ; void adapter_state_changed( in ObjectReferenceTemplateSeq templates, in AdapterState state ) ; } ; 2. Replace the first sentence in 21.5.4.2 with: "After all of the establish_components methods have been called, the components_established methods are called on all registered IORInterceptor_3_0 instances." 3. Replace the first sentence in 21.5.4.3 with: "Any time the state of an adapter manager changes, the adapter_manager_state_changed method is invoked on all registered IORInterceptor_3_0 instances." 4. Replace the first sentence in 21.5.4.4 with: "Adapter state changes unrelated to adapter manager state changes are reported by invoking the adapter_state_changed method on all registered IORInterceptor_3_0 instances."
Actions taken:
June 14, 2002: received issue
April 28, 2003: closed issue

Discussion:

Issue 5439: processing TaggedComponents within an IOR (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Ms. Anne E. Collins, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

The overhead of processing TaggedComponents within an IOR becomes
significant when done many times, as in the case of J2EE
implementations where multiple interceptors are used.


The definition of IORs in the IOP module is intended to support
transmission and interoperability, rather than efficient access to the
local, ORB specific, internal structure.


I would like to propose that an abstract model of an IOR is introduced
which recognises that many of the constituent parts of IOR profiles are
identical for different objects, along the following lines:-
   - an IOR has a type ID string, and contains TaggedProfile instances
   - a TaggedProfile has an ID and data
   - an IIOPProfile is a TaggedProfile; it is composed of an
     IIOPProfileTemplate and an object ID.
   - an IIOPProfileTemplate has IIOP addressing information, and contains
     TaggedComponents.
   - a TaggedComponent has an ID and data
   - a TaggedComponentFactory creates a TaggedComponent
   - a TaggedProfileFactory creates a TaggedProfile


with corresponding IDL definitions that allow the language bindings
to optimise conversion between transmission and internal IOR formats
to provide a performant and natural interface for IOR access.


Rationale:
In Java, for example, it should be possible to manipulate IOR
TaggedProfiles and IIOPProfileTemplate TaggedComponents using the
facilities of the Java collections framework, or at least some
equivalent facility that is a natural Java idiom.


Templates can be used to create IIOPProfiles because the basic object
adapter model for object creation is to establish many of the properties
of an IOR when the object adapter is created.


- This has been present for the POA essentially from the beginning, since
  policies can only be passed to create_POA, and cannot be changed on an
  existing POA.
- The Portable Interceptors work has also made this clear, since the IOR
  interceptor establish_components method, which is the only time that
  user code can add tagged components to an IOR, is only guaranteed to
  be called once for each distinct set of server policies i.e need only
  be run when an object adapter is created.
- It is also likely that more than one object within an adapter will
  map to a TCP endpoint.


TaggedProfile and TaggedComponent are intended as frameworks that may be
extended to support application defined tagged profiles and components.
To support this it is necessary to be able to register TaggedProfile and
TaggedComponentFactory instances with an ORB, in which case any IOR
unmarshalled by that ORB instance will use the registered factory
to unmarshal the tagged profile or component.



Since there has already been quite a bit of discussion about this in the
Java RTF, here is a proposal for review:-



Proposal:


- add the following sections after the IOR Interceptor Overview:-



21.5.2 An Abstract Model for IORs


To support efficient access to IORs, avoiding repeated marshaling and
demarshaling of IOR components, it is helpful to have an abstract model
of the, ORB specific, local representation of an IOR.


Recognising that many of the constituent parts of IOR profiles are
identical for different objects allows the following model to be
defined:-
   - an IOR has a type ID string, and contains TaggedProfile instances
   - a TaggedProfile has an ID and data
   - an IIOPProfile is a TaggedProfile; it is composed of an
     IIOPProfileTemplate and an object ID.
   - an IIOPProfileTemplate has IIOP addressing information, and contains
     TaggedComponents.
   - a TaggedComponent has an ID and data
   - a TaggedComponentFactory creates a TaggedComponent
   - a TaggedProfileFactory creates a TaggedProfile



21.5.3 Local IOR Interfaces


The following interfaces provide access to the data within a local IOR
using this model.


TaggedProfile and TaggedComponent are generic interfaces. Users of the ORB
may create implementations of them. Corresponding factories may be
registered with the IORFactory.


The IORFactory is obtained through a call to
ORB::resolve_initial_references ("IORFactory") and may also be used to
obtain an IOR for an Object.


An ORB must return all tagged profiles in an IOR through the IOR
getProfiles operations. The ProfileIterator interface allows a client
to iterate through the TaggedProfiles using the next operation.
Those profiles whose ids have a registered TaggedProfileFactory will
be made available in the form returned by the registered factory's
TaggedProfileFactory create operation, which must return a subtype of
TaggedProfile.


An ORB will provide a TaggedProfileFactory implementation for the
IIOPProfile.


Profiles with ids for which no TaggedProfileFactory has been registered
will be made available as instances of a generic ORB implementation of
TaggedProfile.



Similarly, an ORB must return all tagged components in an IIOP profile
through the IIOPProfile().getTemplate().getComponents() operations.
The ComponentIterator interface allows a client to iterate through the
TaggedComponents using the next operation.
Those components whose ids have a registered TaggedComponentFactory
will be made available in the form returned by the registered factory's
TaggedComponentFactory create operation, which must return a subtype of
TaggedComponent.
Components with ids for which no TaggedComponentFactory has been
registered will be made available as instances of a generic ORB
implementation of TaggedComponent.



module PortableInterceptor {


  local interface TaggedComponent {
      readonly attribute IOP::ComponentId component_id;
      readonly attribute CORBA::OctetSeq component_data;
      IOP::TaggedComponent convert();
  };


  local interface ComponentIterator {
      TaggedComponent next();
      boolean has_next();
  };


  local interface TaggedProfile {
      readonly attribute IOP::ProfileId profile_id;
      readonly attribute CORBA::OctetSeq profile_data;
      IOP::TaggedProfile convert();
  };


  local interface ProfileIterator {
      TaggedProfile next();
      boolean has_next();
  };


  local interface IOR {
      readonly attribute string type_id;
      ProfileIterator get_profiles ();
      ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id);
  };


  local interface IIOPProfileTemplate {
      readonly attribute IIOP::Version iiop_version;
      readonly attribute string host;
      readonly attribute unsigned short port;
      ComponentIterator get_components();
      ComponentIterator get_components_by_id (in IOP::ComponentId id);
  };


  local interface IIOPProfile:TaggedProfile {
      readonly attribute CORBA::OctetSeq  object_key;
      readonly attribute IIOPProfileTemplate profile_template;
  };


  local interface TaggedComponentFactory {


      readonly attribute IOP::ComponentId factory_id;
      TaggedComponent create_tagged_component
         (in CORBA::OctetSeq component_data);
  };


  local interface TaggedProfileFactory {


      readonly attribute IOP::ProfileId factory_id;
      TaggedProfile create_tagged_profile
         (in CORBA::OctetSeq profile_data);
  };


  local interface IORFactory {


    IOR  create_ior (in Object obj);
    void register_tagged_profile_factory (in TaggedProfileFactory tpf);
    void register_tagged_component_factory (in TaggedComponentFactory tcf);
  };


};



21.5.3.1 IOR Factory Interface


   create_ior
   Return an IOR relating to the given Object.


   If create_ior is invoked when the object reference is not bound,
   standard system exception BAD_INV_ORDER with minor code n will be
   raised.


   register_tagged_profile_factory
   Register a TaggedProfileFactory to create TaggedProfiles with the id
   returned by the given factory's getId method. If a TaggedProfileFactory
   already exists for the given id, standard system exception
   BAD_INV_ORDER is raised with a standard minor code of n+1.
   Instances of this interface may be defined by users to support custom
   tagged profiles.


   register_tagged_component_factory
   Register a TaggedComponentFactory to read TaggedComponents with the id
   returned by the given factory's getId method. If a
   TaggedComponentFactory already exists for the given id, standard system
   exception BAD_INV_ORDER is raised with a standard minor code of n+2.
   Instances of this interface may be defined by users to support custom
   tagged components.


21.5.3.2 IOR Interface


   This interface gives access to a local representation of an
   IOP::IOR.


   type_id
   The type id string from the IOR.


   get_profiles
   Returns an iterator over the TaggedProfiles within the IOR.


   get_profiles_by_id
   Returns an iterator over the TaggedProfiles with the given
   Profileid.



21.5.3.3 TaggedProfile Interface


   This interface gives access to a local representation of an
   IOP::TaggedProfile.


   profile_id
   This attribute is the identifier for this TaggedProfile.


   profile_data
   This attribute is the data from the TaggedProfile. It is
   normally a CDR encapsulation.


   convert
   Create an IOP representation of this TaggedProfile


21.5.3.4 TaggedComponent Interface


   This interface gives access to a local representation of an
   IOP::TaggedComponent.


   component_id
   This attribute is the identifier for this TaggedComponent.


   component_data
   This attribute is the data from the TaggedComponent. It is
   normally a CDR encapsulation.


   convert
   Create an IOP representation of this TaggedComponent.


21.5.3.5 TaggedProfileFactory Interface


   factory_id
   This attribute is the identifier of profiles created by this
   TaggedProfileFactory.


   create
   Create a TaggedProfile from the given profile_data.


21.5.3.6 TaggedComponentFactory Interface


   factory_id
   This attribute is the identifier of components created by this
   TaggedComponentFactory.


   create
   Create a TaggedComponent from the given component_data.


21.5.3.7 ProfileIterator Interface


   next
   Returns the next TaggedProfile in the iteration. If next is called
   after the last TaggedProfile has been returned, BAD_INV_ORDER will
   be raised with a standard minor code of n+3.


   If an IOR is modified in between calls to next, the behavior of
   further calls to next is implementation dependent.


   has_next
   Returns true if the iteration has more elements. In other words,
   returns true if next would return an element rather than throwing
   an exception.


21.5.3.8 ComponentIterator Interface


   next
   Returns the next TaggedComponent in the iteration. If next is called
   after the last TaggedComponent has been returned, BAD_INV_ORDER will
   be raised with a standard minor code of n+3.


   If a profile is modified in between calls to next, the behavior of
   further calls to next is implementation dependent.


   has_next
   Returns true if the iteration has more elements. In other words,
   returns true if next would return an element rather than throwing
   an exception.


21.5.3.9 IIOPProfile Interface


   object_key
   This attribute is the Object key contained in this IIOPProfile.


   profile_template
   This attribute is the IIOPProfileTemplate associated with this
   IIOPProfile.



21.5.3.10 IIOPProfileTemplate Interface


   iiop_version
   This attribute is the GIOP version of this profile. If the major
   value is 1 and the minor value is 0, this profile cannot contain
   any TaggedComponents.


   host
   This attribute is the host name string of this IIOPProfileTemplate.


   port
   This attribute is the port number of this IIOPProfileTemplate.


   get_components
   Return an iterator over the TaggedComponents within the
   IIOPProfileTemplate.


   get_components_by_id
   Returns an iterator over the TaggedComponents with the given
   ComponentId.



In current Section 21.5.3:
- add the following after the ORBInfo Interface


  local interface IORInfo_3_n:IORInfo {
      ProfileIterator get_profiles ();
      ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id);
  };



- add the following sections:


21.5.3.4  get_profiles
   Returns an iterator over the TaggedProfiles within the IOR.


21.5.3.5  get_profiles_by_id
   Returns an iterator over the TaggedProfiles within the IOR with the
   given Profileid.


   Parameter   Description
   profile_id  The IOP::ProfileId of the profiles in the iteration
               to be returned.



- add the IORFactory to the list of reserved ObjectIds for
  resolve_initial_references in section 4.5.2

Resolution:
Revised Text:
Actions taken:
June 25, 2002: received issue
April 11, 2012: Deferred to next RTF

Issue 5448: BAD_INV_ORDER minor code 5 and 10 mean the same thing? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

From the descriptions in CORBA 2.6.1 sections 7.2 and 7.2.3, the
BAD_INV_ORDER minor codes 5 and 10 appear to mean the same thing.  We
should officially deprecate one, or state that either is acceptable

Resolution: Easiest fix is to state either is acceptable
Revised Text: In formal/02-06-01 make the following changes: 1. In section 7.2 in the last sentence replace the phrase "with standard minor code 5" by "with the standard minor code 5 or 10". 2. In section 7.2.3 in the last sentence replace the phrase "with standard minor code 10" by "with the standard minor code 5 or 10"
Actions taken:
June 30, 2002: received issue
April 28, 2003: closed issue

Issue 5449: Wrong minor code listed in POAManager::deactivate (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 11.3.2.5 states that BAD_INV_ORDER with minor code 6 is raised
if POAManager::deactivate is called from an invocation on a POA that
would be affected by the deactivate call.


This minor code ought to be 3 instead

Resolution: editorially fixed in 3.0
Revised Text:
Actions taken:
July 1, 2002: rerceived issue
July 8, 2002: closed issue

Issue 5467: How does DynValue handle derived valuetypes? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

I just noticed that the description of DynValue is totally silent on the
issue of derived valuetypes.


Here's an example to set things up:


// IDL


valuetype A {
    public short s;
};


valuetype B {
    public long l;
};


struct S {
    A   an_a;
};


// C++


DynamicAny::DynFactory  df = ...;
B                       *b = ...;
S                       my_s;
CORBA::Any              my_any;
    
s.an_a = b;
my_any <<= s;
    
DynamicAny::DynAny_var          da = df->create_dyn_any(my_any);
DynamicAny::DynStruct_var       ds = DynamicAny::DynStruct::_narrow(da);


ds->seek(0);
da = ds->current_component();


DynamicAny::DynValue_var        dv = DynamicAny::DynValue::_narrow(da);
CORBA::TypeCode_var             tc = dv->type();


cout << tc->id() << endl;


-----------


Now some questions:


1.  What is printed by the above C++ code?  "IDL:A:1.0" or "IDL:B:1.0"?


2.  If the typecode is for valuetype A, what happens to the members
defined in valuetype B?  Seems they must be inaccessable yet still
recoverable if I convert the DynValue back to an any and extract the
value, because I can't truncate a B to an A.


3.  If the typecode is for valuetype B, we now have the interesting case
where:


    tc->equivalent(ds->type()->member_type(0))


is false.  Is this going to confuse programmers or programs?  I think it
will, since it means that if I try to insert dv into another DynStruct
via assign() or the like, it will fail, since the TypeCodes are no
longer equivalent.


4.  Do the answers change if B is truncatable and the program can find
the TypeCode for B (perhaps via SendingContextRunTime)?  How about if it
can't find the TypeCode?

Resolution:
Revised Text:
Actions taken:
July 16, 2002: received issue
April 11, 2012: Deferred to next RTF

Discussion:

Issue 5587: Inconsistent definition of semantics of RebindPolicy? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.12.3.32 states:


> REBIND is raised when the current effective RebindPolicy, as described in
> Section 22.2.1.2, interface RebindPolicy on page 22-5, has a value of
> NO_REBIND or NO_RECONNECT and an invocation on a bound object reference results
> in a LocateReply message with status OBJECT_FORWARD or a Reply message with
> status LOCATION_FORWARD. This exception is also raised if the current effective
> RebindPolicy has a value of NO_RECONNECT and a connection must be re-opened.
> The invocation can be retried once the effective RebindPolicy is changed to
> TRANSPARENT or binding is re-established through an invocation of
> CORBA::Object::validate_connection.


but 22.2.1.2 says:


> If the effective Policy of this type has a rebind_mode value of NO_REBIND, the
> ORB will raise a REBIND system exception if any rebind handling would cause a
> client-visible change in policies. This could happen under the following
> circumstances:
>
> o The client receives a LocateReply message with an OBJECT_FORWARD status and a
> new IOR that has policy requirements incompatible with the effective policies
> currently in use.
>
> o The client receives a Reply message with LOCATION_FORWARD status and a new
> IOR that has policy requirements incompatible with the effective policies
> currently in use.


So the former says that a REBIND exception *always* occurs a rebind is
necessary (and NO_REBIND is set), but the latter says that a REBIND
exception only occurs when any client-visible policies would change.


Which one is correct?


Also, it is not clear from the specification whether an invocation on a
new object reference that has never been bound must fail if RebindMode
is not TRANSPARENT, forcing the use of validate_connection, or whether
the first initial binding can proceed without the use of
validate_connection.

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes: 1. In section 4.12.3.32 replace the entire content of the section by: "REBIND is raised when there is a problem in carrying out a requested or implied attempt to rebind an object reference (See section 22.2.1.2), and the failure is caused by an inability to carry out the binding consistent with the RebindPolicy in effect at the time." 2. In section 22.2.1 insert the first paragraph which says: "Rebind support discussed in this section refers to the act of rebinding an object reference that has already been bound once. The policies discussed here do not affect the initial binding of an object reference."
Actions taken:
August 20, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: First of all the detailed stuff that appears in section 4.12.3.32 is inappropriate for that section. Instead, in line with the sort of things that appear for other exceptions, what should appear in this section is something like: "REBIND is raised when there is a problem in carrying out a requested or implied attempt to rebind an object reference (See section 22.2.1)". 

Then the current text in 4.12.3.32 is merely a failed attempt at summarizing what is stated in section 22.2.1.2, and should simply be removed. 

Finally since in section 22.2.1 appears to address only issue of "re"-connecting and "re"-binding it would appear that the first binding is not governed by this set of policies. If it were otherwise, the prefix "re" would not have been used. We could explicitly clarify this by inserting sentences to the effect that the value of RebindPolicy does not affect the initial binding of an Object Reference, it only affect binding changes resulting from forwarding or disconnection

Issue 5592: Object::get_client_policy problem (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

4.3.7.2 says:


"Returns the effective overriding Policy for the object reference. The
effective override is obtained by first checking for an override of the
given PolicyType at the Object scope, then at the Current scope, and
finally at the ORB scope. If no override is present for the requested
PolicyType, the system-dependent default value for that PolicyType is
used. Portable applications are expected to set the desired defaults
at the ORB scope since default Policy values are not specified."


Some policies may not have a sensible default value, such as
RequestStartTime and in fact, perhaps should not have one to avoid
putting any value in the INVOCATION_POLICIES service context.  In this
case, it would be better if get_client_policy were allowed to return a
nil Policy reference.


Suggested revision:


Change the sentence that reads:


"If no override is present for the requested PolicyType, the
system-dependent default value for that PolicyType is used."


to:


"If no override is present for the requested PolicyType, a
system-dependent default value for that Policy Type may be returned.  A
nil Policy reference may also be returned to indicate that there is no
default for the policy."

Resolution: Fix as suggested
Revised Text: In formal/02-06-01 make the following changes: 1. In section 4.3.8.2 change the sentence that reads: "If no override is present for the requested PolicyType, the system-dependent default value for that PolicyType is used. to read: "If no override is present for the requested PolicyType, a system-dependent default value for that Policy Type may be returned. A nil Policy reference may also be returned to indicate that there is no default for the policy."
Actions taken:
August 24, 2002: received issue
April 28, 2003: closed issue

Issue 5614: Sloppy text in CORBA 3.0, 4.3.8.1 get_policy (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

In CORBA 3.0 section 4.3.8.1, the description of the Object::get_policy
operation says:


"Invoking non_existent on an object reference prior to get_policy
ensures the accuracy of the returned effective Policy.Ifget_policy is
invoked prior to the object reference being bound, the returned
effective Policy is implementation dependent.  In that situation, a
compliant implementation may do any of the following: raise the standard
system exception BAD_INV_ORDER, return some value for that PolicyType
which may be subject to change once a binding is performed, or attempt a
binding and then return the effective Policy."


This is silly, since the only portable thing that applications can do is
to call validate_connection or non_existent before calling get_policy,
having two other non-portable behaviors just serves to make the standard
larger and confuse users.


We should pick one of the two reasonable behaviors--throw BAD_INV_ORDER
or force a binding before returning a valid policy value--and make that
the only valid behavior.  Either one will be backwards compatible with
portable code.

Resolution: Makes sense. Fix it as suggested
Revised Text: In formal/02-06-01 make the following changes: 1. In section 4.3.8.1 third paragraph change: "the returned effective Policy is implementation dependent. In that situation, a compliant implementation may do any of the following: raise the standard system exception BAD_INV_ORDER, return some value for that PolicyType which may be subject to change once a binding is performed, or attempt a binding and then return the effective Policy." to read: " a compliant implementation shall attempt a binding and then return the effective Policy. If the binding attempt fails it shall pass through the system exception returned from the binding attempt."
Actions taken:
August 29, 2002: received issue
April 28, 2003: closed issue

Discussion:

Issue 5619: Object::validate_connection() (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

How does Object::validate_connection() interact with RoutingPolicy
values of ROUTE_FORWARD or ROUTE_STORE_AND_FORWARD?  Should
validate_connection() force the client to open a connection to a message
router and fail if it cannot?

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes In section 4.3.10.1 insert the following paragraph immediately following the first paragraph of the section: "If the RoutingPolicy ROUTE_FORWARD or ROUTE_STORE_AND_FORWARD are in effect when validate_connection is invoked then the client ORB shall attempt to open a connection for the first hop to the first target Router (applies to both Router and PersistentRequestRouter) as if it were the target Object and return success or failure based on success or failure to establish this connection."
Actions taken:
September 1, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: Sounds like it might be a good idea to test the first hop at least for ROUTE_FORWARD and ROUTE_STORE_AND_FORWARD, and fail if it is unable to connect for the first hop.

Issue 5620: Who is responsible for generating the TIMEOUT exception (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

What is the expected behavior of a server or router that receives a
request with a RequestEndTimePolicy or ReplyEndTimePolicy value that has
expired?  Who is responsible for generating the TIMEOUT exception--the
client or server or both?

Resolution: This issue is a subset of issue 5626. Merge it with 5626 and close this issue
Revised Text:
Actions taken:
September 1, 2002: received issue
April 28, 2003: closed issue

Issue 5621: messaging router issue (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

What is a messaging router supposed to do if it receives multiple
requests from a client with more than one type of QueueOrderingPolicy
value? (Is this legal? Is it legal to have more than one QueueOrdering
bit set in a single request?)  How can it sort on priority, FIFO, and
deadline simultaneously?

Resolution:
Revised Text:
Actions taken:
September 1, 2002: received issue
April 11, 2012: Deferred to next RTF

Issue 5622: Is a router allowed to pick any value in the range for a priority? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Does it make sense (and is it legal) for a request to be sent with a
RequestPriorityPolicy or ReplyPriorityValue in a service context where
the min and max priorities are not the same?  Is a router allowed to
pick any value in the range for a priority?

Resolution: Close no change
Revised Text:
Actions taken:
September 1, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: 
1. Does it make sense (and is it legal) for a request to be sent with a RequestPriorityPolicy or ReplyPriorityValue in a service context where the min and max priorities are not the same? 

No reason for it to be illegal. Whether it makes sense or not depends on how this facility is being exploited by the user. No reason to disallow this. 

2. Is a router allowed to pick any value in the range for a priority? 

Presumably so. If the users wants to constrain the Router's and others choices it just specifies a narrower range

Issue 5623: determining TimeT or UtcT value (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The Time service states that determining if a TimeT or UtcT value is
absolute or relative needs to be specified by the context.  One presumes
that the Messaging RequestStartTimePolicy, RequestStopTimePolicy,
ReplyStartTimePolicy and ReplyEndTimePolicy contain absolute timestamps,
and that RelativeRequestTimeoutPolicy and RelativeRoundtripTimeoutPolicy
contain relative timestamps.  The specification should make the context
explicit.

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes: 1. In sections 22.2.4.1, 22.2.4.2, 22.2.4.3 and 22.2.4.4 replace the phrase "TimeBase::UtcT is passed" by the phrase "TimeBase::UtcT containing an absolute time is passed". 2. In sections 22.2.4.5 and 22.2.4.6 replace the phrase "TimeBase::UtcT is passed" by the phrase "TimeBase::UtcT containing a relative time is passed".
Actions taken:
September 1, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: Explicitly state whether the time contained in the UtcT is relative or absolute for each of these policies

Issue 5624: Spec doesn't make clear what is valid mix of policies and what is invalid (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The spec doesn't make it clear what is a valid mix of policies and what
is invalid.  For example, should it be legal to set a
RequestPriorityPolicy, MaxHopsPolicy or QueueOrderingPolicy value if the
RoutingPolicy is ROUTE_NONE?


Also, should setting both RequestEndTimePolicy and
RelativeRequestTimeoutPolicy be illegal?  Or must the client/server pick
which ever one expires first?

Resolution:
Revised Text:
Actions taken:
September 1, 2002: received issue
April 11, 2012: Deferred to next RTF

Discussion:

Issue 5626: Messaging time based policy enforcement? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 22.2.4 provides various time-based policies to bound the
delivery and lifetime of requests, but has no information about who
(client, router or target server) is responsible for enforcing those
policies.  Without this information, there will certainly be
interoperability issues.

Resolution: Fix it as suggested in the archive with a few minor changes
Revised Text: In formal/02-06-01 make the following changes: 1. In appendix section A.5 add a new minor codes 5626X1and 5626X2 for the TIMEOUT exception : 5626X1 " End time specified in RequestEndTimePolicy or RelativeRequestTimeoutPolicy has expired". 5626X2 " End time specified in ReplyEndTimePolicy or RelativeReplyTimeoutPolicy has expired". 2. In section 22.2.4.1 append the following paragraph: "If the effective RoutingPolicy is NONE, the client ORB shall refrain from transmitting the request to the target until after the specified start time. Otherwise, the client ORB and all but the last hop router are free to transmit the request immediately, and the last hop router shall delay the request until the specified start time." 3. In section 22.2.4.2 append the following paragraph: "The client ORB, all routers and the target ORB shall check to see if the end time specified in the RequestEndTimePolicy associated with a request has expired and the request is yet to be delivered to the target. If so, it shall the discard the request and return the system exception TIMEOUT with standard minor code 5626X1." 4. In section 22.2.4.3 append the following paragraph: "If the RoutePolicy is ROUTE_NONE, the client ORB shall delay delivering the reply until the start time has been reached. Otherwise, the target ORB and all but the last hop router are free to transmit the reply immediately, and the last hop router shall delay transmission of the reply to the client until the start time has been reached." 5. In section 22.2.4.4 append the following paragraph: "The client ORB, all routers and the target ORB shall check to see if the end time specified in the ReplyEndTimePolicy associated with a request has expired and a reply has not yet been delivered to the client. If so, it shall the discard the reply and return the system exception TIMEOUT with standard minor code 5626X2." 6. In section 22.2.4.5 append the following paragraph: "Since a RelativeRequestTimeoutPolicy is converted to a RequestEndTimePolicy before transmitting the request to the target ORB, see 22.2.4.2 for the required behavior of an ORB or router when the timeout expires." 7. In section 22.2.4.6 append the following paragraph: "Since a RelativeRoundtripTimeoutPolicy is converted to a ReplyEndTimePolicy before transmitting the request to the target ORB, see 22.2.4.4 for the required behavior of an ORB or router when the timeout expires."
Actions taken:
September 2, 2002: received issue
April 28, 2003: closed issue

Discussion:

There are 6 policies, RequestStartTime, RequestEndTime, ReplyStartTime,
ReplyEndTime, RelativeRequestTimeout and RelativeRoundtripTimeout.  The
latter two are alternative forms of the RequestEndTime and ReplyEndTime
policies, and are encoded the same way in a service context for the
request, so they can be considered equivalent for interoperability
purposes.


Also, these policies are stated to be effective for both synchronous
(ROUTE_NONE) and asychronous (ROUTE_FORWARD and ROUTE_STORE_AND_FORWARD)
invocations.


Proposed semantics:


For RequestStartTime, if the RoutePolicy is ROUTE_NONE, the client must
delay transmitting the request until the start time has been reached. 
Otherwise, the client and all but the last-hop router are free to
transmit the request immediately, and the last-hop router is responsible
for delaying transmission of the request to the target server until the
start time has been reached.


For RequestEndTime, the client, all routers and the target server must
check to see if the RequestEndTime has passed and if so, discard the
request and reply with a TIMEOUT exception.


For ReplyStartTime, if the RoutePolicy is ROUTE_NONE, the target server
must delay transmitting the reply until the start time has been
reached.  Otherwise, the target server and all but the last-hop router
are free to transmit the reply immediately, and the last-hop router is
responsible for delaying transmission of the reply to the client until
the start time has been reached.


For ReplyEndTime, the client, target server and all routers must check
to see if the ReplyEndTime has expired, and if so, discard the reply and
replace it with a TIMEOUT exception.  The client must also retain the
ReplyEndTime value and terminate the invocation with a TIMEOUT
exception, even though a reply (normal or exceptional) has not been
received.  The client must also be prepared to receive and discard any
subsequent reply.

Issue 5641: SyncScope for oneway invocations (corba-rtf)

Click here for this issue's archive.
Source: Eternal Systems (Mr. Wenbing Zhao, wenbing(at)alpha.ece.ucsb.edu)
Nature: Uncategorized Issue
Severity:
Summary:

I was reading the CORBA specification (formal/02-06-01) concerning the
SyncScope for oneway invocations. I found out that there is a mismatch on
the meaning of SYNC_WITH_TARGET:


On page 21-23 (Request Interceptors), there is the following paragraph:


"For SYNC_WITH_SERVER and SYNC_WITH_TARGET, the server does send an empty reply back to the client before the target is invoked."


That is true for SYNC_WITH_SERVER, but not correct according to the specification of the CORBA Messaging service, given on page 22-7:


"SYNC_WITH_TARGET - equivalent to a synchronous, non-oneway operation in CORBA. The server-side ORB shall only send the reply message after the target has completed the invoked operation."


Note that a reply is send back to the client AFTER the target has completed the invoked operation, not BEFORE.


This error has been around already in eariler versions of the CORBA specification.

Resolution: The statement about SYNC_WITH_TARGET in 21-23 is indeed wrong. Fix it.
Revised Text: In formal/02-06-01 in section 21.3.12.9 remove the phrase "and SYNC_WITH_TARGET" from the last paragraph
Actions taken:
September 9, 2002: received issue
April 28, 2003: closed issue

Issue 5642: Messaging: bad example code for type specific poller (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

22.10.3 has bad example code for the type specific poller generated for
the StockManager interface.  The AMI_StockManagerPoller is shown with
the following:


valuetype AMI_StockManagerPoller : Messaging::Poller {
    ...
    attribute AMI_StockManagerHandler associated_handler;
    ...
};


This is illegal, since Messaging::Poller also defines an attribute named
"associated_handler".  Since the text does not specify that this
attribute ought to be generated in a type-specific poller, I suspect
that this is an editing mistake from a draft version of the Messaging
RFP response and should be removed.


The C++ example generated code in 22.11.4.2 also needs to be edited to
remove the associated_handler attribute as well.

Resolution: The observation above is correct. Fix it
Revised Text: In formal/02-06-01 make the following changes: 1. In section 22.10.3 in the IDL for AMI_StockManagerPoller remove the last line which reads: attribute AMI_StockManagerHandler associated_handler; 2. In section 22.11.4.1 in the C++ class declaration of AMI_StockManagerPoller remove the last two lines that correspond to the erroneous attribute in 1 above, and that read: virtual AMI_StockManagerHandler_ptr associated_handler(); virtual void associated_handler(AMI_StockManagerHandler_ptr _val);
Actions taken:
September 11, 2002: receive dissue
April 28, 2003: closed issue

Issue 5660: Errors in definition of Messaging poller types (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The definintion of Messaging::Poller in section 22.9 is missing the
keyword "private" on the target & op_name valuetype attribute
declarations.


The persistent poller in 22.10.2 is also missing a "private" on the
"outstanding_request" attribute, as well as the example in 22.10.3.

Resolution: Resolution: Fix as suggested. No problem with versioninhg since the published IDL already contains t
Revised Text: In formal/02-06-01 make the following changes: 1. In section 22.9 in the IDL for Messaging::Poller replace the following lines of IDL: Object target; string op_name; with: private Object target; private string op_name; 2. In section 22.10.2 replace the following line of IDL: MessageRouting::PersistentRequest outstanding_request; by: private MessageRouting::PersistentRequest outstanding_request; 3. In section 22.10.3 in the IDL for AMI_StockManagerPersistentPoller replace the following line of IDL: MessageRouting::PersistentRequest request; by private MessageRouting::PersistentRequest request;
Actions taken:
September 27, 2002: received issue
April 28, 2003: closed issue

Issue 5661: Messaging type-specific poller valuetypes should be abstract (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The generated type-specific poller valuetypes generated for an interface
should be abstract valuetypes and should inherit the corresponding
type-specific poller valuetypes of the base interfaces.


Without this, code reuse is prevented in both implementing the
type-specific poller valuetypes, as well as in using them in client
code.

Resolution: The resolution of 5666 fixes this. Close this one no change with that comment
Revised Text:
Actions taken:
September 27, 2002: received issue
April 28, 2003: closed issue

Issue 5662: Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

It is impossible to use the routing protocol to communicate with servers
that only support GIOP 1.0 or 1.1, because the information contained in
struct MessageBody does not contain enough information to determine the
alignment requirements of the contents of body member.  The GIOP 1.0 &
1.1 RequestHeader struct contain an octet sequence for principle as the
last member, and specify no alignment requirements for the message
body.  Thus, it is impossible for the final router to determine the
proper alignment for the message body when marshalling a GIOP Request
message for delivery to the target object.


The same problem applies to the Response message.

Resolution:
Revised Text:
Actions taken:
September 26, 2002: received issue
April 11, 2012: Deferred to next RTF

Issue 5663: potential name clash with Messaging type-specific poller timeout argument (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The name generated for the type-specific poller timeout argument is
"timeout", which could clash with a real IDL argument name.


The name should be changed to "ami_timout", similar to "ami_return_val".

Resolution: make it so
Revised Text: In formal/02-06-01 make the following changes: 1. In section 22.10.1.1 in item 3 of the first numbered list change the phrase "unsigned long timeout" to "unsigned long ami_timeout" and make the "ami_timeout" bold. 2. In section 22.10.1.2 second paragraph change the phrase "unsigned long timeout" to "unsigned long ami_timeout" and make the "ami_timeout" bold. 3. In the IDL in section 22.10.3 replace all occurences of: "in unsigned long timeout" by: "in unsigned long ami_timeout" 4. In the C++ code in section section 22.11.4.1 change all occurences of: "CORBA::ULong timeout" to: "CORBA::ULong ami_timeout"
Actions taken:
September 27, 2002: received issue
April 28, 2003: closed issue

Discussion:

Issue 5664: AMI vs abstract & local interfaces (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The spec is silent about the interaction of AMI implied IDL and abstract
interfaces

Resolution: Clarify that sendc_ and sendp_ operations are not generated for abstract interfaces
Revised Text: In formal/02-06-01 make the following changes: In section 22.6 insert the following sentence immediately following the first sentence of the first paragraph: "Note that no callback and polling asynchronous method signatures are generated for any operations or attributes of abstract interfaces."
Actions taken:
September 27, 2002:
April 28, 2003: closed issue

Issue 5665: name disambiguation for AMI interface & poller names is confusing (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The rule for generating a unique AMI_ callback or poller name is to
stuff additional "AMI_" strings until the name is unique.  However,
consider the following IDL:


// IDL
module M {


    interface A {
    };


    interface AMI_A {
    };


};


this apparently maps to the implied IDL:


// implied IDL
module M {


    interface A {
    };


    interface AMI_AMI_A { // callback interface for A
    };


    interface AMI_A {
    };


    interface AMI_AMI_AMI_A {  // callback interface for AMI_A
    };
};



however, if I switch the order of declaration of A and AMI_A, the names
of the associated callback interfaces change.


Not only that, but if I split the IDL into two files:



// File 1
module M {


    interface A {
    };
};


// File 2
module M {
    interface AMI_A {
    };


};


and try to compile them separately, the generated code will fail.


I don't think there is any solution to this problem other than to
declare it an error to use an IDL identifier that begins with "AMI_" if
it causes a name clash.


The same problem applies to the AMI poller valuetypes.

Resolution: Resolution: Insert the requirement that any IDL that is meant to be used for AMI should not have any
Revised Text: In formal/02-06-01 make the following changes: In section 22.6 insert the following paragraph immediately following the first paragraph: " Due to the way in which identifier names are generated in the implied IDL, in order to avoid name clashes, any IDL that is meant to be used with Asynchronous Messaging must not contain any identifiers that have the string "AMI_" as a prefix."
Actions taken:
September 27, 2002: received issue
April 28, 2003: closed issue

Issue 5666: Messaging Poller generation is broken for interfaces with multiple inherite (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity: Critical
Summary:

22.10.1 states that Type-Specific poller valuetypes inherit from the
poller valuetype associated with the interface that the original
interface inherits from.  This does not address multiple inheritance,
and in fact it cannot, since valuetype inheritance is more limited than
interface inheritance.


The problem is that the base valuetype for polling, Messaging::Poller,
is not abstract, and cannot be inherited more than once by a derived
valuetype.  So as it stands now, the AMI polling model is broken for
multiple inheritance, and needs to be treated as an urgent issue in
order to produce an immediate fix.


Proposed resolution:


1.  Make Messaging::Poller an abstract valuetype, and remove the state
members from it.  Change the IDL for Poller in 22.9 and 22.16.1 to:


module Messaging {
    abstract valuetype Poller : CORBA::Pollable {
        readonly attribute Object operation_target;
        readonly attribute string operation_name;
        attribute ReplyHandler associated_handler;
        readonly attribute boolean is_from_poller;
    };
};


2.  Add back the private target and op_name state members to the
persistent type-specific poller valuetypes.  Modify the example IDL in
22.10.2 to:


valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller {
    private MessageRouting::PersistentRequest outstanding_request;
    private Object target;
    private string op_name;
};


This is necessary so the PersistentPoller can be propagated from one
process to another with all of its necessary state.


3.  Change the text in 22.10.1 that describes inheritance of
type-specific pollers to:


For each interface, the IDL compiler generates a type-specific Poller
value. A Poller is created by the ORB for each asynchronous invocation
that uses the polling model operations. The name of the basic
type-specific Poller is AMI_<ifaceName>Poller, where ifaceName is the
unqualified name of the interface for which the Poller is being
generated. If the interface ifaceName derives from one or more IDL
interfaces, then the Poller is derived from the corresponding
Poller for each base interface, but if it does not, then it is derived
from Messaging::Poller. Poller valuetypes are declared abstract.  If
this name conflicts with definitions in the original IDL, additional
AMI_ prefixes are prepended before <ifaceName> until a unique valuetype
name is generated (such as "AMI_AMI_FooPoller"for interface Foo).


4.  Change the example IDL in 22.10.3 to make the poller abstract:


// AMI implied-IDL of type-specific Poller
// for original example IDL defined in Section 22.5
abstract valuetype AMI_StockManagerPoller : Messaging::Poller {
   ...


and add the target and op_name private state members to the persistent
poller:


valuetype AMI_StockManagerPersistentPoller : AMI_StockManagerPoller
{
    private MessageRouting::PersistentRequest request;
    private Object target;
    private string op_name;
};

Resolution: Make the changes recommended in the archive
Revised Text: In formal/02-06-01 make the following changes: 1. Make Messaging::Poller an abstract valuetype, and remove the state members from it. Change the IDL for Poller in 22.9 and 22.16.1 to: module Messaging { abstract valuetype Poller : CORBA::Pollable { typeid ::Messaging::Poller "IDL:omg.org/Messaging/Poller:3.1"; readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; }; }; 2. Add back the private target and op_name state members to the persistent type-specific poller valuetypes. Modify the example IDL in 22.10.2 to: valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller { private MessageRouting::PersistentRequest outstanding_request; private Object target; private string op_name; }; This is necessary so the PersistentPoller can be propagated from one process to another with all of its necessary state. 3. Change the text in 22.10.1 that describes inheritance of type-specific pollers to: For each interface, the IDL compiler generates a type-specific Poller value. A Poller is created by the ORB for each asynchronous invocation that uses the polling model operations. The name of the basic type-specific Poller is AMI_<ifaceName>Poller, where ifaceName is the unqualified name of the interface for which the Poller is being generated. If the interface ifaceName derives from one or more IDL interfaces, then the Poller is derived from the corresponding Poller for each base interface, but if it does not, then it is derived from Messaging::Poller. Poller valuetypes are declared abstract. If this name conflicts with definitions in the original IDL, additional AMI_ prefixes are prepended before <ifaceName> until a unique valuetype name is generated (such as "AMI_AMI_FooPoller"for interface Foo). 4. Change the example IDL in 22.10.3 to make the poller abstract: // AMI implied-IDL of type-specific Poller // for original example IDL defined in Section 22.5 abstract valuetype AMI_StockManagerPoller : Messaging::Poller { ... and add the target and op_name private state members to the persistent poller: valuetype AMI_StockManagerPersistentPoller : AMI_StockManagerPoller { private MessageRouting::PersistentRequest request; private Object target; private string op_name; };
Actions taken:
September 28, 1992: received issue
April 28, 2003: closed issue

Discussion:

Issue 5667: Bad example code in 22.11.4.3 (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The example code in 22.11.4.3 seems to be from a draft version of the
Messaging specification where the Pollable type was an interface rather
than a valuetype

Resolution: Turns out that the examples in both 22.11.4.2 and 22.11.4.3 need fixing. Make changes as described
Revised Text: In forma/02-06-01 make the following changes: 1. Replace the example C++ code in 22.11.4.2 by: // polling_client_main.cpp #include <stockmgr_c.hh> // include filename is non-normative int main(int argc, char ** argv) { // Initialize the ORB CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); // Initializing objRef for StockManager -- assumes IOR is passed // on command-line CORBA::Object_var obj = orb->string_to_object(argv[1]); StockManager_var stockMgr = StockManager::_narrow(obj); // Obtain the ORB's PolicyManager CORBA::Object_var orbQosObj = orb->resolve_initial_references("ORBPolicyManager"); CORBA::PolicyManager_var orbQos = CORBA::PolicyManager::_narrow(orbQosObj); // Create and apply an ORB-wide Routed Delivery QoS CORBA::Any routing_val; Messaging::RoutingTypeRange routing; routing.min = Messaging::FORWARD; routing.max = Messaging::STORE_AND_FORWARD; routing_val <<= routing; CORBA::PolicyList orb_pols(1); orb_pols.length(1); orb_pols[(CORBA::ULong) 0] = orb->create_policy(Messaging::ROUTING_POLICY_TYPE, routing_val); orbQos->set_policy_overrides(orb_pols, CORBA::ADD_OVERRIDE); // Create and apply an object-reference-specific Priority QoS CORBA::Any priority_val; Messaging::PriorityRange priority; priority.min = 5; priority.max = 15; priority_val <<= priority; CORBA::PolicyList obj_pols(1); obj_pols.length(1); obj_pols[(CORBA::ULong) 0] = orb->create_policy(Messaging::REQUEST_PRIORITY_POLICY_TYPE, priority_val); stockMgr = stockMgr->set_policy_overrides(obj_pols); // At this point QoS has been set and a protocol selected. // Make each invocation and store the returned Pollers AMI_StockManagerPoller_var pollers[6]; // Async Attributes pollers[0] = stockMgr->sendp_set_stock_exchange_name("NSDQ"); pollers[1] = stockMgr->sendp_get_stock_exchange_name(); // Async Operations pollers[2] = stockMgr->sendp_add_stock("ACME", 100.5); pollers[3] = stockMgr->sendp_edit_stock("ACME", 150.4); // Notice no out param is passed. pollers[4] = stockMgr->sendp_remove_stock("ABC"); pollers[5] = stockMgr->sendp_find_closest_symbol("ACMA"); // Now obtain each result CORBA::ULong max_timeout = (CORBA::ULong) -1; pollers[0]->set_stock_exchange_name(max_timeout); cout << "Setting stock exchange name succeeded" << endl; CORBA::String_var exchange_name; pollers[1]->get_stock_exchange_name(max_timeout, exchange_name.out()); cout << "Obtained stock exchange name [" << exchange_name << "]" << endl; CORBA::Boolean stock_added; pollers[2]->add_stock(max_timeout, stock_added); if (stock_added) cout << "Stock added successfully" << endl; else cout << "Stock not added" << endl; try { pollers[3]->edit_stock(max_timeout); cout << "Edited stock successfully" << endl; } catch (const CORBA::Exception& e) { cout << "Edit stock failure [" << e << "]" << endl; } try { CORBA::Double quote; pollers[4]->remove_stock(max_timeout, quote); cout << "Removed stock successfully with quote [" << quote << "]" << endl; } catch (const CORBA::Exception& e) { cout << "Remove stock failure [" << e << "]" << endl; } CORBA::Boolean closest_found; CORBA::String_var symbol; pollers[5]->find_closest_symbol(max_timeout, closest_found, symbol.out()); if (closest_found) cout << "Found closest symbol [" << symbol << "]" << endl; cout << "Exiting Polling Client" << endl; return 0; } 2. Replace the contents of section 22.11.4.3 by: The following example client program demonstrates the use of the PollableSet and wait for multiple requests to finish. The program would be exactly the same as that of the previous section, as far as the comment "// Now obtain each result". In this example, after the PollableSet::get_ready_pollable indicates that a particular Poller has finished, the code makes the call on the type-specific poller in a non-blocking manner and doesn't bother checking for completion in the return value. Checking isn't necessary when only a single client is using the Poller, but it is the safe practice if multiple clients are waiting. // Obtain results in any order. First set up // the PollableSet. CORBA::PollableSet_var poll_set = pollers[0]->create_pollable_set(); for (int i=0; i<6, i++) { poll_set->add_pollable(pollers[i]); } // repeat until all completions have been received CORBA::ULong max_timeout = (CORBA::ULong) -1; while (poll_set->number_left() > 0) { // wait for a completion CORBA::Pollable_var pollable = poll_set->get_ready_pollable(max_timeout); // the returned Pollable is ready to return its reply for (int j=0; j < 6; j++) { if (pollers[j] == pollable.in()) break; } switch(j) { case 0: pollers[0]->set_stock_exchange_name(0UL); cout << "Setting stock exchange name succeeded" << endl; break; case 1: CORBA::String_var exchange_name; pollers[1]->get_stock_exchange_name(0UL, exchange_name.out()); cout << "Obtained stock exchange name [" << exchange_name << "]" << endl; break; case 2: CORBA::Boolean stock_added; pollers[2]->add_stock(0UL, stock_added); if (stock_added) cout << "Stock added successfully" << endl; else cout << "Stock not added" << endl; break; case 3: try { pollers[3]->edit_stock(0UL); cout << "Edited stock successfully" << endl; } catch (const CORBA::Exception& e) { cout << "Edit stock failure [" << e << "]" << endl; } break; case 4: try { CORBA::Double quote; pollers[4]->remove_stock(0UL, quote); cout << "Removed stock successfully with quote [" << quote << "]" << endl; } catch (const CORBA::Exception& e) { cout << "Remove stock failure [" << e << "]" << endl; } break; case 5: CORBA::Boolean closest_found; CORBA::String_var symbol; pollers[5]->find_closest_symbol(0UL, closest_found, symbol.out()); if (closest_found) cout << "Found closest symbol [" << symbol << "]" << endl; break; } } cout << "All replies received. Exiting Polling Client" << endl; return 0;
Actions taken:
September 30, 2002: received issue
April 28, 2003: closed issue

Issue 5668: DII sendc reply delivery underspecified (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

7.2.10 states that sendc delivers the reply by using the supplied
Messaging::ReplyHandler, but it does not spell out the mechanics of the
delivery.


I presume that for an invocation of operation "foo", the "foo" or
"foo_excep" methods of the ReplyHandler will be invoked to deliver the
reply

Resolution: Yes, indeed. Insert a short description in section 7.10.2 on how the reply is obtained from the Repl
Revised Text: In formal/02-06-01 make the following changes: In section 7.2.10 insert the following sentence immediately following the second sentence in the first paragraph in the section: "For an invocation of operation "foo", the "foo" or "foo_excep" methods of the ReplyHandler is invoked to receive the reply. See Section 22.8 "Type Specific ReplyHandler Mapping" for details of how the names of the operations to be invoked to return the reply are constructed, as well as the form of the argument lists for the reply invocations."
Actions taken:
September 30, 2002: received issue
April 28, 2003: closed issue

Issue 5669: Oneway operations should not generate sendc_ and sendp_ variants (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Somewhere in the discussion in 22.6, it should specify that oneway
operations are not mapped with sendc_ and sendp_ variants, because they
would be useless.

Resolution: see above
Revised Text: In formal/02-06-01 in section 22.6, insert the following paragraph immediately following the first paragraph of the section: "Even though vanilla oneway operations have no associated reply, under certain circumstance, like for SyncScope value of SYNC_TARGET or SYNC_SERVER, it may be useful and necessary to receive a reply (either normal or exceptional). The sendc_ and sendp_ operations therefore need to be created for oneway operations too. Note that for other SyncScopes (SYNC_NONE and SYNC_TRANSPORT), invocations of sendc_ oneway operations should result in an immediate callback, and invocations of sendp_ oneway operations should result in a poll becoming immediately ready."
Actions taken:
September 30, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: Since oneway "semantics" can be tuned with the SyncScope policy, there are some cases when oneways DO have replies. In these cases, one might wish to invoke a oneway with SYNC_TARGET or SYNC_SERVER using sendc or 
sendp and establish that the request was either received or even invoked or that exceptions were thrown. So while there admittedly is no use for the sendc and sendp for oneway with SyncScope  SYNC_NONE and SYNC_TRANSPORT.

Issue 5672: Pollable in more than one PollableSet? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The descriptions of Pollable and PollableSet in 7.4 do not indicate if
it is legal to add a Pollable to more than one PollableSet.  If this is
made illegal, it is easier to implement Pollable and PollableSet to
cooperate behind the scenes to improve the efficiency of the PollableSet
implementation.


Recommended Resolution:


Make it illegal to add a Pollable to more than one PollableSet, by
adding the following text to 7.4.3.2:


"If the supplied Pollable has already been added to another PollableSet,
this operation raises the standard BAD_PARAM system exception with minor
code XYZ.


and add a new minor code for BAD_PARAM to appendix A:


"XYZ:  Attempt to add a Pollable to a second PollableSet."

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes: 1. Add a new minor code for BAD_PARAM to appendix A: "X5672: Attempt to add a Pollable to a second PollableSet." 2. Add the following text to 7.4.3.2: "If the supplied Pollable has already been added to another PollableSet, this operation raises the standard BAD_PARAM system exception with minor code X5672."
Actions taken:
October 5, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: 
The semantics of PollableSet is not compatible with adding a Pollable to more than one set.  Since a Pollable is removed from the set once it has become ready and collected via get_ready_pollable(), adding a Pollable to more than one set would require it to either silently disappear from one of the sets once it becomes ready and is collected, or else report ready to both sets.  The latter is in conflict with the semantics of Messaging::Poller, since it specifically is designed not to allow delivery of the Poller results to more than one caller.  The former is confusing to users and complicates writing code that correctly manages a PollableSet. 

So make it illegal to add Pollable to more than one PollableSet

Issue 5673: Why does PollableSet::number_left() return unsigned short? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Is there a particular design reason to limit the Pollable count to
65535?

Resolution: Incorporate change and close issue
Revised Text: In formal/02-06-01 make the following change: Append the following sentence to section 7.4.3.5 para 1: "A return value of 65535 indicates that there are at least 65535 remaining number of potential happenings."
Actions taken:
October 7, 2002: received issue
April 28, 2003: closed issue

Issue 5674: Local types allowed as valuetype state? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

A bullet in 3.8.7 states:


"o A local type may not appear as a parameter, attribute, return type,
or exception declaration of an unconstrained interface or as a state
member of a valuetype."


while 3.9.1.4 says:


"A valuetype that has a state member that is local (i.e. non-marshalable
like a local interface), is itself rendered local. That is, such
valuetypes behave similar to local interfaces when an attempt is made to
marshal them."


I presume the second statement is the correct one.


Proposed resolution:


Strike "or as a state member of a valuetype." from the bullet in 3.8.7.

Resolution: Presumption is correct. Fix as suggested
Revised Text: In formal/02-06-01 in section 3.8.7 strike the following phrase from the 7th bullet: "or as a state member of a valuetype"
Actions taken:
October 12, 2002: received issue
April 28, 2003: closed issue

Issue 5687: Derived component supported interface restriction (formal/2002-06-01) (corba-rtf)

Click here for this issue's archive.
Source: Computational Physics, Inc. (Mr. J. Scott Evans, evans(at)cpi.com)
Nature: Uncategorized Issue
Severity:
Summary:

Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface." 
Resolution:


In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence


"A derived component type may not directly support an interface."


with


"If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both  the interface of its base component type and the supported interfaces."

Resolution: see above
Revised Text: In formal/02-06-01 in section 3.17.2.3 on page 3-61 remove the first bullet in the section which reads: "A derived component type may not directly support an interface."
Actions taken:
October 10, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: The problem exists and the fix suggested applies only to the Component chapter which will be handled in a separate issue by the Components RTF. The change to the Core Chapter 3 is simply to remove the false statement that appears there. There is no reason to introduce details about the equivaelnt IDL in Core Chapter 3.

Issue 5689: Exception handling in Interceptor initialization (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

It is undocumented what should happen if an exception is thrown while
the ORB initialization process is calling ORBInitializer::pre_init or
post_init.


In section 21.7.3.1 concerning the Java binding, the following statement
related to calling pre_init and post_init appears:


"If there are any exceptions, the ORB shall ignore them and proceed."


Taking this as precedent, it suggests that exceptions raised by pre_init
and post_init should be ignored.  However, I'm not convinced that this
is a good idea, since a failure in an ORBInitializer is very likely to
cause the application to fail in mysterious ways later on that would be
difficult to debug.


I think it would be better to define explicit behavior for exceptions
raised from pre_init and post_init to be that the ORB initialization is
abandoned and the ORB is destroyed. Any ORBInitializer implementation
that really needs the ORB to ignore any thrown exceptions can simply
catch and discard them itself.

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes: 1. In section 21.7.1 (section 21.8.1 in the revised document) append the following sentences to the first paragraph:: "Any exceptional return from the invocation of any operation of the ORBInitializer interface other than those resulting from the failure to instantiate a portable interceptor object shall result in the abandonment of the ORB initialization and destruction of the ORB. Any ORBInitializer implementation that needs the ORB to ignore any thrown exceptions can simply catch and discard them itself." 2. In section 21.7.3.1 (section 21.8.3.1 in the revised document) replace the sentence that reads: "If there are any exceptions, the ORB shall ignore them and proceed." by: "If the attempt to instantiate an interceptor object fails the ORB shall ignore the failure and continue execution. For any other exceptions returned by pre_init or post_init, the ORB shall discontinue initialization and destroy itself, and the original exception returned by the ORBInitializer shall be returned by ORB_init."
Actions taken:
October 16, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: Abandoning ORB initialization and destroying it under these circumstances seems to be the only reasonable recourse. Document it as such in the specification

Issue 5690: ORBInitInfo::arguments() underspecified (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

21.7.2.3 states:


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


First, what good does this do?  A portable application can't depend on
anything useful being returned by this attribute.


This should be changed to state that ORBInitInfo::arguments() returns
the original unmodified argv parameter that was passed to ORB_init.


-----


Second, this attribute really ought to be read-write, so that an
Interceptor implementation can find and strip out arguments that are
intended for the Interceptor.


Alternatively, we should specify a standard prefix for arguments that
are recognized and processed by interceptors, so that the ORB and client
code can be explicitly coded to recognize and ignore them.

Resolution: see above
Revised Text: In formal/02-06-01 make the following changes: 1. In section 21.7.2.3 (section 21.8.2.3 in the revised document) replace the entire 1st paragraph by: "This attribute returns the original argv parameters as they were passed to ORB_init."
Actions taken:
October 16, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: The first point needs fixing. The second point is more controversial. Stripping arguments works only under the assumption that (a) the application has not already looked at and used those arguments before doing ORB_init, and (b) the arguments, while used by the interceptors are not also of use to the application. I.e assumes a particular usage pattern of the arguments which may or may not be what people do with them. The problem with normatively requiring use of prefixes is that it will break exisiting apps that do not use said prefixes. So the most that can be done is to give advise on how to use these arguments, and that is done better in training materials than in normative text of the standard. So let us not do anything about the seocnd point.

Issue 5691: What ORBInitInfo operations are legal during pre_init() and post_init()? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is no information in chapter 21 that specifies which operations on
ORBInitInfo can be legally called during pre_init or post_init.


The intention appears to be that calls to register new interceptors or
allocate a new slot id should be illegal during post_init.


Calling resolve_initial_references during pre_init does not appear to be
wise, but otherwise seems benign.


Proposed resolution:


Add the following to 21.7.1.2:


"During a call to post_init(), invoking the ORBInitInfo methods: 
add_client_request_interceptor, add_server_request_interceptor,
allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER
standard system exception with minor code nnn."

Resolution: Fix it as suggested in the archive.
Revised Text: In formal/02-06-01 make the following changes: 1. In Appendix section A.5 add a new minor code X5691 for BAD_INV_ORDER which says: "Invocation of this operation not allowed in post_init" 2. In section 21.7.1.2 (section 21.8.1.2 in the new document) append the following paragraph: "During a call to post_init(), invoking the ORBInitInfo methods: add_client_request_interceptor, add_server_request_interceptor, allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER standard system exception with minor code X5691
Actions taken:
October 18, 2002: received issue
April 28, 2003: closed issue

Discussion:

Issue 5692: What ORBInitInfo operations are legal during pre_init() and post_init()? (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is no information in chapter 21 that specifies which operations on
ORBInitInfo can be legally called during pre_init or post_init.


The intention appears to be that calls to register new interceptors or
allocate a new slot id should be illegal during post_init.


Calling resolve_initial_references during pre_init does not appear to be
wise, but otherwise seems benign.


Proposed resolution:


Add the following to 21.7.1.2:


"During a call to post_init(), invoking the ORBInitInfo methods: 
add_client_request_interceptor, add_server_request_interceptor,
allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER
standard system exception with minor code nnn."

Resolution: duplicate of issue 5691
Revised Text:
Actions taken:
October 17, 2002: received issue

Issue 5726: How do Portable Interceptors interact with Messaging callbacks (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the messaging callback model, the response is delivered as a request
invocation on another object.  What is the call-pattern for
ClientRequestInterceptors in this case?


My guess is that the receive_other interception point is called for each
registered ClientRequestInterceptor.

Resolution: close no change
Revised Text:
Actions taken:
October 25, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: 
This was already handled by the resolution for 3599 in vote 9.  The invoker of the sendc_ operation will cause the send_request client interception point followed by the receive_other or receive_exception interception points to be called.  After this, the request has been completed as far as PI is concerned.  When the response comes back, it will be handled as an independent invocation on the callback handler target object.

Issue 5743: CORBA::WrongTransaction and Interceptors (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

How can a portable OTS implementation, using only Portable Interceptors,
achieve the correct semantics for raising CORBA::WrongTransaction from
Request::get_response or ORB::get_next_response or type specific
pollers?  There doesn't appear to be a way to do this for two reasons:


1.  ClientRequestInterceptors can only change a request result into a
system exception, but WrongTransaction is a user exception.


2.  21.4.4.6 says:


"Interceptors shall assume that each client-side interception point
logically runs in its own thread, with no context relationship between
it and any other thread. While an ORB implementation may not actually
behave in this manner, it is up to the ORB implementation to treat
PICurrent as if it did."


I take this to mean that the PICurrent in the receive_* client
interception points cannot be guaranteed to share the same slot data as
the client thread that called Request::get_response.  This means that
the interceptor has no way to determine whether or not the transaction
context of the client thread matches that of the request.

Resolution: Resolved together with 3599. Resolution appears in the resolution for 3599
Revised Text:
Actions taken:
October 31, 2002: received issue
April 28, 2003: closed issue

Issue 5764: add a ClientInterceptor then create_POA() in the post_init() method? (corba-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: close no change
Revised Text:
Actions taken:
November 18, 2002: received issue
April 28, 2003: closed issue

Discussion:

Resolution: 
It is not clear what the filer of the issue is attempting to accomplish, since create_POA() and ClientInterceptors have no interactions. 
Also, the only way to be able to call create_POA inside a post_init() implementation is to call the ORBInitInfo::resolve_initial_references() operation to get the RootPOA, assuming that is even a good idea in the first place, since any registered IORInterceptors won't necessarily ever get run if the RootPOA and the child POA are created at that time. 

Otherwise, it appears to a question that pertains to the details of a particular product implementation

Issue 5766: Unfortunate CDR Encapsulation of ASN.1 Encodings (corba-rtf)

Click here for this issue's archive.
Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Indeed a severe interoperability problem. Fix as suggested.
Revised Text: In formal/02-06-01 make the following changes: 1. Remove the word "encapsulation" before "octet stream" from the rows of the table 24-2 "Identity Token Types". 2. Remove the word "encapsulation" in the fourth paragraph in section 24.2.3 "Authorization Token Format". 3. On page 24-60 emove the word "encapsulated" in the comments both before and after the IDL line that reads: "typedef sequence <octet> X509CertificateChain;" 4. On page 24-61 Remove the sentence "The two-part SEQUENCE is encapsulated in an octet stream." in the comment above the IDL const definition line that reads: "const AuthorizationElementType X509AttributeCertChain = OMGVMCID | 1;". 5. 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 theoctet 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."
Actions taken:
November 19, 2002: received issue
April 28, 2003: closed issue

Issue 5771: Type code creation (corba-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

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).

Resolution: Fix as suggested
Revised Text: In formal/02-06-01 make the following changes: 1. In section 4.11.3 fourth paragraph first sentence replace the phrase that reads: "the name is a valid IDL name or is a null string" by: "the name is a valid IDL name or is a empty string"
Actions taken:
December 1, 2002: received issue
April 28, 2003: closed issue

Issue 5781: What is the RSC when using a PersistentPoller (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution:
Revised Text:
Actions taken:
November 25, 2002: received issue
April 11, 2012: Deferred to next RTF

Discussion:

Issue 5856: Bad text in 22.6 mandates Routing for sendc/sendp (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

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."

Resolution:
Revised Text:
Actions taken:
February 11, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 5880: Clarification on multi-threaded codeset negotiation (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
Summary:

We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue.

The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6):

"Codeset negotiation is not performed on a per-request basis, but only when a client
initially connects to a server. All text data communicated on a connection are encoded
as defined by the TCSs selected when the connection is established."

but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter.

There are two possible approaches to solving this:

a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests.

b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information).

CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen?

Resolution:
Revised Text:
Actions taken:
March 11, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 5892: restriction of where a valuetype chunk can end (corba-rtf)

Click here for this issue's archive.
Source: AT&T (Dr. Duncan Grisby, )
Nature: Revision
Severity: Minor
Summary:

There is a small issue with the restriction of where a valuetype chunk can end. The spec says 

"The data may be split into multiple chunks at arbitrary points except within primitive CDR types, arrays of primitive types, strings, and wstrings, or between the tag and offset of indirections. It is never necessary to end a chunk within one of these types as the length of these types is known before starting to marshal them so they can be added to the length of the currently open chunk." 

However, in the case of array of wchar, the length is not known before starting to marshal, since each char (in GIOP 1.2 and 1.3) is marshalled as a (sort-of) sequence of octets. I think it should be legal to end a valuetype chunk in the middle of an array of char.

Resolution:
Revised Text:
Actions taken:
March 26, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 5895: Problem with ServerRequestInterceptor::receive_request and DSI (corba-rtf)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

21.3.9.2 states:

"In the DSI model, since the parameters are first available when the user code calls arguments, receive_request is called from within arguments. It is possible that arguments is not called in the DSI model. The target may call set_exception before calling arguments. The ORB shall guarantee that receive_request is called once, either through arguments or through set_exception."

The problem here, is that the DSI servant has already been invoked at this point, and the DSI implementation will be unaware that the server interceptor may have cancelled the invocation via raising a system exception or ForwardRequest user exception. So the DSI implementation will carry on, creating all sorts of wonderful havoc as it continues to interact with the ServerRequest PO.

Any vendors want to comment on what their PI implementation does now?

Proposed fix:

First, we should define a new system exception minor code that the servant implementation can detect so that it can clean up and get out of the way as expeditiously as possible when raised by arguments or set_exception. Perhaps a minor code for OBJ_ADAPTER? Should there be two minor codes, to distinguish a system exception from ForwardRequest as the reason for cancelling the invocation?

Second, we need some more text either in chapter 8 or 21 that states that any calls by the DSI implementation to ServerRequest::set_result or ServerRequest::set_exception will be ignored (or perhaps reraise the exception defined in the previous paragraph) if ServerRequestInterceptor::receive_request raises an exception.

Resolution:
Revised Text:
Actions taken:
April 2, 2003: received issue
April 11, 2012: Deferred to next RTF

Discussion:

Issue 5899: rules for marshalling ValueBoxes (corba-rtf)

Click here for this issue's archive.
Source: AT&T (Dr. Duncan Grisby, )
Nature: Uncategorized Issue
Severity:
Summary:

The GIOP specification does not say anything at all about the rules for marshalling ValueBoxes. 

I believe the expected format is to marshal ValueBoxes as if they were a normal Value with a single member, and that they follow the normal rules about indirections and chunking. The spec should clearly state this.

Resolution:
Revised Text:
Actions taken:
April 16, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 5939: ValueMembersSeq (corba-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

ValueMembersSeq is not defined in the CORE Specification and appears in interface ORB, but I believe it is a typo of ValueMemberSeq: 

TypeCode create_value_tc ( in RepositoryId id, in Identifier name, in ValueModifier type_modifier, in TypeCode concrete_base, in ValueMembersSeq members );

Resolution: In CORBA v3.3 Part 1 Interfaces, section section 8.2 change ValueMembersSeq to ValueMemberSeq
Revised Text: TypeCode create_value_tc ( in RepositoryId id, in Identifier name, in ValueModifier type_modifier, in TypeCode concrete_base, in ValueMemberSeq members );
Actions taken:
May 11, 2003: received issue
April 11, 2012: Deferred to next RTF
July 19, 2012: closed issue

Issue 5941: valuetype fragmentation ambiguous (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
Summary:

Although I now think I know the intent of the spec, its is ambiguous if not plain wrong with respect to valuetype fragmentation.


In particular 15.3.4.6:


Bullet 1 says:


"End tags, chunk size tags, and value tags are encoded using non-overlapping ranges
so that the unmarshaling code can tell after reading each chunk whether:
� another chunk follows (positive tag).
� one or multiple value types are ending at a given point in the stream (negative
tag).
� a nested value follows (special large positive tag)."


Bullet 3 says:


"� For the purposes of chunking, values encoded as indirections or null are treated as
non-value data."


And the pseudo-BNF says:


"(1) <value> ::= <value_tag> [ <codebase_URL> ]
[ <type_info> ] <state>
| <value_ref>
(2) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
(3) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
(4) <type_info> ::= <rep_ids> | <repository_id>
(5) <state> ::= <octets> |<value_data>* [ <end_tag> ]
(6) <value_data> ::= <value_chunk> | <value>"


Now clearly the implication of bullet 1 is that an indirection or null must appear  inside a chunk in a chunked encoding, otherwise you would be able to see the value 0 or -1 after a chunk and the -1 in particular could mean an end tag or an indirection. However the possible implication of bullet 3 and the BNF (note the use of "value data") is that nulls and indirections are values and thus must appear outside of chunks. Clearly the former interpretation is the correct one otherwise anarchy ensues.


So I propose that we change the 3rd bullet to say:


"For the purposes of chunking, values encoded as indirections or null are treated as
if they were not values and therefore must always appear inside a chunk when a chunked encoding is in effect."


and then change the BNF to say:


"(1) <value> ::= <concrete_value> | <value_ref>
(2) <concrete_value> ::= <value_tag> [ <codebase_URL> ]
[ <type_info> ] <state>
(3) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
(4) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
(5) <type_info> ::= <rep_ids> | <repository_id>
(6) <state> ::= <octets> |<value_data>* [ <end_tag> ]
(7) <value_data> ::= <value_chunk> | <concrete_value>"


etc

Resolution:
Revised Text:
Actions taken:
May 23, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 5952: BNF changes (corba-rtf)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 25, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 6007: Mapping from -ORBxxx to Java properties does not work for -ORBInitRef (corba-rtf)

Click here for this issue's archive.
Source: Syracuse University (Mr. C. Joncheng Kuo, joncheng_kuo(at)bristol.com)
Nature: Uncategorized Issue
Severity:
Summary:

The CORBA 3.0 spec adds the following note in Section 4.5.1: ORB Initialization.


"Whenever an ORB_init argument of the form -ORBxxx is specified, it is understood that the argument may be represented in different ways in different languages. For example, in Java -ORBxxx is equivalent to a property named org.omg.CORBA.ORBxxx."


The approach stated in the above note does not work for -ORBInitRef. For example, if you have
   -ORBInitRef NameService=URL,
you cannot translate the above arguments into a property named "org.omg.CORBA.ORBInitRef" because there can be only one property of this name and there may be many different services. This issue was slightly cover by Issue 3643 (java-rtf), which was not resolved. This issue becomes obvious and important because the note added in the CORBA 3.0 spec.


Proposed solution: Arguments like "-ORBInitRef id=url" should be equivalent to a property named "org.omg.CORBA.ORBInitRef.id" with value "url".

Resolution:
Revised Text:
Actions taken:
July 19, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 6050: 15.3.3 - codesets must be "explicitly defined" (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com)
Nature: Uncategorized Issue
Severity:
Summary:

For codesets in encapsulations we have:


15.3.3 - codesets must be "explicitly defined"


Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it"


But in 13.8 there is no prescribed way of "explicitly defining" the codeset.


Please, please can we simply define that the fallbacks in 13.10.2.6 apply everywhere that the codeset is not known (whether negotiated or not) and be done with it.


Another alternative would be to add codeset parameters to the encode() and decode() functions of  13.8.

Resolution:
Revised Text:
Actions taken:
August 26, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 6283: CodeSet and CSIv2 Negotitaion (corba-rtf)

Click here for this issue's archive.
Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

I believe that we send CSIv2 stuff in a GIOP Request until a corresponding
GIOP reply has been containing corresponding CSIv2 context ids is sent.


For Codeset, I think the policy is to send the service context in each
GIOP request until a corresponding GIOP Reply is received, thereby saying
that the "negotiation" is completed and excepted (otherwise an exception
will be raised.


We should probably look at the fact that multiple NSReq messages can be
sent, and there are no corresponding reply messages depending on the
service contexts.


I think that these messages should be intercepted since they are
delivering service contexts.

Resolution:
Revised Text:
Actions taken:
October 2, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 6285: Change new GIOP Negotiate Session Message to Firewall Specific (corba-rtf)

Click here for this issue's archive.
Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

Here is a small proposal for GIOP 1.4 with Firewall and Bidirectional. We
would get rid of all the weird nasty service contexts and make it
simplistic. The FireWall messages are only allowed before any other GIOP
messages. BiDir messages can happen at any time according to their
protocol.


What do you think? Asside from some problems I see with BiDir
offer/challenge/response correlation, it is essentially equivalent to the
solution proposed in the adopted spec.


module GIOP {
    enum MsgType_1_4{
        Request,            Reply,          CancelRequest,
        LocateRequest,      LocateReply,
        CloseConnection,    MessageError,
        Fragment,           // GIOP 1.1 addition


        // GIOP 1.4 additions


        FirewallPathRequest,        // 8
        FirewallPathRepsonse,       // 9
        BiDirOffer,                 // 10
        BiDirChallenge,             // 11
        BiDirResponse               // 12
    };


    // Firewall Traversal GIOP 1.4


    struct FirewallSpec {
        boolean                     is_intelligent;
        IOP::TaggedComponentSeq     endpoints;
    };
    typedef sequence<FirewallSpec> FirewallPath;


    struct FirewallPathRequestHeader {
        unsigned long           host_index;
        FirewallPath            path;
    };
    // No body follows.


    enum FirewallPathResponseStatusType {
        NO_EXCEPTION,
        SYSTEM_EXCEPTION
    };


    struct FirewallPathResponseHeader{
        FirewallPathResponseStatusType  status;
        boolean                         connection_complete;
    };
    // Marshalled body immediately follows


    // Bidirectional GIOP 1.4


    // To keep this file uncomplicated we can introduce the
    // headers and put the marshalled bodies in a separate BiDir module
    // Due due some issue about the challege/response protocol for this,
    // there may be a need of an offer_id to correlate them.


    struct BiDirOfferHeader{
        unsigned long offer_id;
    };
    // Marshalled body immediately follows.


    struct  BiDirChallengeHeader {
        unsigned long offer_id;
    };
    // Marshalled body immediately follows.


    struct BiDirResponseHeader  {
        unsigned long offer_id;
    };
    // Marshalled body immediately follows.
};

Resolution:
Revised Text:
Actions taken:
October 2, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 6287: Chapter/section: 15.4.2.2 "Request Body" (corba-rtf)

Click here for this issue's archive.
Source: 2AB (Ms. Carol Burt, cburt(at)2ab.com)
Nature: Clarification
Severity: Critical
Summary:

Suppose you are sending a request (GIOP 1.2 or 1.3) and the request will
be fragmented into two segments. The first segment is a Request message
that has the GIOP Header and part of the Request Header. The second
segment is a Fragment message that has a GIOP Header, a Fragment Header,
and the body is the remainder of the Request Header and the Request Body.
Section 15.4.2.2 of CORBA 3.0 states that the Request Body (in a Request
Message) should always be aligned on an 8 octet boundary.


My question is, in the above scenario, where the Request Body begins in
the Fragment message, should the Request Body be aligned on an 8 octet
boundary or not? I have not found anything in the specification that
explicitly says what to do.

Resolution:
Revised Text:
Actions taken:
October 1, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 6314: GIOP Conformance and Interceptors (corba-rtf)

Click here for this issue's archive.
Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com)
Nature: Uncategorized Issue
Severity:
Summary:

GIOP Conformance and Interceptor don't play well together.


GIOP minor version conformance mandates two things.


1. That standard service contexts that are considered optional
   can be ignored should the implementation not understand them.


2. That certain service contexts get processed according to the
   specification of where they are defined.


This requirement works well for GIOP 1.2 where a lot of them are optional,
since (1) will apply. An implementation can claim 1.2 conformance and not
process any of them.


However, 1.3 and upcoming 1.4 will mandate the processing of them
according to their specification. In many cases, this means that some
default response may be required, which means that a GIOP 1.3, or later
engine must have a "default" response for these service contexts.


In an ORB that uses interceptors and has a generic GIOP messaging engine
there is no way for the engine to "know"  when or not to process a
particular service context. It requires strict processing by the GIOP
engine, or it requires "default" interceptors to be installed to maintain
the level of conformance.


However, interceptors have no way of "declaring" which service contexts
they handle, and whether they they are overriding already installed
(default) interceptors for processing those particular service contexts.


For example, an non-transactional ORB that is GIOP 1.2 compliant must
process the Transaction Service Context by raising a
TRANSACTION_UNAVAILABLE exception, because by default the ORB is in the
OTS_NOT_CONNECTED state. It cannot be ignored to comply with GIOP 1.2 (but
by certain in implementations it ALWAYS is). A default interceptor is
needed in the ORB implementation to do this. However, for an ORB
configuration that wants to process this, there is no way for an
interceptor to "override" default processing.

Resolution:
Revised Text:
Actions taken:
October 8, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 6318: valuetypes and local interfaces (corba-rtf)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

The spec appears silent as to whether valuetypes are allowed to support local interfaces. Table 3-10, for example, says nothing at all about local interfaces.
 
There's a couple ways to look at this. First, valuetypes are not CORBA objects. Servants for local interfaces are direct CORBA object instances, i.e., the "local" declaration on an interface effectively removes the distinction between a CORBA object and its servant. If a valuetype were used as a servant for a local object, then the valuetype would itself also be a CORBA object. By this analysis, valuetypes should not be allowed to support local interfaces.
 
Another way to look at it is that the valuetype should just inherit the local interface's operations and attributes without having any subtype/subclass relationship with the base local interface. This would be a rather pointless approach to take, is there would be no possibility of using the valuetype polymorphically with respect to the base local interface.

Resolution:
Revised Text:
Actions taken:
October 16, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 6391: Interface Introspection (corba-rtf)

Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

Inspired by a recent paper by Doug Schmidt and Steve Vinoski
and the resulting newsgroup discussion on comp.object.corba,
I have a feature request to introduce a better reflection
mechanism into CORBA.


At the moment, there is the CORBA::Object::get_interface()
operation to access a matching InterfaceDef entry in an
Interface Repository. Since an Interface Repository is
seldomly deployed, using this operation is pretty much
futile and will either return a nil reference or throw
an exception.


Therefore, I propose to add a new get_interface_def()
operation to the Object interface that returns a FullInter-
faceDef structure, as defined by the Interface Repository.
This structure contains all that a dynamic client (such as
the ones proposed by Schmidt&Vinoski, or software like
CorbaScript or Combat) needs to know about an interface.


A new _interface_def pseudo-operation then needs to be added
to GIOP. This could probably be done without a version change,
as no marshalling changes or new messages are involved, it's
just another operation.


On the server side, the IDL compiler would generate a suitable
implementation as part of the skeleton. This implementation
could just contain a binary representation of the FullInterface-
Description structure (just like a "precompiled" TypeCode) that
is dumped to the GIOP stream. (So that you don't need the
Interface Repository IDL around.)


Proposed resolution:


In chapter 4.3, "Object Reference Operations," add the following
operation to the Object interface:


  module CORBA {
    interface Object { // PIDL
      ... other operations ...
      FullInterfaceDescription get_interface_def ();
    };
  };


Add the following explanation to 4.3.1, "Determining the Object
Interface"


  4.3.1.2 get_interface_def


  FullInterfaceDescription get_interface_def ();


  The get_interface_def operation returns a data structure
  describing the most derived type of the object addressed by
  the reference. The FullInterfaceDescription structure includes
  descriptions of all the operations and attributes in the
  transitive closure of the inheritance graph of the interface
  being described. See the Interface Repository chapter for the
  contents of the data structure. Note that if an Interface
  Repository is not available, object references contained in
  this structure may be nil or inaccessible.


In chapter 15.4.2, "Request Message", update the text that
reads


  In the case of CORBA::Object operations that are defined in
  the CORBA Core (Section 4.2, "Object Reference Operations,"
  on page 4-12) and that correspond to GIOP request messages,
  the operation names are _interface, _is_a, _non_existent,
  _domain_managers and _component.


to read


  In the case of CORBA::Object operations that are defined in
  the CORBA Core (Section 4.2, "Object Reference Operations,"
  on page 4-12) and that correspond to GIOP request messages,
  the operation names are _interface, _is_a, _non_existent,
  _domain_managers, _component or _interface_def.


In the C++ language mapping, section 1.37.1, "Mapping of
PortableServer::Servant", add the following operation to
class ServantBase:


  namespace PortableServer { // C++
    class ServantBase {
      ... other operations ...
      virtual CORBA::FullInterfaceDescription_ptr
        _get_interface_def ();
    };
  }


Update the paragraph that reads,


  ServantBase provides default implementations of the
  _get_interface, _is_a and _non_existent object reference
  operations [...]


to read


  ServantBase provides default implementations of the
  _get_interface, _is_a, _non_existent and _get_interface_def
  object reference operations [...]


Add a new paragraph,


  For static skeletons, the default implementation of the
  _get_interface_def function returns information about the
  interface associated with the skeleton class. For dynamic
  skeletons, the default implementation uses the
  _get_interface function to determine its return value.


Other language mappings might need similar updates.


By the way, since FullInterfaceDescription is only used as
a return value, only a pointer to FullInterfaceDescription
is needed. Therefore, you don't need the full Interface
Repository interface descriptions but only a pointer to an
incomplete type.


On the client side, you only need to pull in the Interface
Repository IDL if you are actually calling _get_interface_def.


On the server side, the skeleton can do some ORB-dependent
magic to push a precompiled binary data structure into the
result.

Resolution:
Revised Text:
Actions taken:
October 27, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 6424: Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy (corba-rtf)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Wolfgang Haefelinger, nobody)
Nature: Clarification
Severity:
Summary:

[..] It is used to indicate  the relative amount
of time for which a Request or its corresponding
Reply  may  be  delivered. After  this amount of 
time, the  Request  is cancelled  (if a response 
has not  yet been received  from  the target) or 
the Reply  is  discarded  (if  the  Request  had
already been delivered and a Reply returned from
the target) [..]
---------------------------------------------------------
Question:


* What  is  the precise  meaning  of "Request is
cancelled"?


Does it mean that client ORB just  gives  up  or
does it mean that client tries, in kind of  best
effort semantics, to cancel request  on  server?


If this cancellation fails, how will client user
be  informed  about  this?  By  a  minor code in 
thrown Timeout exception? 


Is it possible to clarify this?

Resolution:
Revised Text:
Actions taken:
October 29, 2003: received issue
April 11, 2012: Deferred to next RTF

Issue 6899: CORBA 3.02, page 11-25, section 11.3.6 (corba-rtf)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

Fifth bullet near the beginning of this section states:
 
Incarnations of a particular object may not overlap; that is, incarnate shall not be invoked with a particular ObjectId while, within the same POA, that ObjectId is in use as the ObjectId of an activated object or as the argument of a call to incarnate or etherealize that has not completed.
 
Unfortunately, I do not see anywhere where the exception to be thrown from activate_object_with_id() for this case is specified. According to this text, if incarnate() is executing for a particular ObjectId, any calls to activate_object_with_id() should be rejected by the POA. This came up in comp.object.corba, where someone posted a question as to why Orbix 2000 throws the ObjectAlreadyActive exception for this case.

Resolution:
Revised Text:
Actions taken:
January 12, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 6912: Error in Chapter 21 of CORBA 3.0 (corba-rtf)

Click here for this issue's archive.
Source: Oracle (Mr. Ken Cavanaugh, nobody)
Nature:
Severity:
Summary:

there is a serious error in Chapter 21 in both the CORBA 3.0 specification and the 3.1 drafts.  The ORT final adopted specification (ptc/01-08-31 mentioned above) does NOT contain the methods ObjectReferenceFactory::equals an ObjectReferenceFactory::make_profiles.  These methods were first added in the ORT FTF in issue 4476, then removed after further discussion in issue 4478.  The final adopted specification reflects this, but somehow the incorrect text was incorporated into the official CORBA 3.0 specification. Unfortunately I only noticed this recently

Resolution: issue closed editorially
Revised Text:
Actions taken:
February 5, 2004: closed issue

Issue 7340: module SendingContext (corba-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

The CORBA specification has module SendingContext { //... interface CodeBase { //... CORBA::FullValueDescription meta(in CORBA::RepositoryId x); //... }; //... }; but there is no CORBA::FullValueDescription defined in the specification, yet the supplied <SendingContext.idl> file declares module SendingContext { //... interface CodeBase { //... CORBA::ValueDef::FullValueDescription meta(in CORBA::RepositoryId x); //... }; //... };

Resolution:
Revised Text:
Actions taken:
May 15, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 7592: An extension of IOR to protect target objects Nature (corba-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity:
Summary:

Related Specification: CommonObject Request Broker Architecture: Core Specification November 2002 Version 3.0 - Editorial edit to cover formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect target objects Nature: Enhancement Issue Summary: IOR (Interoperable Object Reference) is the distributed reference of a CORBA object. The IOR of a target object is distributed to client applications that want to access the target object. Clients can easily connect to the target objects based on the location information in IOR. As a kind of object discovery scheme, IOR publishes some attributes related to target object, such as IP address, port number, internal object id, etc. As we know, many kinds of attacks can be performed to a target server when the IP address and port number of the target is exposed. The exposition of internal object id may also leads to security problems. We use Abstract IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent to client applications, thus the target objects is protected from potential attacks. Proposed solution: We use proxy technology to protect target servers, following is the architecture of a typical scenario. Service Proxy (SP) acts as a portal for all background servers. SP will handle all requests from clients to background servers. So background servers are transparent to clients. +-------------+ +-------------+ | Client | Abstract IORs | Service | | application +-----------------++ Proxy | | | | | +-------------+ +---+--+--+---+ BS1's IORs | | | +---------------------------+ | | | BS2's IORs | | + +--------------+ | +------+-----+ + +-+ BS3's IORs | Background | +------+-----+ + | Server 1 | | Background | +------+-----+ +------------+ | Server 2 | | Background | +------------+ | Server 2 | +------------+ The core concept of the above architecture is Abstract IOR (AIOR). AIOR can be described by a simple equation: AIOR = SP's regular IOR + logical name Logical name is uniquely corresponding to an IOR of an object running on background server. So the SP should set up the mapping before corresponding request comes, and map the logical name in the AIOR to the regular IOR of the target object at background server for a coming request. The structure of AIOR is compatible to regular IOR. Firstly let's have a look at the structure of regular IOR defined at page 13-15. Then we will discuss how to support AIOR based on existing IOR data structures and what interfaces and methods will be defined. module IOP { // IDL // Standard Protocol Profile tag values typedef unsigned long ProfileId; struct TaggedProfile { ProfileId tag; sequence <octet> profile_data; }; typedef sequence <TaggedProfile> TaggedProfileSeq ; // an Interoperable Object Reference is a sequence of // object-specific protocol profiles, plus a type ID. struct IOR { string type_id; sequence <TaggedProfile> profiles; }; // Standard way of representing multicomponent profiles. // This would be encapsulated in a TaggedProfile. typedef unsigned long ComponentId; struct TaggedComponent { ComponentId tag; sequence <octet> component_data; }; typedef sequence<TaggedComponent> TaggedComponentSeq; }; CORBA specification defines 3 standard IOR profiles (at page 13-17): module IOP { const ProfileId TAG_INTERNET_IOP = 0; const ProfileId TAG_MULTIPLE_COMPONENTS = 1; const ProfileId TAG_SCCP_IOP = 2; typedef sequence <TaggedComponent> MultipleComponentProfile; }; The following are standard IOR components that can be included in TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS profiles, and may apply to IIOP, other GIOPs, ESIOPs, or other protocols. An ORB must not drop these components from an existing IOR (at page 13-19). module IOP { const ComponentId TAG_ORB_TYPE = 0; const ComponentId TAG_CODE_SETS = 1; const ComponentId TAG_POLICIES = 2; const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3; const ComponentId TAG_ASSOCIATION_OPTIONS = 13; const ComponentId TAG_SEC_NAME = 14; const ComponentId TAG_SPKM_1_SEC_MECH = 15; const ComponentId TAG_SPKM_2_SEC_MECH = 16; const ComponentId TAG_KerberosV5_SEC_MECH = 17; const ComponentId TAG_CSI_ECMA_Secret_SEC_MECH = 18; const ComponentId TAG_CSI_ECMA_Hybrid_SEC_MECH = 19; const ComponentId TAG_SSL_SEC_TRANS = 20; const ComponentId TAG_CSI_ECMA_Public_SEC_MECH = 21; const ComponentId TAG_ GENERIC_SEC_MECH = 22; const ComponentId TAG_FIREWALL_TRANS = 23; const ComponentId TAG_SCCP_CONTACT_INFO = 24; const ComponentId TAG_JAVA_CODEBASE = 25; const ComponentId TAG_TRANSACTION_POLICY = 26; const ComponentId TAG_MESSAGE_ROUTERS = 30; const ComponentId TAG_OTS_POLICY = 31; const ComponentId TAG_INV_POLICY = 32; const ComponentId TAG_CSI_SEC_MECH_LIST = 33; const ComponentId TAG_NULL_TAG = 34; const ComponentId TAG_SECIOP_SEC_TRANS = 35; const ComponentId TAG_TLS_SEC_TRANS = 36; const ComponentId TAG_ACTIVITY_POLICY = 37; const ComponentId TAG_INET_SEC_TRANS = 123; }; The following additional components that can be used by other protocols are specified in the DCE ESIOP chapter of this document and CORBAServices, Security Service, in the Security Service for DCE ESIOP section (at page 13-19, 13-20): const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service The following is the description of our proposed supplement to CORBA core specification. We add one component into module IOP: const ComponentId TAG_AIOR_LOGICALNAME = XXX; // XXX is an undetermined ComponentId. The TAG_AIOR_LOGICALNAME component has an associated value of type string encoded as a CDR encapsulation. We have not defined the interface of mapping logical names to regular IOR because now this function is local and its interoperability is not necessary. But if two or more SPs want to exchange their mapping items to provide more intelegent services, we may need to define the coresponding interfaces.

Resolution:
Revised Text:
Actions taken:
July 15, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 7730: Codec Interface Deficiencies (corba-rtf)

Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 3, chapter 13.8, defines the Codec interface to encode
arbitrary data values into CORBA::OctetSeq "blobs" and vice
versa. This interface can be used, e.g., to supply and retrieve
ServiceContext data using the PortableInterceptor interfaces.


In practice, the Codec interface is also being used for data
serialization, i.e., to store and retrieve arbitrary values in
files or other databases.


However, the interface is deficient in that it does not consider
all possible variables that are needed for interoperability.
It supports setting the CDR version that is to be used, but
neglects byteorder and codeset settings.


Consequently, the encoded values are platform-specific. If a
value was encoded on a little-endian system, it will not decode,
or worse, decode erroneously, on a big-endian system. The same
caveats apply to codesets, e.g., when an ISO-8859-1 encoded
blob is decoded using UTF-8 or Windows-1252.


To support interoperability, the Codec interface needs to be
extended.


My recommendation is to extend the CodecFactory interface,
so that it supports creating CDR version-, byteorder-, and
codeset-specific Codec instances, either supplying user-
provided values for each, or informing the user about chosen
defaults.


Example:


module IOP {
  const EncodingFormat ENCODING_DEFAULT = -1;


  typedef short ByteorderFormat;
  const ByteorderFormat BYTEORDER_DEFAULT = -1;
  const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
  const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;


  struct EncodingExt {
    EncodingFormat format;
    octet major_version;   // set to 0 for default
    octet minor_version;
    ByteorderFormat byteorder;
    CONV_FRAME::CodeSetId char_data; // set to 0 for default
    CONV_FRAME::CodeSetId wchar_data; // set to 0 for default
  };


  local interface CodecFactory {
    // create_codec remains as before
    Codec create_codec_ext (inout EncodingExt enc)
      raises (UnknownEncoding);
  };
};


The create_codec_ext operation would create an appropriate
Codec instance, if available; it will then set all "default"
members of the EncodingExt structure to their actual values,
so that the application can store this information along
with any encoded values.


One potential criticism of the above is that the encoding
format's parameters depend on the encoding format. For example,
there may be encoding formats that are byteorder-independent,
or that consistently use UTF-32 for strings, thus not needing
codeset parameters. Also, they may use wildly different
versioning. So a "better" solution might involve passing
the EncodingFormat, and an Any with a format-specific data
type.


That could look like:


module GIOP {
  typedef short ByteorderFormat;
  const ByteorderFormat BYTEORDER_DEFAULT = -1;
  const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
  const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;


  struct CDREncodingParameters {
    octet major_version;   // set to 0 for default
    octet minor_version;
    ByteorderFormat byteorder;
    CONV_FRAME::CodeSetId char_data; // set to 0 for default
    CONV_FRAME::CodeSetId wchar_data; // set to 0 for default
  };
};


module IOP {
  const EncodingFormat ENCODING_DEFAULT = -1;


  local interface CodecFactory {
    // create_codec remains as before
    Codec create_codec_ext (inout EncodingFormat format,
                            inout Any parameters)
      raises (UnknownEncoding);
  };
};


Once we have consensus on the approach, I will gladly volunteer
to come up with a full set of editing instructions

Resolution:
Revised Text:
Actions taken:
September 9, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 7731: Codec Interface Deficiencies (corba-rtf)

Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 3, chapter 13.8, defines the Codec interface to encode
arbitrary data values into CORBA::OctetSeq "blobs" and vice
versa. This interface can be used, e.g., to supply and retrieve
ServiceContext data using the PortableInterceptor interfaces.


In practice, the Codec interface is also being used for data
serialization, i.e., to store and retrieve arbitrary values in
files or other databases.


However, the interface is deficient in that it does not consider
all possible variables that are needed for interoperability.
It supports setting the CDR version that is to be used, but
neglects byteorder and codeset settings.


Consequently, the encoded values are platform-specific. If a
value was encoded on a little-endian system, it will not decode,
or worse, decode erroneously, on a big-endian system. The same
caveats apply to codesets, e.g., when an ISO-8859-1 encoded
blob is decoded using UTF-8 or Windows-1252.


To support interoperability, the Codec interface needs to be
extended.


My recommendation is to extend the CodecFactory interface,
so that it supports creating CDR version-, byteorder-, and
codeset-specific Codec instances, either supplying user-
provided values for each, or informing the user about chosen
defaults.


Example:


module IOP {
  const EncodingFormat ENCODING_DEFAULT = -1;


  typedef short ByteorderFormat;
  const ByteorderFormat BYTEORDER_DEFAULT = -1;
  const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
  const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;


  struct EncodingExt {
    EncodingFormat format;
    octet major_version;   // set to 0 for default
    octet minor_version;
    ByteorderFormat byteorder;
    CONV_FRAME::CodeSetId char_data; // set to 0 for default
    CONV_FRAME::CodeSetId wchar_data; // set to 0 for default
  };


  local interface CodecFactory {
    // create_codec remains as before
    Codec create_codec_ext (inout EncodingExt enc)
      raises (UnknownEncoding);
  };
};


The create_codec_ext operation would create an appropriate
Codec instance, if available; it will then set all "default"
members of the EncodingExt structure to their actual values,
so that the application can store this information along
with any encoded values.


One potential criticism of the above is that the encoding
format's parameters depend on the encoding format. For example,
there may be encoding formats that are byteorder-independent,
or that consistently use UTF-32 for strings, thus not needing
codeset parameters. Also, they may use wildly different
versioning. So a "better" solution might involve passing
the EncodingFormat, and an Any with a format-specific data
type.


That could look like:


module GIOP {
  typedef short ByteorderFormat;
  const ByteorderFormat BYTEORDER_DEFAULT = -1;
  const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
  const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;


  struct CDREncodingParameters {
    octet major_version;   // set to 0 for default
    octet minor_version;
    ByteorderFormat byteorder;
    CONV_FRAME::CodeSetId char_data; // set to 0 for default
    CONV_FRAME::CodeSetId wchar_data; // set to 0 for default
  };
};


module IOP {
  const EncodingFormat ENCODING_DEFAULT = -1;


  local interface CodecFactory {
    // create_codec remains as before
    Codec create_codec_ext (inout EncodingFormat format,
                            inout Any parameters)
      raises (UnknownEncoding);
  };
};


Once we have consensus on the approach, I will gladly volunteer
to come up with a full set of editing instructions

Resolution: duplicate
Revised Text:
Actions taken:
September 24, 2004: closed isuse

Issue 7890: methods on the POA (corba-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

A lot of the methods on the POA which have USE_DEFAULT_SERVANT or USE_SERVANT_MANAGER as policies don't describe in detail what should happen when one of these policies is set, but no default servant/servant manager is set. For example reference_to_servant, when USE_DEFAULT_SERVANT is set and default servant is registered we return the default servant, but what when no default servant is set, is then the ObjectNotActive the correct exception? Shouldn't this be something like a system exception (bad inv order, obj adapter or something like that?)

Resolution:
Revised Text:
Actions taken:
November 1, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 7891: Make a typedef for the POA id new (corba-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Made a typedef for the POA id new: local interface POA { typedef CORBA::OctetSeq POAid; } change: local interface POA { readonly attribute CORBA::OctetSeq id; } to: local interface POA { readonly attribute POAid id; }

Resolution:
Revised Text:
Actions taken:
November 1, 2004: received issue
July 11, 2011: closed issue

Issue 7892: Add a typedef for the POAManager id (corba-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Add a typedef for the POAManager id and use this throughout the spec for POAManager, POAManagerFactory and IORInterceptor add typedef string POAManagerId change in POAManager string get_id(); to POAManagerId get_id(); Or better (see other issue). readonly attribute POAManagerId the_id;

Resolution:
Revised Text:
Actions taken:
November 1, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 7893: change in the POAManager (corba-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

I would propose to change in the POAManager the following: State get_state(); string get_id(); to readonly attribute State the_state; readonly attribute string the_id; The get method just hide the fact that this are readonly attributes

Resolution:
Revised Text:
Actions taken:
November 1, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 7896: argument of the set_servant call has a small typo (corba-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The argument of the set_servant call has a small typo, it must be p_servant to match the full IDL spec some pages further

Resolution:
Revised Text:
Actions taken:
November 2, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 7900: omission from the OMG --Trader spec (corba-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Given a property P defined by type B as PROP_NORMAL, two types T1 and T2 inherit from B but each strengthens the mode to PROP_READONLY and PROP_MANDATORY respectively. Then is there an implied strengthening to PROP_MANDATORY_READONLY in a further derived type T3 which inherits from both T1 and T2? Related to this, the OMG spec has nothing to say about waht exception should be raised by an attempted "weakening" of a property mode by a sub-type or exactly what is construed as a "weakening" with multiple inheritance. Another slightly different senario is: Given a property P defined by type B as PROP_READONLY, two types T1 and T2 inherit from B with one of them "strengthening" the mode of B to PROP_MANDATORY_READONLY. Is deriving a type T3 from both T1 and T2 legal?

Resolution:
Revised Text:
Actions taken:
November 3, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 7955: The POA state inactive is not used consistent. (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

The POA state inactive is not used consistent. On several places it is called deactivated instead of inactive. For example in 11.3.8.2, in the transient bullet, it mentions: "Once the POA's POAManager enters the dactivated state". Chapter 11.3.2.1 describes clearly the states are: active, inactive, holding and discarding. I would propose to scan the complete spec for these incorrect POA Manager state.

Resolution:
Revised Text:
Actions taken:
December 1, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 7978: CORBA 3.0.3 ch. 3.4 OMG IDL Grammar (corba-rtf)

Click here for this issue's archive.
Source: EADS (Mr. Oliver M. Kellogg, oliver.kellogg(at)cassidian.com)
Nature: Clarification
Severity:
Summary:

The grammar definition for valuetype <state_member> via the rule
<declarators> includes <complex_declarator>.


It should be clarified whether valuetype state members are intended
to include <array_declarator>.


IMHO clarification is needed as state members are usually mapped
to accessor methods in programming languages. If permissible,
the accessor methods would return a complex type.

Resolution:
Revised Text:
Actions taken:
December 15, 2004: received issue
April 11, 2012: Deferred to next RTF

Issue 8221: Section: 4.3.13 (corba-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The spec describes respository_id which should be repository_id. Is on two places, in 4.3.14 and 4.3

Resolution:
Revised Text:
Actions taken:
February 3, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8230: Appendix A (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

The overview of all system exceptions is missing several ones which seem to be availalble in http://www.omg.org/docs/omg/03-01-04 For example NO_IMPLEMENT_TABLE minor code 8 is missing

Resolution:
Revised Text:
Actions taken:
February 4, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8244: Code Set Conversion on Operations (corba-rtf)

Click here for this issue's archive.
Source: Motorola (Mr. Gary Duzan, gary.duzan(at)motorola.com)
Nature: Uncategorized Issue
Severity:
Summary:

 The "operation" field in the RequestHeader_1_2 struct is a string,
which implies that it should be subject to code set conversion. However,
existing practice seem to be that it is not converted, and there are other
factors which could make it difficult for implementations to convert it.
In addition, since the operation name is based on IDL/ASCII, conversion
doesn't necessarily make sense.


   The easiest remedy would be to specify this as an exception in the
text of the spec. The "correct" remedy would probably be to change the
operation field from "string" to "sequence<octet>". This could cause
problems at some point, but it might not break too much since the CDR
encodings are the same.

Resolution:
Revised Text:
Actions taken:
February 7, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8586: Moving *Seq typedefs into ORB chapter (corba-rtf)

Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the CORBA specification, chapter 5 (Value Type
Semantics), section 5.5 (Custom Marshalling), defines
sequences of primitive types in the CORBA module,
i.e., CORBA::StringSeq et al. Some of these types are
then used by the DynamicAny and Portable Interceptor
chapters.


The presence of these typedefs in section 5.5 seems
to imply that they only need to be defined if the ORB
implements custom marshalling -- a feature still
lacking in some open-source and commercial ORBs.


In my experience, having worked with multiple ORBs,
many of them do not provide the complete set of
typedefs in their "orb.idl" file. Many ORBs only
provide a limited set, usually, the set that is
exercised by the other ORB features (such as PI).
This implies that most ORBs added these typedefs
on an "as needed" basis instead of simply referring
to section 5.5.


I suggest to move these typedefs from section 5.5
into chapter 4 (ORB interface), e.g., into section
4.2 (ORB operations) to highlight that these types
should be present even if custom marshalling is not
implemented by the ORB.


Proposed resolution:


In section 5.5.2 (Marshalling Streams), cut the
type definitions, starting with AnySeq, up to and
including WStringSeq.


In section 4.2, in the IDL code fragment, at the
beginning of the CORBA module, paste the type
definitions cut above.

Resolution:
Revised Text:
Actions taken:
March 17, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8618: Minor code ambiguity (corba-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Neil Richards, neil_richards(at)uk.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the CORBA specification dated 04-03-12, the last two paragraphs on page 15-33 (section 15.4.1) describe the use of MARSHAL minor codes 7 and 8. 
However, this use of these minor codes is not reflected in the table of minor codes on page A-11 (appendix A). 

Furthermore, MARSHAL minor code 7 has also been assigned (at an earlier date?) to an issue resolved in the Java to IDL specification dated 03-09-04 (see page 1-50 / end of section 1.5.1.5). 
This use of minor code 7 is reflected in the table in the CORBA specification. 
However minor code 10, which is also specified in the same section in the Java to IDL specification, is not documented in the CORBA specification. 

In summary, MARSHAL minor code 7 is double-booked, whilst minor codes 8 (used in the CORBA specification) and 10 (used by the Java to IDL specification) are not documented in the table of codes. 

Proposed solution: 

Change section 15.4.1 to define the use of MARSHAL minor code 9  (in addition to minor code 8), instead of MARSHAL minor code 7. 

Update the table of minor codes on page A-11 with the definitions of MARSHAL minor codes 8, 9 and 10.

Resolution:
Revised Text:
Actions taken:
March 21, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8629: Typo in sections 22.10.1.1 and 22.10.1.2 (corba-rtf)

Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

In section 2.10.1.1, page 22-26 (my copy is formal/04-03-01), 
enumerated item 3, second bullet, the text reads "232-1 - the
maximum value for unsigned long [...]". The "32" needs to be
in superscript, i.e., to indicate "2 to the power of 32 minus
1".


The same typo exists in section 2.10.1.2, page 22-28, fourth
paragraph, second bullet (at the top of the page).

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8630: Section: 7.4 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

Minor formatting issue in: abstract valuetype Pollable { boolean is_ready( in unsigned long timeout ); PollableSet create_pollable_set( ); }; boolean is_ready is in the wrong font in the idl overview

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8631: Section: 13.6.2 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

Update: struct IOR { string type_id; sequence <TaggedProfile> profiles; }; to struct IOR { string type_id; TaggedProfileSeq profiles; }; And also use CORBA::OctectSeq instead of sequence<octet>

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8632: Section: 4.2 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

The is an error in the ServiceDetail struct. service_detail is listed twice, the first one should be removed. struct ServiceDetail { ServiceDetailType service_detail_type; sequence <octet> service_detail; ServiceDetailData service_detail; };

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8633: Section: 4.2 (02) (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

Struct ServiceInformation is wrong, the sequence<> lines should be removed. struct ServiceInformation { sequence <ServiceOption> service_options; ServiceOptionSeq service_options; sequence <ServiceDetail> service_details; ServiceDetailSeq service_details; };

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8783: update the spec to not used anonymous types (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

The spec describes that anonymous types are deprecated and will be removed in the future (as below), but this is used throughout the spec. Before deprecating this fully, update the spec to not used anonymous types: >From 3.11.6 IDL currently permits the use of anonymous types in a number of places. For example: struct Foo { long value; sequence<Foo> chain; // Legal (but deprecated) } Anonymous types cause a number of problems for language mappings and are therefore deprecated by this specification. Anonymous types will be removed in a future version, so new IDL should avoid use of anonymous types and use a typedef to name such types instead. Compilers need not issue a warning if a deprecated construct is encountered.

Resolution:
Revised Text:
Actions taken:
May 18, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8843: Section: 21.7 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Significant
Summary:

In the draft 3.1 spec chapter 21.7 says the following: An Interceptor's behaviour may itself be modified by one or more Interceptor Policies. These Policy objects are created using a call to ORB::create_policy and are associated with an Interceptor during registration (see Section 21.7.2, ORBInitInfo Interface). All Policy interfaces defined in this section are local. The ORB can be accesed via the implicit get_orb operation of ORBInitInfo. The ORBInitInfo is passed on the pre_init and post_init call of the ORBInitializer but what should be the orb in the pre_init call? The orb is not initialized at that moment? Shouldn't it say that calling get_orb on the ORBInitInfo in the pre_init call gives the default exception that is given when get_orb is called on a local object?

Resolution:
Revised Text:
Actions taken:
June 1, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8844: Section: 21.9.1 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

The draft document says the following in 21.9.1. The description about the type of exceptions sounds very vague. Shouldn't the spec be more detailed, which type of exceptions should be ignored specifically? Any exceptional return from the invocation of any operation of the ORBInitializer interface other than those resulting from the failure to instantiate a portable interceptor object shall result in the abandonment of the ORB initialization and destruction of the ORB. Any ORBInitializer implementation that needs the ORB to ignore any thrown exceptions can simply catch and discard them itself.

Resolution:
Revised Text:
Actions taken:
June 1, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8856: Section: 21.4.3.1 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

In case get_slot is called from withing an ORB itializer chapter 21.4.3.1 says a BAD_INV_ORDER with minor code 10 is thrown, this should be 14 as mentioned also in 21.7.2.11

Resolution:
Revised Text:
Actions taken:
June 6, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8860: Section: 4.5.2 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

This corba spec describes POAManagerFactory. I have been searching on the web and it seems for example Orbacus has the possibility to do a resolve_initial_references ("POAManager"). This seems not possible with the latest corba spec. This seems an usefull extension. The only option there is now is to get the RootPOA, get from there the POAManagerFactory and use that again.

Resolution:
Revised Text:
Actions taken:
June 7, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8862: Section: 21.3.14.11 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

The minor code for add_reply_service_context is not correct. The spec says: Indicates the behavior of this operation when a service context already exists with the given ID. If false, then BAD_INV_ORDER with a standard minor code of 11 is raised. If true, then the existing service context is replaced by the new one. The minor code should be 15.

Resolution:
Revised Text:
Actions taken:
June 8, 2005: received issue

Issue 8864: Section: Appendix A (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

The tags for unreliable multicast are missing. // The following are defined in 03-01-11 const ProfileId TAG_UIPMC = 3; const ComponentId TAG_GROUP = 39; const ComponentId TAG_GROUP_IIOP = 40;

Resolution:
Revised Text:
Actions taken:
June 8, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8874: Page: 21-5 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

In the Interceptor interface there is a destroy method which can throw a system exception just like all other corba calls. What is the behaviour when the orb shutdown is done and an Interceptor::destroy() call throws an exception? Should the ORB ignore this exception and continue the shutdown or should it return the exception to the caller. I would except ignore the exception and continue but the spec doesn't describe the behaviour.

Resolution:
Revised Text:
Actions taken:
June 21, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8879: Page: 9-1 (corba-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

There are some inconsistent idl declarations in CORBA3.0.2 Chapter 9(with editorial update version) 1?page 9-10: the idl declaration of DynAnyFactory is not the same as the idl declared earlier(page 9-9). It seems that three new fuctions have been left out. 2?Page 9-5: DynUnion should have a member fuction is_set_to_default_member, which is declared on page 9-20

Resolution:
Revised Text:
Actions taken:
June 27, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8881: Page: 7-7 (corba-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

CORBA3.0.2(formal/02-12-02), chapter 7.2.1, says "The implicit object reference operations non_existent, is_a, repository_id and get_interface may be invoked using DII. No other implicit object reference operations may be invoked via DII." However, I think we should add "get_component" to this list of allowable operations. Or else we can't use some features of CCM via DII, because the implementation of get_component resides on the server side.

Resolution:
Revised Text:
Actions taken:
June 28, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8929: NVList Section: 7.5 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

The NVList has a count, which is defined as long, it would be better to make this an unsigned long. This has impact on ORB::create_list, change the type of argumetn count to unsigned long. Also update NVList::get_count to have an unsigned long argument.

Resolution:
Revised Text:
Actions taken:
July 15, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8969: Allowing Mutual Recursion for IDL Structures (corba-rtf)

Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 2.4 introduced forward declarations for IDL structures
and unions in support of recursive structures, deprecating the
prior practice of anonymous types.


Also allowed were sequences of forward-declared structures
("incomplete types"), which could then be used as members in
defining the structure. Currently, it is only allowed to use
incomplete types in the actual definition of the type itself.


As an example in section 3.11.2.3 demonstrates, this does
allow indirect recursion -- but only if the incomplete types
are nested, as in [first example]


  struct Foo;
  typedef sequence<Foo> FooSeq;


  struct Foo {
    struct Bar {
      FooSeq fs;
    } b;
  };


Specifically not allowed -- and this is the point of this
issue -- is the seemingly more intuitive definition of
[second example]


  struct Foo;
  typedef sequence<Foo> FooSeq;


  struct Bar {
    FooSeq fs;
  };


  struct Foo {
    Bar b;
  };


Currently, the spec says that, "sequence members that are
recursive must refer to an incomplete type currently under
definition," and thus Bar is not allowed to use FooSeq as
a member.


However, the second example is, in effect, no different than
the first. In the first example, "Foo::Bar" is a well-defined
stand-alone type that can be used elsewhere (e.g., as a
structure member or operation parameter).


If a developer intends to use both structures, the second
example makes this much clearer, as it syntactically elevates
"Foo::Bar" from a mere sub-type to an "independent" structure. 


Therefore, I would like to change the current wording of
section 3.11.2.3 to allow the second example. A proposed
update is below.


This issue is all the more urgent because another available
specification, the "Deployment and Configuration of
Component-based Distributed Applications," depends on it,
by using two IDL structures that mutually and indirectly
recurse, effectively using [third example]


  struct Package;
  typedef sequence<Package> PackageSeq;


  struct Assembly;
  typedef sequence<Assembly> AssemblySeq;


  struct Package {
    AssemblySeq as;
  };


  struct Assembly {
    PackageSeq ps;
  };


In reality, the IDL in question is a bit more complicated,
using some intermediate structures, which makes rewriting
the IDL without this mutual recursion impractical and
non-intuitive -- also because both "Package" and "Assembly"
are meant to be potentially top-level, stand-alone items.


Some might argue that the IDL restriction existed before
the "Deployment" specification was adopted, and that CORBA
should not be changed just because some later spec
willingly (or rather, naively) used buggy IDL.


So let me make some more arguments in favor of my request.


First, as explained above, IDL already allows for indirect
recursion. It just requires nesting.


Second, defining structures as a "side-effect" of a member
declaration is ugly, only marginally better than anonymous
types. Allowing the type definition of a member to stand
by itself is, in my opinion, much cleaner.


Third, indirect recursion between non-nested types is no
more difficult to implement in an ORB than indirect recursion
between nested types.


In fact, some existing ORB products already have no problem
with indirect recursion, and are able to compile the IDL
from the third example, resulting in correct code. The code
works fine with Mico, TAO, JacORB and Combat, all of which
apparently neglect to implement the check that "sequence
members that are recursive must refer to an incomplete type
currently under definition."


OmniORB does issue a diagnostic, but simply removing the
check, and making another trivial change to its IDL compiler,
results in correct C++ code.


Four, the existing IDL syntax, TypeCodes, CDR marshalling
rules, and Interface Repository all allow indirect recursion
to exist. In fact, it is already possible to create the
above data types using the Interface Repository and
TypeCode interfaces -- as well as to create instances
using DynamicAny, and to marshal them.


With this background, I suggest to remove the statement
that prevents indirect recursion between non-nested
structures and unions.


Proposed resolution:


In section 3.12.2.3, change paragraphs (counting each IDL
code example as a single paragraph) 10 to 12 (page 3-42)
from


  If a recursive structure or union member is used,
  sequence members that are recursive must refer to
  an incomplete type currently under definition. For
  example


    struct Foo;
    typedef sequence<Foo> FooSeq;
    struct Bar {
      long value;
      FooSeq chain; // Illegal, Foo is not an enclosing
    };              // struct or union.


  Compilers shall issue a diagnostic if this rule is
  violated.


to


  If a sequence member of a structure or union refers
  to an incomplete type, the structure or union itself
  remains incomplete until the member's definition is
  completed. For example


    struct Foo;
    typedef sequence<Foo> FooSeq;
    struct Bar {
      long value;
      FooSeq chain; // Use of incomplete type
    };              // Bar itself remains incomplete
    struct Foo {
      // ...
    };              // Foo and Bar are complete



Thank you for listening. Also thanks to Jeff Parsons
and Boris Kolpakov from Vanderbilt University for
researching this issue.


We, the submitters of the "Deployment" specification,
genuinely believe that indirect recursion is useful,
and its lack (and having to work around) would take
considerable value from the specification.


I am uncomfortable arguing to change another spec
to fix ours. But one spec has to change, and I believe
that indirect recursion is a useful feature that already
(unwillingly) exists in many ORBs, that it is no more
problematic to implement than the existing means of
recursion, and that the resulting data types are already
valid when obtained from the TypeCode or Interface
Repository interfaces.


Considering the conflict of available specifications,
I am tempted to flag this issue as urgent. Andrew, is
that even possible, given that there is no active Core
RTF?

Resolution:
Revised Text:
Actions taken:
August 17, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8985: Section: Chapter 11 (corba-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Section 11.3.1 "The Servant IDL Type" defines the default implementations of get_interface, is_a, and non_existent. However, we should define the default implementation of "get_component" as well because this fuction is also an ORB-mediated implicit object reference operation. By default, this function returns a nil reference. When the object is a component or a facet, as other default implementations, this operation can be overridden by the servant's implementation.

Resolution:
Revised Text:
Actions taken:
September 4, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 8986: Section: Chapter 9, Chapter 5 (corba-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Section 9.2.9 says "A reference to a DynValueCommon interface (and interfaces derived from it) exhibit the same sharing semantics as the underlying valuetype that it represents.", which defines the sharing semantics of DynAny. However, I think its precondition is that valuetype's sharing semantics can be preserved in Any. DynAny is usually used with Any, converted from or to Any. If Any can't preserve sharing semantics, there is no necessary for DynAny to keep them. Suppose we use a struct which consists of several valuetypes to store a graph. In order to ensure the correctness of an application based on DII/DSI, converting this struct to Any and then to DynAny should produce an identical graph. However, if Any can't preserve sharing semantics, this goal is impossible. Any's sharing semantics focuses on valuetype conversion, because we don't concern the concrete internal implementation of Any. It means that when we extracting valuetypes from an Any or converting an Any contains valuetypes into a DynAny, sharing semantics should be preserved. For example, different Anys contain same valuetype only produce one valuetype instance when their contents are extracted. We can implement this by the help of a global valuetype manager. To sum up, the sharing semantics of valuetype can be divided into three layers: valuetype itself, Any and DynAny. All of them constitute a complete hierarchy. Only after each layer has been implemented, we are able to ensure that applications that use the DII and DSI can correctly view and preserve the semantics of the valuetype graph. Because Any's sharing semantics is very fundamental, it is necessary for us to clarify it in the specification, though we haven't special chapter/section on Any. We can add it to Chapter 5 "Value Type Semantics". Section 5.2.4.2 only defined sharing semantics in the layer of valuetype itself. We should say something about sharing semantics in the other two layers at the end of this section.

Resolution:
Revised Text:
Actions taken:
September 5, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 9016: Section: 11.3.9 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Significant
Summary:

The CORBA spec describes the following about the wait_for_completion parameter of the POA::destroy call: The wait_for_completion parameter is handled as follows: � If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA belonging to the same ORB as this POA, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. � If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA belonging to the same ORB as this POA, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur. We have a use case where we have an ORB with two POA's, A1 and B1, each POA again has a child A2 and B2. In case we get a request for a servant of A2 to destroy POA B2 and we specify TRUE for wait_for_completion then we get an exception back, but this doesn't seem locally. We understand that when we want to destroy A1 when handling a request using a servant of A2 that we get an exception at that moment. We propose the change the description as following: The wait_for_completion parameter is handled as follows: � If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA that is a child of this POA or from this POA itself, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. � If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA that is a child of this POA or from the POA itself, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur.

Resolution:
Revised Text:
Actions taken:
September 26, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 9075: Section: 22.16/ (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

There are some issues with the definition of ExceptionHolder. In 22.16 it is as below, see the raise_exception_with_list, this seems to have two arguments here, in 22.7 there is just one argument. The same problem also appears in the draft 3.1 spec. Also, there is no CORBA::ExceptionList defined in the spec at all, there is Dynamic::ExceptionList but no CORBA::ExceptionList. valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) in Dynamic::ExceptionList exc_list) raises (UserExceptionBase); private boolean is_system_exception; private boolean byte_order;

Resolution:
Revised Text:
Actions taken:
October 5, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 9082: Section: 22.11.1 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

In the C++ example code of 22.11.3 Messaging::ExceptionHolder_ptr is used, for valuetypes there is no _ptr, the could should read Messaging::ExceptionHolder *

Resolution:
Revised Text:
Actions taken:
October 17, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 9112: Page: 21-43 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Significant
Summary:

The following methods are not described in this chapter: Object make_object (in string repository_id, in ObjectId id); IOP::TaggedProfileSeq make_profiles (in string repository_id, in ObjectId id); These are mentioned in 21.10.3

Resolution:
Revised Text:
Actions taken:
October 25, 2005: received issue
April 11, 2012: Deferred to next RTF

Discussion:

Issue 9118: Page: 56..64 (corba-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

C++ as a language is not just the core language but also STL that accompanies with it. There are lots of useful algorithms in STL, but they are not very easily used with the C++ mappings of CORBA Sequences. Step closer to this usability would be to add a member typedef that would tell the type of items the sequence contains - this would allow implementing an STL iterator compliant types more easily. And really nice thing would be if the mapping would have begin() and end() functions like STL containers do.

Resolution:
Revised Text:
Actions taken:
October 26, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 9140: FullInterfaceDescription and base_interfaces question (corba-rtf)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

Regarding the base_interfaces attribute of the Interface Repository  
(IFR) InterfaceDef and the ExtInterfaceDef interfaces, the CORBA spec  
has only this to say:


"The base_interfaces attribute lists all the interfaces from which  
this interface inherits."


Does that sentence mean that the base_interfaces attribute lists only  
immediate base interfaces, or does it list *all* base interfaces,  
i.e., the transitive closure of the inheritance graph (minus the  
implied Object interface at the root)? I believe it is supposed to be  
a list of only immediate interfaces, as one can make further calls on  
the IFR to obtain more information about  those bases, including  
their bases.


However, both the FullInterfaceDescription and the  
ExtFullInterfaceDescription structures also have a base_interfaces  
member, which is specified as a sequence of repository IDs.  
Unfortunately, the specification contains no description whatsoever  
for this member. I argue that unlike the base_interfaces attribute  
described above, this member can't list only the immediate base  
interfaces.


I believe that the base_interfaces member of the  
FullInterfaceDescription and the ExtFullInterfaceDescription  
structures should contain the transitive closure of all base  
interfaces. These structures are intended to supply *full* interface  
descriptions, after all. Specifying the base_interfaces as I suggest  
would match the operations and attributes fields of the same structs,  
which are already explicitly specified to contain all operations and  
attributes respectively from the transitive closure of the  
inheritance graph. Note also that if base_interfaces does not contain  
the transitive closure of all base interfaces, there's no way to  
obtain the information from TypeCodes, since names do not appear in  
TypeCodes in minimum CORBA.


I therefore propose that the third paragraph of section 10.5.24.1 of  
CORBA 3.0.2 be changed from this:


"The describe_interface operation returns a FullInterfaceDescription  
describing the interface, including its operations and attributes.  
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."


to add a sentence defining the base_interfaces member, like this:


"The describe_interface operation returns a FullInterfaceDescription  
describing the interface, including its operations and attributes.  
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 base_interfaces field of the  
FullInterfaceDescription structure includes the repository IDs of all  
the base interfaces in the transitive closure of the inheritance  
graph of the interface being described, except for the repository ID  
of the implied Object base interface."


Note that even if this change is made, the base_interfaces attribute  
of InterfaceDef and ExtInterfaceDef can (and should) remain as  
listing only immediate bases, assuming that's what the spec's  
original intent was.

Resolution:
Revised Text:
Actions taken:
November 7, 2005: received issue
April 11, 2012: Deferred to next RTF

Issue 9460: Section: 11.3.9.16 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

For activate_object_with_id it is described that when SYSTEM_ID has been set and the object id was not generated by this system or tis POA we throw a BAD_PARAM, but the minor code is not described. Shouldn't this have an unique minor code?

Resolution:
Revised Text:
Actions taken:
March 16, 2006: received issue
April 11, 2012: Deferred to next RTF

Issue 9618: CORBA Exceptions (corba-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

I implemented CORBA functionality, in that implementation I got some exceptions. I am sending that exceptions list in the below. omniORB: ERROR -- the application attempted to invoke an operation on a nil reference. terminate called after throwing an instance of 'CORBA::INV_OBJREF' Aborted (core dumped) I have some doubts on these exceptions. What is the cause for this exception? How can I solve this exception? Please clarify my doubts.

Resolution:
Revised Text:
Actions taken:
May 4, 2006: received issue
April 11, 2012: Deferred to next RTF

Issue 10558: Allowing mutual recursion for IDL structs - clarification needed (corba-rtf)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Naveed Shaikh, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

There was an issue 8969 (Allowing mutual recursion for IDL structures) posted sometime back on CORBA RTF (www.omg.org/issues/issue8969.txt). I am looking for a clarification in the proposed resolution, which allows for the mutual recursion between non-nested structures (CORBA 3.0 specification, section 3.11.2.3). The proposal essentially extends the definition of incompleteness of a struct/union as follows:
 
The original definition was: 
o A struct/union is termed incomplete until its full definition is provided; that is, until the scope of the struct/union definition is closed by a terminating "}"
 
The introduced proposal added to the original definition:
o If a sequence member of a structure or union refers to an incomplete type, the structure or union itself remains incomplete until the member's definition is completed
 
Section 3.11.2.3 also says that "an incomplete type can only appear as the element type of a sequence definition". 
 
Question 1:
Is following legal under the new scheme?
 
   struct Foo;
   typedef sequence<Foo> FooSeq;
 
   struct Bar {
       FooSeq fs;        
   }; // Bar remains incomplete since it is holding an incomplete sequence type
 
   struct FooX {
       Bar b; // Is this valid with Bar marked incomplete here?
   };
 
   struct Foo {
       Bar b;
   }; // According to the proposal, Foo and Bar are complete now
 
Use of Bar under FooX apparently conflicts with the condition that incomplete type can only appear in a sequence definition.
 
Question 2:
Also is it must that there is a mutual recursion between non-nested structures? Consider the following:
 
    struct Foo;
    typedef sequence<Foo> FooSeq;
 
    struct Bar {
        FooSeq fs;
    };   // Bar remains incomplete
 
    struct Foo {
        long a;
    }; // Is Bar also complete here when Foo is complete even though Foo doesn't recurse on Bar?
 
Is the above IDL valid under the new proposal? There is no constraint in section 3.11.2.3, which doesn't allow for this so it stands valid as per spec. Was issue 8969 also intended to make such cases valid?

Resolution:
Revised Text:
Actions taken:
December 1, 2006: received issue
April 11, 2012: Deferred to next RTF

Issue 10817: Section: 21.3.13 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

Table 21-1 has the following note: When ClientRequestInfo is passed to send_request, there is an entry in the list for every argument, whether in, inout, or out. But only the in and inout arguments will be available. What is the behaviour when I request an out value? It says only that in/inout are available, but when I have an argument that is of out and I do get the value, do I then get an empty value (which could lead to a crash when using it), do I get an exception? That must be clearly specified by the spec

Resolution:
Revised Text:
Actions taken:
March 13, 2007: received issue
April 11, 2012: Deferred to next RTF

Issue 11027: Section: exceptions (corba-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

org.omg.CORBA.NO_PERMISSION: vmcid: 0x0 minor code: 103 completed: No | | at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native | | Method) | | at | | sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces | | sorImpl.java:39) Feb 19 15:48:44 NMADR2CMT1 root: [NotificationChannel]NotificationChannel( ). Creating channel NpmChannel Feb 19 15:52:28 NMADR2CMT1 root: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No Feb 19 15:52:28 NMADR2CMT1 root: above mentioned are the errors we are getting from the the client appilcation. can anybody provide us the information why these execptions are generated and how to fix this kind of errors.

Resolution:
Revised Text:
Actions taken:
May 21, 2007: received issue
May 23, 2007: closed -- vendor issue

Issue 11161: Section: 13.6.10.1 (corba-rtf)

Click here for this issue's archive.
Source: PrismTech (Mr. Steve Osselton, nobody)
Nature: Revision
Severity: Significant
Summary:

The use of the '/' character to identify the object key component of a corbaloc URL is ambiguous where a protocol address also contains the character. Example: corbaloc:uiop:/tmp/uiop/xx/steve This could represent either a uiop address '/tmp/uiop' and an object key 'xx/steve/ or a uiop address '/tmp/uiop/xx' and an object key 'steve'. Suggest removing the '/' character from the list of non excaped object key characters (bottom of page 13-26)to resolve this ambiguity. The corbaloc would then become: corbaloc:uiop:/tmp/uiop/xx%27steve

Resolution:
Revised Text:
Actions taken:
July 18, 2007: received issue
April 11, 2012: Deferred to next RTF

Issue 11332: Section: 15.4.2/16.4.1 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

In 15.4.2 and 16.4.1 get_implementation is mentioned, but this method is nowhere else in the spec. Should this method be there? So far as I can see this is deprecated and should be removed.

Resolution:
Revised Text:
Actions taken:
September 7, 2007: received issue
April 11, 2012: Deferred to next RTF

Discussion:

Issue 11514: Proposal to change PortableInterceptor::ReplyStatus to a real enum (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

Proposal to change PortableInterceptor::ReplyStatus to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum ReplyStatus { SUCCESSFUL, SYSTEM_EXCEPTION, USER_EXCEPTION, LOCATION_FORWARD, TRANSPORT_RETRY, UNKNOWN }; };

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue
October 13, 2007: re-assigned to Core RTF from CORBA/e RTF
April 11, 2012: Deferred to next RTF

Issue 11515: Proposal to change PortableInterceptor::AdapterState to a real enum (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

Proposal to change PortableInterceptor::AdapterState to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum AdapterState { HOLDING, ACTIVE, DISCARDING, INACTIVE, NON_EXISTENT }; };

Resolution:
Revised Text:
Actions taken:
September 25, 2007: received issue
October 13, 2007: re-assigned to Core RTF from CORBA/e RTF

Issue 11525: Third line of 23.1.3.4, ACTIVE must be bold (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

Third line of 23.1.3.4, ACTIVE must be bold

Resolution:
Revised Text:
Actions taken:
September 30, 2007: received issue
October 13, 2007: re-assigned to Core RTF from CORBA/e RTF
April 11, 2012: Deferred to next RTF

Issue 12229: definition of Invalid Policies changed (corba-rtf)

Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Revision
Severity: Minor
Summary:

The CORBA/e FTF slightly changed the definition of Invalid Policies to: exception InvalidPolicies { UShortSeq indices; }; since this avoids the use of an anonymous sequence type, consider changing it (also for consistency).

Resolution:
Revised Text:
Actions taken:
February 15, 2008: received issue
April 11, 2012: Deferred to next RTF

Issue 12230: mention of (deprecated) function get_implementation removed from text (corba-rtf)

Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Clarification
Severity: Minor
Summary:

CORBA/e FTF (issue 11331): removed mention of (deprecated) function get_implementation from text. Consider making same change for consistency

Resolution:
Revised Text:
Actions taken:
February 15, 2008: received issue
April 11, 2012: Deferred to next RTF

Issue 12376: Section: Part 2, Chapter 11 - MIOP (corba-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

The MIOP does not provide an analogous operation to PortableServer::POA::create_POA() for the GOA (i.e. there is no PortableGroup::GOA::create_GOA). The lack of an operation of this nature prevents the ability for an interface (i.e. servant) to subscribe to multiple (i.e. more than one) multicast group. To specify to a POA to allow multiple entries in its Active Object Map, the POAs IdUniquenessPolicy would have to be set to MULTIPLE_ID. This can only be done via the POAs create_POA operation. Since there is no GOA create_GOA operation, a GOAs IdUniquenessPolicy cannot be set to MULTIPLE_ID, which prevents a servant from being able to be subscribed to more than one multicast group. I don't know if the OMG explicitly wants to prevent this capability, thus purposely leaving it out of the MIOP specification, or if this is simply an overlooked issue.

Resolution:
Revised Text:
Actions taken:
April 8, 2008: received issue
April 11, 2012: Deferred to next RTF

Issue 12549: struct PolicyValue (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

This section defines struct PolicyValue { CORBA::PolicyType ptype; sequence<octet> pvalue; }; Which should be as below because anonymous types are deprecated struct PolicyValue { CORBA::PolicyType ptype; CORBA::OctetSeq pvalue; };

Resolution:
Revised Text:
Actions taken:
June 24, 2008: received issue
April 11, 2012: Deferred to next RTF

Issue 12550: move struct to IOP module (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Revision
Severity: Minor
Summary:

The CORBA spec defines the following types to proposage messaging qos. This is really nothing more then propagating policies values. struct PolicyValue { CORBA::PolicyType ptype; sequence<octet> pvalue; }; typedef sequence<PolicyValue> PolicyValueSeq; This is now in the Messaging module, but the propagation of policy values is something that we want to use for ZIOP but also seems usable for other libraries. Instead of duplicating this struct to different modules I propose to move this to the IOP module.

Resolution:
Revised Text:
Actions taken:
June 24, 2008: received issue
April 11, 2012: Deferred to next RTF

Issue 12551: Section: 4.8.1 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Significant
Summary:

The corba spec defines a lot of policies. In 4.8.5 client exposed policies are listed. We do have several of them, also policies could be applied at several levels, but some of them can't be applied to each level. To our idea the scope at which policies can be applied should not only be in the possible, but also part of the policy itself. That way application code and the corba orb could check this. Maybe add this to policy typedef unsigned long PolicyScope; const PolicyScope POLICY_SCOPE_OBJECT = 0x01; const PolicyScope POLICY_SCOPE_CURRENT = 0x02; const PolicyScope POLICY_SCOPE_SCOPE = 0x04; const PolicyScope POLICY_SCOPE_POA = 0x08; const PolicyScore POLICY_SCOPE_CLIENT_EXPOSED = 0x10; Then add to the interface Policy readonly attribute PolicyScope policy_scope; This attribute can then be set in the policy with the values above as bitmask. This can be documented clearly in the documentation, orbs can check this, etc.

Resolution:
Revised Text:
Actions taken:
June 25, 2008: received issue
April 11, 2012: Deferred to next RTF

Discussion:

Issue 12555: Section: 21.7.3 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Significant
Summary:

This chapter defines register_orb_initializer. This itself is ok, but at the moment we have a 24*7 system and we get a new ORBInitializer shipped in for example a DLL we maybe want to get rid of a certain orbinitializer that we registered earlier. This is currently not possible, we propose to add an unregister_orb_initializer which makes it possible to unregister an orbinitializer again

Resolution:
Revised Text:
Actions taken:
June 25, 2008: received issue

Discussion:

Issue 12559: Section 13.7 ServiceContext (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

ServiceContext is defined as: struct ServiceContext { ServiceId context_id; sequence <octet> context_data; }; Anonymous types are deprecated, this should be struct ServiceContext { ServiceId context_id; CORBA::OctetSeq context_data; };

Resolution:
Revised Text:
Actions taken:
June 25, 2008: received issue
April 11, 2012: Deferred to next RTF

Issue 12773: add CORBA::ORB::arg_list (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

For a 24x7 system that doesn't shutdown and gets reconfigured it would be useful if we could for example change "-ORBDefaultInitRef" after the ORB has been initialized. That then would be used for any objects resolved after that. Maybe we could add CORBA::ORB::arg_list (inout arg_list argv); Which would change the arglist

Resolution:
Revised Text:
Actions taken:
August 11, 2008: received issue

Discussion:

Issue 12857: add interface ORB { Object string_to_object ( in wstring str ); }; (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

We see more and more use of unicode. It happens more and more that users have code that gets unicode (wchar) commandline arguments. In order to smoothen corba usage for these users we propose to add interface ORB { Object string_to_object ( in wstring str ); };

Resolution:
Revised Text:
Actions taken:
September 21, 2008: received issue

Discussion:

Issue 12858: Section: 15.4.5.1 struct has to be updated (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

this section says: // GIOP 1.0 struct LocateRequestHeader_1_0 { // Renamed LocationRequestHeader unsigned long request_id; sequence <octet> object_key; }; Anonymous types are deprecated so this struct has to be updated

Resolution:
Revised Text:
Actions taken:
September 23, 2008: received issue
April 11, 2012: Deferred to next RTF

Discussion:

Issue 13056: 16.10 lists register_initial_reference (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

16.10 lists register_initial_reference. It would be usefull for dynamic systems to also have a unregister_initial_reference (in ObjectId id).

Resolution:
Revised Text:
Actions taken:
November 3, 2008: received issue
April 11, 2012: Deferred to next RTF

Issue 13105: There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle (corba-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle. Having multiplex publisher port it would be easier to connect with dynamically created event consumers such that each consumer would have its own private communication channel with the publisher. In case of dynamically created consumers it is not possible to foresee the number of publisher ports required. For synchronous communication the elegant solution is a component with a multiplex receptacle for which we have separate communication channels.

Resolution:
Revised Text:
Actions taken:
November 24, 2008: received issue
April 11, 2012: Deferred to next RTF

Issue 14364: Japan CORBA Part 1 PAS Ballot Comments - comment 1 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Source: Japan NB,  Severity te
Summary: 
Japan will approve this DIS if the TH comments will accept.		
Resolution: 
If  The TH comments JP17 were accepted in the approved resolutions. See resolutions to OMG Issues 
Revised Text: 

Disposition:	Duplicate of xxxxxx

Resolution:
Revised Text: See resolution for JP17 (OMG Issue 14390)
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14365: Japan CORBA Part 1 PAS Ballot Comments - comment 2 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

	
Source: Japan NB,  Severity ed
Summary: 
Location:
Forword	5th paragraph
Comment: 
1) The reference to JTC1 is not correct.
2) The JTC1 Subcommittee referenced in this standard should be SC7 instead of SC32.
Proposed Change
1) "ISO/IEC/TC JTC1" should be replaced with "ISO/IEC JTC1."
2) "Subcommittee SC 32, Data Management" should be replaced with "Subcommittee SC 7, Software and Systems Engineering."
Resolution: 
Revised Text: 

Disposition:

Resolution: To be consistent with resolution of similar comment on part 3 (OMG Issue 14406), 1)�ISO/IEC/TC JTC1� should be replaced with �ISO/IEC JTC1� 2) Remove reference to SC32.
Revised Text: Change para 5 from: � ISO/IEC 19500-1 was prepared by Technical Committee ISO/IEC/TC JTC1, Information technology, Subcommittee SC 32, Data Management and Interchange in collaboration with the Object Management Group (OMG), following the submission and processing as a Publicly Available Specification (PAS) of the OMG Common Object Request Broker Architecture (CORBA) specification Part 1 Version 3.1 CORBA Interfaces. � To: � ISO/IEC 19500-1 was prepared by ISO/IEC JTC1, Information technology, in collaboration with the Object Management Group (OMG), following the submission and processing as a Publicly Available Specification (PAS) of the OMG Common Object Request Broker Architecture (CORBA) specification Part 1 Version 3.1 CORBA Interfaces.
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14366: Japan CORBA Part 1 PAS Ballot Comments - comment 3 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Forword	6th paragraph
Comment: 
1) The year of the standard's issurance need to be corrected.
2) The names in the second half of four referenced standards start with "-" and need to be removed.
3) ISO/IEC 19500-3 needs to be added in the list of relevant standards.
Proposed Change
1) The years within the title of RM-ODP Part 2 and 3 should be replaced with 1996, like the following.
o ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996
o ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996
2) Starting "-"s need to be removed.
3) Add the following to the list of related standards.
ISO/IEC 19500-3, Information Technology - Open Distributed Processing - CORBA Specification Part 3: CORBA Components

Resolution: Accept proposed change
Revised Text: Change second and third bullets of para 6 from: � � ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1995, Information Technology - Open Distributed Processing - Reference Model: Foundations � �ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1995, Information Technology - Open Distributed Processing - Reference Model: Architecture � To: � � ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996, Information Technology - Open Distributed Processing - Reference Model: Foundations � �ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996, Information Technology - Open Distributed Processing - Reference Model: Architecture � Remove the leading �-� character after the third and fourth bullets in para 6. Add the following new bullet to the list of related standards. � ISO/IEC 19500-3, Information Technology - Open Distributed Processing - CORBA Specification Part 3: CORBA Components Document
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14367: Japan CORBA Part 1 PAS Ballot Comments - comment 4 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Introduction	3rd paragraph
Comment: 
1) The second "Part 2" seems to be "Part 3" instead.
2) Mixed use of "RM-ODP" and "RM ODP" is confusing.
Proposed Change
1) The second "Part 2" should be replaced with "Part 3."
2) "RM ODP" should be replaced with "RM-ODP" where applicable.

Resolution: Accept proposed change
Revised Text: Change para 3 of introduction from: � RM-ODP Part 3 (ISO/IEC 10746-3) specifies a generic architecture of open distributed systems, expressed using the foundational concepts and framework defined in Part 2. Given the relation between UML as a modeling language and Part 2 of the RM ODP standard, it is easy to show that UML is suitable as a notation for the individual viewpoint specifications defined by the RM-ODP. � To: � RM-ODP Part 3 (ISO/IEC 10746-3) specifies a generic architecture of open distributed systems, expressed using the foundational concepts and framework defined in Part 2. Given the relation between UML as a modeling language and Part 3 of the RM-ODP standard, it is easy to show that UML is suitable as a notation for the individual viewpoint specifications defined by the RM-ODP.
Actions taken:
September 29, 2009: received issue\
July 11, 2011: closed issue

Issue 14368: Japan CORBA Part 1 PAS Ballot Comments - comment 5 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Introduction	context of CORBA last para
Comment: 
1) Since this document is submitted as PAS, it is better to reference ISO/IEC standard in addition to OMG standard 
Proposed Change
1) Add ", or this standard (ISO/IEC 19500)" at the end of the first sentence.
Resolution:

Resolution: accept proposed changes
Revised Text: Change first sentence of last paragraph of context of CORBA unnumbered subclause from: � The architecture and specifications described in this standard are aimed at software designers and developers who want to produce applications that comply with OMG specifications for the Object Request Broker (ORB). � To: � The architecture and specifications described in this standard are aimed at software designers and developers who want to produce applications that comply with OMG specifications for the Object Request Broker (ORB), or this standard (ISO/IEC 19500).
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14369: Japan CORBA Part 1 PAS Ballot Comments - comment 6 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Introduction	Structure of this standard
Comment: 
1) The chapter numbers in Structure of this standard are not consistent with actual chapter numbers. 
Proposed Change
1) Revise the chapter numbers.

Resolution: Accommodate by deletion of �Structure of this Standard� unnumbered subsection. This subsection is not required.
Revised Text: Delete the unnumbered subsection �Structure of this Standard� at the end of the Introduction.
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14370: Japan CORBA Part 1 PAS Ballot Comments - comment 7 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature:
Severity:
Summary:

Introduction	last paragraph
Comment: 
1) There is no sentence included with respect to annexes of this standard.
Proposed Change
1) Add text that says this standard includes normative and non-normative annexes.
Resolution:

Resolution: Agree to add proposed sentence, however Annex B and C are to be removed, and the Annex A is non -normative
Revised Text: Add the following sentence to the end of the Introduction clause: � This Part of this Internationsl Standard includes a non-normative annex. �
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14371: Japan CORBA Part 1 PAS Ballot Comments - comment 8 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
Clause 2
Comment: 
1) It would be better to have reference to programming language C++ standard, since it is used in mapping examples.
2) It would be better to have reference to programming language C standard too.
Proposed Change
1) Add the reference to C++, which is ISO/IEC 14882:2003, somewhere in the document.
See also a comment on Clause 7.3.
2) Add the reference to C, which is ISO/IEC 9899:1999, somewhere in the document.

Resolution: Agree to proposed change
Revised Text: Add the following two references to the normative references clause 3: � ISO/IEC 14882:2003, Information Technology - Programming languages - C++ � ISO/IEC 9899:1999, Information Technology � Programming languages - C
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14372: Japan CORBA Part 1 PAS Ballot Comments - comment 9 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Clause 3	Bullet items
Comment: 
1) The year of the standard's issuance need to be corrected.
Proposed Change
1) The years within the title of RM-ODP Part 2 and 3 should be replaced with 1996, like the following.
o ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996
o ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996

Resolution: Accept proposed change
Revised Text: Change first and second bullets of Clause 3 from: � � ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1995, Information Technology - Open Distributed Processing - Reference Model: Foundations � �ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1995, Information Technology - Open Distributed Processing - Reference Model: Architecture � To: � � ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996, Information Technology - Open Distributed Processing - Reference Model: Foundations � �ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996, Information Technology - Open Distributed Processing - Reference Model: Architecture �
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14373: Japan CORBA Part 1 PAS Ballot Comments - comment 10 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
Clause 4	
Comment: 
1) There seems to be duplication between "structure of this standard" section of Introduction and clause 4, and therefore it is better to make text simpler.
Proposed Change
1) Structure of this standard section of Introduction and clause 4 should be merged and placed in one place.

Resolution: Accommodated by removal of Structure of Standard subsection from Issue 14369.
Revised Text: See resolution to Issue 14369, which removes the structure of standard subsection.
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14374: Japan CORBA Part 1 PAS Ballot Comments - comment 11 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
Clause 4	
Comment: 
This is a multipart standard, and this clause title is "4 Part1 Document". It is confusing.   
Proposed Change
Delete unnecessary "Part1".

Resolution: agree to proposed change
Revised Text: Change the heading of clause 4 from: � 4 Part 1 Document � To: � 4 Document � Dis
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14375: Japan CORBA Part 1 PAS Ballot Comments - comment 12 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
Forword	5th paragraph
Comment: 
1) This document does not have definitions clause.
Proposed Change
1) It is suggested to create definitions clause that covers at least major concepts for this standard

Resolution: Do not agree to proposed change, since the terms are all defined implicitly by the text in the body of the document as they are first introduced.
Revised Text: no change
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14376: Japan CORBA Part 1 PAS Ballot Comments - comment 13 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
Clause 5	
Comment: 
1) OMA is mentioned but no reference to OMA document is included.
Proposed Change
Add the reference to Object Management Architecture Guide

Resolution: Agree to add reference to OMG OMA Guide
Revised Text: Add following bullet to references clause: � � [OMA] Object Management Group, �Object Management Architecture Guide, revision 3.0� , available from http://www.omg.org/oma/ �
Actions taken:
September 29, 2009: received isse
July 11, 2011: closed issue

Issue 14377: Japan CORBA Part 1 PAS Ballot Comments - comment 14 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
All Clauses	
Comment: 
1) Both terms, "OMG IDL" and "IDL," are used in the document, and this usage is not consistent.
Proposed Change
1) It is suggested to use "OMG IDL" for the first appearance, and with the text explaining that IDL hereafter means OMG IDL, use just IDL for the rest of the document.

Resolution: Agree to proposed change
Revised Text: Change the first numbered bullet item of Clause 4 from: � 1. The syntax and semantics of the interface definition language (IDL), which is used to describe the interfaces that client objects call and object implementations provide. � To: � 1. The syntax and semantics of the OMG interface definition language (OMG IDL), which is used to describe the interfaces that client objects call and object implementations provide. Throughout this specification the abbreviation IDL is used, for brevity, as shorthand for OMG IDL. � In the remainder of the specification, replace every occurrence of �OMG IDL� with �IDL�.
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14378: Japan CORBA Part 1 PAS Ballot Comments - comment 15 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Clause 7.3	1st paragraph
Comment: 
1) There is a stand-alone term "1998" in the second line of this paragraph.
Proposed Change
1) Change the standard name to "ISO/IEC 14882:2003" or "ISO/IEC 14882:1998" or remove this number from the text.

Resolution: Agree to proposed change to incorporate reference from normative references
Revised Text: Change the first paragraph of 7.3 from: � OMG IDL is preprocessed according to the specification of the preprocessor in �International Organization for Standardization. 1998. ISO/IEC 14882 Standard for the C++ Programming Language. Geneva: International Organization for Standardization.� The preprocessor may be implemented as a separate process or built into the IDL compiler. � To: � OMG IDL is preprocessed according to the specification of the preprocessor in ISO/IEC 14882:2003. The preprocessor may be implemented as a separate process or built into the IDL compiler. �
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14379: Japan CORBA Part 1 PAS Ballot Comments - comment 16 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Clause 8.5.2 and other places	Table 8.1
Comment: 
1) There are places where the reference to Part 2 is describe like the following:
"See CORBA, Part 2: ORB Interoperability Architecture clause".
Proposed Change
Change the text of referring to other part of the standard throughout the document to:
"See ISO/IEC 19500-2 Common Object Request Broker Architecture (CORBA) specification - Part 2: Interoperability"
or
"See ISO/IEC 19500-2 CORBA specification Part 2: Interoperability"
or
"See Part 2 of this standard"

Resolution: Agree to second proposed change
Revised Text: Throughout the specification (except in the normative references clause): change: �CORBA, Part 2 - ORB Interoperability Architecture� To: �Part 2 of this standard� Then change: �CORBA 3.1, Part 2 - ORB Interoperability Architecture� To: �Part 2 of thisInternational Standard� Then change both: �CORBA 3.1, Part 2� and �CORBA, Part 2� � To: �Part 2 of thisInernational Standard�
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14380: Japan CORBA Part 1 PAS Ballot Comments - comment 17 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Annex B	
Comment: 
This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.
Proposed Change
Remove Annex B or make it informative Annex
Resolution:

Resolution: Agree to make Annex B an informative Annex
Revised Text: Change �(normative)� to �(informative)� on the line after the Title of Annex B
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14381: Japan CORBA Part 1 PAS Ballot Comments - comment 18 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Annex C, D	
Comment: 
This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG document only.
Proposed Change
Remove Annex C and D from ISO standard.

Resolution: Agree to remove Annex C and Annex D from both the ISO Standard and the OMG specification (for consistency)
Revised Text: Remove both annex C and Annex D from the specification.
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14382: Japan CORBA Part 1 PAS Ballot Comments - comment 19 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
All Clauses	
Comment: 
ISO standard documents are described with "shall", "should" and "may".
Proposed Change
Define this with "shall", "should" and "may"

Resolution: Change the title of clause 4 to the following: � 4 Additional information � Add a new sub section header at beginning of clause 4: � 4.1 Outline of specification contents � Add new subsection to end of section 4: � 4.2 Keywords for Requirement statements� The keywords "must", "must not", "shall", "shall not", "should", "should not", and "may� in this specification are to be interpreted as described in [RFC 2119].� � Add the following reference in the normative references - section 3.2: [RFC2119] IETF RFC2119, �Key words for use in RFCs to Indicate Requirement Levels�, S. Bradner, March 1997. Available from http://ietf.org/rfc/rfc2119
Revised Text:
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14383: Japan CORBA Part 2 PAS Ballot Comments - comment 1 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Japan will approve this DIS if the te comment jp 20 will be satisfactorily resolved
Resolution: 
If  the te commentsJP17 were accepted in the approved resolutions. See resolutions to OMG Issues

Resolution: The comment JP20 was resolved in the approved resolutions. See resolutions to OMG Issues
Revised Text: See resolution for JP20 (OMG Issue 14402)
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14384: Japan CORBA Part 2 PAS Ballot Comments - comment 2 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Comment: 
This document is revision for 19500-2:2003. Therefore, status of the old document is ambiguous.
Proposed Change
It is desirable to withdraw the old standard (19500-2:2003) to avoid confusion, if possible.

Resolution: Clarify upon publication by ISO that This PAS specification is intended to supersede the 2003 version
Revised Text: This new version of 19500-2 needs to supersede the 2003 version. Clarify upon publication that the 2003 version needs to be withdrawn.
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14385: Japan CORBA Part 2 PAS Ballot Comments - comment 3 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Clause 2	2nd paragraph
Comment: 
What does ESIOP mean?  There are no descriptions on it.
Proposed Change:
Change 'additional ESIOPs' to 'additional  Environment-Specific Inter-ORB Protocols(ESIOPs)'

Resolution: Agree to proposed change
Revised Text: In clause 2, 2nd para: Change �additional ESIOPs� to �additional Environment-Specific Inter-ORB Protocols(ESIOPs)�
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14386: Japan CORBA Part 2 PAS Ballot Comments - comment 4 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
4.1	1st line
Comment: 
The delimiter between X and 902 is not a comma but a dot, and the part number following a document number should be connected by a hyphen.
Proposed change:
X,902 should be X.902 and 10746.2 should be 10746-2..

Resolution: agree to proposed change
Revised Text: In 4.1 1st line change �X,902� to be �X.902� and �10746.2� to be �10746-2�
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14387: Japan CORBA Part 2 PAS Ballot Comments - comment 5 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
4.1	
Comment: 
As the terms 'transparency',  'domain' and 'service' are used in clause 7, and these terms are important for  the concept of interoperability,  it is preferable to explain the difference or resemblance of usage between  the RM-ODP and this CORBA in the document. One way to do this is to define the meaning of the terms. The term 'domain' is defined in clause 4.2. However, other terms are not defined in this document. Where are the definitions of 'transparency' and 'service' ?
Proposed change:
If the terms are already defined in the other documents, make a reference to the documents in which the terms are defined. Otherwise, define these terms in this document..

Resolution: Add �transparency� and �service� to the list of terms defined in ODP Reference Model 10746-2
Revised Text: Add the following two terms to the list for ISO/IEC 10746-2 in clause 4.1: � service � transparency
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14388: Japan CORBA Part 2 PAS Ballot Comments - comment 6 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
4.2	
In 'repository', the sentence tells to 'see' the other terms. However, there is no 'implementation repository' in the definitions list.
Proposed change:
Modify the definition of this 'repository' or add the reference to the definition of 'implementation repository',  which is mentioned in the clause 6.1.4  of  ISO/IEC 19500-1.

Resolution: Agree that there is no specialized definition of the word repository as used in this spec
Revised Text: Remove the table row for the term �repository� in 4.2
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14389: Japan CORBA Part 2 PAS Ballot Comments - comment 7 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
4.2	
Comment: 
There are misspellings in the definitions list.
Proposed change:
Correct the word 'wiat' to  'wait' in the definition of the "synchronous request".
Correct the word 'tow' to 'two' in the definition of  the 'interoperability'..

Resolution: agree to proposed changes
Revised Text: In clause 4.2 : Correct the word �wiat� to �wait� in the definition for �synchronous request�. Correct the word �tow� to �two� in the definition for �interoperability�..
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14390: Japan CORBA Part 2 PAS Ballot Comments - comment 8 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
4.2
Comment: 
It seems that the definition of  a  'request'  is  circular.
Proposed change:
Modify the definition which is not circular. A candidate is " A message issued by a client  to cause a service to be performed."..

Resolution: Agree to proposed change of definition text
Revised Text: In secton 4.2, change definition for �request� to the following text: �A message issued by a client to cause a service to be performed.�
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14391: Japan CORBA Part 2 PAS Ballot Comments - comment 9 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Clause 5	
Comment: 
The term ESIOP plays important roles in the document.
Proposed change:
ESIOP should be added in the symbols.

Resolution: Agree to add ESIOP to symbols
Revised Text: Add the following to the abbreviations list in section 5 ESIOP Environment-Specific Inter-ORB Protocol
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14392: Japan CORBA Part 2 PAS Ballot Comments - comment 10 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
6.2	
Comment: 
ISO documents are not a book but consist of several parts of  documents. 
Proposed change:
Correct the expression of the phrase "ORB Interface clause of this book(Part1)" , such as "clause 8  of ISO/IEC 19500-1, ORB Interface"..

Resolution: Agree to change reference to a neutral designation for 19500-1 as �Part 1 of this Specification� which will hold for both OMG and ISO versions of text. Use of clause names in other spec references rather than clause numbers is more robust to amendments/corrigenda on the references external specification.
Revised Text: �ORB Interface clause of this book(Part1)� To: ��ORB Interface� clause of Part 1 of this International Standard (ISO/IEC 19500-1)�
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14393: Japan CORBA Part 2 PAS Ballot Comments - comment 11 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
6.3.4	
Comment: 
When referring to clause(s) in other parts of ISO/IEC 19500 from within ISO/IEC 19500-2, it is clearer to explicitly  provide the clause number and part number of the standard, rather stating like "this standard(Part 1).
Proposed change:
Replace "in the Interface Repository clause of this standard (Part1)" with "in clause 14 of ISO/IEC 19500-1, Interface Repository clause of CORBA interfaces"..

Resolution: Agree to refer to clause in 19500-1 as �Part 1 of this Specification� which will hold for both OMG and ISO versions of text.
Revised Text: In clause 6.3.4 change: �in the Interface Repository clause of this standard (Part1)� to: �in the �Interface Repository� clause of Part 1 of this International Standard ( ISO/IEC 19500-1)�
Actions taken:
September 29, 2009: received issue
September 29, 2009: received issue
July 11, 2011: closed issue
July 11, 2011: closed issue

Issue 14394: Japan CORBA Part 2 PAS Ballot Comments - comment 12 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
7.5	
Comment: 
"see CORBA part1, clause 4" is ambiguous.
Proposed change:
Replace "see CORBA part1, clause 4"  with "in clause 5 of ISO/IEC 19500-1, The Object Model".

Resolution: Agree to refer to named clause in 19500-1
Revised Text: In 7.5 change: �see CORBA part1, clause 4� To: �in �The Object Model� clause of Part 1 of this International Standard (ISO/IEC 19500-1)�
Actions taken:

Issue 14395: Japan CORBA Part 2 PAS Ballot Comments - comment 13 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
7.6.3 	p.27, l.24
7.6.9	p.33
Comment: 
We use the term 'clause' when we need to point to the other sections.
Proposed change:
Replace "see Section 9.7.3"  with "see clause 9.7.3".
Replace "see Section 9.3"   with  "see clause 9.3".

Resolution: agree to proposed change
Revised Text: In clause 7.6.3 Replace �see Section 9.7.3� with �see clause 9.7.3�. In clause 7.6.9 Replace �see Section 9.3� with �see clause 9.3�.
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14396: Japan CORBA Part 2 PAS Ballot Comments - comment 14 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
7.6.4.3	p 28
Comment: 
There is a phrase that  "see the CORBA/TC Interworking specification". However,  we can't find the place.
Proposed change:
Where is this clause ?.

Resolution: Agree to add proper reference to OMG spec
Revised Text: Add the following to the �other specifications� references clause 3.2 [SCCP] Object Management Group, � CORBA / TC Interworking and SCCP-Inter ORB Protocol (SCCP)� . Available from http://www.omg.org/spec/SCCP Change the body of 7.6.4.3 from: � See the CORBA / TC Interworking specification and Annex A of this standard for additional information. � To: � See OMG Specification [SCCP] and Annex A of thisPart of this International standard for additional information. �
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14397: Japan CORBA Part 2 PAS Ballot Comments - comment 15 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
7.6.4.4	p.29
Comment: 
The reference pointer of  the "Unreliable Multicast"  is necessary for the convenience of the readers.
Proposed change:
Replace the "Unreliable Multicast"   with  "in clause 11 of ISO/IEC 19500-2, Unreliable Multicast"..

Resolution: Agree to add reference to clause 11:
Revised Text: In 7.6.4.4 change: �Unreliable Multicast clause� With: �clause 11 of this Part of this International Standard�
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14398: Japan CORBA Part 2 PAS Ballot Comments - comment 16 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
7.6.6	p.30
Comment:
We can't find where the DCE ESIOP is. There is no clause  which names DCE ESIOP in ISO/IEC 19500-2.
What document are CORBA services included in? 
Proposed change:
Modify the sentence

Resolution: Agree to fix by removing deprecated references to DCE ESIOP components
Revised Text: Remove the final paragraph and list from the intro to section 7.6.6: � The following additional components that can be used by other protocols are specified in the DCE ESIOP clause of this document and CORBAServices, Security Service, in the Security Service for DCE ESIOP: const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service � Remove the following lines from the end of clause 7.6.6.3 associated with the deprecated DCE ESIOP: � � TAG_COMPLETE_OBJECT_KEY - See the DCE ESIOP clause: CORBA, v3.0.3 (formal/04-03-01). � TAG_ENDPOINT_ID_POSITION - See the DCE ESIOP clause: CORBA, v3.0.3 (formal/04-03-01). � TAG_LOCATION_POLICY - See the DCE ESIOP clause: CORBA, v3.0.3 (formal/04-03-01). � TAG_DCE_STRING_BINDING - See the DCE ESIOP clause: CORBA, v3.0.3 (formal/04-03-01). � TAG_DCE_BINDING_NAME - See the DCE ESIOP clause: CORBA, v3.0.3 (formal/04-03-01). � TAG_DCE_NO_PIPES - See the DCE ESIOP clause: CORBA, v3.0.3 (formal/04-03-01). � Disposition: Also need to delete tags from Annex A of part 1
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14399: Japan CORBA Part 2 PAS Ballot Comments - comment 17 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
7.6.6.3	p.31, p.32
Comment:
There are sentences each of which begins with "See �".
However, the reference pointers are ambiguous for those who are not familiar with the CORBA work.
Proposed change:
Replace the references as mentioned above.

Resolution: Agree to change to proper OMG normative references, and to add to normative references clause. OMG is an Authorized Reference Originator Replace all the numbered reference text to Firewall spec , showing in the document as �(ptc/04-03-01)� with the �[FIREWALL]� reference tag.
Revised Text: Add following references to OMG Specifications in section 3.2 Other Specifications: � [JAV2I] Object Management Group,: �Java to IDL� , available from http://www.omg.org/spec/JAV2I/1.4 [CORBASEC] Object Management Group, � Security Service�, available from http://www.omg.org/technology/documents/formal/security_service.htm [ASMOTS] Object Management Group, � Additional Structuring Mechanisms for the OTS�, available from http://www.omg.org/technology/documents/formal/add_struct.htm [TRANS] Object Management Group, "Transaction Service", available from http://www.omg.org/ technology/documents/formal/transaction_service.htm [FIREWALL] Object Management Group, "CORBA Firewall Traversal Specfication", available from http://www.omg.org/members/cgi-bin/doc?ptc/04-04-05.pdf � Replace clause 7.6.6.3 with the following: � 7.6.6.3 Other Components The following standard components are specified in the referenced OMG specifications: � TAG_CODE_SETS - See CodeSet Component of IOR Multi-Component Profile in clause 7.10.2.4 of this part of this specification.. � TAG_POLICIES - See the� CORBA Messaging� clause og ISO/IEC 19500-1. � TAG_SEC_NAME - See the Mechanism Tags sub clause og [CORBASEC]. � TAG_ASSOCIATION_OPTIONS - See the Tag Association Options sub clause og [CORBASEC] � TAG_SSL_SEC_TRANS - See the Mechanism Tags sub clause of [CORBASEC]. � TAG_GENERIC_SEC_MECH and all other tags with names in the form TAG_*_SEC_MECH - See the �Mechanism Tags� sub clause of [CORBASEC]. � TAG_FIREWALL_SEC - See [FIREWALL]. � TAG_SCCP_CONTACT_INFO - See [SCCP]. � TAG_JAVA_CODEBASE - See [JAV2I]. � TAG_TRANSACTION_POLICY - See [TRANS]. � TAG_MESSAGE_ROUTERS - See the �CORBA Messaging� clause of ISO/IEC 19500-1. � TAG_OTS_POLICY - See [TRANS]. � TAG_INV_POLICY - See [TRANS]. � TAG_INET_SEC_TRANS - See [CORBASEC]. � TAG_CSI_SEC_MECH_LIST, TAG_NULL_TAG, TAG_SECIOP_SEC_TRANS, TAG_TLS_SEC_TRANS - See the �Secure Interoperability� clause 10 of this part of this Specification.. � TAG_ACTIVITY_POLICY - See [ASMOTS]. � TAG_RMI_CUSTOM_MAX_STREAM_FORMAT - See [JAV2I]. � TAG_GROUP and TAG_GROUP_IIOP - See the �Unreliable Multicast Inter-ORB Protocol� clause 11 of this part of this Specification.. � TAG_IIOP_SEC_TRANS - See the �Secure Interoperability� clause 10 of this part of this specification. � Throughout the entire document, replace : �(ptc/04-03-01)� With: �[FIREWALL]�
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14400: Japan CORBA Part 2 PAS Ballot Comments - comment 18 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Location:
3.1	p 2
Forward	p xv
Comment: 
The year of ITU-T recommendation  is different from  that of ISO/IEC. The former is 1995, and the latter is 1996.
Proposed change:
The correct expressions of the Normative references are as follows:
ITU-T Recommendation X.902 (1995)| ISO/IEC 10746-2:1996,
ITU-T Recommendation X.903 (1995)| ISO/IEC 10746-3:1996,

Resolution: Agree to proposed change
Revised Text: In both Forward and clause 3.1 replace the referenced to X.902 and X.903 as follows: ITU-T Recommendation X.902 (1995)| ISO/IEC 10746-2:1996, ITU-T Recommendation X.903 (1995)| ISO/IEC 10746-3:1996,
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14401: Japan CORBA Part 2 PAS Ballot Comments - comment 19 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Introduction	p.xviii (Last paragraph) 
Comment:
There is no sentence included with respect to annexes of this standard.
Proposed change:
Add a sentence which says that  this standard includes normative and non-normative annexes.

Resolution: Agree to add proposed sentence
Revised Text: Add the following sentence to the end of the Introduction clause: � This Part of this International Standard includes normative and non-normative annexes. �
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14402: Japan CORBA Part 2 PAS Ballot Comments - comment 20 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Annex B	
Comment: 
This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.
Proposed Change
Remove Annex B or make it informative Annex

Issue 14403: Japan CORBA Part 2 PAS Ballot Comments - comment 21 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Annex C, D	
Comment: 
This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG document only.
Proposed Change
Remove Annex C and D from ISO standard.

Resolution: Agree to remove Annex C and Annex D from both the ISO Standard and the OMG specification (for consistency)
Revised Text: Remove both annex C and Annex D from the specification
Actions taken:
September 29, 2009: received issue\
July 11, 2011: closed issue

Issue 14404: Japan CORBA Part 2 PAS Ballot Comments - comment 22 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
All Clauses	
Comment: 
ISO standard documents are described with "shall", "should" and "may".
Proposed Change
Define this with "shall", "should" and "may"

Resolution: Specification uses RFC 2119 Terminology
Revised Text: Add new subsection to end of existing section 4: � 4.3 Keywords for Requirement statements� The keywords "must", "must not", "shall", "shall not", "should", "should not", and "may� in this specification are to be interpreted as described in IETF RFC 2119.� � Add the following reference in the normative references - section 3.2:
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14405: Japan CORBA Part 3 PAS Ballot Comments - comment 1 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Source: Japan NB,  Severity te
Summary: 
Japan will approve this DIS if the te comment jp 8, 11, 14 will be satisfactorily resolved
Resolution: 
If  the te comments JP 8, 11, 14  were accepted in the approved resolutions. See resolutions to OMG Issues

Resolution: All of the comments JP 8, 11, and 14, were resolved in the approved resolutions. See resolutions to OMG Issues
Revised Text: See resolutions for JP 8, 11, 14 (OMG issues 14412, 14415, and 14419).
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14406: Japan CORBA Part 3 PAS Ballot Comments - comment 2 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Foreword	5th paragraph 
Comment:
1) The reference to JTC1 is not correct.
2) The JTC1 subcommittee referenced in this standard is SC32. It  seems there is no reference to the reference.
Proposed change:
1)"ISO/IEC/TC JTC1" should be replaced with "ISO/IEC JTC1"
2) Remove reference to SC32.

Resolution: Accept proposed change
Revised Text: Change para 5 from: � ISO/IEC 19500-1 was prepared by Technical Committee ISO/IEC/TC JTC1, Information technology, Subcommittee SC 32, Data Management and Interchange in collaboration with the Object Management Group (OMG), following the submission and processing as a Publicly Available Specification (PAS) of the OMG Common Object Request Broker Architecture (CORBA) specification Part 1 Version 3.1 CORBA Interfaces. ISO/IEC 19500-1 is related to: � To: � ISO/IEC 19500-3 was prepared by ISO/IEC JTC1, Information technology, in collaboration with the Object Management Group (OMG), following the submission and processing as a Publicly Available Specification (PAS) of the OMG Common Object Request Broker Architecture (CORBA) specification Part 3 Version 3.1 CORBA Interfaces. ISO/IEC 19500-3 is related to: �
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14407: Japan CORBA Part 3 PAS Ballot Comments - comment 3 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Foreword	6th paragraph 
Comment
1) The year of the standard's issuance need to be corrected.
2) The names in the second half of  two referenced standards start with "-" and need to be removed. 
Proposed change:
1) The year within the title of RM-ODP Part2 and 3 should be replaced with 1996, like following.
ITU-T Recommendation X.902(1995)|ISO/IEC 10746-2:1996
ITU-T Recommendation X.903(1995)|ISO/IEC 10746-3:1996

Resolution: accept proposed change
Revised Text: Change second and third bullets of para 6 from: � � ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1995, Information Technology - Open Distributed Processing - Reference Model: Foundations � �ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1995, Information Technology - Open Distributed Processing - Reference Model: Architecture � To: � � ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996, Information Technology - Open Distributed Processing - Reference Model: Foundations � �ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996, Information Technology - Open Distributed Processing - Reference Model: Architecture �
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14408: Japan CORBA Part 3 PAS Ballot Comments - comment 4 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Introduction	3rd paragraph 
Comment: 
1) The second "Part2" seems to be "Part3" instead.
2) Mixed use of "RM-ODP" and "RM ODP" is confusing.
Proposed change:
1) The second "Part2" should be replaced with "Part3".
2) "RM ODP" should be replaced with "RM-ODP" where applicable..

Resolution: Accept proposed change.
Revised Text: Change para 3 of introduction from: � RM-ODP Part 3 (ISO/IEC 10746-3) specifies a generic architecture of open distributed systems, expressed using the foundational concepts and framework defined in Part 2. Given the relation between UML as a modeling language and Part 2 of the RM ODP standard, it is easy to show that UML is suitable as a notation for the individual viewpoint specifications defined by the RM-ODP. � To: � RM-ODP Part 3 (ISO/IEC 10746-3) specifies a generic architecture of open distributed systems, expressed using the foundational concepts and framework defined in Part 2. Given the relation between UML as a modeling language and Part 3 of the RM-ODP standard, it is easy to show that UML is suitable as a notation
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14409: Japan CORBA Part 3 PAS Ballot Comments - comment 5 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Introduction	Structure of this standard
Comment:
1) This chapter numbers in Structure of this standard are not consistent with actual chapter numbers.
Proposed change:
1) Revise the chapter numbers..

Resolution: Accommodate by deletion of �Structure of this Standard� unnumbered subsection. This subsection is not required.
Revised Text: Delete the unnumbered subsection �Structure of this Standard� at the end of the Introduction
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14410: Japan CORBA Part 3 PAS Ballot Comments - comment 6 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Introduction	Last paragraph	 
Comment:
There is no sentence included with respect to annexes of this standard.
Proposed change:
Add text that says this standard includes normative and non-normative annexes.

Resolution: Agree to add proposed sentence, however Annex B and C are to be removed, and the Annex A is non -normative
Revised Text: Add the following sentence to the end of the Introduction clause: � This Part of this International Standard includes a non-normative annex. �
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14411: Japan CORBA Part 3 PAS Ballot Comments - comment 7 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Introduction	3rd paragraph 
Comment:
Since this document is submitted as PAS, it is better to reference ISO/IEC standard in addition to OMG standard.
Proposed change:
Add " or this standard (ISO/IEC 19500)" at the end of the first sentence..

Resolution: Agree to clarify the references
Revised Text: At the end of 1st sentence of third paragraph of the introduction clause, change: �defined in Part 2� to �defined in ISO/IEC 10746-2� In the first sentence of paragraph 4 of the introduction, change� �This International Standard for CORBA Interfaces� To: �This Part if this International Standard�
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14412: Japan CORBA Part 3 PAS Ballot Comments - comment 8 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
1 Scope	
Comment: 
There is a reference to EJB. This should be referred as normative reference. Furthermore, this refers to private web page (http://java.sun.com/products/ejb/javadocs-1.1-fr).
Proposed change:
This reference should move to clause "Normative Reference" and refer to public specification, such as JCP. Furthermore, referred version number should be designated.

Resolution: Agree that the reference should be changed to use the JCP url for JSR 950 - EJB 1.1 spec final release with errata
Revised Text: change EJB reference in normative references, as follows [EJB] Java Community Process, �Enterprise JavaBeans Specification - Version 1.1� (with errata), June 8, 2000. Available from http://jcp.org/aboutJava/communityprocess/maintenance/jsr905
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14413: Japan CORBA Part 3 PAS Ballot Comments - comment 9 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
1 Scope	
Comment: 
There are many references to PIM/PSM. However, those definitions aren't prescribed.
Proposed change:
Add reference to MDA prescription. http://www.omg.org/docs/omg/03-06-1/pdf

Resolution: Agreed to add refernce to MDA Guide version 1.0.1, and to use it in abbreviation definitions for PIM and PSM
Revised Text: Change abbreviations for PIM and PSM as follows: � PIM Platform Independent Model (see [MDA]) PSM Platform Specific Model (see [MDA]) � Add following reference to MDA in section 3 Normative References: [MDA] Object Management Group, �MDA Guide - Version 1.0.1� . Available from http://www.omg.org/cgibin/ doc?omg/03-06-01
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14414: Japan CORBA Part 3 PAS Ballot Comments - comment 10 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
3.1 Normative Reference	
Comment: 
There are reference to UML 1.5, MOF 1.4 and XMI. 
Proposed change:
ISO/IEC 19502:2005  Information technology -- Meta Object Facility (MOF) 
ISO/IEC 19501:2005 Information technology - Unified Modeling Language (UML) 
ISO/IEC 19503:2005  Information technology -- XML Metadata Interchange (XMI)

Resolution: Agreed to add the three references
Revised Text: Add the following references to clause 3.1: � ISO/IEC 19502:2005 Information technology -- Meta Object Facility (MOF) ISO/IEC 19501:2005 Information technology � Unified Modeling Language (UML) ISO/IEC 19503:2005 Information technology -- XML Metadata Interchange (XMI) �
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14415: Japan CORBA Part 3 PAS Ballot Comments - comment 11 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
3.1 Normative Reference	
Comment: 
ZIP is referred to http://www.pkware.com/products/enterprise/white_paper/annnote.txt
Proposed change:
Refer to public document. Otherwise ZIP should be removed.

Resolution: According to section 6.12.1 (note on Tools), the exact nature of a zip file format is tool and platform dependent. Thus the single reference in 14.3.3 should be made informal, and the reference [ZIP] needs to be removed.
Revised Text: Change the first sentence of 14.3.3 from: � 14.3.3 Package The meta-concept of a package is mapped to a ZIP file [ZIP] accessible by URI [URI], that includes implementation artifacts and descriptors. � to: � 14.3.3 Package The meta-concept of a package is mapped to a zip file accessible by URI [URI], that includes implementation artifacts and descriptors. � Remove reference labeled [ZIP] from references section.
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14416: Japan CORBA Part 3 PAS Ballot Comments - comment 12 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
6.11	Figure 6.2 
Comment:
The diagram looks like class diagram. However, its syntax is ambiguous. For example, Inheritance arrowhead is solid black triangle. Generally, Inheritance arrowhead is hollow triangle. Besides, there are dashed lines without definition.
Proposed change:
Replace the diagram with class diagram.

Resolution: Accommodated by deletion of the Figure, since it is not referred to in the text of the document
Revised Text: Remove Figure 6.2 from the specification
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14417: Japan CORBA Part 3 PAS Ballot Comments - comment 13 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
8.2.6, 8.2.7	Figure 8.1, Figure 8.2  
Comment:
Syntax for the composition structure diagram is ambiguous. For example, there are gray dashed arrows, however, the legends only show gray solid arrow.
Proposed change:
The Fig 8.1 and 8.2 should be represented using the symbol of the legend."

Resolution: The light grey dashed arrows are a fourth type, and are used to represent correspondence form the composition example to one of the diagram elements.
Revised Text: Add a fourth key to both figures 8.1 and 8.2 , showing light grey dashed arrow, labeled as �correspondence�
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14418: Japan CORBA Part 3 PAS Ballot Comments - comment 13.5 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
8.2.9.1	Code fragment
Comment: 
It is unclear if this description is normative or informative.
Proposed change:
Make distinction between normative and informative.

Resolution: Agree to clarify that this code fragment is a normative implicit definition
Revised Text: In 8.2.9.1 third paragraph, change: �illustrated the declaration� To �implicitly defines the normative form for the declaration�
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14419: Japan CORBA Part 3 PAS Ballot Comments - comment 14 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Annex A	
Comment: 
This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.
Proposed Change
Remove Annex a or make it informative Annex

Resolution: Agree to make Annex A an informative Annex
Revised Text: Change �(normative)� to �(informative)� on the line after the Title of Annex A
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14420: Japan CORBA Part 3 PAS Ballot Comments - comment 15 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
Annex B,C	
Comment: 
This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG document only.
Proposed Change
Remove Annex D and C from ISO standard.

Resolution: Agree to remove Annex B and Annex C from both the ISO Standard and the OMG specification (for consistency)
Revised Text: Remove both annex B and Annex C from the specification
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14421: Japan CORBA Part 3 PAS Ballot Comments - comment 16 (corba-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 
Location:
All Clauses	
Comment: 
ISO standard documents are described with "shall", "should" and "may".
Proposed Change
Define this with "shall", "should" and "may"

Resolution:
Revised Text: Add a new sub section header at beginning of clause 4: � 4.1 Terms Defined in this Standard � Add new subsection to end of section 4: � 4.2 Keywords for Requirement statements� The keywords "must", "must not", "shall", "shall not", "should", "should not", and "may� in this specification are to be interpreted as described in [RFC 2119].� � Add the following reference in the normative references - section 3.2: [RFC2119] IETF RFC2119, �Key words for use in RFCs to Indicate Requirement Levels�, S. Bradner, March 1997. Available from http://ietf.org/rfc/rfc2119
Actions taken:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 15714: Bad quotes and imported dot (corba-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Is:
A character literal is one or more characters enclosed in single quotes, as in �x.� 
Should be:
A character literal is one or more characters enclosed in single quotes, as in 'x'. 

(note that the present version uses curly quotes and the dot is probably misplaced)

Resolution:
Revised Text:
Actions taken:
September 30, 2010: received issue
April 11, 2012: Deferred to next RTF

Issue 15715: rule (85) is misplaced (corba-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The rule number (85) is indented, the rule number is not aligned with other rule numbers.

Resolution:
Revised Text:
Actions taken:
September 30, 2010: received issue

Issue 16047: Make anonymous types illegal (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

the specification already deprecated anonymous types, but to our idea it would be time to update the specification to say that anonymous types are illegal and remove all references to them

Resolution:
Revised Text:
Actions taken:
March 2, 2011: received issue
April 11, 2012: Deferred to next RTF

Issue 16315: interface ORB should be local (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

The ORB is intended to be a local object, it is not to be used outside of the process, so it should be a local interface

Resolution:
Revised Text:
Actions taken:
June 7, 2011: received issue
April 11, 2012: Deferred to next RTF

Issue 16887: Relationship connector and components/homes not clearly specified (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Martin Corino, mcorino(at)remedy.nl)
Nature: Clarification
Severity: Significant
Summary:

The spec does not clearly describe the relationship between connectors and components (inheritance?) and homes (manageability).


>From paragraph 7.4 (programming model for connectors) we can conclude the following:
1. connectors are derived from CCMObject
2. connectors (can) have a (keyless) Home


The formal spec in the earlier paragraphs of chapter however does not seem to mention any of this or of the consequences like:
a) can we explicitly define a connector as the managed component of a Home?
b) can we define explicit factories for connectors in a Home managing that connector?
c) can we declare a component as an explicit derivative of a connector?


I think the answers to a) and b) should be yes. This should be clearly described in the spec.
In principal the answer to c) could also be yes but I think that is a bad idea since the connector is definitely not meant to be used as a general purpose component. I feel this should actually be explicitly prohibited by the spec.

Resolution:
Revised Text:
Actions taken:
December 12, 2011: received issue
April 11, 2012: Deferred to next RTF

Issue 16942: Redundant bullet (corba-rtf)

Click here for this issue's archive.
Source: Kestrel Institute (Mr. Alessandro Coglio, coglio(at)kestrel.edu)
Nature: Clarification
Severity: Minor
Summary:

It seems that the last and 4th-to-last bullets both describe the Wstring type. Thus, one should suffice.

Resolution:
Revised Text:
Actions taken:
December 30, 2011: received issue
April 11, 2012: Deferred to next RTF

Issue 16994: Typo in set_values (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

The set_values is defined as 


void set_values(
in NVLis values // property values to set
);


but should be


void set_values(
in NVList values // property values to set
);

Resolution: In CORBA v3.3 Part 1 Interfaces, section8.6.2.2 change in NVLis to in NVList
Revised Text: in NVList values
Actions taken:
January 12, 2012: received issue
July 19, 2012: closed issue

Issue 16995: context:delete_values has type (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

delete_values is define as 


void delete_values(
in Identifie prop_name // name of property(s) to delete
);


but should be


void delete_values(
in Identifier prop_name // name of property(s) to delete
);

Resolution: In CORBA v3.3 Part 1 Interfaces, section section 8.6.2.4 replace: in Identifie with in Identifier
Revised Text: in Identifier
Actions taken:
January 12, 2012: received issue
July 19, 2012: closed issue

Issue 16996: context should be local interface (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

The context has to be define as local interface instead of a regular interface

Resolution:
Revised Text:
Actions taken:
January 12, 2012: received issue
April 11, 2012: Deferred to next RTF

Issue 17208: Add create_policy with just the type as argument (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl)
Nature: Clarification
Severity: Minor
Summary:

For several cases it would be helpful to have a:


Policy create_policy(
in PolicyType type) raises(PolicyError);

The name of the method has to change, to not conflict with the existing method

Resolution:
Revised Text:
Actions taken:
March 1, 2012: received issue

Issue 17273: Two typo's in Annex A.4 (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Marcel Smit, msmit(at)remedy.nl)
Nature: Enhancement
Severity: Minor
Summary:

There are two typo's in section A.4 on page 495. 
1
SERVENT_RETENTION_POLICY_ID should be SERVANT_RETENTION_POLICY_ID
2
PortableServer::ServentRetentionPolicy should be PortableServer::ServantRetentionPolicy

Resolution:
Revised Text:
Actions taken:
March 27, 2012: received issue

Issue 18150: Invalid IDL (corba-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the ZIOP 1.0 specification, the IDL in Annex A has:


  typedef unsigned short CompressorId { };

The braces are invalid and should be removed.

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18151: Invalid IDL (2) (corba-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the ZIOP 1.0 specification, Annex A has:


  Compressor get_compressor(
      in CompressorId compressor_id,
      in CompressorLevel compression_level)
        raises (UnknownCompressorId);

CompressorLevel should be CompressionLevel.

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18152: Missing PolicyValue encoding instructions (corba-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Section 17.3.1 of CORBA 3.1 / 3.2 says:


  17.3.1 Structures


  PolicyValue


  This structure contains the value corresponding to a Policy of the
  PolicyType indicated by its ptype. This representation allows the
  compact transmission of QoS policies within IORs and Service
  Contexts. **The format of pvalue for each type is given in the
  specification of that Policy.**



When the ZIOP 1.0 specification describes the ZIOP policies, it does not
give the format for pvalue.

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue

Issue 18153: Missing size information for decompress() (corba-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

The ZIOP body format contains the original length of the compressed
data, which is important because it allows the compressor to efficiently
allocate a buffer to uncompress it. Unfortunately, the
Compressor::decompress() operation is not given that size, meaning that
it has to guess how big the uncompressed data will be.


The original data size should be given to the decompress() operation.
One way to do that without changing the operation signature would be to
specify that the inout Buffer target sequence should have its length
pre-populated to the expected size.

Resolution:
Revised Text:
Actions taken:
October 10, 2012: received issue