Issues for Interoperability Revision Task Force mailing list

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
Issue 74: Type ids in OBJECT_FORWARD return message
Issue 77: LOCATION_FORWARD byte alignment
Issue 89: Correct IIOP marshalling of union TypeCodes
Issue 126: CORBA::Object::non_existent
Issue 382: Use of dynamic ports
Issue 383: Callbacks in IIOP
Issue 460: IORs and identifying Object Keys
Issue 465: Transport Level Bridge
Issue 488: Problem with GIOP CancelRequest when fragments are used
Issue 543: IIOP server-initiated connection closure problem
Issue 573: Type Extensions and code set negotiation
Issue 574: Type extensions char code set negotiation
Issue 585: IDL Type Extensions: wchar and wstring CDR encoding
Issue 586: IDL Type Extensions: wstring CDR encoding issue
Issue 589: Fragment improvements (1)
Issue 590: Fragment improvements (2)
Issue 591: 1.0 backward compat (1)
Issue 592: 1.0 backward compat (2)
Issue 593: CloseConnection messages
Issue 651: Issue with service context
Issue 782: Clarification on IIOP2.1 12.3.2 fixed point type representation needed
Issue 798: Additional Requirement for GIOP 1.2
Issue 807: Additional enumeration to the ReplyStatusType
Issue 817: IIOP marshalling of empty strings
Issue 885: Section 12.7.2 type IIOP::ProfileBody_1_0 not compatible
Issue 886: Changes to and strategy for 1.2
Issue 904: Alignment and offsets in the presence of fragmentation
Issue 905: marshalling service context
Issue 935: GIOP Exception formatting description (12.4.2)
Issue 960: Query about GIOP and IIOP version numbers in 98-01-03
Issue 1096: Issue about CDR encoding for wide characters
Issue 1111: Wchar and Char can both be multibyte
Issue 1129: How to handle unexpected exceptions?
Issue 1130: Compacting GIOP messages by using indirections
Issue 1131: Compacting GIOP Messages by using templates
Issue 1132: Compacting GIOP Requests by hashing down operation names
Issue 1133: Optimization of LOCATION_FORWARD replies
Issue 1136: Typecode equality
Issue 1138: Correct CDR encoding of an empty string
Issue 1292: CDR encoding of TypeCodes
Issue 1302: No provision for numbering the fragments in fragmented IIOP messages
Issue 1303: TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY
Issue 1486: LOCATE_FORWARD_PERM and hash()
Issue 1503: Typecode indirection issue
Issue 1525: Type code marshalling
Issue 1531: Typecode encoding is too long
Issue 1544: Marshalling of union type codes
Issue 1581: Type any marshalling rules force slow implementation
Issue 1588: Contents of MultiComponent component an encapsulation?
Issue 1653: CDR encoding for fixed
Issue 1669: Narrow Interop
Issue 1677: Chunked GIOP marshalling for variable-length types
Issue 1707: New IDL types
Issue 1857: IIOP 1.2 fragmentation presents an unrecoverable error situation
Issue 1948: Clarification requested on GIOP 1.1 and wstring
Issue 1962: Transmission of type codes across 2.2/2.3 boundaries
Issue 1968: CloseConnection
Issue 1975: Typo in page 15-44
Issue 1978: COMM_FAILURE and completion_status
Issue 1982: GIOP fragment alignment issue for CORBA 2.3
Issue 2031: .Passing the interface repository ID of the method in IIOP
Issue 2045: Obsolete text in ptc/98-08-13.pdf
Issue 2068: Tagged Component interactions
Issue 2077: A Messaging related issue in GIOP 1.2
Issue 2155: OBV chunk boundaries
Issue 2315: OBV GIOP clarification needed
Issue 2324: Move recently added text to correct place
Issue 2326: Clarification of OBV GIOP encoding rules
Issue 2333: GIOP encoding of nil Abstract Interface is unspecified
Issue 2338: Potential interop. problem in CORBA 2.3: pseudo-operation marshalling
Issue 2457: Unknown parts of an IOR and interoperability
Issue 2494: LocateRequest and LocateReply messages
Issue 2620: CODESET_INCOMPATIBLE exception
Issue 2801: fragmentation broken with bi-dir giop
Issue 2863: Issue: Problem with issue 2801 resolution
Issue 2904: profile ids & component ids setting of ORB level policies unclear
Issue 2914: Component ids in 13.6.2.2
Issue 2939: IANA ports for IIOP need to be documented in Ch 13 and 15
Issue 2940: Need clarification on GIOP::TargetAddress
Issue 2941: Is GIOP 1.x sustainable any more?
Issue 2952: Interop, 15.7.3 unclear wording
Issue 2961: Standard System Exception minor codes missing in Chapter 13
Issue 2968: Second bit of response_flags
Issue 3014: padding at the end of a non-fragmented 1.2 request message
Issue 3040: Minor code allocation inconsistency
Issue 3075: Length of wstring in GIOP 1.1
Issue 3096: CDR Encapsulation Issue
Issue 3102: marshalling of null values unclear
Issue 3128: Table 13-1 needs update for valuetypes & abstract interfaces Can MOF Package contain a Constant? (mof-rtf)
Issue 3176: Supporting TAG_MULTIPLE_COMPONENTS
Issue 3195: CORBA 2.3.1 missing text describing the response_expected field
Issue 3231: chunked value encoding:
Issue 3234: What should an ORB do when it does not find any profile in an IOR
Issue 3235: Should an ORB be allowed to drop non-standard profiles
Issue 3303: An ORB should not accept an IOR with no usable profiles
Issue 3307: Validity of object references
Issue 3315: Indirection for value types
Issue 3327: Preserving unencapsulated information
Issue 3405: Transferring Java exception reason string across the wire
Issue 3409: IIOP 1.2 Early Reply message in presence of fragmented Request
Issue 3431: Marshaling fixed-point decimal types
Issue 3434: Valuetype in anys. Unmarshaling problem?
Issue 3438: GIOP version and CloseConnection
Issue 3512: Valuetype encoding grammar in 15.3.4.7 is wrong
Issue 3526: Nesting depth in valuetype end tags
Issue 3561: Wrong minor code specified in Chapter 13
Issue 3565: ORB throwing exception if it finds unknown service context
Issue 3576: Absence of Wide Character Code Set
Issue 3622: selected_profile_index origin
Issue 3623: Issue 1 -- resulting from Japanese comment JPN-009E:
Issue 3624: Issue 2 -- resulting from UK comment UK-5:
Issue 3680: Version and byte order changes when fragmenting messages (interop)
Issue 3681: interop issue: CodeSets service context in GIOP 1.0 request
Issue 3708: Small optimization for the GIOP header
Issue 3787: GIOP _get_domain_managers ambiguous
Issue 3792: Is padding necessary for empty Reply body?
Issue 4007: wchar alignment in GIOP 1.2
Issue 4113: Null termination of strings
Issue 4198: Fixed point marshalling
Issue 4213: GIOP 1.2 AddressingDisposition processing on the client side
Issue 4242: Table 15-2 is missing entry for tk_local_interface
Issue 4273: GIOP is silent about extra data in the Request or Reply body
Issue 4280: In RMI rep Id, when is inclusion of SUID legal?
Issue 4283: RMI repository ID references to serial version UID
Issue 4289: GIOP issue : fragmented replies with exceptions
Issue 4294: tk_indirect
Issue 4299: GIOP 1.1 Fragment problem
Issue 4309: Incorrect text in 15.4.6.2
Issue 4311: Incorrect table in section 15.4
Issue 4314: Urgent issue: Alignment of LocateReply body
Issue 4328: Indirections with chunking & fragmentation "supports" terminology issue for CCM
Issue 4339: Incomplete grammar in section 15.3.4.8
Issue 4342: Question about corbaname URL
Issue 4618: Changing VSCID prefix to 24 bits

Issue 55: IIOP object pointer resetting (interop)

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

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?

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

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

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

 moved from orb_revision to interop

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

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.

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

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

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)

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

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

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."

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

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

 received issue

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?

 closed issue

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.

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

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

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

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

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

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

 closed issue

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.
 

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.
 

 closed with revision

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

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
 

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.
 

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.
 
 
 

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.
 
 

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

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?
 

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.
 

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.  
 

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?
 

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.
 

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.
 

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.
 

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.
 

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.
 

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)
 

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.
 

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.
 

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?
 

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

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".

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.
 
 

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.
 

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.
 

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.
 

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

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?
 
 

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.
 

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

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.
 

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.
 
 

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.
 

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.
 

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

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. 

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

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. 

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.

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

 received issue

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.
 
 

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.
 

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
 

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.
 

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.
 

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. 

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.
 
 

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.

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?
 

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. 

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

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.
 

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. 

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.
 

To Add proposed clarification text for nil abstract interface case. 

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 sam