Subject: [ietf-tls] Re: London

From: "Joseph Hui" <[email-masked]>
Date: Thu, 5 Jul 2001 12:31:12 -0700

Incrementing the minor number may complicate whatever somehow.
But it would certainly "uncomplicate" to great extent the task
of convincing browser/server vendors to adopt dns_name quickly.
The fact of matter is: the vendors are not direct beneficiaries
of dns_name, so they need some extra incentives to move. 
If we can't tempt them with greed (as all browsers are free), 
then fear -- the fear of falling behind one TLS revision -- is
the obvious alternative.

I'd like to remind ourselves, in the final analysis, the issue is not
so much about potential complication, necessary or unnecessary, but
about prompt dns_name adoption.  Vendors will do what needs to be done.
It so happens that we're now in the position to articulate the need.
So let's not blow it.  If we don't make dns_name a big deal to the
vendors the first time we may not get a second chance.  
Squeaky wheels get more oil.  Let's make it big and keep it simple,
so vendors and end users are not burdened with caveats and stipulations.
Seems to me incrementing the rev# will help the cause, so I'm for it.

We've been in this neighborhood twice before and gotten nowhere.
Perhaps this time, before jumping straight to the rev# decision,
we first try characterizing dns_name as: 1) a bug fix (for TLS 1.0),
2) a new functionality (of TLS); or 3) a new feature (of an
existing functionality).  If we can agree on the characterization,
then the answer to the rev# question should arrive accordingly.

Regards,

Joe Hui
Digital Island
====================================================================
-----Original Message-----
From: Bodo Moeller [mailto:[email-masked]]
Sent: Thursday, July 05, 2001 6:29 AM
To: IETF Transport Layer Security WG
Subject: [ietf-tls] Re: London

On Wed, Jul 04, 2001 at 07:50:53PM -0800, Mark Nottingham wrote:

> There's a difference between jumping between what are perceived as two
> different protocols (even though they're similar) and jumping versions
> (especially away from 1.0). Yes, this is just a perception thing, but
that's
> part of what versioning is about.
> 
> Also, I'm concerned about user identification of the capabilities of a
> browser or other product; I'm not too optimistic about MS or anyone
else
> clearly labeling their product as "TLS plus extensions foo, bar and
baz";
> while they'll be more apt to state "TLS 1.1" once they're compliant.

The extensions are mostly optional -- the client is not obliged to
generate them, and the server can ignore them except that it must
abort the handshake if server_hello_extension_list does not parse
correctly.  So "TLS 1.1 compliancy" wouldn't mean a lot.

Internal version numbers, such as { 3, 1 } for TLS 1.0, are important
for protocol negotiation.  There is no need to use anything other than
{ 3, 1 } for using TLS extensions as proposed in
draft-ietf-tls-extensions-00.txt.  Of course we could declare that
{ 3, 1 } denotes both TLS 1.0 (if used without extensions) and TLS 1.1
(if used with extensions), but I think this is pointless.

Using a new internal version number such as { 3, 2 } would make things
unnecessarily complicated.  There is no need to increment the version
number unless we are doing incompatible changes.

-- 
Bodo Möller <[email-masked]>
PGP
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.
html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283
Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]