For your info:
>> when you have compiled OpenSSL 0.9.8f or later with 'enable-tlsext' and
>
> Out of curiousity, do you happen to know why this isn't enabled by
> default in openssl?
The openssl patch was originally developped for the "latest" snapshots,
that was already
in 2004, when it got finally accepted last year that was 0.9.9.

Recently it was backported to the 0.9.8 stable version by Steve Henson
and ... ... since the developers are conservative with the stable
branches ...

A little bit of history:
     http://www.edelweb.fr/EdelKey/
We did not patch curl at that time for the servername extension.

>
>> The patch is a proposal for further discussion - there are a couple
>> of questions which need to be discussed, and are not yet coded in the
>> patch, f.e:
>> - should SNI be disabled at configure time (my 2ct: no, it can be
>> automatically detected)
>
> I agree, but that's also why I asked about openssl. Why do they have
> it disabled by default? Is there a particular risk or impact involved
> with having it enabled by default? If not, I think it should be
> enabled if a capable lib is detected.
see above.
>
>> - should SNI feature be switchable at runtime (my 2ct: yes)
>
> I think it should, just most features are with libcurl as I have no
> doubts that we will sooner or later face servers in the wild that have
> problems with it.
When using the the compatible sslv2 mode client hello, you cannot use
the extension anyway.
I think that no implementation of SSLV3 aor TLS1 has a problem when
seeing extensions.
>
>> - should it be enabled or disabled by default (my 2ct: enabled)
>
> I vote enabled too.
This means that ssl2 is disabled by default (which is probably a good
thing today).

There is another way to disable the extension: When an IP address is used,
the servername cannot be used.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.