Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!CHEETAH.NYSER.NET!mrose
From: mrose@CHEETAH.NYSER.NET (Marshall Rose)
Newsgroups: comp.protocols.iso.dev-environ
Subject: Re: Encoding RFC 1006 addresses in X.500
Message-ID: <18945.632511213@cheetah.nyser.net>
Date: 16 Jan 90 17:33:33 GMT
References: <9001161233.AA03477@jerry.inria.fr>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 34

Who made

	"the political decision to describe RFC-1006 as ``an emulation
	 of TP-4 over TCP''"

This certainly was not I.  At various times I have said that RFC-1006 was
using TCP as an X.25 and then running TP0 over it, in order to describe
the structure of the protocol.  However, for the last year, RFC-1006 has
been "officially" described as a

	"transport service convergence protocol, which smooths over the
	 differences in the services offered by the OSI transport
	 service and the other transport service (e.g., the service
	 offerred by the TCP)."

If you can find any old documents or messages written by me which say
this "TP-4 emulation" nonsense, then destroy them.  If the documents or
messages are written by others, then let me know and I will set them
straight.

Note that from my perspective the fact that TP0 is used on top of a
packetization protocol on top of the TCP is completely irrelevant.  If
Dwight and I could have stolen a simpler protocol to get the job done,
we would have done so, rather than stealing TP0.

The decision to not allow the RFC1006 protocol to carry end-to-end NSAP
addresses was made some time ago, for the simple reason that this
concatenated CONS thing is a big mess.  The so-called "pure" OSI world
has yet to get this right (CONS relays, "arp" for CONS subnets, etc.,
etc.) so there is very little reason to jump into that swamp merely to
sink.  Better to run around the swamp on two legs.  That's what RFC1006
does now.

/mtr