I prefer my college tutor, Tony Hoare's view. It did win him the Turing award
after all.
Knowledge of the lower layers is important when you negotiate the contract. The
means of fullfilment are irrelevant.
We build complex systems, the most complex mechanisms built in the history of
civilization. Ruthless insistence on modularity is essential if the systems are
to work over decades.
We are not architects of buildings, we are urban planners who lay out the
streets to meet the needs of centuries.
Sent from my GoodLink Wireless Handheld (www.good.com)
-----Original Message-----
From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu]
Sent: Friday, July 13, 2007 02:24 PM Pacific Standard Time
To: Hallam-Baker, Phillip
Cc: Russ Housley; Robert Sayre; IETF discussion list
Subject: Re: Updating the rules?
Hallam-Baker, Phillip wrote:
What Russ is stating here seems to me to be simply good, modular design.
If the applications care about the lower levels the architecture is
broken.
false. the implication of that statement is that an application should
be able to function no matter how much or little functionality the lower
layers provide, and thus, the application must provide all of the
functionality that it needs so that it can function with the most
minimal or dysfunctional of lower layers. this defeats the entire
purpose of layering.
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf