🚀 go-pugleaf

In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
>Virtually everyone now agrees that the OSI model is a good way to look at
>networking.  The war is about which protocols which be used in which layer.
To the entent that everyone agrees that networking should be performed
by layered "entities" communicating with layer protocols and each
layer using the services of *a* layer below it and providing services
to *a* layer above it, then probably everyone (even Mike Padlipsky!)
is in agreement. Of course the OSI Reference Model goes much further
than that, eg. it precludes "layer skipping", ie. a layer using the
services of a layer not directly below it. Furthermore, IS 7498 SAYS
there are SEVEN layers and says roughly what their purposes are. You
will have a lot of difficulty getting some people to agree with that.

>TCP is clearly one candidate for the transport protocol, but most
>companies in the U.S., and virtually all companies outside the U.S. are
>committed to supporting the ISO OSI transport protocol and the ISO protocols
>in layers 5 through 7 too.  (1-3 are much fuzzier, what with IEEE 802 etc.)
First, it goes without saying that the OSI reference model achieves
very little towards interoperability (how many times have you seen
Sales brochures using disgustingly misleading phrases like "our networking
complies with the OSI Model"?) Standards are about interoperability.
ISO standards exist for protocols up to layer 5, Presentation is about
to go to IS status as are a number of Application Layer standards
including FTAM. Down at layers 1-3, the IEEE 802 standards are
becoming IS8803 and the connectionless network protcocol (equivalent
in most senses to IP) is already an international standard.
So make no mistake, the standards ARE here and the
weight of support for their adoption is enormous.
Frankly, the possibility of TCP/IP becoming part of the OSI "suite" is
long since past, and before people criticize that, make sure you have
examined ISO TP-4 in comparison with TCP.

In any case, irrespective of the technical merits of any of the OSI
protocols, acceptance of what is standard rather than what is best is
unfortunately necessary. This was the view expressed in
message <1680@munnari.oz> where kre@munnari.oz (Robert Elz) writes:
>The whole purpose
>of standardisation is for political considerations to override the
>technical ones.  And no, I'm not being cynical.  The absolute essential
>for a standard is for everyone to agree with it, and getting everyone
>to agree means lots of compromises.
>There's absolutely no hope of a technically perfect standard, especially
>not in any area where there's any dispute about what is perfect.
Unfortunate, but so, so true.

In article <1204@botter.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) continues:
>There has been a lot of generalized disgust with OSI expressed here and
>elsewhere.  I would be very interested in hearing specific comments about
>  1. What is wrong with the OSI model itself.
>  2. What is wrong with the specific protocols ISO has adopted.
and also
>I would like to see a discussion of this subject, preferably by people 
>who know what they are talking about.

First, I thoroughly agree with the the last statement. We need more
discussion and we need it from people who know what they are talking
about. Given the FACT that OSI standards will happen, the closer we
can go to getting them right the better! 
Unfortunately there are many contributions on the net and elsewhere
(Padlipsky's book is an example) from people who in my view have seen
some early OSI stuff, have said "It'll never work" or "What's wrong
with Arpanet?" and they haven't even attempted to keep up to date with
the latest development in OSI. So let's have input from people who
know what the latest standards say.

One could write a whole book on the two questions raised above, and
indeed day by day, experts all around the world are contributing
comments to Standards Committees for consideration in the further
development of standards. For the time being, let me summarise what I
see as the biggest single problem with the OSI Model: THE ROLE OF THE
PRESENTATION LAYER.

One problem arises with Message Handling systems (a la X.400 which is
currently being standardized by ISO also, and there is a commitment
for complete alignment of X.400 and the corresponding ISO standards).
X.400 provides for a kind of "sub-layering" in the Application Layer
with the higher layer handling particular message types, eg. Inter
Personal Messaging (Mail) and the lower layer handling Message
Transfer. The reference model says that the encoding ought to be done
by the Presentation Layer so the message passed to the Message
Transfer Sub-Layer must (at least conceptually) be unencoded. X.400
provides for relaying so that the message may be received by a Message
Transfer Agent (MTA) on an intermediate machine (or several) which will
forward it on to another MTA, eventually reaching the right machine 
which where the MTA will pass the message "up" to a User Agent, ie. it
will deliver the mail. 

Now the Presentation Service (quite properly)
provides for different parts of the data to be encoded in different
ways so that for instance, the Message could be encrypted. But how
does the Presentation Layer on the intermediate machine (which we assume 
for security reasons doesn't have the capability to decrypt the 
message) unencode the message so it can pass it up to the MTA? Well of
course it can't, and indeed the situation couldn't have arisen because
the two communicating Presentation Entities would have failed in their
attempts to negotiate a common transfer encoding.

What is the solution? Well, in my view, the Presentation Layer doesn't
belong as a true Layer in the OSI model but should instead be
provided as a so-called Application Service Entity (ASE) that can be
used by other parts of the application layer as and when they see fit.
There is nothing wrong with having another ASE - there are already
quite a few of them (Remote Operations, Reliable Transfer, Commitement
Concurrency and Recovery just to name three). A Presentation ASE could
still negotiate with its peer, but another part of the Application
layer, eg. the MTA described above, could choose if and when it wants to
use it.

This contribution has gone on long enough, but it should  also be
stated that there are other problems with the positioning of the
Presentation Layer that have to do with applications that want to do
checkpointing, but because they are dealing with unencoded data, they
don't have any concept of data size and thus where checkpoints should
be placed. Perhaps we can pursue that problem in another article.

Ian Richards.