RE: Updating the rules?

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: Re: Updating the rules?

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@xxxxxxxxxxxx]
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf