[e2e] time for a presentation layer?

[John Day]

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

None of these are transport issues.  As Scott pointed out, they are 
sublayers of the application.  TCP should concentrate on issues of 
reliable end2end transfer and just that.

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

Actually, it wouldn't have to be ugly at all. Think of it as a 
wrapper before and after the current protocol.

Take care,
John