CORBA24 — mixing giop versions

Summary: The spec is currently unclear on when and how messages with different
giop versions may share a single connection.

This has already been discussed, with different RTF members holding
positions running the range from: "all messages on a connection must
have the same giop version" to "messages with differing giop versions
must be permitted on the same connection". So clearly there is an issue.

The resolution of this issue should address at least the following
unclear points:

1) suppose a client orb supporting giop 1.2 initiates an invocation on
an IOR with iiop version 1.1. As a result, it establishes a new
connection and sends the request using giop 1.1. Later, the same client
obtains another IOR referencing the same transport address, but
specifying iiop version 1.0.

• may the same connection be used to send a request to the new IOR?
• if so, what giop version should be used to send the request?

2) Later, the same client obtains another IOR referencing the same
transport address, but specifying iiop version 1.2.

• may the same connection be used to send a request to the new IOR?
• if so, what giop version should be used to send the request
• if so, what giop version should be used to send subsequent requests
  to the IORs mentioned in (1).

3) Imagine a day in the not too distant future, when giop 1.3 has been
approved and implemented. A client that supports giop 1.3 obtains an IOR
with iiop version 1.2, establishes a new connection, and then sends a
request using giop 1.2. A service context offering bidirectional giop is
sent with this request, and accepted by the server. The client provides
the server (that supports giop 1.3) with a callback IOR that has iiop
version 1.3, and the server attempts to call back on it.

• may the callback use the incoming connection?
• if so, what giop version should the request use?
• if so using v1.2, what if the callback request requires a feature
  only available in giop 1.3?

closed in interop/2000-01-01