[e2e] time for a presentation layer?
John Day
day at std.com
Mon Jun 18 13:45:40 PDT 2001
At 10:34 -0700 6/18/01, B. Scott Michel wrote:
> > I wonder if the talk about end-node services are arguments for a
> > standardized set of presentation layer services. Is it time to do one for
> > new apps to use? Some of the possible components:
> >
> > o absolute reliability
>
>Correct me if I'm misinterpreting you, but isn't that already done at the
>transport layer or are you arguing for a more general purpose foo that
>implements reliability such as various flavors of FEC?
>
> > o encryption
> > o compression
> > o data-typing (maybe)
>
>I've been running into problems with the ISO model recently trying to
>explain where my particular research fits and the session and presentation
>layers always cause me the most grief. The reason being that they tend to be
>sublayers of the application. Since applications tend to do their own thing,
>I'm not entirely sure that a presentation layer is all that useful.
>
>It might be useful to define a set of functionality that coalesces the
>various points you enumerate as a general framework for application
>"presentation" issues. Eventually, it will become reasonably monolithic and
>then a de-facto layer.
>
Don't worry, its not you. You are correct. The session,
presentation, and application layer functionality are merely
sublayers of the application. (In fact, my clueless test from about
1984 on was anyone who implemented them as separate layers, clearly
hadn't understood.) The layers were proposed before we knew what
they were. Once we recognized that they were sublayers, it was felt
that it was too late to change, so changes were made to the Session,
Presentation, and ACSE protocols so that if you were smart you just
built it as one state machine.
However, to help you out a little more: the upper 3 layers are
actually upside down. The common protocol for setting up an
application association and doing authentication belongs directly on
top of Transport. Next you need a little sublayer to specify the
syntax of the application (presentation). (Actually, it would just be
an additional parameter in the "ACSE." And then the session layer
which contains a basket of independent modules that may be helpful as
common constructs for some applications. These are the elements that
the application protocol is built out of that OSI called ASEs. (I
always wanted to write this up call the paper "Green Side Up". But
never got to it.) If you think about this way, you see that the
upper layers are far simpler than they first appear to be and it even
makes some sense! And you get global application names used by all
applications that solves other problems we have. When you combine
ACSE and "presentation" and you get something close to what people
had always talked about a "session" layer being, rather than what OSI
defined it to be,which by the way was a political game pulled by the
Europeans for Videotex which would clearly dominate the future of
computing, just as the Europeans knew that X.25 would be the basis
for networking well into the 21st C. Technical reasons had very
little to do with the definition of the Session Layer. And as time
went on and they tried to use it in other application and because
they had designed to do just Videotex, it couldn't be used to do much
of anything else. So while the constructs in the OSI Session Layer
could have been good common building blocks they weren't.
Oddly enough, if you look at recent proposals such as WAP and
Bluetooth. They suffer from similar design flaws. Does what it
does, but can't do the next thing.
Take care,
John
More information about the end2end-interest
mailing list