Tony Finch wrote: > On Thu, 13 Sep 2007, Keith Moore wrote: > > >> Offhand I don't know why it should be necessary to build a mechanism >> that spans several transport lifetimes. >> > > TLS session caches. HTTP cookies. FTP control connections. > okay fine (at least for the first two) but should that information be managed by the application, or at a lower layer? particularly if it needs to be shared among multiple instances of a service that may reside on different hosts? > Apps that want to deal with concurrent data streams within one user's > session currently have to establish and authenticate multiple TCP > connections (e.g. HTTP, IMAP) or re-implement TCP's multiplexing and > windowing at the application level (e.g. BEEP, ssh). > I actually don't think that having multiple concurrent TCP connections between two peers is a bad thing. sure we could have a transport protocol that provided multiple streams, but why bother when concurrent TCP connections works pretty well? > A session layer would allow an app to establish a security context once > then re-use it when establishing new transport connections, so that > re-connecting can be cheap and concurrent data streams can be simple. > Unfortunately TCP doesn't share congestion information between > connections, which penalises new bulk-data streams and requires > workarounds at the application level (e.g. HTTP/1.1 persistent > connections). > mumble. I don't have a problem with multiple TCP connections, but OTOH I think that using TCP close for framing is bad application design. so I don't view persistent connections in HTTP as a workaround, I view it as fixing a design flaw in HTTP/1.0. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf