[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