Yep. A new RFC is needed. The original author has been saying that for ten years, has asked for collaborators, and is still open.
The original design intentionally left compression and encryption out of scope. The advent of SSL suggests that was probably a good choice. ZIP has been around since long before UFT. GZIP was there at the start. Both of these have some functionality on CMS, but not well integrated. But we were talking about SSL, not compression. Sorry. Negotiation was worked on, but has never made it into a follow-on RFC. (Probably because there is no follow-on RFC ... yet.) Authentication in UFT suggests how TLS/SSL negotiation might be done because authentication was always open and variable ... "negotiated". The bottom line for UFT is to do over TCP what RSCS does over CTC/VTAM/NJE, but not in the way NJE/IP does. (Of course, it might be a good hint to the present NJE/IP authors and owners to create a UFT driver for their stuff. hint hint) The point is that UFT gives you RSCS-style transport without adding more network topology. If then you are behind a firewall, you might not care to secure the UFT channels. (Did he just say that? He did! I can't believe he said that!) -- R; <>< On Thu, Dec 2, 2010 at 08:29, Alan Altmark <[email protected]> wrote: > On Thursday, 12/02/2010 at 08:15 EST, Mark Wheeler > <[email protected]> wrote: > > It would be nice if UFT(D) would support it. > > RFC 1440 does not define a mechanism for the UFT client and server to > negotiate and initiate TLS. A new RFC is needed. (Note that the IETF now > requires protocols to be able to negotiate TLS on the same port as the > unsecured version.) > > Further, UFT(D) in VM is not written to the VMCF/Pascal interface and so > couldn't support it until CMS supports dynamic TLS for IUCV sockets. > > Alan Altmark > > z/VM and Linux on System z Consultant > IBM System Lab Services and Training > ibm.com/systems/services/labservices > office: 607.429.3323 > [email protected] > IBM Endicott >
