[e2e] time for a presentation layer?

[Eric A. Hall]

> Much depends on what the application wants to do and I think we've
> identified a spectrum of presentation issues.

Exactly. The arguments pro-and-con for several sub-app technologies and
services illustrate the need for an ability to negotiate over thier use,
rather than accepting a default position which suits neither extreme (less
than perfect error detection, for example). That there are many such
examples means that the need is large.

My not-a-proposal is simply an observation that these could be considered
as presentation layer services, and also pointing out that such a layer
could not be deployed cleanly in the existing model.

To answer Dr.Reed's question specifically, I am not suggesting that any
transport provide these services. I would expect that the collection of
services would be deployed as system services which the applications
interacted with, while the transports continued to simply move the data
around the network. The "transport functionality" would be limited to
handshake negotiation of the specific features desired.

Whereas now the apps communicate with system calls to read/write data,
handle conversion, etc., these calls could be extended to support
negotiation of other presentation-like features.

      APPLICATION
           |
        SESSION ---- {encryption, compression, etc.}
           |
       TRANSPORT

My not-a-proposal would be that specifying a negotiation mechanism for
these kinds of services would be useful, but probably only useful for new
transports. It's not that radical, but it's too hard to do with the
existing transports and applications.

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