Issues for Interoperability Revision Task Force mailing list

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

Issue 55: IIOP object pointer resetting (interop)

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

Summary: Some IIOP implementations set the object pointers to nil object pointers, while others set them to nil pointers.

Resolution: closed, no revision required
Revised Text:
Actions taken:
July 16, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 74: Type ids in OBJECT_FORWARD return message (interop)

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

Summary: When a GIOP "LocateRequest" message is sent to a location service and it replies with OBJECT_FORWARD, can the IOR have a type_id equal to simply CORBA::Object rather than the true type id?

Resolution: Closed with revised text
Revised Text:
Actions taken:
August 13, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 77: LOCATION_FORWARD byte alignment (interop)

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

Summary: It would be good if the request body of a LOCATION_FORWARD reply always started on an 8 byte boundary.

Resolution: closed with revision from issue 901, 902
Revised Text:
Actions taken:
August 13, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 89: Correct IIOP marshalling of union TypeCodes (interop)

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

Summary: There is a problem with marshalling of union TypeCodes where multiple discriminant values select the same arm of the union.

Resolution: closed with revised text
Revised Text:
Actions taken:
August 22, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 126: CORBA::Object::non_existent (interop)

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

Summary: section 7.2.5 names it "non_existent", while section 12.4.1 says that the GIOP protocol version is "_nonexistent".

Resolution: resolved, close issue
Revised Text: Apparently _nonexistent was mistyped as _not_existent in Rev 2.0, 2.1, and 2.2. Fix is to change it > to _non_existent on Page 13-23 bullet 3 para 2 of Rev 2.2.
Actions taken:
September 23, 1996: received issue
June 24, 1998: moved from orb_revision to interop
February 17, 1999: closed issue

Discussion:

 moved from orb_revision to interop

Issue 382: Use of dynamic ports (interop)

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

Summary: Static port # should not be mandated-unworkable.It would be nice if a "standard" IIOP port # was registered with IANA

Resolution: closed with no revision required
Revised Text:
Actions taken:
December 2, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 383: Callbacks in IIOP (interop)

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

Summary: Callbacks in IIOP are to be implemented by getting the server to connect back to client and act as a client itself. If this could be changed it would really help from firewall perspective.

Resolution: closed with no revision required
Revised Text:
Actions taken:
December 2, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 460: IORs and identifying Object Keys (interop)

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

Summary: Is there a standard by which you can identify whether incoming IOR is for an object reference in our ORB or not? Opaque object key could have same encoding in another ORB...Confusion

Resolution: closed with no revision required
Revised Text:
Actions taken:
December 5, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 465: Transport Level Bridge (interop)

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

Summary: Work for transport level bridge that doesn"t need to understand full GIOP/IIOP protocol. Requirements: interoperability across network that doesn"t share commom transport protocol

Resolution: accomodated by "NeedAddressingInfo" change
Revised Text: related issues are issue 382 and 383
Actions taken:
December 4, 1996: received issue
April 9, 1998: closed issue

Discussion:

Issue 488: Problem with GIOP CancelRequest when fragments are used (interop)

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

Summary: Potential problem in determining whether CancelRequest message applies to the current message or a message that has already had a reply sent. Resolutions to this: (file)

Resolution: closed with revised text
Revised Text:
Actions taken:
January 30, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 543: IIOP server-initiated connection closure problem (interop)

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

Summary: On several operating systems the client"s writing of Request message after CloseConnection message can cause the unread CloseConnection message to be discarded from buffer

Resolution: resolved, see above
Revised Text: : change " After sending (or receiving) a CloseConnection message, both client or server must close the TCP/IP connection. " to " 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. "
Actions taken:
April 16, 1997: received issue
March 8, 1999: closed issue

Discussion:

Clarify behaviour of server closure to allow other options to avoid problems with some TCP/IP platforms   As a result of discussion on issue 2338, a recommendation for maximum interoperability using TCP/IP was proposed to be added to the GIOP  text

Issue 573: Type Extensions and code set negotiation (interop)

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

Summary: page 26 of ptc/97-01-01: replace "Code set negotiation is not....." with"Code set negotiation is performed on a per-request basis."

Resolution: closed with no revision required
Revised Text:
Actions taken:
May 14, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 574: Type extensions char code set negotiation (interop)

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

Summary: This negotiation adds 16 bytes to both request and reply messages. It"s overburdening an already obese message header scheme.

Resolution: closed, no revision required
Revised Text:
Actions taken:
May 14, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 585: IDL Type Extensions: wchar and wstring CDR encoding (interop)

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

Summary: Section 4.1 GIOP CDR Transfer Syntax: The spec should cover cases where TCS-W is byte-oriented or non-byte oriented

Resolution: duplicate to closed issue 1096
Revised Text: see core rtf 2.2 changes , changed to fix marshalling for giop 1.2
Actions taken:
May 29, 1997: received issue
June 22, 1998: moved from orb_revision to port-rtf
June 23, 1998: moved from port-rtf to interop
February 17, 1999: closed issue
February 19, 1999: closed issue; Resolved

Discussion:

 received issue

Issue 586: IDL Type Extensions: wstring CDR encoding issue (interop)

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

Summary: Section 4.1.2 p. 20 : Implementation needs to know whether it is byte-oriented or not, since CDR representation is different in each case. ORB expected to maintain table mapping of all codesets?

Resolution: duplicate to closed issue 1096
Revised Text: see core rtf changes interop/98-08-01
Actions taken:
May 29, 1997: received issue
June 23, 1998: moved from orb_revision to interop
February 17, 1999: closed issue

Discussion:

 closed issue

Issue 589: Fragment improvements (1) (interop)

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

Summary: Fragment messages should contain fragment header which contains a Request ID to associate the fragment with given request message. Frgamented request could otherwise block connection until sent.

Resolution: fixed, close issue
Revised Text:
Actions taken:
June 17, 1997: received issue
April 9, 1998: closed issue

Discussion:

Issue 590: Fragment improvements (2) (interop)

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

Summary: A response_expected setting should be added to a new "Fragment Header"(issue589) so that this setting may be delayed until the final fragment

Resolution: issue closed, no change required
Revised Text:
Actions taken:
June 17, 1997: received issue
April 9, 1998: closed issue

Discussion:

Issue 591: 1.0 backward compat (1) (interop)

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

Summary: If 1.1 client sends request to 1.0 server and tis causes 1.0 MessageError msf from serverthen 1.1 client must recognize MessageErrors from 1.o servers

Resolution: accomodated by clarification of version semantics
Revised Text:
Actions taken:
June 17, 1997: received issue
April 9, 1998: closed issue

Discussion:

Issue 592: 1.0 backward compat (2) (interop)

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

Summary: Assuming a 1.1 server we must Reply using 1.o to Request sent from 1.o client. If we get request with junk revision (eg 2.2) we wil automatically send (1.1) MessageError, but connection is close

Resolution: closed, accomodated by clarification of version semantics
Revised Text:
Actions taken:
June 17, 1997: received issue
April 9, 1998: closed issue

Discussion:

Issue 593: CloseConnection messages (interop)

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

Summary: 1.1 client may get 1.0 CloseConnection prior to first attemptto send Requests which it needs to recognize. Spec should clarify this.

Resolution: closed with revised text
Revised Text:
Actions taken:
June 17, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 651: Issue with service context (interop)

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

Summary: What should an ORB do when it gets a message with an unknown service context ID value?

Resolution: closed with revision
Revised Text:
Actions taken:
August 4, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 782: Clarification on IIOP2.1 12.3.2 fixed point type representation needed (interop)

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

Summary: In CORBA /IIOP 2.1, 12.3.2 OMG IDL Constructed Types, Fixed-Point Decimal Type Section it is unclear to me that where is the decimal point in the IDL Fixed Type Representation (Figure 12-3), how the scale information is represented in the format

Resolution: close with no change: The scale information is in the IDL definition of the fixed-point type
Revised Text:
Actions taken:
November 7, 1997: received issue
June 23, 1998: moved from orb_revision to interop
February 17, 1999: closed issue

Discussion:

 closed issue

Issue 798: Additional Requirement for GIOP 1.2 (interop)

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

Summary: I"d like to suggest that for GIOP 1.2 that we add an additional requirement   that an eight byte alignment occur before the body of any message.   This allows for numerous optimizations that currently cannot be performed   because the alignment of the beginning of the bodies is not consistent.

Resolution:
Revised Text:
Actions taken:
December 22, 1997: received issue
April 9, 1998: closed issue

Discussion:

Issue 807: Additional enumeration to the ReplyStatusType (interop)

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

Summary: Add an additional enumeration to the ReplyStatusType (and   LocationStatusType) called LOCATION_FORWARD_PERM (and   OBJECT_FORWARD_PERM) that acts like the current LOCATION_FORWARD (and   OBJECT_FORWARD), but can be used as a hint by the client that it should   permanently discard the original IOR and replace it with the new IOR.

Resolution:
Revised Text:
Actions taken:
December 10, 1997: received issue
March 26, 1998: closed issue

Discussion:

 closed with revision

Issue 817: IIOP marshalling of empty strings (interop)

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

Summary: Add a rule to CDR that allows an empty string to be  marshaled as a four byte count of zero, followed by nothing. This change is backward compatible because a count value of zero is currently impossible.           For a structure with five simple data members, this reduces the size of the   TypeCode on the wire from 88 bytes to 60 bytes (32% saving).

Resolution:
Revised Text:
Actions taken:
December 1, 1997: received issue
June 25, 1998: closed issue

Discussion:

Issue 885: Section 12.7.2 type IIOP::ProfileBody_1_0 not compatible (interop)

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

Summary: Section 12.7.2 defines the type IIOP::ProfileBody_1_0, which is      supposed to be compatible with the type ProfileBody of earlier      versions of CORBA. Unfortunately, it has a different repository      ID, leading to incompatibilities.      Proposed change: Add two pragmas to section 12.7.2, inside      the module IIOP

Resolution:
Revised Text:
Actions taken:
January 7, 1998: received issue
June 23, 1998: moved from orb_revison to interop
February 17, 1999: closed issue

Discussion:

Issue 886: Changes to and strategy for 1.2 (interop)

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

Summary: There are 2 changes:     1. add the request id to message fragments so that fragmentation is usable.     2. change the alignment rules so that message headers may be changed   without having to remarshal the body.     [ as an aside we"d really like to remove all the alignment rules so that   any"s no longer have to be double marshaled, but we don"t think its   possible to deal with all the details quickly ]     3. Add some more addressing information to request, locate_request,etc.

Resolution:
Revised Text:
Actions taken:
January 8, 1998: received issue
June 25, 1998: closed issue

Discussion:

Issue 904: Alignment and offsets in the presence of fragmentation (interop)

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

Summary: Its not clear to me how octet indices used for alignment and for   TypeCode indirection offsets are calculated in the presence of   fragmentation.  Different interpretations will prevent successful   interoperablity when fragmentation is used. IIOP 1.2 should clarify how alignment and TypeCode indirection work in the presence of fragmentation.

Resolution: closed with revision
Revised Text:
Actions taken:
January 13, 1998: received issue
March 26, 1998: closed issue

Discussion:

Issue 905: marshalling service context (interop)

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

Summary: The question is: What is the exact marshalling for an encapsulation    of a zero length sequence? (Service context is an encapsulation of a   sequence. CORBA 2.1, Section 10.6.7, page 10-22.)   While it may or may not be an ambiguity,    it does appear that ORB vendors differ in their interpretations, so   it might be important to clarify it.

Resolution: closed, no revision required
Revised Text:
Actions taken:
January 14, 1998: received issue
March 26, 1998: closed issue

Discussion:

Issue 935: GIOP Exception formatting description (12.4.2) (interop)

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

Summary:  CORBA 2.1"s GIOP Exception formatting description (12.4.2)   partitions the space of valid minor codes, with    20 bits reserved for unique vendor IDs and only 12 bits   (4096) for possible minor codes for each exception.   This seems backwards (1 million vendors each with   only 4 thousand minor codes!) and I would like   to request a change to (at least) swap these   numbers with the following textual change:      The high order 10 bits of minor_code_value contain a 10-bit   "vendor minor codeset ID" (VMCID);  the low order 22 bits    contain a minor code.  A vendor (or group of vendors)   wishing to define a specific set of system exception    minor codes should obtain a unique VMCID from the OMG, and   then define up to (22 bits of) 4194304 minor codes for each   system exception.  Any vendor....

Resolution:
Revised Text:
Actions taken:
February 2, 1998: received issue
June 23, 1998: moved from orb_revision to interop
February 17, 1999: closed issue

Discussion:

Issue 960: Query about GIOP and IIOP version numbers in 98-01-03 (interop)

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

Summary: I"ve been reading through 98-01-03.pdf (Change pages from Interop 1.2   RTF), and come across a problem concerning version numbers.      On page 13-39, the following paragraph has been added:        "The version number published in the Tag Internet IIOP Profile body     signals the highest GIOP minor version number that the server supports     at the time of publication of the IOR"      As far as I can see, the only version information in the profile body is   "iiop_version", which has the following note in its description:         "Note - This value is not equivalent to the GIOP version number      specified in GIOP message headers. Transport-specific elements of the      IIOP specification may change independantly from the GIOP specification"      Which is correct?

Resolution:
Revised Text:
Actions taken:
February 5, 1998: received issue
June 25, 1998: closed issue

Discussion:

Issue 1096: Issue about CDR encoding for wide characters (interop)

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

Summary: 1.  When encoding a wchar, always put 4 bytes into the CDR stream,   > adding any zero pad bytes as necessary to make the value 4 bytes   > long.   2.  When encoding a wstring, always encode the length as the total   > number of bytes used by the encoded value, regardless of whether the   > encoding is byte-oriented or not.

Resolution:
Revised Text:
Actions taken:
March 24, 1998: received issue
June 25, 1998: closed issue

Discussion:

Issue 1111: Wchar and Char can both be multibyte (interop)

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

Summary: With regard to the character encoding issue.      This is not just a problem with Wchar, and Wstring, it can happen   with char and string as well.  Multibyte encodings are used for   normal strings in the enhanced IDL as well as for    Wchars.   I think the problem is in the definition of char. For interop, the char type could be either:    1) restricted to a syntactic thing which can only be used with single byte encodings, or   2) we need to bite the bullet and make the encoding for char a sequence    of bytes if a multibyte encoding is chosen.

Resolution:
Revised Text:
Actions taken:
March 25, 1998: received issue
June 25, 1998: closed issue

Discussion:

Issue 1129: How to handle unexpected exceptions? (interop)

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

Summary: If I invoke an operation and the result is an exception that is not   defined as part of the operation"s definition, what should happen?  It   seems obvious that a different exception needs to be raised but which   one?  MARSHAL?

Resolution: Clarify to Be consistent with behaviour for system exceptions. Raise UNKNOWN exception
Revised Text: 15.3.5.5 change the last sentence to the following: " If an ORB receives a non-standard system exception that it does not support, or a user exception that is not defined as part of the operation's definition, the exception shall be mapped to UNKNOWN. "
Actions taken:
April 2, 1998: received issue
July 13, 1998: moved from orb_revision to interop
March 8, 1999: closed issue

Discussion:

Issue 1130: Compacting GIOP messages by using indirections (interop)

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

Summary: Repeated strings within an encapsulation can account   for a large percentage of the size of the encapsulation.   Indirections are already used in the marshaling of TypeCodes   to allow compacting of messages.  This can be extended   to also allow indirection for strings.  The current   encoding of a string is the unsigned long number of characters   in the string, followed by the null-terminated characters    comprising the string.  If we resolve the maximum value   for unsigned long "0xffffffff" for indirections, the   next byte can refer to a previously marshaled string.

Resolution: Close previously deferred issue as too much for RTF. Add to GIOP future version "wish list".
Revised Text:
Actions taken:
April 2, 1998: received issue
February 27, 2001: closed issue

Discussion:

Issue 1131: Compacting GIOP Messages by using templates (interop)

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

Summary: A common server pattern is that of "factory".  As a result   of a request, a Factory returns an object reference.   Frequently, these object references differ only by a   small fraction of their full size.  For example, object   references may be exactly the same except for the object_key   member of a GIOP profile and maybe the repository_id field   of the IOR.  Allowing the factory to return a more compact   representation of the object reference would yield great   savings in message size.   If the server or client can establish a template for filling    out object references (or possibly any type of data), a    more compact on-the-wire form can be used for such object   references once the template is established.

Resolution: Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do
Revised Text:
Actions taken:
April 2, 1998: received issue
February 27, 2001: closed issue

Discussion:

Issue 1132: Compacting GIOP Requests by hashing down operation names (interop)

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

Summary: As of GIOP/IIOP 1.1, a Request identifies the operation to   be invoked as a string.  If this can be compacting to   an integral value, savings would be possible on all   subsequent requests.  A simple solution would involve   a service context containing "operation name to index"   mappings.

Resolution: Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" st
Revised Text:
Actions taken:
April 2, 1998: received issue
February 27, 2001: closed issue

Discussion:

Issue 1133: Optimization of LOCATION_FORWARD replies (interop)

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

Summary: As of GIOP/IIOP 1.1, if a server wants to have a client   use some locally hashed down object_key in future requests   for an object, it must require one of the following:   a) the client use a LocateRequest in order for the server   to reply with a forwarded object reference that has   a hashed down object key.   b) respond with an OBJECT_FORWARD reply to the request,   forcing the client to remarshal the request with the   new target (the forwarded object reference"s key).   With some already recommended changes to GIOP 1.1,    such a reply will only require remarshaling the   message header, but an extra roundtrip is still required.      This could be avoided by addind a new service context   to the reply that contains the forward IOR, or a new   Reply type such as NO_EXCEPTION_AND_FORWARD that    indicates the first request has succeeded and that   subsequent requests can use the supplied forward IOR.

Issue 1136: Typecode equality (interop)

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

Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR   encoding of TypeCodes:      "The name parameters in tk_objref, tk_struct, tk_union, tk_enum,   tk_alias, and tk_except TypeCodes and the member name parameters in   tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified   by (or significant in) GIOP. Agents should not make assumptions about   type equivalence based on these name values; only the structural   information (including RepositoryId values, if provided) is significant.   If provided, the strings should be the simple, unscoped names supplied   in the OMG IDL definition text. If omitted, they are encoded as empty   strings."      This would suggest that the name and member name parts of a typecode   should never be considered significant when an ORB compares typecodes.      Of course, this still leaves the issue of what to do about aliases up in   the air.

Resolution:
Revised Text:
Actions taken:
March 29, 1998: received issue
February 17, 1999: closed issue

Discussion:

Issue 1138: Correct CDR encoding of an empty string (interop)

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

Summary: What is the correct encoding for an empty string according to GIOP?      In section 13.3.2, page 13-11 of CORBA 2.2, the following paragraph    describes the encoding of 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.  Both the string length and contents   include a terminating null."      This does not clarify what is the correct encoding for empty strings,   as there are two possibilities:   a) length=0, no string follows   b) length=1, "\0" (one-char with the terminating null)

Resolution:
Revised Text:
Actions taken:
April 15, 1998: received issue
June 23, 1998: moved from orb_revision to interop
June 25, 1998: closed issue

Discussion:

Issue 1292: CDR encoding of TypeCodes (interop)

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

Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR   encoding of TypeCodes:      "The name parameters in tk_objref, tk_struct, tk_union, tk_enum,   tk_alias, and tk_except TypeCodes and the member name parameters in   tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified   by (or significant in) GIOP. Agents should not make assumptions about   type equivalence based on these name values; only the structural   information (including RepositoryId values, if provided) is significant.   If provided, the strings should be the simple, unscoped names supplied   in the OMG IDL definition text. If omitted, they are encoded as empty   strings."      This would suggest that the name and member name parts of a typecode   should never be considered significant when an ORB compares typecodes.

Resolution:
Revised Text:
Actions taken:
March 30, 1998: received issue
June 23, 1998: moved from orb_revision to interop
June 25, 1998: closed issue

Discussion:

Issue 1302: No provision for numbering the fragments in fragmented IIOP messages (interop)

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

Summary: There seems to be no provision for numbering the fragments in fragmented    IIOP messages.  It is apparently assumed that the fragments will always   be received in the order that they are generated, however in unreliable    networks, such as mobile networks, this may not be a safe assumption.

Resolution:
Revised Text:
Actions taken:
May 1, 1998: received issue
June 23, 1998: moved from orb_revision to interop
June 25, 1998: closed issue

Discussion:

Issue 1303: TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY (interop)

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

Summary: Is there any particular reason that we shouldn"t allow these two   ComponentIds in IIOP IORs?  They certainly can be useful using IIOP for   optimization of client/server interactions, and can be safely ignored by   clients that don"t implement/understand them.      So could we add text to the spec that states that these components are   allowed in IIOP IORs, but the clients are free to ignore them?

Resolution: Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do
Revised Text:
Actions taken:
May 4, 1998: received issue
February 27, 2001: closed issue

Discussion:

Issue 1486: LOCATE_FORWARD_PERM and hash() (interop)

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

Summary: With GIOP 1.2, we added LOCATE_FORWARD_PERM to the protocol, which   permanently replaces an IOR with a different one. I believe we shouldn"t   have done this because it creates an internal inconsistency. The   Object::hash() operation requires that the hash value for a reference   must be immutable during its life time. (Unfortunately, "life time" isn"t   well-defined.)

Resolution: resolved
Revised Text: Since these fixes have not arrived, the resolution proposed is to depricated use of LOCATE_FORWARD_PERM Revised Text: Add the following statement to 13.4.3.2 at the end of the bullet list containing the explanation for LOCATE_FORWARD_PERM: " Note: Usage of LOCATE_FORWARD_PERM is now depricated, due to problems it causes with the semantics of the Object::hash() operation. LOCATE_FORWARD_PERM features could be removed from some future GIOP versions if solutions to these problems are not provided . " Add the following statement to 13.4.6.1 at the end of the bullet list containing the explanation for OBJECT_FORWARD_PERM: " Note: Usage of OBJECT_FORWARD_PERM is now depricated, 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. " In 15.6, immediately after the paragraph beginning "For GIOP version 1.2, the usage of LOCATION_FORWARD_PERM (OBJECT_FORWARD_PERM) behaves like ...", add the following " Note: Usage of LOCATE_FORWARD_PERM and OBJECT_FORWARD_PERM is now depricated, due to problems it causes with the semantics of the Object::hash() operation. LOCATE_FORWARD_PERM and OBJECT_FORWARD_PERM could be removed from some future GIOP versions if solutions to these problems are not provided .
Actions taken:
June 3, 1998: received issue
October 4, 2000: Approved by RTF in Vote 2
October 4, 2000: closed issue

Discussion:

At the final meeting of the Interop2000 rtf, it was agreed that unless fixes to the identified problems could be found, use of locate  forward perm should be depricated.     As a result of comments in vote 2, the wording of the future version message was modified from "will" to "could".

Issue 1503: Typecode indirection issue (interop)

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

Summary: We have come across the following issue with regard to typecode   indirections. The specification states:          the indirection is a numeric octet offset within the scope of some       "top level" TypeCode and points to the TCKind value for the       typecode.      The question arrises then is it legal to point to the (possible)   padding bytes preceeding the TCKind value or must the numberic value   indicate the position of the actual TCKind value. If you assume the   former then having rewound the required number of bytes you would word   align before interogating the TCKind enum value.

Resolution:
Revised Text:
Actions taken:
June 4, 1998: received issue
February 17, 1999: closed issue

Discussion:

Issue 1525: Type code marshalling (interop)

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

Summary: If a type code does not have a repository ID      (e.g. dynamic type ) then the member names for   structs and unions etc. should be required to be   sent on the wire for GIOP marsalling of Typecodes.   This may help the type code comparision issue to be resolved.

Resolution:
Revised Text:
Actions taken:
June 14, 1998: received issue
February 17, 1999: closed issue

Discussion:

Issue 1531: Typecode encoding is too long (interop)

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

Summary: Proposal: allow for alternate, compact encoding of typecodes   It is clear that typecodes are quite long when encoded into CDR and    transmitted over the wire.  This is particularly painful when the CORBA::Any   type is used in interfaces.  Besides, the use of any is becoming increasingly   important in multiple CORBA specifications, and a global solution to this   problem should be provided.      My proposal is to allow for an alternate encoding of typecodes, for those   specific cases where type identification can be achieved either by other   application specific mechanisms (for example, Name-Value pairs) or where   the Repository Id of the type is enough to reconstruct the full typecode   information locally on the receiving side.

Resolution:
Revised Text: :Any
Actions taken:
June 18, 1998: received issue
February 17, 1999: closed issue

Discussion:

Issue 1544: Marshalling of union type codes (interop)

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

Summary: On page 13-14, the spec says for marshaling of type codes:      	"Note that the tuples identifying struct, exception, and enum   	 members must be in the order defined in the OMG IDL definition   	 text."      This is right and proper, otherwise I wouldn"t know in what order things are   encoded or what their ordinal values are. However, the text does *not*   mention unions, so the order in which a type code describes the union   members is left to the implementation.      Suggestion: Require union members to also appear in the order in which   they are defined in the IDL.

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue
June 24, 1998: moved from orb_revision to interop
February 17, 1999: closed issue

Discussion:

Issue 1581: Type any marshalling rules force slow implementation (interop)

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

Summary: type any marshalling rules force slow implementation      Proposal: require that type any are marshalled as encapsulations

Resolution:
Revised Text: require that type any are marshalled as encapsulations
Actions taken:
June 25, 1998: received issue
February 17, 1999: closed issue

Discussion:

Issue 1588: Contents of MultiComponent component an encapsulation? (interop)

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

Summary: I can"t find any text in the CORBA 2.2 spec which says explicitly   whether the "component_data" field of IOP::TaggedComponent is actually   an encapsulation, or something else.      Why don"t we define a typedef "Encapsulation" for "sequence<octet>",   and use it in the IDL for those octet sequences which are really   encapsulations?

Resolution: :TaggedComponent is actually
Revised Text:
Actions taken:
June 29, 1998: received issue
February 17, 1999: closed issue

Discussion:

Issue 1653: CDR encoding for fixed (interop)

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

Summary: The CDR encoding rules for fixed-point types are incomplete.      In particular, it is not stated which value encodes what digit in each   nibble of an octet. It seems sensible to use 0x0 -> "0", 0x1 -> "1", ...,   0x9 -> "9". However, this isn"t stated (but should be).      The same comment applies to page 7-10 for DynFixed. I would suggest that   rather than repeat the same explanations in the CDR section and the DynFixed   section, the spec should use a cross-reference in the DynFixed section that   points at the CDR rules.

Resolution: Interop RTF has recommended adoption of this resolution.
Revised Text: : add to the CDR encoding rules 15.3.2.8 for the fixed type following the last paragraph: " Decimal digits are encoded as hexadecimal values in each half-octet as follows: Decimal digit Half-Octet Value ---------------------------------------- 0 0x0 1 0x1 2 0x2 ... ... 9 0x9
Actions taken:
July 9, 1998: received issue
February 12, 1999: moved from port rtf to interop
August 19, 1999: closed issue

Discussion:

State the rules in Chapter 15     This issue also asks for a cross-reference from the DynFixed section   to page 15-12. However, the DynFixed interface is likely to undergo   changes so I'd like to wait until we know where DynFixed is headed before   adding a cross-reference.     Since Chapter 15 is under control of the Interop RTF recommend the resolution   to that RTF.   Revised Text:   Page 15-12:     Add text below following the last para on page 15-12:             Decimal digits are encoded as hexadecimal values in each           half-octet as follows:                     Decimal digit           Half-Octet Value                   ----------------------------------------                           0                       0x0                           1                       0x1                           2                       0x2                         ...                       ...                           9                       0x9

Issue 1669: Narrow Interop (interop)

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

Summary: Narrowing is used in CORBA to check if an object reference obtained by    a client is of the desired type, ie. supports a specific IDL interface    that the client wants to use.      The client program has static information about the interface it wants    to use from the IDL specification. However, this is not enough as it    must also be possible to invoke remote objects that support an IDL    interface derived from the interface the client knows of.      There are at least 4 possiblities how the type checking can be resolved    (+ combinations of them):      (i) Narrow makes a query to an interface repository.   (ii) Narrow makes a call to the remote object.   (iii) The object reference contains enough information, e.g. the whole    interface type hierarchy that the remote object supports.   (iv) There is no narrow; the type check is made when a request is    received by the server-side ORB.

Resolution:
Revised Text:
Actions taken:
July 13, 1998: received issue
February 17, 1999: closed issue

Discussion:

Issue 1677: Chunked GIOP marshalling for variable-length types (interop)

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

Summary: Following the discussion of valuetype chunking in the OBV group, I"ve   been thinking that the arguments advanced for it really apply to all   the other variable-length types in CORBA (sequences and strings) as   well as to OBV value types, and wonder if we might try a small change   to the marshalling rules.      Currently, we marshal a string (say) by sending the length of the   string followed by the bytes of the string.  If we don"t know the   string"s length in advance, say because we are reading it from stdin   or a subprocess, we need to buffer it in memory and send it as one big   thing.  That"s inefficient.

Resolution: Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do
Revised Text:
Actions taken:
July 14, 1998: received issue
February 27, 2001: closed issue

Discussion:

Issue 1707: New IDL types (interop)

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

Summary: When the new IDL types were added (fixed, long double, etc), no new   IIOP or GIOP version was introduced, and no new version of CDR was introduced.   Instead, the marshaling rules for the new types were simply added to CDR,   and the type code interface was extended to handle these.      Unfortunately, this creates some rather serious problems for interoperability.

Resolution:
Revised Text:
Actions taken:
July 21, 1998: received issue
February 17, 1999: closed issue

Discussion:

Issue 1857: IIOP 1.2 fragmentation presents an unrecoverable error situation (interop)

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

Summary: IIOP 1.2 fragmentation presents an unrecoverable error situation   1.2 IIOP attempted to provide fragment interleaving  by defining a 1.2   fragment  header containing request    id.  This does  not  solve  the   possibility of receiving   multiple first   fragments over the    same   connection which do  not  contain request id"s.  There  is  no  way to   associate subsequent fragments with these  initial fragments since the   initial request id is received after the 1.2 Fragment header specified   request_id.

Resolution:
Revised Text:
Actions taken:
August 24, 1998: received issue
February 17, 1999: closed issue

Discussion:

Issue 1948: Clarification requested on GIOP 1.1 and wstring (interop)

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

Summary: Document interop/98-08-02 states:      For GIOP versions prior to 1.2, interoperability for Wstring is limited   to the use of two octet fixed length encodings.      Does this mean simply that only fixed length character encodings that   are use 2 byte characters are allowed for GIOP versions prior to 1.2?      The statement is slightly ambiguous, in that it can be parsed as: "(two   octet) fixed length encodings" or "two (octet fixed length encodings)".

Resolution: Close issue without change
Revised Text:
Actions taken:
September 14, 1998: received issue
March 8, 1999: closed issue

Discussion:

No change required.  The earlier marshalling rules for wstring in giop 1.1 were broken, and would only reliably work, given different implementations, with two octet encodings.

Issue 1962: Transmission of type codes across 2.2/2.3 boundaries (interop)

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

Summary: Suppose I am using a 2.3 ORB and receive a type code from a 2.2 ORB without   a repository ID. What am I supposed to do if I want to send that type   code somewhere else? (This could happen for an event channel, for example.)

Resolution: In this case, we need to add the case for empty repository ID string implies that a repositoryID is
Revised Text: page 15-23, second sentence of first paragraph of "Encoded Identifiers and Names" immediatly preceeding Table 15-7: Change sentence: " For GIOP 1.2 onwards, repositoryID values are mandatory. " to the following sentence with footnote: " For GIOP 1.2 onwards, repositoryID values are required to be sent, if known by the ORB. An empty repositoryID string is only allowed if a repositoryID value is not available to the ORB sending the type code. * " <* indicates footnote number> <text of footnote > " * A type code passed via a GIOP 1.2 connection shall contain non-empty repositoryID strings, unless a repositoryID value is not available to the sending ORB for a specific type code. This situation can arise,for example, if an ORB receives a type code containing empty repository IDs via a GIOP 1.0 or 1.1 connection and passes that type code on via a GIOP 1.2 connection). "
Actions taken:
September 16, 1998: received issue
October 25, 1999: moved from core to interop rtf
October 4, 2000: closed issue

Discussion:

This could also happen with  run-time specification of property types in property lists, where new properties could be defined by an  application, without reference to an IDL module containg the property Type definition.

Issue 1968: CloseConnection (interop)

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

Summary: There are quite a few words about CloseConnection in the GIOP 1.2 draft.   The major change is that either end of a connection can send the message   for a bi-directional connection.      However, the spec doesn"t say that a client *must* send a CloseConnection   message to the server before closing down. It just says that it *may*.      Similarly, CloseConnection is only partially defined for the server side,   as far as I can see.

Resolution: resolved
Revised Text: Resolution: Clarify section 15.5.1.1 Based on a circulated proposed resolution, it was agreed to make the client use of CloseConnection required for orderly release in GIOP 1.2, given the change can be published with CORBA 2.3a. After the first vote on a proposed resolution, discussion pointed out the need to keep the semantics of a connection shutdown implicitly cancelling any pending non-oneway requests. This requires changes to section 15.8. The close connection semantics, with the proposed resolution below, are stated in 15.5.1.1, for all versions of GIOP. The text imported from the bidirectional GIOP chapter has been changed to having a close connection automatically imply cancel of outstanding requests, for all versions of GIOP. The connection closure text in 15.8 is changed to a reference to the new proposed text for 15.5.1.1 Proposed Revised Text: 15.5.1.1 Change the clause to the following, given that the output of this Interop 2.4 RTF will be adopted in time for publication of CORBA 2.3 " Connections can be closed in two ways: orderly shutdown, or abortive disconnect. For GIOP versions 1.0, and 1.1: orderly shutdown is initiated by servers reliably sending a CloseConnection message, or by clients just closing down a connection. Orderly shutdown may be initiated by the client at any time. A server may not initiate shutdown if it has begun processing any requests for which it has not either received a CancelRequest or sent a corresponding reply. If a client detects connection closure without receiving a CloseConnection message, it must assume an abortive disconnect has occurred, and treat the condition as an error. . For GIOP Version 1.2 : Orderly shutdown is initiated by either the originating client orb (connection initiator) or by the server orb (connection responder) reliably sending a Close Connection message If the ORB sending the CloseConnection is a server, or BiDirectional GIOP is in use, the sending ORB must not currently be processing any Requests from the other side. The ORB which sends the CloseConnection must not send any messages after the CloseConnection. If either ORB detects connection closure without receiving a CloseConnection message, it must assume an abortive disconnect has occurred, and treat the condition as an error. If bidirectional GIOP is in use, the conditions of section 15.7 apply. For all uses of CloseConnection (for GIOP versions 1.0, 1.1, and 1.2): If there are any pending non-oneway requests which were initiated on a connection by the ORB shutting down that connection, the connection-peer ORB should consider them as canceled. If an orb receives a CloseConnection message from its connection-peer ORB, it should assume that any outstanding messages (i.e., without replies) were received after the connection-peer ORB sent the CloseConnection message, were not processed, and may be safely resent on a new connection. After reliably issuing a CloseConnection message, the issuing orb may close the connection. Some transport protocols (not including TCP) do not provide an "orderly disconnect" capability, guaranteeing reliable delivery of the last message sent. When GIOP is used with such protocols, an additional handshake needs to be provided as part of the mapping to that protocol's connection mechanisms, to guarantee that both ends of the connection understand the disposition of any outstanding GIOP requests. " In section 15.4.6 (CloseConnection): Change the sentence: " In GIOP version 1.2, if BiDirectional GIOP (see �Bi-DirectionalvGIOP� on page 15-48) is in use, both sides of the connection may send the CloseConnection message. " to the following: " In GIOP version 1.2, both sides of the connection may send the CloseConnection message. " In Section 15.8, Change the paragraph: " CloseConnection messages are a special case however. Either ORB may send a CloseConnection message, but the conditions in �Connection Management� on page 15-41, are modified for GIOP version 1.2, in that the ORB sending the CloseConnection must not be awaiting Replies to any Requests, and must not have begun processing any Requests from the other side. If these conditions are satisfied and the ORB sends a CloseConnection, the ORB on the opposite side must assume that any outstanding Requests it has sent were not processed and may be resent on a new connection. The ORB which sends the CloseConnection must not send any messages after the CloseConnection. It may also close the connection, although the caveats regarding protocols which do not implement "orderly shutdown" in �Connection Management� on page 15-41, apply. " to " CloseConnection messages are a special case however. Either ORB may send a CloseConnection message, but the conditions in �Connection Management� on page 15-41, apply. "
Actions taken:
September 18, 1998: received issue
March 8, 1999: closed issue

Discussion:

Issue 1975: Typo in page 15-44 (interop)

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

Summary: Page 15-44, second para after bullet list, the word LOCATION_FORWARD   appears in the wrong font (in two places).

Resolution: duplicate of issue # 2045
Revised Text:
Actions taken:
September 18, 1998: received issue
March 8, 1999: closed issue

Discussion:

 received issue

Issue 1978: COMM_FAILURE and completion_status (interop)

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

Summary: Page 15-43 of 98-08-13:   As Bob Kukura pointed out, COMPLETED_MAYBE could well be wrong. In particular,   if the connection goes down in the middle of a series of fragments that   make up the reply, or in between reads by the client of parts of the   message from a socket, the client can actually conclude reliably   that the status should be COMPLETED_YES.      I would suggest to strike the last clause of this para. This would also   bring things in line with the additions made to the exception section in   the IDL chapter.

Resolution: agree to remove the last sentence of 15.5.1.1
Revised Text: : Remove last sentence of 15.5.1.1. (note this has been done in the proposed resolution to Issue 1968)
Actions taken:
September 18, 1998: received issue
March 8, 1999: closed issue

Discussion:

Issue 1982: GIOP fragment alignment issue for CORBA 2.3 (interop)

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

Summary:    The following issue should be fixed prior to publishing CORBA 2.3.      Section 15.4.8 Fragment Message, page 15-40, of ptc/98-08-03, says:      > A primitive data type of 8 bytes or smaller should never be broken across two   > fragments.      This text has been in the specification since GIOP 1.1.      Section 15.4.1 GIOP Message Header, page 15-29, of ptc/98-08-03,   contains new text under the "message size" bullet:      > For GIOP version 1.2, if the second least significant bit of flags is 1, the   > message_size value must be evenly divisible by 8.

Resolution: resolved
Revised Text: In section 15.4.1 (pg 15-29), change the last paragraph to be " For Giop version 1.2, if the second least significant bit of Flags is 1, the sum of the message size value and 12 must be evenly divisible by 8. " In section 15.4.8 on the fragment message, in page 15-40, Change " For GIOP version 1.2, fragments other than the final fragment ... " to " For GIOP version 1.2, the total length (including the message header) of a fragment other than the final fragment ... "
Actions taken:
September 20, 1998: received issue
September 30, 1998: moved from core to interop
March 8, 1999: closed issue

Discussion:

Issue 2031: .Passing the interface repository ID of the method in IIOP (interop)

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

Summary: If we had a repository ID on the wire with every request, such errors could   > be caught. In addition, it would make it substantially easier to build   > tools such as IIOP packet tracers -- right now, it is next to impossible   > to dump the parameter values of IIOP requests because the packet tracer   > has no way of figuring out what the type of the target object is.      This could be added to IIOP in a reasonably non-invasive way, too.  We   could add a service context to the request which would carry the   repository ID of the interface in which the method was defined

Resolution: Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do
Revised Text:
Actions taken:
October 5, 1998: received issue
February 27, 2001: closed issue

Discussion:

Issue 2045: Obsolete text in ptc/98-08-13.pdf (interop)

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

Summary: In section 15.7, the second two paragraphs:      "IIOP 1.0 is based on GIOP 1.0.      IIOP 1.1 can be based on either GIOP 1.0 or GIOP 1.1. An IIOP 1.1 client   can either support both GIP 1.0 and 1.1, or GIOP 1.1 only. An IIOP 1.1   server must support both GIOP 1.0 and GIOP 1.1. An IIOP 1.1 server must   be able to receive both GIOP 1.0 and GIOP 1.1 requests and reply using   the same GIOP revision as invoked."      only refer to GIOP 1.0 and 1.1, not 1.2.  In light of the note in   section 15.7.2, these two paragraphs are obsolete and could be removed,   since the note covers the same information in a more generic way.

Resolution: resolved
Revised Text: Replace the last paragraph of 15.7 introduction with the following: " IIOP 1.1 can be based on either GIOP 1.0 or 1.1. An IIOP 1.1 client must support GIOP 1.1, and may also support GIOP 1.0. An IIOP 1.1 server must support processing both GIOP 1.0 and GIOP 1.1 messages. IIOP 1.2 can be based on either GIOP minor versions 1.0, 1.1, or 1.2. An IIOP 1.2 client must support GIOP 1.2, and may also support lesser GIOP minor versions. An IIOP 1.2 server must also support processing messages with all lesser GIOP versions." "
Actions taken:
October 6, 1998: received issue
March 8, 1999: closed issue

Discussion:

Issue 2068: Tagged Component interactions (interop)

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

Summary: The Tagged Components TAG_SSL_SEC_TRANS and TAG_IIOP_ALTERNATE_ADDRESS    both allow an IIOP profile to have an extra port in the IOR.  The    words around SSL_SEC_TRANS say something like "to be used instead    of the one in the profile proper".  Whereas the words around    ALTERNATE_ADDRESS are deliberately (?) vague.      So what should a client-side ORB do with one of these?  It could    view the IOR as broken, it could treat the ALTERNATE_ADDRESS    component as invalid or it could treat the port in the ALTERNATE_   ADDRESS component as either for TCP connection requests >or< for    SSL connection requests.  It could even look for a second    SSL_SEC_TRANS component.

Resolution: resolved, see above
Revised Text:
Actions taken:
October 9, 1998: received issue
March 8, 1999: closed issue

Discussion:

Discussion brought out the view that it has very clearly specified behavior which consists of   one of the following at the behest of the client ORB that is trying to establish a session:   (i) It decides that it wants to use SSL and proceeds to use the info from TAG_IIOP_SEC_TRANS, or     (ii) It decides to use TAG_IIOP_ALTERNATE_ADDRESS, and then SSL is completely out of the picture.     Once this choice is made the behavior is perfectly well specified.

Issue 2077: A Messaging related issue in GIOP 1.2 (interop)

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

Summary: Tom and I have discovered a minor outage in GIOP 1.2 relative to the   Messaging spec. The outage exists if we want to keep the door open for   publishing Messaging before GIOP is revved again. If we do not fix this   the publishing of Messaging will have to wait until the next rev of   GIOP. The outage is the following:      1) In the Request header the boolean field "response_expected" was   changed to an octet field "response_flags" in Messaging, with more   precise definition of the meanings of various flag values.      2) The Messaging spec defines a IOP::TaggedComponent for including QoS   policies in an IOR.      3) The Messaging service defines a ServiceContext for carrying QoS   policies in GIOP messages that carry ServiceContexts.

Resolution: Close with No change required
Revised Text: Text was incorporated into Corba 2.3, as directed in interop rtf report 98-07-01.
Actions taken:
October 13, 1998: received issue
October 13, 1998: closed issue

Discussion:

Issue 2155: OBV chunk boundaries (interop)

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

Summary: Section 15.3.4.4. of ptc/98-10-11 includes the following statement wrt to   ObV chunking:      "The data may be split into multiple chunks at arbitrary points except   within primitive CDR types, arrays of primitive types, strings, and   wstrings."      Unfortunately, this provides only dubious benfits, but introduces   significant problems.  Traditionally, CDR has been designed so that encoding   engines are only responsible for marshalling CDR primitives, and remain   independent of the actual constructed IDL type being marshalled.  The above   clause violates this rule: the CDR stream must know that the primitives   being marshalled are part of an array, understand the size of the array,   distinguish sequences from arrays, etc.      In addition, this is impossible to implement using the Java portable   streams.

Resolution:
Revised Text:
Actions taken:
October 30, 1998: received issue
March 5, 1999: moved from obv to interop
March 5, 1999: closed issue

Discussion:

Issue 2315: OBV GIOP clarification needed (interop)

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

Summary: On page 15-15 of the 2.3a core chapters, I am having trouble   understanding the wording in the first two bullets.  The definition   of what the different bit values mean is clear enough, but the   rationale for when they are used is not.      Specifically, I don"t understand the subtle difference between    "the actual parameter is the same type as the formal argument"   (first bullet) and "the actual value"s most derived type is the    same as the static type of the position currently being marshaled"   (second bullet).  Are these different cases?  If so, what is the   difference?

Resolution: resolved see above
Revised Text: Change the text: " Replace the second bullet on page 15-15 by the following text: " o the value 2 if only a single repository id is present in the encoding, which indicates the most derived type of the actual parameter (which may be either the same type as the formal argument or one of its derived types). " Add the following new section before existing section 15.3.4.2, : " 15.3.4.x Example The following examples demonstrate legal combinations of truncatability, actual parameter types and GIOP encodings. This is not intended to be an exhaustive list of legal possibilities. The following example uses valuetypes animal and horse, where horse is derived from animal. The actual parameters passed to the specified operations are an_animal of runtime type animal and a_horse of runtime type horse. The following combinations of truncatability, actual parameter types and GIOP encodings are legal. 1) If there is a single operation: op1(in animal a); a) If the type horse cannot be truncated to animal, i.e. horse is declared: valuetype horse: animal ... Actual Invocation Legal Encodings op1(a_horse) 2 horse 6 1 horse Note: If the type horse is not available to the receiver, then the receiver throws a demarshaling exception. b). If the type horse can be truncated to animal, i.e. horse is declared: valuetype horse: truncatable animal ... Actual Invocation Legal Encodings op1(a_horse) 6 2 horse animal Note: If the type horse is not available to the receiver, then the receiver tries to truncate to animal. c) Regardless of the truncation relationships, when the exact type of the formal argument is sent: Actual Invocation Legal Encodings op1(an_animal) 0 2 animal 6 1 animal 2) Given the additional operation: op2(in horse h); (i.e. the sender knows that both types horse and animal and their derivation relationship are known to the receiver) a). If the type horse cannot be truncated to animal, i.e. horse is declared: valuetype horse: animal ... Actual Invocation Legal Encodings op2(a_horse) 2 horse 6 1 horse Note: The demarshaling exception of case 1 will not occur, since horse is available to the receiver. b). If the type horse can be truncated to animal, i.e. horse is declared: valuetype horse: truncatable animal ... Actual Invocation Legal Encodings op2 (a_horse) 2 horse 6 1 horse 6 2 horse animal Note: Truncation will not occur, since horse is available to the receiver. "
Actions taken:
January 20, 1999: received issue
January 22, 1999: moved from Core to Interop RTF
March 8, 1999: closed issue

Discussion:

Add clarification that second case is for when actual parameter value type  is derived from formal parameter value type, and truncation is not in use.

Issue 2324: Move recently added text to correct place (interop)

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

Summary: The recently addded fourth bullet on page 15-18 "For value types that have   an RMI: rep id, ORBs must include at least the most derived rep id, in the   value type encoding." should be moved back to be a paragraph on page 15-15,   preceding the paragraph that starts "If the receiving context ...".      Its current placement is incorrect because this section (15.3.4.4)    describes chunking, and this bullet has nothing to do with chunking but    concerns how much type information needs to be specified in the encoding   (the subject of section 15.3.4.1).

Resolution: To accept proposed change
Revised Text: Move fourth bullet on page 15-18 to be its own paragraph in 15.3.4.1, preceeding the paragrapy that starts "If the receiving context.."
Actions taken:
January 21, 1999: received issue
March 8, 1999: closed issue

Discussion:

Issue 2326: Clarification of OBV GIOP encoding rules (interop)

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

Summary: The last sentence of section 15.3.7 "The abstract encoding of value type   always includes RepositoryId information." needs to appear somewhere in   section 15.3.4.1.

Resolution: see above
Revised Text: Add the following new paragraph preceding the paragraph on page 15-15 that starts "If the receiving context ...". " For value types marshaled as abstract interfaces (see section 15.3.7), repository ID information must be included in the value type encoding. "
Actions taken:
January 21, 1999: received issue
March 1, 1999: moved from Core RTF to Interop
March 8, 1999: closed issue

Discussion:

Editorial repeat of text from 15.3.7 to also appear in 15.3.4.1  Since this issue is purely editorial, it was not voted by the RTF.

Issue 2333: GIOP encoding of nil Abstract Interface is unspecified (interop)

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

Summary: Section 15.3.7 of 98-12-04 discusses the encoding of abstract   interfaces, but neglects to mention how to encode an abstract   interface whose value is nil.

Resolution: see above
Revised Text: : Append sentence to 15.3.7: "If there is no indication whether a nil abstract interface represents a nil object reference or a null valuetype, it shall be encoded as a null valuetype."
Actions taken:
January 21, 1999: received issue
June 15, 2001: closed issue

Discussion:

To Add proposed clarification text for nil abstract interface case.

Issue 2338: Potential interop. problem in CORBA 2.3: pseudo-operation marshalling (interop)

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

Summary: Existing CORBA 2.2 compatible CORBA clients will fail when invoking   the non_existent pseudo-operation with a compliant CORBA 2.3 server.    We have observed this problem in practice with at least one other   commercial Java ORB, who changed from the Corba 2.2 marshalling to the   Corba 2.3 marshalling when they changed the version of their product,   thereby breaking our existing customer"s code.      Section 15.4.1.2 (p. 15-31) of ptc/98-12-04 CORBA 2.3a defines the CDR   marshalling for pseudo-operation non_existent in Object   pseudo-interface to be _non_existent. The spec is worded in such a way   that it implies that this marshalling applies for all GIOP clients,   not just GIOP 1.2 client      However, p. 13-23 of the CORBA 2.2 specification defines the mapping   of the same pseudo-operation as _not_existent.

Resolution: see below
Revised Text: Resolution: ORB vendors agreed that the text "_not_existent" was a typographic error, and "_non_existent" is what the concensus was as the correct operation name for GIOP. GIOP 1.2 will only accept "_non_existent". However, since some legacy GIOP 1.0 and 1.1 mplementations respond to "_not_existent", some clarification is required to reflect the facts of legacy implementations. Based on comments earlier circulated revision for vote, the proposed replacement makes conformance require use of _non_existent, but allows implementations of GIOP 1.0 and 1.1 to respond to "_not_existent", which came from a typographical error. Proposed Revised Text: add the following text after the introduction of "_non_existent" in 15.4.1.2: " For GIOP 1.2 and later versions, only the operation name "_non_existent" shall be used. The correct operation name to use for GIOP 1.0 and 1.1 is "_non_existent". Due to a typographical error in CORBA 2.0, 2.1, and 2.2, some legacy implementations of GIOP 1.0 and 1.1 respond to the operation name "_not_existent". For maximum interoperability with such legacy implementations, new implementations of GIOP 1.0 and 1.1 may wish to respond to both operation names, "_non_existent" and "_not_existent". "
Actions taken:
January 22, 1999: received issue
March 8, 1999: closed issue

Discussion:

Issue 2457: Unknown parts of an IOR and interoperability (interop)

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

Summary: There is currently a heated discussion in comp.object.corba about   interoperability (Subject: Naming Service Interoperability).      In a nutshell, the argument is about whether, if I send an object reference   created by ORB A as a parameter to ORB B, whether or not ORB B is      	a) obliged to accept that reference as a valid parameter      	b) obliged to return me the same reference I sent (in the sense   	   that the reference is functionally equivalent) when it returns   	   that reference as a parameter to me      	c) obliged to preserve the contents of the reference if it goes   	   though a cycle of object_to_string/string_to_object in ORB B.      Now, my argument in this thread is that if an ORB doesn"t behave in line   with the above three points, interoperability is completely lost because   I could never be guaranteed that I can, for example, expect to be able   to store an IOR in a Naming Service and have that work.

Resolution: issue split into issues 3234 and 3235
Revised Text:
Actions taken:
February 19, 1999: received issue
August 18, 1999: moved from core revision to interop
February 4, 2000: issues 3234 and 3235 replace this one
February 4, 2000: closed issue

Discussion:

The interop 1.1 RTF added the following "clarifications": Page 13-16 - " Object references have at least one tagged profile. Each profile supports one or more protocols and encapsulates all the basic information the protocols it supports need to identify an object. Any single profile holds enough information to drive a complete invocation using any of the protocols it supports; the content and structure of those profile entries are wholly specified by these protocols. A bridge between two domains may need to know the detailed content of the profile for those domains� profiles, depending on the technique it uses to bridge the domains [see footnote 1] . ----------- footnote 1. Based on topology and policy information available to it, a bridge may find it prudent to add or remove some profiles as it forwards an object reference. For example, a bridge acting as a firewall might remove all profiles except ones that make such profiles, letting clients that understand the profiles make routing choices. " page 13-18 subclause 13.6.2.3 " Specifications of components must include the following information: � Component ID: The compound tag that is obtained from OMG. � Structure and encoding: The syntax of the component data and the encoding rules. If the component value is encoded as a CDR encapsulation, the IDL type that is encapsulated and the GIOP version which is used for encoding the value, if different than GIOP 1.0, must be specified as part of the component definition. � Semantics: How the component data is intended to be used. � Protocols: The protocol for which the component is defined, and whether it is intended that the component be usable by other protocols. � At most once: whether more than one instance of this component can be included in a profile. Specification of protocols must describe how the components affect the protocol. The following should be specified in any protocol definition for each TaggedComponent that the protocol uses: � Mandatory presence: Whether inclusion of the component in profiles supporting the protocol is required (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). � Droppable: For optional presence component, whether component, if present, must be retained or may be dropped. " The issue was agreed to be replaced with two, more precisely worded issues.

Issue 2494: LocateRequest and LocateReply messages (interop)

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

Summary: GIOP 1.1 only allows Request and Reply headers to be fragmented.  But   GIOP 1.2 increases the size of LocateRequest messages, and large   LocateReply messages are also likely.  I see no reason why GIOP 1.2   should not allow LocateRequest and LocateReply messages to be   fragmented.  If noone objects, I"d like to see the following put to a   vote in the next ORB 2.4 Interoperability RTF for inclusion in CORBA   2.3:

Resolution: see above
Revised Text: Given the output of this Interop 2.4 RTF will be published in Corba 2.3: the following changes are proposed: In CORBA 2.3a, section 15.4.8, page 15-40, 3rd paragraph, change the first sentence from: "A Request or Reply message can be broken into multiple fragments." to to two sentences: "In GIOP 1.1, a Request or Reply message can be broken into multiple fragments. In GIOP 1.2, a Request, Reply, LocateRequest, or LocateReply message can be broken into multiple fragments." On the same page, in the second paragraph after the note, change: "... other than the final fragment of a Request or Reply message are required ..." to: "... other than the final fragment of a fragmented message are required ..." Note that this is the middle part of the same sentence whose begining is modified in the resolution being voted on for issue 1982. On page 15-28, at the end of the first paragraph of the "flags" bullet, add the following sentence: "The byte order for fragment messages must match the byte order of the initial message that the fragment extends."
Actions taken:
February 26, 1999: received issue
September 16, 1999: closed issue

Discussion:

:  The following text changes for fragmentation are proposed, including some clarifications for byte order   for fragmented messages being all the same.

Issue 2620: CODESET_INCOMPATIBLE exception (interop)

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

Summary: if a code set negotiation fails the CORBA 2.3 specfication says that a   CODESET_INCOMPATIBLE exception is to be raised. There doesn"t seem to be   any further reference to a CODESET_INCOMPATIBLE exception elsewhere. So   where is the CODESET_INCOMPATIBLE exception defined? Or should it read   INV_OBJREF?

Resolution:
Revised Text:
Actions taken:
April 22, 1999: received issue
April 26, 1999: moved from C++ to interop
April 28, 1999: closed issue

Discussion:

 closed

Issue 2801: fragmentation broken with bi-dir giop (interop)

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

Summary: I wish to raise the following as an urgent issue:      The way that message fragments are encoded in giop 1.2, in conjunction   with the giop 1.2 specification for bi-directional use of a connection,   can lead to situations where the protocol is ambiguous.      (This is urgent because it is impossible to implement the bi-directional   part of GIOP 1.2 without it.)

Resolution:
Revised Text:
Actions taken:
July 13, 1999: received issue
August 4, 1999: closed issue

Discussion:

Issue 2863: Issue: Problem with issue 2801 resolution (interop)

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

Summary: > > Add the following paragraph to 15.8:   > >   > >  "To avoid collisions of requestId in fragment messages when   > >  bi-directional GIOP is in use:   > >   > >  - a request may not be sent by an endpoint if a reply has been   > > sent by that endpoint without a terminating fragment.   > >   > >  - a reply may not be sent by an endpoint if a request has been   > > sent by that endpoint without a terminating fragment."   > >   >   > Why is a plain (non-fragmented) request/reply prohibited here? There has   > never been and feature interaction between fragmented request/replies and   > non-fragmented ones, so why have this restriction.      Jishnu Mukerji wrote:      > After poking around some it seems to me that the following words address   > Martin"s concern and hence the issue of inadvertently disallowing something   > that wasn"t broken in the current resolution of 2801. The additional word   > "fragmented" in two places is bracekted between "*"s.   >   > "To avoid collisions of requestId in fragment messages when   > bi-directional GIOP is in use:   >   >  - a *fragmented* request may not be sent by an endpoint if a   > *fragemented* reply has been sent by that endpoint without a terminating   >fragment.   >   >  - a *fragemented* reply may not be sent by an endpoint if a   > *fragmented* request has been sent by that endpoint without a terminating   >fragment."

Resolution: resolved, see below
Revised Text: Resolution: In section 15.8 (Bi-Directional GIOP), replace the para. that begins with "Bi-directional GIOP connections modify the behavior of Request IDs" with the following new paragraph: " Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP specification, "Connection Management" on page 15-44, it is noted that "Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection". This property of unambiguous association of requests and replies must be preserved while permitting each end to generate Request Ids for new requests independently. To ensure this, on a connection that is used bi-directionally in GIOP 1.2, the connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext is transmitted. A connection on which this regime of Request ID assignment is not used, shall never be used to transmit bi-directional GIOP 1.2 messages.
Actions taken:
September 15, 1999: received issue
September 28, 1999: closed issue

Discussion:

Issue 2904: profile ids & component ids (interop)

Click here for this issue's archive.
Source: Real-Time Innovations (Mr. Dave Stringer, dstringer(at)rti.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 15.7.3 includes TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS   in the list of tagged component ids when they are tagged profile ids.

Resolution: editorial change to CORBA 3.0 resolved
Revised Text:
Actions taken:
September 28, 1999: received issue
October 20, 1999: closed issue

Issue 2914: Component ids in 13.6.2.2 (interop)

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

Also, 13.6.2.2 claims "ORB services are assigned component identifiers   in a namespace that is distinct from the the profile identifiers".   What is the significance of this statement?

Resolution: duplicate
Revised Text:
Actions taken:
September 22, 1999: received issue
October 4, 2000: closed issue

Issue 2939: IANA ports for IIOP need to be documented in Ch 13 and 15 (interop)

Click here for this issue's archive.
Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Chapter 15 (formal/99-07-19), page 15-51 last para of section 15.7.2, and  Chapter 13 (formal/99-07-17), page 13-36 last para, assert that "no 'well known'  ports have been allocated", and then proceeds to state that individual  implementations must use some unallocated port and document it.    The statement about "no well known port has been allocated" needs to be revised  to reflect that a well known port (683 for IIOP) has been allocated. Then we can  change the statement about what individual implementations are expected to do by  merely replacing the "must use some unallocated port" by a "may use the well  known port or may use some unallocated port and document it" or some such.

Resolution: see below
Revised Text: The spec mentions port 683, but doesn�t say what it�s for (which is pointless). No-one is actually using 683 (or at least not for anything that�s well-defined). In addition, 683 is rather useless anyway because (at least under UNIX), you can use that port only if you are root. Change the first para on page 15-54 to read: Agents may freely choose TCP port numbers for communication; IIOP supports multiple agents per host.
Actions taken:
September 21, 1999: received issue
May 13, 2002: closed issue

Issue 2940: Need clarification on GIOP::TargetAddress (interop)

Click here for this issue's archive.
Source: Cisco Systems (Mr. Paul Kyzivat, nobody)
Nature: Clarification
Severity:
Summary:

Something seems unclear to me about how to interpret a RequestHeader_1_2  when the AddressingDisposition of the TargetAddress is ReferenceAddr:    In the case the request contains a full IOR, which may have several  profiles. Since each profile has its own object_key, and there is no  requirement that they all be the same, the key for the operation may  depend on which profile chosen.     The client had to choose some profile in order to send the request, but  that information is not included in the request. So apparently the  server must decide on its own which profile it would like to use. This  may not be the same one the client chose.    What if any requirements are there on how this is done?

Resolution: withdrawn by submitter...issue closed
Revised Text:
Actions taken:
September 22, 1999: received issue
October 22, 1999: closed issue

Issue 2941: Is GIOP 1.x sustainable any more? (interop)

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

Is GIOP 1.x really sustainable any more?  We've got implementation nightmares because:    * Features haven't been thought through properly    eg Fragment in 1.1, BiDir in 1.2    * Simple backwards compatibility is being lost    eg ReplyHeader v1.2 has fields in completely different places to    previous versions, albeit for very good reasons.    * The TypeCode CDR version problems    * Not enough information in certain messages    eg MessageError can't indicate which message may have caused a    problem, and certainly can't describe in what way there was an error.

Resolution: see above
Revised Text:
Actions taken:
September 23, 1999: received issue
May 13, 2002: closed issue

Discussion:

Changes of this magnitude cannot be cannot be done by an RTF and require  an RFP.

Issue 2952: Interop, 15.7.3 unclear wording (interop)

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

I do have a quick question on one part and that is  Section 15.7.3 IIOP IOR Profile Components.  This first paragraph has the  following line in it:  " All these components are optional presence in the  IIOP profile  and cannot be dropped from an IIOP 1.1 or 1.2 IOR".  Now I must admit that I  am  new to this CORBA thing, but is there something wrong with this sentence?  I am not quite sure what this means and the grammar seems quite odd ("are  optional prensence"?).  Any chance someone could translate?

Resolution: see above
Revised Text:
Actions taken:
October 15, 1999: received issue
May 13, 2002: closed issue

Discussion:

Rationale for Rejection  The quoted text has to do with fragmenting but since the example request is  not fragmented, the padding restriction does not apply.

Issue 2961: Standard System Exception minor codes missing in Chapter 13 (interop)

Click here for this issue's archive.
Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Chapter 13 (formal/99-07-17) is missing specification of minor codes for many  the standard system exceptions that are specified to be raised under various  circumstances.

Resolution: correct the erroneous minor codes and add ones where missing in chaps 13 and 15. Leave the resolutio
Revised Text: In 13.6.7 Object URLs, Change: " If conversion fails, string_to_object raises a BAD_PARAM exception with the following minor codes (to be assigned by the OMG): - BadSchemeName - BadAddress - BadSchemeSpecificPart - Other " to: " If conversion fails, string_to_object raises a BAD_PARAM exception with one of following minor codes, as appropriate: minor code 7 - string_to_object conversion failed due to bad scheme name minor code 8 - string_to_object conversion failed due to bad address minor code 9 - string_to_object conversion failed due to bad bad schema specific part minor code 10 - string_to_object conversion failed due to non specific reason " In 13.7.2.4 CodeSet Component of IOR Multi-Component Profile. change last paragraph: " If the code set component is not present in a multi-component profile structure, then the default char code set is ISO 8859-1 for backward compatibility. However, there is no default wchar code set. If a server supports interfaces that use wide character data but does not specify the wchar code sets that it supports, client-side ORBs will raise exception INV_OBJREF. " to (OMG Staff must supply the next available minor code as <n>: " If the code set component is not present in a multi-component profile structure, then the default char code set is ISO 8859-1 for backward compatibility. However, there is no default wchar code set. If a server supports interfaces that use wide character data but does not specify the wchar code sets that it supports, client-side ORBs will raise exception INV_OBJREF, with minor code <n>. " Add the following new minor code for the INV_OBJREF system exception in table 4-1 Minor exception codes: " <n> wchar Code Set Support not specified " In 13.7.2.6 Code Set Negotiation, change: " A DATA_CONVERSION exception is raised when a client or server attempts to transmit a character that does not map into the negotiated transmission code set. For example, not all characters in Taiwan Chinese map into Unicode. When an attempt is made to transmit one of these characters via Unicode, an ORB is required to raise a DATA_CONVERSION exception. " to (OMG Staff must assign the next avalable minor code for DATA_CONVERSION to <i>): " A DATA_CONVERSION exception is raised when a client or server attempts to transmit a character that does not map into the negotiated transmission code set. For example, not all characters in Taiwan Chinese map into Unicode. When an attempt is made to transmit one of these characters via Unicode, an ORB is required to raise a DATA_CONVERSION exception, with minor code <i>. " and change: " 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. 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. " to (OMG Staff must assign the next available minor code for BAD_PARAM as <m> ): " 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 minor code set to <n>. 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 minor code set to <m>. " Add the following new minor code for the DATA_CONVERSION system exception in table 4-1 Minor exception codes: " <i> character does not map to negotiated transmission code set " Add the following new minor code for the BAD_PARAM system exception in table 4-1 Minor exception codes: " <m> wchar transmission code set not in service context " In 15.3.5.5, change: " If an ORB receives a non-standard system exception that it does not support, or a user exception that is not defined as part of the operation's definition, the exception shall be mapped to UNKNOWN. " to (OMG staff must assigne the next two available minor code for UNKNOWN to <j> and <k>): " If an ORB receives a non-standard system exception that it does not support, or a user exception that is not defined as part of the operation's definition, the exception shall be mapped to UNKNOWN, with minor code set to <j> for a system exception or set to <k> for a user exception. " Add the following new minor codes for the UNKNOWN system exception in table 4-1 Minor exception codes: " <j> non-standard System Exception not supported <k> User Exception not defined for operatin "
Actions taken:
October 26, 1999: received issue
October 4, 2000: closed issue

Issue 2968: Second bit of response_flags (interop)

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 question below was posted to the corba-dev list. I have to admit  that I don't understand the purpose of the second-least significant bit  of response_flags either. From the text in the spec, it appears that  this bit is set if a request expects a response and is not invoked via  the DII, whereas if a request is oneway or invoked via the DII with  INV_NO_RESPONSE set, the bit is clear.

Resolution: closed issue ...clarified
Revised Text:
Actions taken:
November 2, 1999: received issue
November 5, 1999: closed issue

Issue 3014: padding at the end of a non-fragmented 1.2 request message (interop)

Click here for this issue's archive.
Source: AT&T (Dr. Sai-Lai Lo, )
Nature: Clarification
Severity:
Summary:

Suppose a GIOP 1.2 request message is sent for an operation with *no*  argument. In this case the request body is empty because there is no  argument.     Furthermore, the whole request message is non-fragmented, i.e. the  2nd least significant bit of Flags in the request header is 0. Now if the  request message header ends on a boundary which is not 8-byte  aligned. Should the request message be extended with extra padding after the  request message header to make the whole request message multiple of 8?    I think the relevant statement is in section 15.4.1 (page 15-31):    "For GIOP version 1.2, if the second least significant bit of Flags is 1,  the sum the message_size value and 12 must be evenly divisible by 8"    My intepretation of the statement is that the condition I just described  does not meet this critera. Hence the message should not be padded to  multiple of 8. It should just be ended with the end of the message header,  just like previous GIOP versions.    I'm asking for clarification on this issue because I'm seeing a different  behaviour in another ORB implementation and would like to pre-empt any  interoperability problem in future.

Resolution: see above
Revised Text:
Actions taken:
November 9, 1999: received issue
May 13, 2002: closed issue

Discussion:

Rationale for Rejection  Changes of this magnitude cannot be cannot be done by an RTF and require  an RFP.

Issue 3040: Minor code allocation inconsistency (interop)

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

CORBA 2.3, section 15.4.3.2 - Reply Body - states:    "A vendor (or group of vendors) wishing to define a specific set of system  exception minor codes should obtain a unique VMCID from the OMG, and then  define up to 4096 minor codes for each system exception."    Section 3.17 - Standard Exceptions - states:    "Within a vendor assigned space, the assignment of values to minor codes is  left to the vendor."    The first dictates that minor code numbers are in the space of each  Standard Exception.  Ie, the true # of minor codes is (4096 times  #-of-Standard-Exceptions).  But the second implies that vendors can  allocate their minor codes however they wish.    So which is it?  The first mandate (if you read it as a mandate) or the  second freedom?

Resolution: Take proposed resolution from Core RTF discussion in issue Archive
Revised Text: Change paragraph in section 15.4.3.2 - Reply Body : "A vendor (or group of vendors) wishing to define a specific set of system exception minor codes should obtain a unique VMCID from the OMG, and then define up to 4096 minor codes for each system exception." be replaced with with "A vendor (or group of vendors) wishing to define a specific set of system exception minor codes should obtain a unique VMCID from the OMG, and then use those 4096 minor codes as they see fit; for example, defining up to 4096 minor codes for each system exception."
Actions taken:
November 12, 1999: received issue
January 6, 2000: moved from core to interop rtf
October 4, 2000: closed issue; Resolved

Issue 3075: Length of wstring in GIOP 1.1 (interop)

Click here for this issue's archive.
Source: Fujitsu (Mr. Masayoshi Shimamura, shima.masa(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:

I have a question about GIOP wstring encoding. Section "15.3.2.7 Strings  and Wide Strings" in CORBA 2.3.1 says:        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. Both the string length and contents      include a terminating null. The terminating null character for a      wstring is also a wide character.    In the sentence above, I believe that the "length" represents number of  octets (in the case of byte oriented codeset) or number of unsigned  integers (in the case of non-byte oriented codeset).    For example,          "abc" (ASCII code) ----> length is 4 (including one null terminate)        L"abc" (Unicode, USC2) ----> length is 4 (including one null terminate of wchar)    Is my understanding right?

Resolution: see above
Revised Text:
Actions taken:
December 3, 1999: received issue
May 13, 2002: closed issue

Discussion:

Rationale for Rejection  This is correct for GIOP 1.1. GIOP 1.2 changed the meaning of length to  always indicate the number of octets, in order to reduce problems with bridg-ing  in environments where the codeset is unknown in the intermediate  bridges. The specification is unambiguous with respect to string length, so no  change is required.

Issue 3096: CDR Encapsulation Issue (interop)

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

In the current 2.3 spec section 15.3.3 on Encapsulation  states in the last paragraph:    "Note that this gaurantees a four-octet alignment of the     start of all encapsulated data within GIOP messages and     nested encapsulations(2)"    There's a foot note on the bottom of the page stating:    (2) "Accordingly, in cases where encapsulated data holds         data with natural alignment of greater than four         octets, some processors may need to copy the octet         data before removing it from the encapsulation. The         GIOP protocol itself does not require encapsulation         of such data"    Here's the problem, the latest revisions have added support  for a "[unsigned] long long" being the discriminator type  within a union and therefore the encapsulated information  for a tk_union TypeCode could have alignment needs of eight,  not four.    The footnote needs to be revised to indicate that copying  could be necessary for some type code indirections or at  least the sentence stating that  "GIOP problem itself..."  should be removed/revised. Of course we could try to   remove support for "long long" discriminators....    Some of the interoperability testing we've been doing  indicates that all but one vendor who supports long long  discriminator types are not doing things correctly...

Resolution: to close with revision
Revised Text: Change footnote 2 in 15.3.3 from: " 2) Accordingly, in cases where encapsulated data holds data with natural alignment of greater than four octets, some processors may need to copy the octet data before removing it from the encapsulation. The GIOP protocol itself does not require encapsulation of such data. " to: " 2) Accordingly, in cases where encapsulated data holds data with natural alignment of greater than four octets, some processors may need to copy the octet data before removing it from the encapsulation. For example, an appropriate way to deal with long long discriminator type in an encapsulation for a union TypeCode is to encode the body of the encapsulation as if it was aligned at the 8 byte boundary, and then copy the encoded value into the encapsulation. This may result in long long data values inside the encapsulation being aligned on only a 4 byte boundary when viewed from outside the encapsulation. "
Actions taken:
December 7, 1999: received issue
October 4, 2000: closed issue

Issue 3102: marshalling of null values unclear (interop)

Click here for this issue's archive.
Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Description: Instruction for marshalling of null values is missing (in    ptc/99-03-07). Issues include:  - The null_tag token is included in the grammar, but it's purpose is   described nowhere. If this is the intended encoding of any null value,  how  are the typing semantics of values to be maintained? For example,  which  type-specific factory is to be used to create the null value to  be  passed  to the servant? How are the truncation semantics to be  preserved?  - There is a statement in 15.3.4.5 that "[t]he tag value 0 is reserved  for future use". Does this refer to null_tag? (Note that there seems to  be  inconsistent use of "tag" within the text.) If so, how are null values  to be marshalled? The grammar doesn't seem to allow for zero length  value_data.

Resolution: to close with revision
Revised Text: Add new section after current 15.3.4.3: " 15.3.4.4 Null Values All value types have a distinguished "null". All null values are encoded by the <null_tag> (0x0). The CDR encoding of null values includes no type information. " In 15.3.4.5, change the following paragraph: " The end tag is a negative long whose value is the negation of the absolute nesting depth of the value type ending at this point in the CDR stream. Any value types that have not already been ended and whose nesting depth is greater than the depth indicated by the end tag are also implicitly ended. The tag value 0 is reserved for future use (e.g., supporting a nesting depth of more than 2^31). The outermost value type will always be terminated by an end tag with a value of -1. " to: " The end tag is a negative long whose value is the negation of the absolute nesting depth of the value type ending at this point in the CDR stream. Any value types that have not already been ended and whose nesting depth is greater than the depth indicated by the end tag are also implicitly ended. An end tag value of 0 is reserved for future use (e.g., supporting a nesting depth of more than 2^31). The outermost value type will always be terminated by an end tag with a value of -1. "
Actions taken:
December 10, 1999: received issue
October 4, 2000: closed issue

Issue 3128: Table 13-1 needs update for valuetypes & abstract interfaces (interop)

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

Table 13-1 is missing a row:    Feature		Version 1.0	Version 1.1	Version 1.2  -----------------------------------------------------------  Valuetypes and					yes  Abstract  Interfaces

Resolution: add table row as suggested.
Revised Text: Add the following row to table 13-1,. which states that the "valuetypes and abstract interfaces" are included in GIOP 1.2: " Feature Version 1.0 Version 1.1 Version 1.2 ----------------------------------------------------------- Valuetypes and yes Abstract Interfaces ----------------------------------------------------------- "
Actions taken:
December 16, 1999: received issue
October 4, 2000: closed issue

Issue 3176: Supporting TAG_MULTIPLE_COMPONENTS (interop)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Vishy Kasar, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

I have a question on how can ORB vendor support  profile with ID  TAG_MULTIPLE_COMPONENTS? The spec 2.3/13.6.2 says single profile holds  enough information to drive a complete invocation. Let us say we have an  IOR with one profile and the ID is TAG_MULTIPLE_COMPONENTS. As per  13.6.2.2, the profile body in this case contains a  MultipleComponentProfile. Let us again assume that there is only one  TaggedComponent with component id of TAG_CODE_SETS and its component  data.    What we have here is a legal profile with no end point information. What  can a ORB do with such a profile? Is there any thing broken here or did  I just misinterpret the spec completely?

Resolution: Close with no revision
Revised Text:
Actions taken:
January 4, 2000: received issue
October 4, 2000: closed issue

Discussion:

When the spec says that a single profile holds enough information to drive a complete invocation, it means two things:     1.  Each profile is exclusive.  The ORB should not combine information from more than one profile when binding to the object  implementation.     2.  Each profile must stand alone.  A profile is broken if it does not contain enough information to complete an invocation.  This is  where the above example IOR fails.

Issue 3195: CORBA 2.3.1 missing text describing the response_expected field (interop)

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

When the response_flags text was added for GIOP 1.2 Request processing,  the old text for the GIOP 1.0 and 1.1 response_expected field was  removed.  Thus, the current documentation no longer completely describes  the GIOP 1.0 and 1.1 protocols.

Resolution: to close with revision
Revised Text: Add the following following text to the response_flags bullet item of section 15.4.2.1: " For GIOP 1.0 and 1.1 a response_expected value of true is treated like a response_flags value of \x03, and a response_expected value of false is treated like a response_flags value of \x00. "
Actions taken:
January 7, 2000: received issue
October 4, 2000: closed issue

Issue 3231: chunked value encoding: (interop)

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

a chunk can be followed by:    1. a new chunk (starting with its size tag)     (1 <= chunk_size_tag < 0x7fffff00  2. a new value (value_tag | 0 | value_ref)      (0x7fffff00 <= value_tag <= 0x7fffffff)     (valueref = 0xffffffff)  3. an end tag      (0x80000000 <= end_tag <= 0xffffffff)    A value indirection and a "top-level" end tag, both have the same tag (0xffffffff).  Consequently, the 0xffffffff tag marks the end of the current value but it is not clear whether or not a new value (indirection) has started.     An example where this situation occurs is a ring buffer that is chunked encoded.

Resolution: to close with revision
Revised Text: n section 15.3.4.5, 3rd bullet point, move the sentence " For the purposes of chunking, values encoded as indirections or null are treated as non-value data. " to its own bullet point before the current 3rd bullet.
Actions taken:
January 18, 2000: received issue
October 4, 2000: closed issue

Discussion:

The following was extracted from Email discusson on this Issue   > >   > > All null values and indirections are stored as part of the containing   > > chunk, therefore a chunk will never terminate with either of these   > > values.   > >   > > See 15.3.4.5, two pages along, 3rd bullet point from start of section,   > >   > > "Chunks are never nested. ... For purposes of chunking, values encoded   > > as indirections or null are treated as non-value data"   > >   > > This should be made clearer, put the last sentance as a bullet point   > > before the "Chunks are never nested.." point, and change the bullet   > > point to "With the exception of indirected or null values enclosed in a   > > chunked value, chunks are never..."   > >   > > This is a clear enough proposal for a vote.   > >   > There was quite a bit of further debate of this wording after this initial   > proposal.  I do not agree with adding "With the exception of indirected or   > null values enclosed in a chunked value," to the "Chunks are never nested"   > sentence.  This is because indirected or null values enclosed in a chunked   > value are not chunks and are therefore not an exception to the rule about   > non-nesting of chunks.   > I am OK with the other proposed change to move up the sentence "For   > purposes of chunking, values encoded as indirections or null are treated as   > non-value data" and make it a separate bullet point.

Issue 3234: What should an ORB do when it does not find any profile in an IOR (interop)

Click here for this issue's archive.
Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

As per the discussion in the Interop RTF meeting in Mesa, it was decided to  split up 2457 into two parts as follows:    Part 1: What should an ORB do when it does not find any profile in an IOR that  it is able to use? This should usually not happen in a CORBA interoperability  compliant ORB, but the possibility should be covered in the spec anyway.

Resolution: to close with agreed resolution
Revised Text: 1. In Chapter 4 of Core in the table of standard minor codes add the following: a. Under TRANSIENT add the line (OMG staff needs to use the next available minor code as <j>: --- <j> No usable profile in IOR b. Under IMP_LIMIT add line (OMG staff needs to use the next available minor code as <k>: --- <k> Unable to use any profile in IOR 2. Immediately following the first paragraph after the module IOP IDL in section 13.6.2, starting with "Object references have at least one tagged profile.", insert the following paragraph: "An ORB may be unable to use any of the profiles provided in an IOR for various reasons which may be broadly categorized as transient ones like temporary network outage, and non-transient ones like unavailability of appropriate protocol software in the ORB. The decision about the category of outage that causes an ORB to be unable to use any profile from an IOR is left up to the ORB. At an appropriate point, when an ORB discovers that it is unable to use any profile in an IOR, depending on whether it considers the reason transient or non-transient, it should raise the standard system exception TRANSIENT with standard minor code <j>, or IMP_LIMIT with the standard minor code <k>."
Actions taken:
January 18, 2000: received issue
October 4, 2000: closed, approved in vote 1
October 4, 2000: closed issue

Discussion:

There is no way for an ORB to know theintended use of an IOR when it is received. indeed, it may even be difficult for an application to know whether it wants to use an IOR to invoke an operation or it simply wants to pass it on as a parameter in another operation invocation a-priori. There potentially are two parts to this issue: (i) What should an ORB do when it receives an IOR that contains no profile that it knows anything about. (ii) What should an ORB do when an attempt is made to invoke an operation using an IOR which contains no profiles that the ORB understands at the point the invocation is attempted. The primary focus of this issue in my opinion should be (ii), since (i) is covered by issue 3303. You can either accept and stash away such an IOR or you can reject it, and the resolution of 3303 will cover that. There was an extended discussion on what standard exception should be raised when an attempt is made to invoke an operation using an IOR that contains no understandable profiles/components, in which TRANSIENT, INV_OBJREF, IMP_LIMIT, etc. were considered. The bottom line here is that not finding a working profile is one of several possible reasons why an attempt to do an invocation might fail. The other reasons could be temporary outage in network, or permanently bad IP address in the IOR, or a bunch of other things, many of which are not even clearly recognizable at a given point in time. Perhaps, it is reasonable to see if one can clearly divide the failure causes into those that the ORB believes are recoverable (e.g. I know the profile, but can't raise the target), and those that it definitely knows are not recoverable (e.g. no understandable profile/component in IOR), and based on that raise either a TRANSIENT or a IMP_LIMIT standard exception respectively, with specific new standard minor code.

Issue 3235: Should an ORB be allowed to drop non-standard profiles (interop)

Click here for this issue's archive.
Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

Part 2: Should an ORB be allowed to drop non-standard profiles (as it is allowed  to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though it is not faced  with any resource contraints. Moreover, when it is faced with resource  contraints should it be required to follow a specific sequence in determining  what profiles to drop.

Resolution: The proposed resolution defines two possible IOR conformance classes for every ORB interoperability
Revised Text: Suggested Proposed Changes: Change the last sentence in the paragraph in 13.6.6 under the IDL description of the IOR format, and its footnote from: " A bridge between two domains may need to know the detailed content of the profile for those domains� profiles, depending on the technique it uses to bridge the domains.1 <footnote 1 on page 13-16:> Based on topology and policy information available to it, a bridge may find it prudent to add or remove some profiles as it forwards an object reference. For example, a bridge acting as a firewall might remove all profiles except ones that make such profiles, letting clients that understand the profiles make routing choices. " to the following new paragraphs: " When a specific protocol is used to convey an object reference passed as a parameter in an IDL operation invocation (or reply), an IOR which reflects, in its contained profiles, the full protocol understanding of the operation client (or server in case of reply) may be sent. A receiving ORB which operates (based on topology and policy information available to it) on profiles rather than the received IOR as a whole, to create a derived reference for use in its own domain of reference, is placing itself as a bridge between reference domains. Interoperability inhibiting situations can arise when an orb sends an IOR with multiple profiles (using one of its supported protocols) to a receiving orb, and that receiving orb later returns a derived reference to that object, which has had profiles or profile component data removed or transformed from the original IOR contents. To assist in classifying behaviour of ORBS in such bridging roles, two classes of IOR conformance may be associated with the conformance requirements for a given ORB interoperability protocol: Full IOR conformance requires that an orb which receives an IOR for an object passed to it through that ORB interoperability protocol, shall recover the original IOR, in its entirety, for passing as a reference to that object from that orb through that same protocol Limited-Profile IOR conformance requires that an orb which receives an IOR passed to it through a given ORB interoperability protocol, shall recover all of the standard information contained in the IOR profile for that protocol, whenever passing a reference to that object, using that same protocol, to another ORB. Note: Conformance to IIOP versions 1.0, 1.1 and 1.2 only requires support of limited-Profile IOR conformance, specifically for the IIOP IOR profile. However, due to interoperability problems induced by Limited-Profile IOR conformance, it is now depricated by the CORBA 2.4 specification for an orb to not support Full IOR conformance. Some future IIOP versions could require Full IOR conformance. " Page 13-17, last para of 13.6.2.1: Add the following at the end of the para. " ORBs claiming to support the Full-IOR conformance are required to preserve all the semantic content of any IOR (including the ordering of each profile and its components), and may only apply transformations which preserve semantics(e.g., changing Byte order for encapsulation). For example, consider an echo operation for object references: interface Echoer {Object echo(in Object o);}; Assume that the method body implementing this operation simply returns its argument. When a client application invokes the echo operation and passes an arbitrary object reference, if both the client and server ORBs claim support to Full IOR conformance, the reference returned by the operation is guaranteed to have not been semantically altered by either client or server ORB. That is, all its profiles will remain intact and in the same order as they were present when the reference was sent. This requirement for ORBs which claim support for Full-IOR conformance, ensures that, for example, a client can safely store an object reference in a naming service and get that reference back again later without losing information inside the reference. Page 13-18, section 13.6.2.3, last bullet: Replace last two bullet points and their preceding paragraph: " Specification of protocols must describe how the components affect the protocol. The following should be specified in any protocol definition for each TaggedComponent that the protocol uses: Mandatory presence: Whether inclusion of the component in profiles supporting the protocol is required (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). Droppable: For optional presence component, whether component, if present, must be retained or may be dropped. " with the following: " Specifications of protocols must describe how the components affect the protocol. In addition, a protocol definition must specify, for each TaggedComponent, whether inclusion of the component in profiles supporting the protocol is required (MANDATORY PRESENCE) or not required (OPTIONAL PRESENCE). An ORB claiming to support Full-IOR conformance shall not drop optional components, once they have been added to a profile. " Page 13-18, first para of 13.6.3: Change the last sentence of this para from: " An ORB must not drop these components from an existing IOR. " to: " An ORB claiming to support IIOP must retain these components if present in an IOR. " Page 13-19, last sentence of 13.6.3.1: Change last sentence to read: " The TAG_ORB_TYPE component can appear at most once in any IORprofile. For profiles supporting IIOP 1.1 or greater, it is optionally present. " Page 15-48, 15.7 immediately before 15.7.1: add the following paragraph: " Conformance to IIOP versions 1.1 and 1.2 requires support of Limited-Profile IOR conformance (see 13.6.2), specifically for the IIOP IOR Profile. As of CORBA 2.4, this limited IOR conformance is deprecated, and ORBs implementing IIOP are strongly recommended to support Full IOR conformance. Some future IIOP versions could require support of Full IOR conformance. " Page 15-51, first nested bullet above penultimate paragraph of 15.7.2: Change " These rules specify which components are mandatory presence, which are optional presence, and which can be dropped. " to read: " These rules specify which components are mandatory and which are optional. " Page 15-51, 15.7.3, first para: Change first para to read: " The following components are part of IIOP 1.1 and 1.2 conformance. All these components are optional. " Page 15-52, first para: Change para to read: " The following components are part of IIOP 1.2 conformance. All these components are optional. "
Actions taken:
January 18, 2000: received issue
October 4, 2000: closed issue

Discussion:

Consensus appears to be that ORBS should retain all information in an IOR received through IIOP messages, for  subsequent. passing to other orbs as parameters in IIOP request and reply messages.  However, ORBS should be able to continue  to claim conformance to existing versions of IIOP event if they prune received IORs of all non IIOP IOR profile information.     Comments from Vote 2 resulted in editorial changes to the wording of the deprecation text regarding future versions of GIOP  from "future IIOP versions will" to "Some future IIOP versions could".

Issue 3303: An ORB should not accept an IOR with no usable profiles (interop)

Click here for this issue's archive.
Source: Xerox (Mr. William C. Janssen, Jr., janssen(at)parc.xerox.com)
Nature: Uncategorized Issue
Severity:
Summary:

ORBs should be required to reject IORs that do not contain any profile that the ORB can use

Resolution: accomodated by proposed change from Issue 3234.
Revised Text:
Actions taken:
February 9, 2000: received issue
October 4, 2000: closed issue

Issue 3307: Validity of object references (interop)

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

Section 15.4.5, page 15-39:    	LocateRequest messages may be sent from a client to a server to  	determine the following regarding a specified object reference:    	- whether the object reference is valid    In the absence of a definition for how to judge a reference "valid", this  is a meaningless statement.

Resolution: close with revision
Revised Text: delete the following bullet item in 15.4.5: " whether the object reference is valid "
Actions taken:
February 9, 2000: received issue
October 4, 2000: closed issue

Issue 3315: Indirection for value types (interop)

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

Section 15.3.4, page 15-18:    	The encoding used for indirection is the same as that used for  	recursive TypeCodes (i.e., a 0xffffffff indirection marker  	followed by a long offset (in units of octets) from the beginning  	of the long offset).    	[...]  	  	Indirections may refer to any preceding location in the GIOP  	message, including previous fragments if fragmentation is used.  	This includes any previously marshaled parameters.    The beginning of the section ("is the same as that used for recursive  TypeCodes") is in conflict with what appears at the end ("refer to any  preceding location in the GIOP message [...]. This includes any previously  marshaled parameters.")    This is incorrect because the indirection for type codes does *not* permit  indirections that span type code boundaries (page 15-27):    	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.    I would suggest to rephrase the first part of what is on page 15-18  to avoid saying that the indirection is the same as for type codes  because that's simply not the case.

Resolution: close with revision
Revised Text: In 15.3.4, change: " The encoding used for indirection is the same as that used for recursive TypeCodes (i.e., a 0xffffffff indirection marker followed by a long offset (in units of octets) from the beginning of the long offset). " to: " The encoding used to indicate an indirection is the same as that used for recursive TypeCodes (i.e., a 0xffffffff indirection marker followed by a long offset (in units of octets) from the beginning of the long offset). "
Actions taken:
February 11, 2000: received issue
October 4, 2000: closed issue

Issue 3327: Preserving unencapsulated information (interop)

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

Page 15-50 of 2.3.1:    	ORBs that suport only version 1.1. or 1.2 IIOP profiles must  	ignore, but preserve, any data in the profile that occurs  	after the components member.    A 1.2 ORB is obliged to ignore, but preserve, any information that follows  the components member in 1_1 profile body. I think the cost of implementing  this is quite high. What follows after the components member is *not* in  a separate encapsulation. So, an ORB that receives an IOR that indeed has  data after the components member doesn't understand anything about that data  and therefore must treat it as a blob of bits.    However, the IOR might be little-endian and the receiving ORB might be  big-endian. When the receiving ORB wants to send the IOR back out, it  can't send it as a big-endian IOR because it can't know how to byte-swap  the data that follows the components member. That means that a big-endian  ORB is obliged to remarshal the IOR back as a little-endian IOR.  That's inconvenient, to say the least.    I don't think it makes sense to require an ORB to preserve something that  is not encapsulated, simply because the cost of doing this is high.  (The ORB has to keep a copy of the marshaled profile around because of  the trailing bit it doesn't understand.)

Resolution: Close with revision
Revised Text: On page 15-50 in the Bullet item "IIOP version", change: " If the minor version number is 0, the encapsulation is fully described by the ProfileBody_1_0 structure. If the minor version number is 1 or 2, the encapsulation is fully described by the ProfileBody_1_1 structure. If the minor version number is greater than 1, then the length of the encapsulated profile may exceed the total size of components defined in this specification for profiles with minor version number 1. ORBs that support only version 1.1 or 1.2 IIOP profiles must ignore, but preserve, any data in the profile that occurs after the components member. " to: " If the minor version number is 0, the encapsulation is fully described by the ProfileBody_1_0 structure. If the minor version number is 1 or 2, the encapsulation is fully described by the ProfileBody_1_1 structure. If the minor version number is greater than 2, then the length of the encapsulated profile may exceed the total size of components defined in this specification for profiles with minor version number 1 or 2. ORBs that support only version 1.1 or 1.2 IIOP profiles must ignore, but preserve, any data in the profile that occurs after the components member, for IIOP profiles with minor version greater than 1.2. "
Actions taken:
February 17, 2000: received issue
October 4, 2000: closed issue

Discussion:

The profile itself is an encapsulation. When an IOR is sent out, the encapsulated profiles *can* be   remarshalled without knowing their full internal structure. All that is necessary is to only decode as much as you know of a   profile when using it, ignoring any other data it might contain. And, keep the full encapsulated profile around for sending later.     Preserving the entire profile encapsulation is only necessary when two conditions are both true: the minor version is unknown, and  there is extra data in the encapsulation after demarshaling the members defined for the highest known minor version.  This isn't  going to cause any overhead at all until a new minor version of IIOP comes out that adds members to the profile.  Given that  anything that can be done with extra members could also be done with extra components,  this is not very likely.     However, it should be clarified that a legal IIOP 1.1 or 1.2 profile may not have any data after the sequence of components.

Issue 3405: Transferring Java exception reason string across the wire (interop)

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

Although this is a Java-specific issue, I suspect it will have to be  decided in interop, therefore I'd like this to be an interop issue.  I've  cc'ed java-rtf since I'm sure they'll be interested.    System exceptions only have:  minor code, completion status.  Java  exceptions all have a reason string as well.  This is a potentially  significant bit of info that is not getting transferred across the wire in  Java ORB implementations.  Our rmi over iiop customers expect this  information.    Our suggested solution is to create another service context for a system  exception reason string.  When a system exception occurs, on a Java server,  the ORB places the reason string into this service context on the reply  message.  On a Java client, the ORB checks for and extracts this string and  uses it when creating the system exception instance which is propagated to  the application code.  If the service context doesn't exist, the Java ORB  just does what it does today.  Any other client bindings may ignore this  service context.    Java bindings do not need to change for this proposal.    To be more precise (sorta), we need three things:  1.  A new service context ID         const ServiceId SystemExceptionReason = TBD;    2.  The context data associated with this ID is a CDR encapsulation of a  string.  3.  Some verbage somewhere describing this.

Resolution: closed/resolved
Revised Text: 1. In section 13.6.7, add a new IDL ServiceId constant called " ExceptionDetailMessage (value to be allocated). " 2. In section 13.6.7, add a new bullet to the ServiceId list as follows: " � ExceptionDetailMessage identifies a CDR encapsulation of a wstring, encoded using GIOP 1.2 with a TCS-W of UTF-16. This service context may be sent on Reply messages with a reply_status of SYSTEM_EXCEPTION or USER_EXCEPTION. The usage of this service context is defined by language mappings. " 3. In Table 13-1, add an entry for ExceptionDetailMessage showing that it is an optional part of GIOP 1.2.
Actions taken:
March 21, 2000: received issue
October 4, 2000: closed issue

Discussion:

The specified encoding for the encapsulated wstring is UTF-16.  This seems   natural since UTF-16 is the GIOP 1.2 fallback encoding for wstring, and so   all ORBs must be able to support this encoding for wstring data. The exception detail message should be encoded as a dedicated service context.   If further exception diagnostic data is added in the future, additional   service contexts can be defined to carry this.   The encoding is GIOP 1.2 (which fixed an encoding ambiguity in GIOP 1.1), with   TCS-w of UTF-16.

Issue 3409: IIOP 1.2 Early Reply message in presence of fragmented Request (interop)

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

It is unclear in the spec when reply messages are allowed when a fragmented  send message is sent.     It is possible to know that a system exception will occour before the last  fragment in a message is recieved, for example the request can be  demultiplexed to discover the object does not exist, or the appropriate  service contexts are not present.     It should be legal to send a reply containing anything but a NO_EXCEPTION or  USER_EXCEPTION before the last fragment is recieved.

Resolution: close without revision
Revised Text:
Actions taken:
March 8, 2000: received issue
October 4, 2000: closed issue

Discussion:

Issue 3431: Marshaling fixed-point decimal types (interop)

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

Looking at formal/99-10-07, 15.3.2.8 which describes marshaling of fixed  types I ran into a question. The section doesn't mention how to indicate  the scale of the written decimal.    My understanding is that the TypeCode of kind fixed, which gets written  before the value, indicates the maximum number of digits and the maximum  scale, not what is currently contained in the number. To describe the  current scale I would expect that a decimal point gets written to the  stream, just like the decimals into the half-octets as described in  15.3.2.8.

Resolution: Close with no Interop Revision
Revised Text:
Actions taken:
March 16, 2000: received issue
March 24, 2000: moved frpm core to interop
October 4, 2000: closed issue

Discussion:

  The TypeCode is only written to the stream if the fixed is contained in an any.  Otherwise, both sender & receiver implicitly know  the type.     The GIOP encoding for fixed is well specified as packed BCD with the number of digits as specified by the fixed type as declared  by the IDL.  For the particular case above, the fixed value must be padded with zeros to fit the scale and digits requirement of the  typecode.  So, for fixed<4.2>, the value "1.2" is transmitted as "0120".     this turns out to be a java-rtf issue.     The signature of the methods         void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal)       java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed()     need to be changed to         void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal, short, short)       java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed(short, short)     where the short parameters indicate the digits and scale of the fixed-point decimal.     This is because the information of the maximum number of digits and scale is lost when the IDL fixed gets mapped to the  BigDecimal for write_fixed.     On the other end, when the fixed is read off the stream, the BigDecimal can't be reconstructed to the original scale without  explicitly passing in the scale.     For fixed contained in an Any this information can be gathered from the associated TypeCode.

Issue 3434: Valuetype in anys. Unmarshaling problem? (interop)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Vijaykumar Natarajan, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

There seems to be a problem with valuetypes contained in anys.    Consider the following:  valuetype A {      A a;  };    valuetype B : A {    private long long x;  };      If an instance w/ the following structure:    A { a = {B { x = {<value>}}}}    is inserted into an any and the any is received by an event service. Given that  the event service has no type information of the B encoded inside of A, the  event service has no way of knowing how big A.a (an instance of B) is and how  many bytes it needs to read (unless it contacts an IR)    Am I missing something here?

Resolution: Close this issue and place it into the GIOP wish list for future enhancements to GIOP.
Revised Text: None required for GIOP 1.2
Actions taken:
March 20, 2000: received issue
February 27, 2001: closed issue

Discussion:

The fundamental problem comes down to the desire that Services like the event service be able to pass through valuetypes that it does not have compile time knowledge of. The obvious solution is to maintain the valuetype in its CDR encoded form, but the valuetype CDR encoding is not self-identifying in several ways: 1. The non-chunked encoding does not indicate the end of a valuetype (or the existence and extent of valuetypes encoded in its state). 2. The chunked encoding solves this problem, but still is not adequate. The encoded form cannot be reliably remarshalled without knowing the valuetype's TypeCode, since the byte order of the encoding is not part of the encoding, and even the chunked form doesn't make it possible to find and patch valuetype indirections in a valuetype's state. The only solution that applies to GIOP 1.2 is for the receiver to find the TypeCode for the valuetype in question. It can find the TypeCode in two ways: 1. Using a CodeBase reference it receives from the sender. 2. Doing its own lookup in the IFR. This is not as reliable as option 1, since it can suffer from version skew problems. If these methods of finding the TypeCode fails, then the receiver has no choice but to raise the MARSHAL or NO_IMPLEMENT exceptions as detailed in Chapter 5. Looking forward, if a future version of CDR encoding for valuetypes were modified (in GIOP 1.3?), then valuetypes could be held in CDR encoded-form and remarshalled without having to know the TypeCode (or quivalent information). However such CDR modifications are beyond the scope of this RTF, and should be place on the GIOP wish list.

Issue 3438: GIOP version and CloseConnection (interop)

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 believe that, at some point, we decided that it is legal to send  request for different GIOP versions over the same connection. Could someone  please confirm or deny? (My memory is a bit hazy on the details.)    At any rate, careful scrutiny of the spec does not reveal any words that would  either state that separate connections must be used for different GIOP versions  or that they can share a single connection. A definite statement is required  either way.    Assuming that different GIOP versions can indeed coexist on the same  connection, we get an interesting problem: for GIOP 1.0 and 1.1, the spec  disallows a client to send a CloseConnection message; for GIOP 1.2, it  requires the client to send a CloseConnection message. This begs the question:  if different GIOP versions can coexist on the same connection, it becomes  impossible to achieve orderly connection shutdown. Sending a CloseConnection  message is illegal for GIOP 1.0 and 1.1, whereas it is required for  GIOP 1.2... So, what's the client to do if multiple GIOP versions are used  over the same connection?

Resolution: To close with revision
Revised Text: In 15.5.1, after the existing third paragraph, add the following new paragraph: " If multiple GIOP versions are used on an underlying transport connection, the highest GIOP version used on the connection can be used for handling the close. A CloseConnection message sent using any GIOP version applies to all GIOP versions used on the connection (i.e., the underlying transport connection is closed for all GIOP versions). In particular, if GIOP version 1.2 or higher has been used on the connection, the client can send the CloseConnection message by using the highest GIOP version in use. "
Actions taken:
March 22, 2000: received issue
October 4, 2000: closed issue

Discussion:

If multiple versions are being used on the connection, since the close isn't  determined by anything that is version specific, the   highest known good version can be used for handling the close.  So, if 1.2 is  known to be valid on the connection, the client can  send the CloseConnection  message using GIOP version 1.2..

Issue 3512: Valuetype encoding grammar in 15.3.4.7 is wrong (interop)

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

The valuetype encoding "grammar" in 15.3.4.7 is wrong.  The rule for  <state> should be:    <state> ::= <octets> |<value_data>* [ <end_tag> ]    to allow for valuetypes with no state and therefore no value chunks.    -

Resolution: to close with revised text
Revised Text: In 15.3.4.7: change the rule for <state> to be: " <state> ::= <octets> | <value_data>* [ <end_tag> ] "
Actions taken:
March 29, 2000: received issue
October 4, 2000: closed issue

Issue 3526: Nesting depth in valuetype end tags (interop)

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

Section 15.3.4.5 contains an inconsistency in the description of how end tags  for valuetypes are written.  Consider the case where an unchunked value (V)  contains a chunked value (CV1).  Should the end tag for CV1 contain a nesting  depth of -2 or -1?    The following sentence in the spec seems to imply that the correct value is -2:    > The end tag is a negative long whose value is the negation of the absolute  > nesting depth of the value type ending at this point in the CDR stream.    However the spec also says:    > The outermost value type will always be terminated by an end tag with a  > value of -1.    which is not true if the end tag for CV1 is written as -2, since no end tag   with a -1 value will be written.    Proposed resolution:    Delete the second above sentence from the spec.

Resolution: Close with revision using alternative A above.
Revised Text: Apply alternative A above to 15.3.4.5.
Actions taken:
March 31, 2000: received issue
October 4, 2000: closed issue

Discussion:

  There are two interpretations of the text.  There are current implementations with both interpretations, which probably will not  interoperate at the moment.     This was put to vote to determine one of two possible alternative resolutions:     Alternative a)   In section 15.3.4.5, add the following sentence to the end of the bullet paragraph that starts "The end tag is a negative long whose  value is the negation...":    "   Enclosing non-chunked valuetypes are not considered when determining  the nesting depth.   "   Alternative b)   Remove the statement   "   The outermost value type will always be terminated by an end tag with a value of -1.   "   and replace with the following sentence   "   Enclosing non-chunked valuetypes are considered when determining the nesting depth.   "

Issue 3561: Wrong minor code specified in Chapter 13 (interop)

Click here for this issue's archive.
Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

In document ptc/00-03-02 on page 13-30 in the last bullet on that page it says: "If a system  exception is raised , it shall be BAD_PARAM with an OMG standard minor code of 1".    This cannot be right because the OMG standard minor code of 1 for BAD_PARAM is assigned to "failure  to register, unregister or lookup value factory."    I recommend that we change this minor code to a new one that is properly allocated with the  associated text that reads something like: "Service context not understood". I am still wondering  though why BAD_PARAM is the correct exception to raise. Wouldn't BAD_CONTEXT be more appropriate?    In any case we have to change the minor code, even if we cannot make up our minds about which  exception.

Resolution: resolved and closed
Revised Text: n 13.6.8 Object Service context, bullet before Table 13-2, change: " The service context is not in the OMG-defined range: The receiving ORB may choose to ignore it, process it if it �understands� it, or raise a system exception, however it must be passed on through a bridge. If a system exception is raised, it shall be BAD_PARAM with an OMG standard minor code of 1 " to : " The service context is not in the OMG-defined range: The receiving ORB may choose to ignore it, or process it if it �understands� it, however the service context must be passed on through a bridge and must be made available to interceptors. "
Actions taken:
April 14, 2000: received issue
October 4, 2000: closed issue

Discussion:

Proposed Resolution:   Since no one could have properly implemented the correct minor code for this exception,   elimination of the ability to throw exception is a better resolution.

Issue 3565: ORB throwing exception if it finds unknown service context (interop)

Click here for this issue's archive.
Source: UBS (Urs Kuenzler, urs.kuenzler(at)ubs.com)
Nature: Uncategorized Issue
Severity:
Summary:

Why does it make sense at all to allow an ORB to throw an exception if it finds   a service context it does not "understand"? This is not very helpful for   interoperability. Would a sending ORB have to handle this exception and resend   the same request without context to allow to interoperate with an ORB throwing   BAD_PARAM in this case? If an unknown service context is sent with a reply, the   receiving ORB would throw BAD_PARAM at the caller (even if it got a valid   reply). The originator of the service context wouldn't even know.

Resolution: To close with Issue 3561 resolution to eliminate option of throwing exception
Revised Text: Resolved by revision proposed in Issue 3561.
Actions taken:
April 14, 2000: received issue
October 4, 2000: closed issue

Discussion:

  Allowing an ORB to throw an exception for unknown service contexts causes difficulties when interceptors are used.

Issue 3576: Absence of Wide Character Code Set (interop)

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

CORBA is inconsistent on how to deal with the lack wide character code set information in an IOR and the codes set service context. When a server receives a service context without a wide character code set specified, then it is supposed to raise BAD_PARAM when it receives wide characters data from the client. However a client is supposed to raise INV_OBJREF if the IOR is missing from the server's native wchar code set . In CORBA 2.3, section13.7.2.6, "Code Set Negotiation", it says, "... 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." This requires a client to know whether a server supports interfaces that use wide character data at the time the client receives an IOR. To determine this when the first IOR is received is a burdensome task. The client orb would be forced to apply an exhaustive examination, such scanning all of the server's IDL bindings or the contents of the IFR looking for wchar types. Additionally the client may need to determine if some Any might flow containing wchar data. I propose that the client's behavior be changed to match the server's. If any wide character data is encountered and the server's IOR was missing the native wchar code set, (which would cause the wide character transmission code set to not be negotiated), the client should raise BAD_PARAM. This will allow common marshal and demarshal code to be independent of whether it is running as a client or server. It also allows users to not configure wide character code sets if they know they aren't using them.

Resolution: The check should be able to be done at invoke time by the client orb
Revised Text: The check should be able to be done at invoke time by the client orb. This should be clarified in the text describing INV_OBJREF. Revised Text: Add clarification to description of INV_OBJREF, in 4.11.3.6: " If the client invokes an operation which results in an attempt by the client orb to marshall wchar or wstring data for an in parameter (or to unmarshal wchar or wstring data for an in/out parameter, out parameter or the return value), and the associated object reference does not contain a codeset component, the INV_OBJREF standard system exception is raised. " Add the following paragraph to 13.9.2.4: " If a client application invokes an operation which results in an attempt by the client orb to marshall wchar or wstring data for an in parameter (or to unmarshal wchar or wstring data for an in/out parameter, out parameter or the return value), and the associated Object Reference does not include a codeset component, then the client ORB shall raise the INV_OBJREF standard system exception (with standard minor code k) as a response to the operation invocation. " Add the following minor codes to table 4-3 for INV_OBJREF Standard System exception: " INV_OBJREF k Codeset component required for type using wchar or wstring data "
Actions taken:
April 21, 2000: received issue
April 28, 2000: moved from core to Interop
February 27, 2001: closed issue

Discussion:

  A Client ORB could check the interface definition upon receipt of an IOR, to determine if the interface type  referenced in the IOR has any Wide character or WideString parameters in any of its operations.  However, it seems  inappropriate for the Client ORB to be required check the use of wchar or wstring in all interfaces of a server system when an  IOR is received.

Issue 3622: selected_profile_index origin (interop)

Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature: Uncategorized Issue
Severity:
Summary:

Since the index numbering of sequences is a language mapping specific issue, the origin of the selected_profile_index within the IORAddressingInfo must be specified. I assume a zero origin is meant.    Proposed Resolution:  Add the following sentence to the description of IORAddressingInfo (in section 15.4.2.1 of the 25 March CORBA 2.4 preliminary draft): "The first profile has an index of zero."

Resolution: Accept proposed solution.
Revised Text: Add the following sentence to the description of IORAddressingInfo (in section 15.4.2.1 of the 25 March CORBA 2.4 preliminary draft): " The first profile has an index of zero. "
Actions taken:
May 18, 2000: received issue
February 27, 2001: closed issue

Issue 3623: Issue 1 -- resulting from Japanese comment JPN-009E: (interop)

Click here for this issue's archive.
Source: Object Management Group (Mr. Henry Lowe, )
Nature: Uncategorized Issue
Severity:
Summary:

The Japanese would like to clarify the first sentence of the first  paragraph of section 15.5.2, page 15-46, of CORBA 2.3.1 (this  is clause 6.4.2 of DIS 19500-2, page 70) by adding the phrase  "if Bi-Directional GIOP is not used" to the end of the sentence.  The resulting sentence would read "Only the client (connection  originator) may send Request, LocateRequest, and CancelRequest  messages if Bi-Directional GIOP is not used."    Is there any reason not to add this phrase now that Bi-Directional  is in the OMG specification?

Resolution: Agree that this was an editorial oversight in corba 2.3.
Revised Text: Change the first paragraph of 15.5.2 from: " Only the client (connection originator) may send Request, LocateRequest, and CancelRequest messages. Connections are not fully symmetrical. " to " Only the client (connection originator) may send Request, LocateRequest, and CancelRequest messages, if Bi-Directional GIOP is not in use. "
Actions taken:
May 19, 2000: received issue
February 27, 2001: closed issue

Issue 3624: Issue 2 -- resulting from UK comment UK-5: (interop)

Click here for this issue's archive.
Source: Object Management Group (Mr. Henry Lowe, )
Nature: Uncategorized Issue
Severity:
Summary:

The UK believes the footnote to section 13.6.2, page 13-16, of CORBA  2.3.1 (this is clause 5.6.2 with the footnote appearing on page 13 of  DIS 19500-2) does not make sense, especially the phrase "... except  ones that make such profiles...".  The meaning of this footnote needs  to be clarified with revised text.

Resolution: Close without revision.
Revised Text:
Actions taken:
May 19, 2000: received issue
February 27, 2001: closed issue

Discussion:

Close without revision.  This footnote was changed in last RTF.  The cited error is not included in the replacement  footnote.

Issue 3680: Version and byte order changes when fragmenting messages (interop) (interop)

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

It's occoured to me that according to the spec it's allowable for  a message to be fragmented and have second and subsequent  fragments change the version fields.    Having the version change while in the middle of reading a  wstring could cause problems, the CDR encoding of version 1.1  strings is always two bytes longer than the corresponding 1.2  encoding, if the version changed while in the middle of reading  the wstring the length field would be out by two.    Secondly if request IDs are per-protocol rather than  per-connection (as aired in issue 3438) then the request ids of  the fragments could interfere.    I think an extra phrase should be added to the spec with regards  to fragmentation, similar to the one regarding byte order:    The version of fragments must match the version of the initial message that  the fragment extends.

Resolution: Close without revision since the spec was already clarified to state this.
Revised Text:
Actions taken:
June 16, 2000: received issue
February 27, 2001: closed issue

Issue 3681: interop issue: CodeSets service context in GIOP 1.0 request (interop)

Click here for this issue's archive.
Source: Xerox (Mr. William C. Janssen, Jr., janssen(at)parc.xerox.com)
Nature: Uncategorized Issue
Severity:
Summary:

Well, a new Java release is upon us, and with it comes a new CORBA  implementation.  I'm trying Java 2 SE 1.3 CORBA clients against an ILU  2.0beta1 CosNaming server, and we find that the Java ORB cannot  reliably connect to the server.  Why not?  First, we must analyze the  IOR provided by the ILU service:    IOR:000000000000002849444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578743A312E300000000002000000000000002F0001000000000016776174736F6E2E706172632E7865726F782E636F6D00270F0000000B4E616D6553657276696365000000000100000024000100000000000100000001000000140001001800010001000000000001010000000000    If we look at this (those who've received it un-truncated) we find that it advertises the following:    _IIOP_ParseCDR:  byte order BigEndian, repository id <IDL:omg.org/CosNaming/NamingContext:1.0>, 2 profiles  _IIOP_ParseCDR:  profile 1 is 47 bytes, tag 0 (INTERNET), BigEndian byte order  _IIOP_ParseCDR:  profile 2 is 36 bytes, tag 1 (MULTIPLE COMPONENT), BigEndian byte order  (iiop.c:parse_IIOP_Profile):  bo=BigEndian, version=1.0, hostname=watson.parc.xerox.com, port=9999, object_key=<NameService>  (iiop.c:parse_IIOP_Profile):  encoded object key is <NameService>  (iiop.c:parse_IIOP_Profile):  non-native cinfo is <iiop_1_0_1_NameService@tcp_watson.parc.xerox.com_9999>  (iiop.c:parse_MultiComponent_Profile):  profile contains 1 component  (iiop.c:parse_MultiComponent_Profile):  component 1 of type 1, 20 bytes  (iiop.c:parse_MultiComponent_Profile):  native codeset for SHORT CHARACTER is 00010001, with 0 converters  (iiop.c:parse_MultiComponent_Profile):  native codeset for CHARACTER is 00010100, with 0 converters    That is, there's a vanilla Internet profile (bo=BigEndian,  version=1.0, hostname=watson.parc.xerox.com, port=9999,  object_key=<NameService>), plus a Multicomponent profile, noting that  the ILU ORB's native codesets are Latin-1 and UCS-2.    OK, great.  Now we get the first message from the Java ORB:    0000   47 49 4f 50 01 00 00 00 00 00 01 00                GIOP........  0000   00 00 00 02 00 00 00 01 00 00 00 0c 00 00 00 00   ................  0010   00 01 00 20 00 01 01 00 00 00 00 06 00 00 00 90   ... ............  0020   00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e   .......(IDL:omg.  0030   6f 72 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65   org/SendingConte  0040   78 74 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00   xt/CodeBase:1.0.  0050   00 00 00 01 00 00 00 00 00 00 00 54 00 01 01 00   ...........T....  0060   00 00 00 0c 31 33 2e 31 2e 31 30 33 2e 36 38 00   ....13.1.103.68.  0070   0e e9 00 00 00 00 00 18 af ab ca fe 00 00 00 02   ................  0080   67 d5 93 95 00 00 00 08 00 00 00 00 00 00 00 00   g...............  0090   00 00 00 01 00 00 00 01 00 00 00 14 00 00 00 00   ................  00a0   00 01 00 20 00 00 00 00 00 01 01 00 00 00 00 00   ... ............  00b0   00 00 00 05 01 00 00 00 00 00 00 07 53 79 6e 65   ............Syne  00c0   72 67 79 00 00 00 00 06 5f 69 73 5f 61 00 00 00   rgy....._is_a...  00d0   00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e   .......(IDL:omg.  00e0   6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61   org/CosNaming/Na  00f0   6d 69 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00   mingContext:1.0.    Note that we are seeing a CodeSets service context, even though the  request is GIOP 1.0.  The service context specifies a TCS-C of ASCII,  and a TCS-W of UCS-2.    The question is, what should the server do with it?    First of all, there seems to be no way in which the algorithm in  section 13.2.7.6 can result in the TCS-C specified in the service  context.  So perhaps this bug should be detected and signalled back to  the sending ORB.  How?  Using CODESET_INCOMPATIBLE might make sense,  but that really doesn't flag the bug in the client-side implementation  of the codesets determination algorithm.  Perhaps a straight  COMM_FAILURE would be better.  Opinions?    Secondly, since this is GIOP 1.0, the client could reasonably ignore  the service context, and go ahead with using its default codeset  (Latin-1).  However, to do so risks comm failure down the line, as  ASCII (the TCS-C assumed by the client) does not permit many Latin-1  characters.  It seems better to flag this situation up front.

Resolution: close with revision. See below
Revised Text: Resolution: Close with revision Section 13.7.2 makes it very clear that the server should not raise an exception if a codeset service context is contained in a GIOP 1.0 request message. No clarification is needed in that section. If a client or a server sends character data which is not encoded as LATIN-1, the receiver will not be able to detect it is not being LATIN-1 by examining the received sequence octets. Thus nothing can be stated for this case. A client orb should never use a GIOP 1.0 connection to send wchar or wstring data. This situation is covered by the resolution to Issue 3576, since if the objref has a version 1 IOR profile, it does not carry Codeset Information. However, if an operation with Wchar parameter data is erroneosly sent over GIOP 1.0 by a client, the server must generate a "MARSHAL" exception. We need minor code for this case. If a server sends Wchar or wstring data using GIOP 1.0 the client orb should raise a MARSHAL exception to the client application. This should have its own minor code. Revised Text: At the end of section 15.3.1.6 add the following: " If a client orb erroneously sends wchar or wstring data in a GIOP 1.0 message, the server shall generate a MARSHAL standard system exception, with standard minor code i. If a server erroneously sends wchar data in a GIOP 1.0 response, the client orb shall raise a MARSHAL exception to the client application with standard minor code j. " Add the following minor codes to table 4-3 for MARSHAL Standard System exception: " MARSHAL i wchar or wstring data erroneosly sent by client over GIOP 1.0 connection MARSHAL j wchar or wstring data erroneously returned by over GIOP 1.0 connection "
Actions taken:
July 5, 2000: received issue
February 27, 2001: closed issue

Discussion:

The IOR does not have the codeset component in the INTEROP IOR Profile. A client may choose to ignore the MULTIPLE COMPONENTS profile safely. The Interop chapters require profiles to be complete, the MULTIPLE COMPONENTS profile is not complete, since it has no addressing information or object key. The server should not process codeset service context in GIOP 1.0, if present. If client sends other than LATIN-1 in GIOP 1.0, errors may arise. They should be dealt with in the response to each request message, rather than in the processing of the service context in the first message.. We need to clarify what is valid within the GIOP protocol for the server to do in this situation. The client should not be including a codeset service context in a GIOP 1.0 message, and certainly cannot transmit any wide characters or strings over a GIOP 1.0 connection. The codeset service context might be considered harmless if its TCS-C matched the fixed codeset used in GIOP 1.0 for chars and strings. The client is wrong to send the service context in this case of GIOP 1.0, (irrespective of its contents). 13.7.2 of Core states: " The following are the rules for processing a received service context: � The service context is in the OMG defined range: � If it is valid for the supported GIOP version, then it must be processed correctly according to the rules associated with it for that GIOP version level. � If it is not valid for the GIOP version, then it may be ignored by the receiving ORB, however it must be passed on through a bridge and must be made available to interceptors. No exception shall be raised. " Based on the above quote, the server is also wrong to look at it. If the client "pumps" ascii over the connection, the server will have no problems, since ascii is a subset of Latin-1. However, the server might "pump back" string return results or out parameters using the fully extended 8 bit space of Latin-1, and the client has to deal with it. We also need to use the propose/dispose mechanism that has been setup between Sun and the OMG provide for feeding back bug reports to Sun and having them run it through a Java standards process moral equivalent of OMG's "Urgent bugfix process"? That also needs to happen to fix this particular problem..

Issue 3708: Small optimization for the GIOP header (interop)

Click here for this issue's archive.
Source: University of California, Irvine (Mr. Carlos O'Ryan, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

    I think I found a possible (very minor) optimization for the  GIOP 1.3 spec, but maybe I'm missing something in GIOP 1.2         The new <target> field on the RequestHeader_1_2 structure is  always aligned to a 4 byte boundary, the reserved[3] field ensures  that.  Consequently the discriminant for the TargetAddress union  does not end on a 4 byte boundary, but will require 2 bytes of padding  following it, since all the union values in this case start on 4 byte  boundaries.    	IMHO, using just 1 byte for the reserved[] field, would have  resulted in more natural alignments.  Did I get something wrong here?  Is this something likely to be fixed in GIOP 1.3?

Resolution: Close this issue as too much of a change for this RTF, and add it to the GIOP wish list for future p
Revised Text:
Actions taken:
June 16, 2000: received issue
February 27, 2001: closed issue

Discussion:

The GIOP 1.1 header had a sequence of octet (object key) following the response expected boolean, thus there was automatically  three octets of pad included for marshalling.  The spec made these three octets explicit, reserving them for future use.     In GIOP 1.2, the object key was replaced by the TargetAddress union.  The union discriminant is a short, so in fact, the reserved  could have been reduced to 1 byte, leaving the last two bytes open for the union discriminant.     Thus the optimization stated is correct, however does not warrant, in it own right, migration to a new protocol version 1.3.

Issue 3787: GIOP _get_domain_managers ambiguous (interop)

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

In GIOP, the _get_domain_managers operation name is used to indicate  an invocation of the get_domain_managers pseudo operation. OTOH, it is  also used if an attribute domain_managers is accessed, as it would  appear in    interface I{    readonly attribute long domain_managers;  };

Resolution: Changing the object reference operation on the wire to _domain_managers fixes the problem stated.
Revised Text: In the specification of the operation field, in 15.4.2.1, change the paragraph: " In the case of CORBA::Object operations that are defined in the CORBA Core (Section 4.3, �Object Reference Operations,� on page 4-11) and that correspond to GIOP request messages, the operation names are _interface, _is_a, _non_existent, and _get_domain_managers. " to: " In the case of CORBA::Object operations that are defined in the CORBA Core (Section 4.3, �Object Reference Operations,� on page 4-11) and that correspond to GIOP request messages, the operation names are _interface, _is_a, _non_existent, and _domain_managers. Note: The name "_get_domain_managers" is not used, to avoid conflict with a get operation invoked on a user defined attribute with name "domain_managers". "
Actions taken:
August 18, 2000: received issue
February 27, 2001: closed issue

Issue 3792: Is padding necessary for empty Reply body? (interop)

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

The Interop RTF added text that explicitly states that padding for a  Request body in GIOP 1.2 is not necessary if the body is empty.  No  equivalent text was added for empty GIOP 1.2 Reply bodies.

Resolution: Agree to add equivalent text for reply bodies.
Revised Text: Add the following paragraph to the end of 15.4.3.1: " There is no padding after the reply header when an unfragmented reply message body is empty. "
Actions taken:
August 25, 2000: received issue
February 27, 2001: closed issue

Issue 4007: wchar alignment in GIOP 1.2 (interop)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Vishy Kasar, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

I have a question on the octet alignment requirement for wchar as  mentioned in Table 15-1 of CORBA 2.3. In 15.3.1.6 the spec states that    "For GIOP version 1.2,  wchar is encoded as an unsigned binary octet  value followed by the octet sequence representing the encoded value of  the wchar. The initial octet contains a count of the number of elements  in the sequence and the elements of the sequence of octets represent the  wchar, using the negotiated wide character encoding"    If this is a variable length octet sequence anyway, specifying an octet  alignment for this does not make sense. Our assumption is that alignment  is specified only for GIOP 1.1 style wchars and is irrelevant for  GIOP 1.2 style wchars. I am looking for confirmation of that assumption.    If that is a valid assumption, shall we change the table 15.1 third row  first column entry to state "wchar (in GIOP 1.1)" instead of "wchar"?    If that is not a valid assumption, what are we aligning here? The length  byte? The elements of octet sequence? What is the benefit of any  aligning in this case?

Resolution: Close with revision
Revised Text: In table 15.1 third row first colum entry: change: " wchar 1, 2 or 4 depending on codeset " to "wchar 1, 2 or 4 for GIOP 1.1 | 1 for GIOP 1.2 "
Actions taken:
October 31, 2000: received issue
February 27, 2001: closed issue

Discussion:

Close with revision   Agree with change to table 15.1.   The use of a single octet for the length was   originally proposed to facillitate octet alignment of wchar encoding.

Issue 4113: Null termination of strings (interop)

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

Section 15.3.2.7 of the CORBA 2.3 spec, which describes the CDR encoding  of strings, includes the following sentence in the first paragraph:      "Both the string length and contents include a terminating null."    It is not clear from this whether exactly one terminating null is required,  or whether more than one null can be included, with the string being terminated  by the first null.    Since IDL strings cannot include nulls (see 3.10.3.2: "OMG IDL defines the string  type string consisting of all possible 8-bit quantities except null"), any  additional nulls following the first terminating null cannot be part of the  string, and it therefore seems reasonable to ignore them.    Proposed Resolution:    Change the above sentence in section 15.3.2.7 to:      "Both the string length and contents include at least one terminating null."    Also make the same change to the corresponding sentence in the third paragraph  of section 15.3.2.7 describing GIOP 1.1 wide strings.

Resolution: To close with clarification revision
Revised Text: Change the first para of 15.3.2.7 from: 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. Both the string length and contents include a terminating null. to read: 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. Change the third para of 15.3.2.7 from: 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. Both the string length and contents include a terminating null. The terminating null character for a wstring is also a wide character. to read: 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. Change the fourth para of 15.3.2.7 from: For GIOP version 1.2, 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 a wstring is not terminated by a NUL character. In particular, in GIOP version 1.2 a length of 0 is legal for wstring. to read: For GIOP version 1.2, 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 a wstring is not terminated by a null character. In particular, in GIOP version 1.2 a length of 0 is legal for wstring.
Actions taken:
December 8, 2000: received issue
October 3, 2001: closed issue

Discussion:

In the words of an RTF member, extracted from the mail archive on this issue:   I don't think any such change is needed. The string length tells me how   many bytes are in the string, including the terminating NUL. I would expect   that length to give me *exactly* that count. What follows the terminating   NUL is either padding, or the next value in the byte stream.   I see no point in allowing a string to have several terminating NUL characters.   What would this improve?        However, several RTF vote 1 comments indicated that clarficication would help.

Issue 4198: Fixed point marshalling (interop)

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

I have a query about the intended marshalling format for Fixed. Is the  sending ORB always required to transmit the number of digits specified  in the IDL, or is it permitted to transmit fewer if there are leading  zeros?    Consider transmitting 123.45 as fixed<6,2>. Is the ORB permitted to  transmit      12 34 5c    or must it send the leading zero (plus another zero to pad the first  octet):      00 12 34 5c    In both cases, the receiving ORB knows it is expecting a scale of 2,  and the sign half-octet tells it where the digits end, so it can  correctly unmarshal the value as 123.45.    The discussion of issue 3431 suggests that the first option is not  permitted, and leading zeros must always be sent. However, the 2.4  GIOP spec makes no mention of how many digits should be sent. The  specification should be clarified to either explicitly permit or  explicitly forbid stripping of leading zeros.

Resolution: Close with clarification revision
Revised Text: Add the following clarification paragraph to the end of 15.3.2.8 Fixed-Point Decimal Type: " The number of digits present must equal the number of significant digits specified in the IDL definition for the fixed type being marshalled, with the exception of the inclusion of a leading 0x0 half octet when there are an even number of significant digits. "
Actions taken:
February 7, 2001: received issue
October 3, 2001: closed issue

Issue 4213: GIOP 1.2 AddressingDisposition processing on the client side (interop)

Click here for this issue's archive.
Source: Oracle (Mr. Ram Jeyaraman, nobody)
Nature: Clarification
Severity:
Summary:

  If the server ORB sends back a NEEDS_ADDRESSING_MODE  reply to the client indicating the prefered  addressing disposition, then is the client ORB required to 'cache' the prefered addressing  disposition per object reference, and use it for further requests to the server ?

Resolution: to close without revision
Revised Text:
Actions taken:
February 28, 2001: received issue
October 3, 2001: closed issue

Discussion:

This behaviour is not required by the specification, but is not disallowed

Issue 4242: Table 15-2 is missing entry for tk_local_interface (interop)

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

Add the missing entry with the same information as tk_objref.

Resolution: add the missing table entry with the same information as tk_objref
Revised Text: insert the following table row just before the final row of table 15-2" tk_local_interface <next free integer after 32> complex string (repository ID), string(name)
Actions taken:
March 27, 2001: received issue
October 3, 2001: closed issue

Discussion:

Issue 4273: GIOP is silent about extra data in the Request or Reply body (interop)

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

The specification does not say whether extra data after the invocation  parameters in a Request or Reply body is ignored or considered an  error.  For interoperability purposes, the spec should require one or  the other.

Resolution: see below
Revised Text: In the para under the bullet point �message_size� on page 15-33, change the following: This count includes any alignment gaps. To r ead: The count includes any alignment gaps and must match the size of the actual request parameters (plus any final padding bytes that may follow the parameters to have a fragment message terminate on an 8-byte bound-ary). A MARSHAL exception with minor code 7 indicates that fewer bytes were present in a message than indicated by the count. (This condition can arise if the sender sends a message in fragments, and the receiver detects that the final fragment was received but contained insufficient data for all parameters to be unmarshaled.) A MARSHAL exception with minor code 8 indicates that more bytes were present in a message than indicated by the count. Depending on the ORB implementation, this condition may be reported for the current mes-sage or the next message that is processed (when the receiver detects that the previous message is not immediately followed by the GIOP magic number). Add the following entries to the exception minor code table in section 4.11.4, page 4-63: MARSHAL 7 Header byte count for GIOP message greater than available data. MARSHAL 8 Header byte count for GIOP message less than available data.
Actions taken:
April 18, 2001: received issue
May 13, 2002: closed issue

Issue 4280: In RMI rep Id, when is inclusion of SUID legal? (interop)

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

In formal 00-11-03 10.6.2 in the discussion of the serial version UID in  the RMI hashed format, the spec defines the repository ID format as    RMI: <class name> : <hash code> [ : <serialization version UID> ]    and says    "If the actual serialization version UID for the Java class differs from  the hash code, a colon and the actual serialization version UID  (transcribed as a 16 digit upper-case hex string) shall be appended to  the RepositoryId after the hash code."    The Java to IDL spec ptc-00-01-06 1.3.5.7 says    "The syntax of the repository ID is the standard OMG RMI Hashed format,  with an initial �RMI:� followed by the Java class name, followed by a  hash code string, followed optionally by a serialization version UID  string."    Questions:    1)  Is it legal to include the serial version UID in the repository ID  even when it is equal to the hash code?  (Alternatively:  Is it legal  for an ORB to throw an exception/fail if the hash code and serial  version UID in the repository Id are the same?)    2)  If it is not legal to include the serial Version UID in the  repository ID when equal to the hash code, what should an ORB do?    Discussion:    Other than it not harming anything to include the SUID, there are rare  cases that the same Java class compiled with different compilers can  result in different default serial version UIDs, so it would be wise to  explicitly specify the serialVersionUID field even in the first version  of a class.  If it is legal to always include the serial version UID  part of the repository ID, ORBs with classes from two different  compilers would still be able to interoperate.

Resolution: see below
Revised Text: Page 10-44, change the following text: If the actual serialization version UID for the Java class differs from the hash code, a colon and the actual serialization version UID (transcribed as a 16 digit upper-case hex string) shall be appended to the RepositoryId after the hash code. To r ead: For Serializable (including Externalizable) classes, the Java serialization version UID, transcribed as a 16 digit upper-case hex string, shall be appended to the RepositoryId following the hash code and a colon. The Java serialization version UID is defined in the Java Object Serialization Specification.
Actions taken:
April 23, 2001: received issue
May 13, 2002: closed issue

Issue 4283: RMI repository ID references to serial version UID (interop)

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

CORBA formal 00-11-03 10.6.2 states    "If the actual serialization version UID for the Java class differs from  the hash code, a colon and the actual serialization version UID  (transcribed as a 16 digit upper-case hex string) shall be appended to  the RepositoryId after the hash code."    Please comment on the following assertions.  The CORBA spec is vague  here, and it has resulted in incompatible interpretations which must be  resolved quickly.    1)  The "actual serialization version UID" mentioned is as defined in  the Java Object Serialization specification.    http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100    Based on this Java specification and its note that "If the SUID is not  declared for a class, the value defaults to the hash for that class":    2)  If a serialVersionUID field is defined in the class with the proper  modifiers, its value is used as the "actual serialization version UID"  mentioned in the CORBA spec    3)  If a serialVersionUID field with the proper modifiers is not  explicitly defined in a class, its value is computed as explained in the  Java Object Serialization spec, and this computed value is used as the  "actual serialization version UID" mentioned in the CORBA spec    4)  It is required by the CORBA spec to always include the Java  serialVersionUID (as computed in assertions 2 and 3 above) in the RMI  repository ID if the value is different than the OMG hash code (for  which the algorithm is defined in CORBA formal 00-11-03 10.6.2)    5)  It is not acceptable to leave off the SUID portion of the RMI  repository ID if the serialVersionUID field is merely absent from the  Java class

Resolution: closed, withdrawn by submitter
Revised Text:
Actions taken:
April 25, 2001: received issue
May 18, 2001: closed issue

Issue 4289: GIOP issue : fragmented replies with exceptions (interop)

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

Let us assume that the server has sent a few reply fragments. But before sending all the reply  fragments, an exception occurs (say while marshalling the response).  What does the server and the client (which has already seen reply fragments) do ?    Just to note, notice that if the same problem happens while the client is in the midst of sending  request fragments, the client can choose to send a CancelRequest message to intimate the server.     Since there are various possible behaviours for the client and server, the GIOP specification needs  to clarify the standard behaviour, in order for different implementations to remain interoperable.    One possible behaviour :    The server could send back a seperate response (containing the exception with  CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that  another reply with the same requestId is pending, could discard the pending reply and process the  latest reply.    Another behaviour :    The client could simply timeout the request and discard any new reply streams (with the same  requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE.

Resolution: This issue is resolved by the resolution to issue 4273.
Revised Text:
Actions taken:
April 30, 2001: received issue
May 13, 2002: closed issue

Issue 4294: tk_indirect (interop)

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

I don't understand why tk_indirect isn't allowed as a top-level typecode. 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 tk_indirect 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 tk_indirect cannot refer to any TypeCode outside the scope of its enclosing top-level TypeCode. However, I don't think this restriction needs to apply to a top-level TypeCode. We have made this change experimentally without any adverse effects and we have discovered that using tk_indirect for all the top-level foo TypeCodes after the first one can speed up some common scenarios by at least a factor of 5 on end-to-end measurements. There seems to be no downside to making this change. I would therefore like to propose the following change to the section headed "Indirection: Recursive and Repeated TypeCodes" within section 15.3.5.1: Change the first bullet from: 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 words: 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. If this change finds favour, then we need to work out how it can be brought into GIOP without causing problems interoperating with older ORBs that insist on the stronger restriction of the current spec. This could perhaps be added to the "wish list" for GIOP 1.3.

Resolution: Close this issue and add it to the GIOP wish list
Revised Text:
Actions taken:
May 4, 2001: received issue
October 3, 2001: closed issue

Discussion:

The proposed change would also require encapsulations to have a CDR version (already   idiscussed on the GIOP wish list). This is too big a change for RTF.   Close this issue and add it to the GIOP wish list.

Issue 4299: GIOP 1.1 Fragment problem (interop)

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

There is nothing in the specification that explicitly states whether the  data in the body of a GIOP 1.1 Fragment message is marshalled relative  to the Fragment header or relative to the unfragmented message as a  whole.    The restriction in GIOP 1.2 that all fragments but the last must have a  multiple of 8 bytes, and the careful padding of the GIOP 1.2 Fragment  header to 16 bytes both strongly suggest that GIOP 1.1 fragments should  be marshalled only relative to the fragment header.    Proposed Resolution:    In section 15.4.9, right after the paragraph that reads:    "A primitive data type of 8 bytes or smaller should never be broken  across two  fragments."    add the following paragraph:    In GIOP 1.1, the data in a fragment is marshalled with alignment  relative to its position in the fragment, not relative to its position  in the whole unfragmented message.

Resolution: Accept proposal above
Revised Text: In section 15.4.9, right after the paragraph that reads: "A primitive data type of 8 bytes or smaller should never be broken across two fragments." add the following paragraph: " In GIOP 1.1, the data in a fragment is marshalled with alignment relative to its position in the fragment, not relative to its position in the whole unfragmented message. "
Actions taken:
May 11, 2001: received issue
October 3, 2001: closed issue

Issue 4309: Incorrect text in 15.4.6.2 (interop)

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

15.4.6.2, "LocateReplyBody" says:    	In GIOP version 1.0 and 1.1, Locate reply bodies are marshaled into  	the CDR encapsulation of the containing Message immediately following  	the Reply Header. In GIOP version 1.2, the Reply Body is always  	aligned on an 8-octet boundary. The fact that GIOP specifies the  	maximum alignment for any primitive type is 8 guarantees that  	the ReplyBody will not require remarshaling if the Locate Reply  	Header are modified.    The final sentence doesn't make sense because the LocateReply header is  a fixed-length header and therefore can't possibly cause remarshalling.    I suggest to delete the final sentence of this para.

Resolution: see resolution of Urgent Issue 4314
Revised Text:
Actions taken:
May 16, 2001: received issue
October 3, 2001: closed issue

Issue 4311: Incorrect table in section 15.4 (interop)

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 table on page 15-31 (Table 15-3 "GIOP Message Types and Originators")  is in error. For CloseConnection, it shows that only the server can  send this message but, in GIOP 1.2, either client or server can send  the message, as detailed in 15.5.1 and 15.4.7.    Also. in 15.4.7, we have:    	In GIOP version 1.2 both sides of the connection may send  	the CloseConnection message.    That should be "must", not "may".

Resolution: see above
Revised Text: Change the existing entries in Table 15-3 below: Message Type Originator Value GIOP Versions Request Client 0 1.0, 1.1, 1.2 Reply Server 1 1.0, 1.1, 1.2 CancelRequest Client 2 1.0, 1.1, 1.2 LocateRequest Client 3 1.0, 1.1, 1.2 LocateReply Server 3 1.0, 1.1, 1.2 CloseConnection Server 5 1.0, 1.1, 1.2 to: Message Type Originator Value GIOP Versions Request Client 0 1.0, 1.1, 1.2 Request Both 0 1.2 with BiDir GIOP in use Reply Server 1 1.0, 1.1, 1.2 Reply Both 1 1.2 with BiDir GIOP in use CancelRequest Client 2 1.0, 1.1, 1.2 CancelRequest Both 2 1.2 with BiDir GIOP in use LocateRequest Client 3 1.0, 1.1, 1.2 LocateRequest Both 3 1.2 with BiDir GIOP in use LocateReply Server 4 1.0, 1.1, 1.2 LocateReply Both 4 1.2 with BiDir GIOP in use CloseConnection Server 5 1.0, 1.1 CloseConnection Both 5 1.2
Actions taken:
May 17, 2001: received issue
October 3, 2001: closed issue

Discussion:

Proposed Resolution: To Close with revision.  However the wording in 15.4.7 is correct, since the semantics of the closeConnection message state when it is required to send the message.   If bidirection GIOP is in use, a similar problem exists in the table for the Request, Reply, CancelRequest, LocateRequest, LocateReply.  This needs to be corrected in the table.

Issue 4314: Urgent issue: Alignment of LocateReply body (interop)

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

In CORBA 2.3, a GIOP 1.2 LocateReply message made no requirements as to the alignment of the LocateReply body. This meant that the LocateReply body needed to be aligned only on a 4-byte boundary. With the resolution for issue 2521, published with CORBA 2.4, the spec was changed to require alignment of the LocateReply body on an 8-byte boundary. The change is incompatible with the CORBA 2.3 definition because the receiver must know where to look for the ReplyBody in the the byte stream following the message header. (The LocateReply header is 12 bytes long, so changing the alignment rules means that the LocateReply body has to start at offset 12 for CORBA 2.3, but has to start at offset 16 for CORBA 2.4.) The change in alignment did *not* result in a version change of GIOP, despite the incompatibility, so it appears that the change is simply illegal. There are already deployed products that use the CORBA 2.3 alignment rule; therefore, we cannot deploy a CORBA 2.4 compliant product without breaking interoperability with already deployed CORBA 2.3 compliant products. So, I'd like to request that we back out the change and continue to permit a LocateReply body to be aligned on a 4-byte boundary. There was never any need to change the alignment of the LocateReply body anyway because a LocateReply header has fixed length and, therefore, cannot ever cause remarshaling of the body due to a size change in the header. In other words, the motivation quoted in the spec for the 8-byte alignment rule isn't founded on fact, and the change should never have been made in the first place. (See issue 4309 for details.)

Resolution:
Revised Text: Replace the final paragraph in section 15.4.6.2 on page 15-43 of CORBA 2.4.2, OMG document number formal/01-02-01: " In GIOP version 1.0 and 1.1, Locate reply bodies are marshaled into the CDR encapsulation of the containing Message immediately following the Reply Header. In GIOP version 1.2, the Reply Body is always aligned on an 8-octet boundary. The fact that GIOP specifies the maximum alignment for any primitive type is 8 guarantees that the ReplyBody will not require remarshaling if the Locate Reply Header are modified. " with: " Locate reply bodies are marshaled immediately following the Locate Reply Header. "
Actions taken:
May 17, 2001: received issue
October 3, 2001: closed issue

Discussion:

The culprit was the  adopted resolution from Issue 2521, from   ORB Interoperability 2000 RTF Report - Interop/00-1-1   The RTF caused an error by accepting the proposed resolution for   issue 2521. It is not possible to signal which alignment method is being used   without a new giop version.     Proposed Resolution:  Back out the revision from previous issue 2521, and add clarification

Issue 4328: Indirections with chunking & fragmentation (interop)

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

When chunking and fragmenting, it is possible for a chunk length to be  inserted between the indirection tag and indirection offset.   Implementations must be careful to compute the indirection offset  correctly both when writing and reading to avoid errors.    For interoperability, we should elminate this possibility.  From an  implementation point of view, the code for handling this special case  should already be there.  Please see the original message (see  attachment) for a detailed description of the problem scenario and two  implementation possibilities.    Proposed resolution:    Elminate the possibility of chunk lengths between indirection tag and  indirection offset by changing the following paragraph in CORBA formal  00-11-03 15.3.4.6.

Resolution: see below
Revised Text: Section 15.3.4.6, page 15-20, change the text that currently reads: The data may be split into multiple chunks at arbitrary points except within primitive CDR types, arrays of primitive types, strings, and wstrings. It is never necessary to end a chunk within one of these types as the length of these types is known before starting to marshal them so they can be added to the length of the currently open chunk. It is the responsi-bility of the CDR stream to hide the chunking from the marshaling code. to read: The data may be split into multiple chunks at arbitrary points except within primitive CDR types, arrays of primitive types, strings, wstrings, or between the tag and offset of indirections. It is never necessary to end a chunk within one of these types as the length of these types is known before starting to marshal them so they can be added to the length of the currently open chunk. It is the responsibility of the CDR stream to hide the chunking from the marshaling code.
Actions taken:
May 25, 2001: received issue
May 13, 2002: closed issue

Issue 4339: Incomplete grammar in section 15.3.4.8 (interop)

Click here for this issue's archive.
Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:

In orbrev/01-03-01:    Production rule two at the end of this sections has a comment that it  should include all IDL types, but in actuality is missing "long long",  unsigned long long" and "long double".    Suggest we add these to the production rule in question.

Resolution:
Revised Text: Add long long, unsigned long long, double, long double, and fixed to produc-tion rule 2 on page 15-23.
Actions taken:
June 5, 2001: received issue
May 13, 2002: closed issue

Issue 4342: Question about corbaname URL (interop)

Click here for this issue's archive.
Source: Raytheon (Mr. Craig Rodrigues, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

I have an interoperability question regarding the  corbaname URL in the CORBA 2.4.2 specification and would appreciate   clarification.    In 13.6.7.3, it states that for a corbaloc URL which  uses IIOP, if the port number of the endpoint is  not specified, then the IIOP profile should default  to port 2809 which is specified by IANA as the corbaloc  port.  eg.     corbaloc:iiop:myhost.com/SomeKey    In 13.6.7.5, the corbaname URL is described.  If a corbaname URL is specified for IIOP, but the port  number is omitted, should the ORB assume that the  root naming context will be on port 2809 of the host  specified?    eg.  corbaname:iiop:myhost.com:3000#path/obj    will look for the root naming context on port  3000 of myhost.com.    eg.  corbaname:iiop:myhost.com#path/obj    Should this look to port 2809 for the root  naming context?

Resolution: see above
Revised Text:
Actions taken:
June 8, 2001: received issue
May 13, 2002: closed issue

Discussion:

Rationale for Rejection  Section 2.5.3.6 of the Naming Service specification unambiguously answers  these questions, so no change is necessary.

Issue 4618: Changing VSCID prefix to 24 bits (interop)

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

In section 13.6.8 of CORBA 2.4.2 (formal/01/02-01), at the top of page  13-29, it says:      The high-order 20 bits of service-context ID contain a 20-bit vendor    service context codeset ID (VSCID); the low-order 12 bits contain the rest    of the service context ID. A vendor (or group of vendors) who wish to    define a specific set of system exception minor codes should obtain a    unique VSCID from the OMG, and then define a specific set of service    context IDs using the VSCID for the high-order bits.      The VSCID of zero is reserved for use for OMG-defined standard service    context IDs (i.e., service context IDs in the range 0-4095 are reserved as    OMG standard service contexts).    The VSCID-related text was added by the Interop 1.2 RTF as per RTF report  as in document number interop/98-01-04, and revised pages as in document  number interop/98-01-03. However, at about the same time OMG staff  established a convention that OMG should allocate vendors a 24-bit "service  tag", which is in fact the same as a VSCID. Since then, some 47 of these 24  bit service tags have been assigned to various vendors.    At the risk of having the tail wag the dog, I propose we resolve this  conflict by revising these paragraphs in the CORBA spec as follows:      The high-order 24 bits of a service context ID contain a 24-bit vendor    service context codeset ID (VSCID); the low-order 8 bits contain the rest    of the service context ID. A vendor (or group of vendors) who wishes to    define a specific set of system exception minor codes should obtain a    unique VSCID from the OMG, and then define a specific set of service    context IDs using the VSCID for the high-order bits.      The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) are reserved for    use for OMG-defined standard service context IDs (i.e., service context    IDs in the range 0-4095 are reserved as OMG standard service contexts).

Resolution: see below
Revised Text: Change the last two paragraphs of section 13.7 on page 13-30 to read: The high-order 24 bits of a service context ID contain a 24-bit vendor ser-vice context codeset ID (VSCID); the low-order 8 bits contain the rest of the service context ID. A vendor (or group of vendors) who wishes to define a specific set of service context IDs should obtain a unique VSCID from the OMG, and then define a specific set of service context IDs using the VSCID for the high-order bits. The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) are reserved for use for OMG-defined standard service context IDs (i.e., service con-text IDs in the range 0-4095 are reserved as OMG standard service con-texts).
Actions taken:
October 12, 2001: received issue
May 13, 2002: closed issue