Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-ses!hpcuhb!hpindda!collin
From: collin@hpindda.HP.COM (Collin Park)
Newsgroups: comp.protocols.iso
Subject: Re: X-WINDOWS & OSI
Message-ID: <5560025@hpindda.HP.COM>
Date: 9 Jun 89 16:07:10 GMT
References: <06.Jun.89..14:24:26.bst..180574@EMAS-A>
Organization: HP Information Networks, Cupertino, CA
Lines: 28

OK, I'll start with the standard disclaimer, the following opinions are
not necessarily those of anyone but myself; in particular they do not
necessarily represent the opinions of my employer.

Seems to me (not an X expert) that if what X needs is reliable non-
duplicated ordered byte-stream communications, and nothing else 
(e.g., graceful release), then putting it on transport is the way
to go.  There are undoubtedly those who would say, no, that doesn't
preserve the architectural purity of osi.  This is a true statement,
but what does "architectural purity" buy the customer (end user,
sys admin, or application developer)?  Seems to me the surest way
to kill OSI is to require applications that used to run over tcp/ip
to now run over TPx/S/P/ACSE.

I don't know of any good argument to increase the communications
overhead of X-windows by requiring S/P/(and at connection-time, ACSE).
If we don't try to call X an OSI application, then there's no need
that I know of to require that it run in its "proper" place in the
osi architecture.

------------------------------------------------------------------------------
Unless explicitly stated otherwise, opinions expressed above are my
own and do not explicitly reflect those of the Hewlett-Packard Company
or any other person or entity.

collin park			Hewlett-Packard Company
collin%hpda@hplabs.hp.com	19420 Homestead Road -- MS 43LT
				Cupertino, CA  95014  USA