[anonsec] Consensus call on WG adoption of draft-komu-btns-api-01

[Nicolas.Williams at sun.com (Nicolas Williams)]

On Thu, May 31, 2007 at 05:52:07PM +0200, Simon Josefsson wrote:
> I object to standardize any API that uses data types from a particular
> external implementation (in this case OpenSSL).

I agree that we must not have APIs that rely on non-standard APIs.
I.e., a C bindings of Michael's API that relies on BSDish sockets (or
Unix-like integer file descriptors for "sockets") is OK, but a C
bindings of Michael's API that relies on OpenSSL is not.

> The approach used in this document appear to require that every
> implementation of the document needs to #include OpenSSL headers, and
> possibly call OpenSSL functions (the implementation of the
> ipsec_openssl_to_channel_info is unclear to me).  I believe that is
> clearly unacceptable for any Standards Track document.
> 
> If this problem can be solved, by having a generic interface to input
> the necessary information needed from the TLS library, the document
> seems like a useful contribution to me.

I'm sure that this problem can be solved.  In fact, I can't understand
why any dependence on any SSL/TLS library would be needed here.  Miika's
API should use octet strings to deal with certificates (DER or PEM) and
raw public keys.

> A suggestion for an improvement to the document would be to add a
> copyright license to the example code to make it possible to use the
> example in implementations.  This often helps spread usage and leads to
> faster adoption of the API.  See section 3 of
> draft-josefsson-free-standards-howto-00.txt.

I should read that I-D.  Yes, it's important in an API document to make
sure that implementors have the right to: a) derive work from the API in
the document and distribute the result freely, b) derive documentation
from the RFC and distribute that freely.