WATM — If acknowledgement is already done is the GIOPDataReply message superfluous

This issue is for Telecom Wireless FTF regarding the current adopted
specification dtc/2001-06-02.

According to current specification, when peer receives GIOPData Message
(7.2.15), it must reply with GIOPDataReply Message (7.2.16). GIOPDataReply
can acknowledge GIOPDataMessage, or indicate one of two failures,
DELIVERY_FAILED_INVALID_CONNECTION_ID or DELIVERY_FAILED_UNKNOWN_REASON.

The issue is, if acknowledgement is already done in GTP level (using the
last_seq_no_received field of GTPHeader) and errors can be expressed with
Error Message (7.2.19), is the GIOPDataReply message superfluous?

This is extremly important issue for us, for we are considering the use of
very narrow band (and expensive) transports.

For example, according the current specification (with the GIOPDataReply),
every non-oneway method invocation requires a minumum of 4 transport level
messages. Here's the message exhance for method invocation:

[ Client ] [ Object ]

client sends
GIOP Request
message:

------- #1 GIOPData -------->

<----- #2 GIOPDataReply -----
includes ack for #1

object sends
GIOP Reply
message.

<------- #3 GIOPData ---------

------ #4 GIOPDataReply ----->
includes ack for #2 and #3

if there's nothing
else to send

<------ #5 IdleSync ----------
ack for #4

However, without GIOPDataMessage the maximum is 3 messages and typical is 2
messages. Here's how:

[ Client ] [ Object ]

client sends
GIOP Request
message:

------- #1 GIOPData -------->

object sends
GIOP Reply
message.

<------- #2 GIOPData --------
includes ack for #2

if there's
nothing else
to send

------ #3 IdleSync ---------->
ack for #2

Conclusion: We suggest that the GIOPDataReply message is removed from
specification and the error code for the use of unknown connection ID
(DELIVERY_FAILED_INVALID_CONNECTION_ID) is introduced to Error message.

see above