[e2e] time for a presentation layer?

[julian_satran at il.ibm.com]

Except for data typing - all could be glued in existing protocols.
I've attempted to start a "thread" on this with:

http://search.ietf.org/internet-drafts/draft-satran-transport-adaptation-framework-00.txt

but I did sense an overwhelming interest.

Things might change.

Julo

"Eric A. Hall" <ehall at ehsco.com> on 18-06-2001 22:23:55

Please respond to "Eric A. Hall" <ehall at ehsco.com>

To:   "B. Scott Michel" <scottm at cs.ucla.edu>
cc:   end2end-interest at postel.org
Subject:  Re: [e2e] time for a presentation layer?





> >  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?

I'm suggesting that the argument for strong-v-weak reliability is probably
an argument for negotiable reliability extensions (which could include FEC
I suppose) on a per-connection basis.

> >  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 bec 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.

I have argued in various places that TCP and UDP provide session-layer
services as part of their connection-management services. I have also
argued that the historical character apps use a default limited
presentation-layer service in the form of common bit-ordering, charset,
and line termination signals. It would be nice to go beyond that at some
point down the line.

> 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.

It would probably only be *really* useful as part of a new transport
protocol, where the ends negotiated the desired extensions during the
connection-setup handshake. It could be glued onto existing protocols, but
it would be fairly ugly. One could imagine an ESMTP extension for
negotiation compression and the like, and maybe for negotiating numeric
formats (for the SMTP response codes), but it would be pretty ugly in
comparison to a codified option exchange provided during the transport
setup routines.

--
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/