csg@pyramid.pyramid.com (Carl S. Gutekunst) (04/23/88)
[Followups redirected to comp.protocols.iso] >> The 7-bit-printable-ASCII restriction comes from international X.25 gateways, >> many of which insist on swiping the eigth bit for parity or somesuch. > >It's difficult to believe CCITT is so stupid to allow this in X.25 VCs. Ah, but this has nothing to do with X.25, and is completely outside the realm of CCITT. X.25 only describes the connection between a DTE (that is, a host) and a DCE (a network), and *some* of the behavior between two DTEs (two hosts, with a network inbetween). The standards deliberately say nothing about what protocols are used internally in the network, and here is where you get into trouble. Not only do you have gateways, but you also have network proprietary protocols. This is very different from ARPANet, where you have TCP/IP riding on top of an IMP-to-IMP protocol. The DCEs on many public data networks do a protocol conversion, from X.25 to something deemed more suitable for long-haul packet switching, or -- more likely -- whatever protocol the network was using before they started using X.25 to talk to DTEs. >What happens if one wants to run IP, DECNET, or OSI across such a gateway? >I guess you don't. That's right. Note that this *is* changing; I believe we can now run 8 bits among the U.S. (Tymnet and Telenet) the U.K. (PSS) and Canada (Datapac). But for amusement I tried Germany again yesterday. All my 8th-bit-on words were stripped. Curious thing, too -- you *need* all eight bits to get X.25 packet header through, to say nothing of the 16-bit FCS. But if the network has done a protocol conversion, almost anything can happen.... <csg>
jhh@ihlpl.ATT.COM (Haller) (04/25/88)
In article <20532@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: > [Followups redirected to comp.protocols.iso] > > >> The 7-bit-printable-ASCII restriction comes from international X.25 gateways, > >> many of which insist on swiping the eigth bit for parity or somesuch. > > > >It's difficult to believe CCITT is so stupid to allow this in X.25 VCs. > > Ah, but this has nothing to do with X.25, and is completely outside the realm > of CCITT. X.25 only describes the connection between a DTE (that is, a host) > and a DCE (a network), and *some* of the behavior between two DTEs (two hosts, > with a network inbetween). If the network is not passing the eighth bit transparently, it's not X.25. From the 1980 yellow book and the 1984 red book, X.25 section 4.3: Normal network operation dictates that user data in data and interrupt packets are all passed transparently, unaltered through the network in the case of packet DTE to packet DTE communications. There is a similar statement in section 3.3 of X.75 in the red book, so there is no excuse for a network not to pass all bits transparently. Of course, all bets are off if any data passes through a PAD at either end of a connection. Given the intransigence of the German PTT, and the difficulty of certifying a computer's X.25 to their satisfaction, I would not be suprised if there was a PAD at the other end. John Haller Accunet(r) Packet Service Development att!ihlpl!jhh
csch@tmpmbx.UUCP (Clemens Schrimpe) (04/28/88)
Carl (csg@pyramid.pyramid.com) writes:
{} [...]
{} That's right. Note that this *is* changing; I believe we can now run 8 bits
{} among the U.S. (Tymnet and Telenet) the U.K. (PSS) and Canada (Datapac). But
{} for amusement I tried Germany again yesterday. All my 8th-bit-on words were
{} stripped. Curious thing, too -- you *need* all eight bits to get X.25 packet
{} header through, to say nothing of the 16-bit FCS. But if the network has done
{} a protocol conversion, almost anything can happen....
You must be doing something wrong ...
As you now, we're polling YOUR site since Jan'88 - and since the German
Bundespost (PTT) still hasn't set us "online" with our own X.25, we are
using a public-access port (public pad) to dial in at pyramid.
[you call up a local 1200 Bd. Number, where you get connected to a
X.28/X.29 conforming PAD]
We were using UUCP 'g' protocol for four months WITHOUT any trouble, even
in transferring binaries. We now use 'f', but I tend to step over to 'k'.
I think the major problem with the transparancy (and that includes the
eigth bit) lies in the PAD being used. There are some recomended profiles
for X.28 PADs, of which the third is almost transparent.
The parameters for the third are:
1:0, 2:0, 3:0, 4:20, 5:0, 6:0, 7:2, 8:0, 9:0, 8 to 12 all 0!
The most interesting ones are 5&12 (disable flow control), 1 (ignore DLE),
and some national parameters (eg. 123 in Germany), which control the
use of PARITY bits in the data stream.
As I said, you may drive 'g' on this setup without any problems, but
be careful about some hosts, which simply reset your PAD parameters
by an X.29 message to other - and perhaps strange - values, like the
'monopad' does ...
Clemens Schrimpe
UUCP: csch@tmpmbx = {pyramid|tub|unido}!tmpmbx!csch
BITNET: csch@db0tui6 csch@tub.BITNET
PHONE: +49-30-332 40 15
TELEX: 186672 net d
FAX: +49-30-361 40 93
X.25: --- hopefully available soon --- ]:-}