> To put it in the terms I learned from my college tutor, the transport
> protocol enters into a contract with the application protocol.
> Provided both sides meet the contract each is entirely free to
> implement in whatever way they like. In this case the contract is with
> TLS, not a particular version of TLS.
yes, but if the contract was originally defined in terms of a particular
version of TLS, and there is any drift at all in the functionality or
interface provided between one version and another, or if there's any
incompatibility between old and new versions of the protocol (as there
was between SSL 3.0 and TLS 1.0) the application can no longer be
expected to work.
it's not as if the "contract" can automatically be assumed to be amended
just because a new version came out.
in applications (I mean this in the broader sense, not just software)
where reliability is important, it's not acceptable to substitute one
component for another without first doing an analysis of whether the new
component meets the requirements of the design, and whether substitution
of that component will cause any problems.
Yes, care and engineering is needed. I hope that WG review and IETF
Last Call will detect any slips. That is one of the things we expect
to happen during these phases of document development.
I look forward to your participation in the review of TLS 1.2.
Russ
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf