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
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
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
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 same pseudo-operation as _not_existent.
 

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.
 

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.

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:
 
 

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

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?
 

 closed

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

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

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.

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?

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.

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?

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.

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

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?

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.

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.

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.

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.

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

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?

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?

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.

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

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.

Table 13-1 is missing a row:

Feature		Version 1.0	Version 1.1	Version 1.2
-----------------------------------------------------------
Valuetypes and					yes
Abstract
Interfaces

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?

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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. 

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.

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.

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.

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?

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.

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?

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

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.

-

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.

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

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.

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.

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.

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

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.

  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.

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

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?

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.

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

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.

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.

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

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?

		

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.

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

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.

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?

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.

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.

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. 

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.

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 ?

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

Add the missing entry with the same information as tk_objref.

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.

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.

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

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.

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.

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. 

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.

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.

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

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. 

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

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 

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.

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.

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?

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

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