Re: [dix] DRAFT: WAE BOF minutes

"Gavin Baumanis" <gavin.baumanis@rmit.edu.au> Thu, 20 July 2006 03:39 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3PO1-000540-RI; Wed, 19 Jul 2006 23:39:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3PO0-00053u-Rc for dix@ietf.org; Wed, 19 Jul 2006 23:39:40 -0400
Received: from its-mu-mail3.its.rmit.edu.au ([131.170.1.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3PO0-00013C-10 for dix@ietf.org; Wed, 19 Jul 2006 23:39:40 -0400
Received: from its-gw-inet57.its.rmit.edu.au (its-gw-inet57.its.rmit.edu.au [131.170.10.77]) by its-mu-mail3.its.rmit.edu.au (8.13.7/8.13.7/mail3) with ESMTP id k6K3dOd4028684 for <dix@ietf.org>; Thu, 20 Jul 2006 13:39:24 +1000 (EST)
Received: from INET57-MTA by its-gw-inet57.its.rmit.edu.au with Novell_GroupWise; Thu, 20 Jul 2006 13:39:24 +1000
Message-Id: <44BF8782.29CB.0017.3@ems.rmit.edu.au>
X-Mailer: Novell GroupWise Internet Agent 7.0.1
Date: Thu, 20 Jul 2006 13:39:11 +1000
From: Gavin Baumanis <gavin.baumanis@rmit.edu.au>
To: Digital Identity Exchange <dix@ietf.org>
Subject: Re: [dix] DRAFT: WAE BOF minutes
References: <198A730C2044DE4A96749D13E167AD37BD6557@MOU1WNEXMB04.vcorp.ad.vrsn.com> <20060718194907.GW21538@binky.Central.Sun.COM> <86mzb67itl.fsf@raman.networkresonance.com> <44BD56D6.8030502@secure-endpoints.com> <86fygy7fdq.fsf@raman.networkresonance.com> <44BD5C25.4080002@secure-endpoints.com> <1b587cab0607190401x421492f2p19e3bb686e75777a@mail.google.com> <44BE3622.6090504@secure-endpoints.com> <1b587cab0607190658m66dacc79p7a75dcb8285a5270@mail.google.com>
In-Reply-To: <1b587cab0607190658m66dacc79p7a75dcb8285a5270@mail.google.com>
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.44
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Digital Identity Exchange <dix@ietf.org>
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:dix@ietf.org>
List-Help: <mailto:dix-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0450718143=="
Errors-To: dix-bounces@ietf.org

>>> On Wednesday, July 19, 2006 at 23:58, in message
<1b587cab0607190658m66dacc79p7a75dcb8285a5270@mail.google.com>, "Ben
Laurie" <benl@google.com> wrote:
On 7/19/06, Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
> Ben Laurie wrote:
> > I'd note that most of the work of supporting these things has to
be
> > done in OpenSSL, and unlike Apache, OpenSSL does not have a large
> > funded development community.
> >
> > Expecting volunteers to rush to implement every cute TLS feature
is
> > asking a lot. The way to make this happen is to find money for
OpenSSL
> > development.
>
> Ben:
>
> I am very well aware that compared to the applications that use
OpenSSL,
> those working on OpenSSL find it next to impossible to obtain
> contributions to support their efforts.  Individuals and small
> businesses are not going to write a check for OpenSSL (or an OpenSSL
> contributor) to develop this code.   That's not how people think.
>
> Instead someone will write a check to Apache to implement support
> for said feature because they want it in their web server.  The
Apache
> folks will respond with (a) once OpenSSL gives it to us we will have
> it so don't worry about it; and (b) it won't do you any good anyway
> because the browsers, webdav clients, etc. don't implement it.
>
> We are therefore left with a serious catch-22.  The only way that we
> can get functionality like this implemented is to first obtain
agreement
> from the client and server vendors.  Only then might it become
> reasonable to expect end users to step up with funding.

Browsers seem to be implementing these features faster. I'm told SNI
is in most major browsers now, for example.

What would help, actually, is keeping a league table of features and
where they're implemented, and thus making it obvious which ones have
to be done to make a feature useful.

Sounds Like a great idea Ben,
However there is then the problem (and it always seems to be the same
problem);
 
Who is going to implement the table?
Who is going to update it?
Can we ensure that when a feature is added into a product that the
table editor is made aware of the new feature set for the product?
 
And that doesn't even cover setting the scope for what information is
needed to be covered in the table.
 
Now, not to be one of "those" that complains about things yet does
nothing about it... I am more than happy to contribute my time to the
creation / upkeep of the table if needed!
_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix