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:housley(_at_)vigilsec(_dot_)com]
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf