Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!ernie.Berkeley.EDU!sklower
From: sklower@ernie.Berkeley.EDU (Keith Sklower)
Newsgroups: comp.protocols.iso
Subject: Re: Gateway ISO8073 Cl4 <-> IEEE802 TCP
Message-ID: <34587@ucbvax.BERKELEY.EDU>
Date: 28 Feb 90 17:17:25 GMT
References: <245@sposp1.UUCP> <5560054@hpindda.HP.COM>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: sklower@ernie.Berkeley.EDU.UUCP (Keith Sklower)
Organization: University of California, Berkeley
Lines: 29

In article <5560054@hpindda.HP.COM> collin@hpindda.HP.COM (Collin Park) writes:
}> 1.	Is it possible to translate TCP/IP <--> ISO8073 Cl4?
}
}In principle, no: tcp/ip has graceful release whereas 8073 has not.

and goes on to say

}...  there may be some
}klugey way to get around it...  For example, if the 8073 class 4 (i'll
}call it 'tp4' from now on) sends data and then waits for ALL data to
}be acknowledged before sending the DR TPDU, then the close is
}'graceful' from the sender's side.

This in fact is not true; ISO 8072 (the transport service specification)
>>REQUIRES<< that if the transport provider on the remote end has
data queued up for its consumer (session), (which has not yet been
delivered), and the remote transport provider receives a disconnect
request, then the remote transport provider MUST THROW AWAY all queued
up data.

Let's repeat that --  You know the remote guy has the received the data
he know's he's got the data, but he can't tell you if his client has
eaten it yet, and if it's still on the table when you the caterer leave
the building, he's required to throw it in the garbage.

What a brain dead protocol!!!!!!!  It has been speciously suggested that
they deliberately castrated TP4 to make it just as limp as X.25, just
so they could make sure session had something to do to justify its
existence.