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:[EMAIL PROTECTED] 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 [email protected] https://www1.ietf.org/mailman/listinfo/ietf
