[e2e] time for a presentation layer?

[julian_satran at il.ibm.com]

There are at least to reason why an IP option (even in the disgust of a
separate protocol header between IP and transport) looks better:

   available for any transport
   can be implemented with intercept code (bump in the stack) instead of
   changing code


And several disadvantages:

   Negotiation in-band is difficult to sync (like IKE and IPSec) (not
   impossible though)
   Negotiation out-of-band requires (probably) a separate protocol


Julo

"Eric A. Hall" <ehall at ehsco.com> on 08-07-2001 19:50:51

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

To:   Julian Satran/Haifa/IBM at IBMIL
cc:
Subject:  Re: [e2e] time for a presentation layer?





julian_satran at il.ibm.com wrote:
>
> 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



A couple of thoughts on this.

First, there needs to be some sort of protocol specification for the
representation, interpretation and handling of codes, both during the
session-establishment phase and dynamically during an existing session.
EG, if a socket is already established, how is it modified, what are the
handling requirements for half- vs full-duplex option negotiation, etc.

Secondarily (and larger), I think this approach would be most useful if it
were an option in the transport headers rather than out-of-band messages.
This is particularly true for in-process negotiation. But since UDP
doesn't have any option space, I don't see how it would be possible to
implement this in that way. Perhaps a separate TCP control channel?

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