Re: [Dime] [SPAM] RE: rfc3588bis version number

["Glen Zorn" <gwz at net-zen.net>]

Sebastien Decugis [mailto:sdecugis at nict.go.jp] writes:

 
> > This is how I think that it would work:
> >
> [...]
> 
> Well, if the bis describes how to handle the interoperability with
> "pure" rfc3588, and the solution is not very very dirty, then I'd agree
> for this type of solution ^^
> But I'd prefer to see the actual description, before saying it's
> possible... To me it looks complex, especially for the initiator's
> side.

Let's just take TLS, for simplicity's sake.  The old and new ways use two
different ports, right?  As long as an implementation knows which of the two
the connection came in on, it knows what to do (or not to do), right?  On
the initiator side, a new implementation would try the special port first
(because it's a "SHOULD") & if no answer then fall back to the old way
(because it's a "MAY", though we can specify this behavior more precisely).
That sounds fairly simple to me.  If we leave capabilities update as a
separate app, then we don't have to worry about that for bis.

...

> 
> > I would prefer to increment the version number, too; I'm just trying
> to
> > break the log jam here.
> >
> Well, not pushing the change to TLS into the Bis version seemed a good
> approach to me.
> If the implementation must be backward-compatible with 3588, it will
> remain open to the security vulnerability anyway...

Not unless it actually practices the old way.

...