Issues for Core Revision Task Force

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

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

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

Jira Issues

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 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 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: received issue
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: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.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 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 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 3914: Missing minor codes in Messaging Chapter (corba-rtf)

Click here for this issue's archive.
Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.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 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 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.  https://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.  https://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.
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: ADLINK Technology Ltd (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 4901: IDL keyword clash in CosNotification.idl (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:

CosNotification.idl contains a struct named 'EventType', which  clashes with the new CCM-related keyword 'eventtype'.

Resolution: purely editorial issue
Revised Text:
Actions taken:
March 5, 2002: received issue
August 21, 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 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 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, r.william.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 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: received issue
July 8, 2002: closed issue

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 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 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: received issue
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 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: received issue
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
April 28, 2003: closed issue, duplicate

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 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
July 19, 2012: closed issue

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:
January 15, 2004: received issue
February 5, 2004: closed issue

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 9, 2004: received issue
September 24, 2004: closed issue, duplicate

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 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 issue; Closed; No Change

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

Discussion:

Issue 14364: Japan CORBA Part 1 PAS Ballot Comments - comment 1 (corba-rtf)

Click here for this issue's archive.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 https://www.omg.org/oma/ �
Actions taken:
September 29, 2009: received issue
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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:
September 29, 2009: received issue
July 11, 2011: closed issue

Issue 14395: Japan CORBA Part 2 PAS Ballot Comments - comment 13 (corba-rtf)

Click here for this issue's archive.
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.
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 https://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.
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.
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.
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 https://www.omg.org/spec/JAV2I/1.4 [CORBASEC] Object Management Group, � Security Service�, available from https://www.omg.org/technology/documents/formal/security_service.htm [ASMOTS] Object Management Group, � Additional Structuring Mechanisms for the OTS�, available from https://www.omg.org/technology/documents/formal/add_struct.htm [TRANS] Object Management Group, "Transaction Service", available from https://www.omg.org/ technology/documents/formal/transaction_service.htm [FIREWALL] Object Management Group, "CORBA Firewall Traversal Specfication", available from https://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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. https://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 https://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.
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.
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.
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.
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.
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.
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.
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.
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 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 19738: Unclear and possibly harmful consequences of mandatory annotation definitions (corba-rtf)

Click here for this issue's archive.
Source: Remedy IT (Mr. Martin Corino, mcorino(at)remedy.nl)
Nature: Enhancement
Severity: Significant
Summary:

The current mandatory annotation definitions (7.4.15.4.1) will cause problems when IDL specifications are attempted to be reused between profiles applying different requirements concerning annotations (for example a profile with annotations and a profile without annotations or two or more profiles with different sets of annotations).      As the IDL 4 specification has removed the support for the commented form of annotations there is no possibility anymore to declare annotations in a form that has semantic meaning in one profile and does not cause parsing errors in another profile not supporting (these) annotations.  Even with the commented form supported the mandatory specification of annotation definitions for applied annotations would cause similar kind of problems as it is likely that the definitions for the standard set of annotations from one profile would not be available in another profile not supporting those annotations.      Personally I do not see any use for annotation definitions (and in fact I cannot find any commentaries regarding that in the spec) but I would suggest that at the very least IDL compilers should be allowed to ignore any annotations not known to the profile for which the IDL compiler is configured.  Ideally I would like to see a specification without any mandatory annotation definitions leaving it up to the tool supplier to enforce annotation definitions or implement implicit (embedded) definitions.

Resolution: withdrawn by submitter
Revised Text:
Actions taken:
March 31, 2015: received issue
November 5, 2015: closed issue