Currently gtp_from_terminal has no raisable exceptions. But it might
happen that the Access Bridge has already forgotten the terminal. In
this case it should communicate this to the invoker by raising an
exception (UnknownTerminalId would be suitable). The invoker can then
send a GTPForwardReply with the status FORWARD_ERROR_UNKNOWN_SENDER.

see above

GTPForwardReply needs to be forwardable

Currently GTPForwardReply (section 7.2.18) is marked not forwardable.
But if there have been outstanding GTPForward messages when handoff
happens, these messages cannot then be acknowledged. This situation
is similar to the one with OpenConnection where OpenConnectionReply is
forwardable, the reason being that outstanding requests can be
responded to after handoff. For the same reason, GTPForwardReply
should also be forwardable.

Make GTPForwardReply forwardable

Chapter 3.1.1.
In paragraphs 2, 3, and wording "returning the object reference of the
Access Bridge" is not precise enough. Instead we should say "returning the
Mobile IOR indicating the Access Bridge".
3rd paragraph, line 4: replace "replies" by "should reply"
4th paragraph, line 3: replace "will reply" by "should reply"

Chapter 3.2.1 IDL of ProfileBody
add space between TerminalObjectKey and teminal_object_key

Page 3-4, 2nd paragraph, line 3: replace "MobileTermial" by "MobileTerminal"

Page 4-2, 1st line: remove "," after "new_access_bridge"

Pages 4-2 and 4-3: replace "UnknownTermialID" by "UnknownTerminalId" (four
times)

Chapter 7.2
Add at the bottom of page 7-2 paragraph: All timeout values are in seconds.

Page 7-5: replace "MobileTeriminal" by "MobileTerminal" (two times)

Page 7-5, last paragraph: The last two line should read as:
"then a handoff procedure or the access recovery procedure as described in
Section 8.2, "Network Initiated Handoff", in Section 8.3, "Terminal
Initiated Handoff", or in Section 8.4, "Access Recovery", is carried out.

Page 7-10, first line: replace
"MobileTerminal::AccessBridgeTransportAddress" by
MobileTerminal::AccessBridgeTransportAddressList"

Page 7-15, second bullet: replace "CLOSE_REASON_RRESOURCE_CONSTRAINT" by
"CLOSE_REASON_RESOURCE_CONSTRAINT"

Page 7-15, third bullet: replace "CLOSE_REASON_RIDLE_CLOSED" by
"CLOSE_REASON_IDLE_CLOSED"

Page 7-15, fourth bullet: replace "CLOSE_REASON_RTIME_TO_LIVE_EXPIRED" by
"CLOSE_REASON_TIME_TO_LIVE_EXPIRED"

Chapter 7.2.17, paret Description, 2nd paragraph: replace "gtp_from
terminal" by gtp_from_terminal"

Chapter 7.5.1, 2nd paragraph: replcae "transmission of unreliable" by
"unreliable transmission"

Chapter 7.5.3, 1st paragraph: add "CDR encapsulation of" at the end of
paragraph

Figure 8-1: replace "location_update" by "update_location"

Chapter 8.3.1, numbered item 5: replace "ReleaseTunnelReuqest" by
"ReleaseTunnelRequest"

Chapter 8.3.2, numbered item 2: replace "location_update" by
"update_location" and "operation" not in bold

Figure 8-2 and 8-3: replace "location_update" by "update_location"

Chapter 8.5, last paragraph, 1st line: replace "an old Access," by "an old
Access Bridge,"

The following editorial changes should be implemented:

The OpenConnectionRequest in section 7.2.10 contains the target object
reference. Since, in case of GIOP 1.0 or 1.1 clients, the Access
Bridge may have only the object key, the note permits the Access
Bridge to use GIOP::TargetAddress as this object reference. I request
that, for consistency and simplicity of implementation, the target
object reference in this message were always given as
GIOP::TargetAddress, in both directions.

The target object reference in the OpenConnectionRequest message to be of type GIOP::TargetAddress.

When a terminal loses connection to its current Access Bridge, section
4.1 says that the Access Bridge deregisters the terminal by invoking
update_location at the Home Location Agent giving NIL as the new
Access Bridge reference. Assume now that the terminal is performing
an access recovery to a new Access Bridge. It may happen that the new
Access Bridge invokes update_location, then the old Access Bridge, not
yet knowing about the recovery in progress, deregisters the terminal
and only after that the new Access Bridge invokes recovery_request at
the old Access Bridge. This sequence of events leaves the Home
Location Agent to believe mistakenly that the terminal does not have
an associated Access Bridge.

A possible solution: Add a deregister() operation to the
HomeLocationAgent interface. This operation would take as parameters
the terminal id and the Access Bridge invoking it, and would return a
boolean value. The Home Location Agent could then compare whether the
invoking Access Bridge is the same as the Access Bridge it believes to
be current. If it is, the HLA deregisters the terminal and returns
true, otherwise the HLA does nothing and returns false. Now, from the
return value, the invoking Access Bridge can tell whether there is an
access recovery in progress, and if so, can prepare for it by hanging
on to the terminal's information.

see above

The struct MobileTerminal::ProfileBody contains as its first member
the version number of the profile. However, the specification does
not say what version number is to be used. A clear-seeming solution
would be to use the same version number as for GTP, since GTP is in a
sense this profile's associated protocol.

Specify that MIOR version is the same as the GTP version.

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

In a network initiated handoff (section 8.2) the old Access Bridge is
given a reference to a HandoffCallback object, to which the Access
Bridge reports the status after handoff. However, if the terminal
uses the alternate handoff procedure of section 8.2.5, the status that
the Access Bridge is supposed to report is not specified. There seem
to be two reasonable options:
1) The Access Bridge reports NO_MAKE_BEFORE_BREAK as status
2) The Access Bridge waits for recovery_request and reports success
or failure according to whether recovery happens

It needs to be specified which of these actions the Access Bridge
takes.

see above

In Access Recovery to a new Access Bridge (section 8.4.2) the
invocation of recovery_request at the old Access Bridge is assumed to
succeed. However, it is possible that the old tunnel has been down
for so long that the old Access Bridge has destroyed all information
it has on the terminal. This would make it impossible to fill the out
parameter of recovery_request correctly. I therefore suggest that an
exception to signal a destroyed association (possibly TerminalNotHere)
be added to recovery_request signature and that the new Access
Bridge's actions when receiving this exception be specified.

see above

In the current specification the different conformance options are separated
by version numbers; version 1.0 that does not include hand-off and version
2.o that supports hand-off.

This can be quite confusing and the confusion is likely to multiply in the
event that the whole specification is updated and receives new version
number.

My suggestion is to use similar technique as in CORBA security, where
different conformance levels are separated, not by version numbers, but by
Level numbers.

I suggest that we change "Version 1.0" to "Level 0" and "Version 2.0" to
"Level 1".

see above

In Terminal Initiated Handoff (section 8.3) and Access Recovery
(section 8.4.2) the new Access Bridge needs to invoke different
methods depending on the kind of handoff (step 4 in 8.3.2 and step 5
in 8.4.2.2). However, it is not possible for it to make this
distinction based on the information it has received in previous steps
of the handoff.

Furthermore, in Network Initiated Handoff (section 8.2) the only
distinction for the new Access Bridge is the previous invocation of
transport_address_request. But it is possible that the terminal could
not establish connectivity during the handoff procedure and resorted
to another kind of handoff later. So in this case the new Access
Bridge misidentifies this handoff as network initiated.

The simplest way to correct this seems to be to add an element for
handoff type into RecoveryRequestBody (section 7.2.4). This solution
also looks quite clean.

see above

In opening a connection for GIOP data (sections 7.2.10--7.2.11) the
receiver of a request is responsible for allocating a connection id.
But if two OpenConnectionRequests cross each other, it might be
possible for the same connection id to be allocated to two different
connections. This would completely break at least one, maybe both, of
the connections.

The easiest way to fix this would be to allocate disjoint subsets of
the available connection id space to Terminal and Access Bridges.
Since this is a question of interoperability, the subsets need to be
also mandated. A good one would be for the Access Bridge to use even
numbers and the Terminal Bridge to use odd numbers (excluding the
invalid 0xffffffff).

Access Bridge uses even numbers and Terminal Bridge odd numbers (but not 0xFFFFFFFF).

In the GTP Header (section 7.2.1) there are two unsigned short members
before the byte order flag. Processing this header correctly requires
either processing out of order or possibly correcting already
processed elements afterwards.

I request that the members gtp_msg_type and flags be moved to the
start of the header. This way the header can be processed in order
without the need for backpatching, which is definitely simpler.

see above