Olivier Bonaventure <[email protected]> writes: > My viewpoint is that it is too early to discuss about an API before we > have a vague idea of the type of solution that will be > developed. Multipath TCP worked on an API before the full protocol was > specified but it is not yet supported by implementations. We will have > a very idea of what the API could provide once we know clearly what > will be in the protocol. Anyway, the API will only be useful once the > protocol has been implemented...
But given that we already have four concrete proposals on the table, is it still too early to talk about API? I think two components of the API are very important: A) some kind of session ID or channel binding, and B) some sort of out-of-band signal to indicate that applications will make use of the session ID. As far as I can tell, EKR seemed pretty happy to go with that API for use TLS. Are there other proposers who would object to such an API? The reason it's useful to get this on the table early is that in the abstract not all protocols are capable of producing a session ID with the appropriate properties. In particular, the session ID must be unique over all time with overwhelming probability even if one end of the connection is malicious. As an example, I believe TLS could not do this in the pre-RFC5929 days. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
