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. An Atom client does not have the ability to specify the transport layer in the general case, nor should it need to do so. The transport is built into the operating system platform. We want to be able to fix TLS without sending out notices to all the applications that rely on it. We want to be able to fix atom similarly. 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.
________________________________ From: Russ Housley [mailto:[EMAIL PROTECTED] Sent: Fri 13/07/2007 12:01 PM To: Robert Sayre Cc: IETF discussion list Subject: Re: Updating the rules? No one had any concern with the version of TLS that was selected by the working group. However, there were two things that cause me to want a change. I'll let others provide their own point of view. 1) History has shown that TLS implementations do a very good job handling backward compatibility. As a result, there has been a smooth transition from SSL 3.0 to TLS 1.0, and a similarly smooth transition has begun from TLS 1.0 to TLS 1.1. TLS 1.2 is being developed in the TLS WG right now. I expect the transition to TLS 1.2 to be smooth as well. 2) We do not want to update the standards-track Atom RFC to track TLS developments. The language that was put in the document made it easy for an implementor to use a TLS library and let the version negotiation naturally select the highest version supported by the two peers. Russ At 11:03 PM 7/9/2007, Robert Sayre wrote: >I'm also interested in the reasoning behind the IESG's decision to >allow Atompub to avoid requiring a specific TLS version. That >certainly allows for incompatible conformant implementations. I don't >understand why WGs are not permitted to make similar judgments >regarding other security mechanisms--they usually know more about >their market than the IESG does. _______________________________________________ Ietf mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ietf
