Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!cheetah.nyser.net!mrose
From: mrose@cheetah.nyser.net (Marshall Rose)
Newsgroups: comp.protocols.iso
Subject: Re: X-WINDOWS & OSI
Message-ID: <552.614737907@cheetah.nyser.net>
Date: 25 Jun 89 00:31:47 GMT
References: <99600003@p.cs.uiuc.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: iso@sri-nic.ARPA
Organization: The Internet
Lines: 56

** FLAME ON **
Thank you so much for pointing out the very obvious (null layers needn't
introduce additional overhead), and the incorrect (you can use null layers
in this situation).
** FLAME OFF **

If the question is: can we define a mapping from X onto ACSE and Presentation?
The answer is yes.  However, we now have to decide what this means exactly.
OSI defines a presentation service and protocol.  If you retain the service
but use a different (e.g., null) protocol, you aren't OSI any more.  Ditto
for session.

To be as-null-as-possible and still use OSI protocols, we can start by
selecting the kernel facilities of the session layer.  These can be
implemented fairly efficiently with only a modest amount of additional burden.
However, at each layer you still have to prepend a header (PCI for you OSI
purists) when data goes down and strip off and interpret the header when the
data comes up the on the other system.  Since session deals with strings of
octets, this can all be handled reasonably.

At the presentation layer, things are more complicated since we must now
introduce an abstract syntax for the data structuctes exchanged by the X-based
applications.  The X11 protocol defines these structures concretely.  So, you
can either define a simple octet string syntax and let the X application do the
work, or you can redefine all the X structures in terms of ASN.1 and let
presentation (conceptually) do the (de-)serialization.  The first alternative,
whilst legal, is probably contrary to the spirit of OSI.  The second
alternative, whilst philosophically correct, is going to be a performance pig.

At the application layer, we note that the X protocol is really an RPC on a
connection-oriented presentation service.  So, to be true to the spirit of
OSI, we should be re-cast the X operations in terms of the ROSE (just as we
recast the X datastructures in terms of ASN.1).  Of course, we needn't use 
ROSE if we just use the existing X framework.  ACSE, per se, isn't such a big
deal, though use of the Directory in order to map application entity names into
presentation addresses, may introduce some additional delay during association
establishment.

In other words, at each layer above transport, you get two choices: wedge the
tried-and-true X way into OSI, or do it the "right" OSI way.  The former will
lead to a system, which, while performant, probably plays overly fast and loose
with the OSI framework.  The latter will lead to a system with interesting
research characteristics.

I prefer a third approach, which is the direct mapping of X onto transport
as an interim measure.  When we have experience building large OSI applications
and have a better understanding of what works and what doesn't, then a thorough
osification of X would be in order.

** FLAME ON **
Next time, before preaching about how efficiently null layers can be realized
in real systems, it would be worthwhile to consider how germane your
proselytizing is for the converation at hand.
** FLAME OFF **

/mtr