On 21 June 2013 02:29, Thor Lancelot Simon <t...@panix.com> wrote: > On Thu, Jun 20, 2013 at 09:30:32PM +0000, Jeff Mendoza (MS OPEN TECH) wrote: >> > Yeah, my point was that in the perfect world, you'd support both at >> > runtime (at least on the server-side) and either ALPN or NPN could be >> > used. I want to have a library that supports both, not either-or. >> >> Yes, supporting both at runtime would be best. But having a compile-time >> option now, and defaulting to NPN should keep this from being a blocking >> issue with the patch, correct? > > I don't speak for the OpenSSL project, but I'd suggest they should treat > it as one. It positively reeks of "embrace and extend". After all, the > effect is to force all build systems producing system default packages > of OpenSSL to pick one way or the other, ensuring that both won't work > at the same time.
That's not really "embrace and extend", but nevertheless it seems like an unacceptable design choice. I suggest you need to figure out how to make both ALPN and NPN work in a single build to have any chance of acceptance at all. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org