[e2e] time for a presentation layer?

[Scott Michel]

On Mon, Jun 18, 2001 at 04:45:40PM -0400, John Day wrote:
> 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.

Here's my particular problem which amplifies your comments a bit.
I'm researching store-and-forward for peer-to-peer services (or as
my dissertation prospectus was entitled "A Forwarding Layer for
Application- level Peer-to-Peer Services (FLAPPS)".) The short
summary is that I'm proposing an application sublayer that does
routing and forwarding in peer networks using the service-specific
composable and location-independent name space. FLAPPS is just an
application sublayer that combines peer network topology construction,
routing protocols to propagate name space reachability, and a
fowarding engine to relay service requests and message flow segments
to a next-hop peer. 

Here's what the layering looks like:

+-+Application ----------------------------------+-+
| |                                              | |
| | Peer Message Processing                      | |
| | and Application Logic                        | |
| |                                              | |
| +------------+--------------+------------------+ | --------
| | Forwarding | Routing      | Topology         | |
| | Engine     | Protocol Mgr | Construction Mgr | | FLAPPS
+-+------------+--------------+------------------+-+ --------
+--------------------------------------------------+
|                    Transport                     |
+--------------------------------------------------+
|                     Network                      |
+--------------------------------------------------+
|                    Physical                      |
+--------------------------------------------------+

In this model, presentation and session issues are above FLAPPS.
FLAPPS doesn't care what transport is used between adjacent peers;
the topology construction protocol used determines what's used.



-scooter

PS: I could go on at much greater length about FLAPPS but that would be
a complete change of thread.

PPS: I'd delighted to BOF this in London if there's interest. I'm
working on an I-D (I've been working on an I-D for a while...) To
some degree, FLAPPS probably overlaps some of the proposed OPES WG
efforts, although FLAPPS is supposed to be agnostic about transport
and is not specifically scoped for content delivery but more
generally for peer-to-peer. FLAPPS and OPES do share the same goal,
namely to make the transit entities explicitly visible.  One of
the goals FLAPPS is functional transparency of the transit entities.