Subject: Call for volunteers for C/C++ API liaison manager

From: IAB Chair <[email-masked]>
Date: Wed, 30 Apr 2014 11:20:31 -0400

We often see proposals for APIs (most commonly C APIs) discussed in the IETF.  ISO/IEC JTC1/SC22 is the standards body for various programming languages, notably including C (WG14) and C++ (WG21), and those groups have been working on APIs for various IETF technologies, including URIs, sockets, IP addresses, etc.  The IAB is considering whether to request a liaison relationship with ISO/IEC JTC1/SC22 and is seeking to determine if there are candidates willing to serve as a liaison manager before determining whether to request the relationship.  For details on what a liaison manager position entails, see RFC 4052, RFC 4053, and RFC 4691.
 
Volunteers are requested to send email to [email-masked] by May 28, 2014.

On behalf of the IAB,
Russ Housley
IAB Chair

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 16:48:45 -0700

On 4/30/2014 8:20 AM, IAB Chair wrote:
> We often see proposals for APIs (most commonly C APIs) discussed in
> the IETF.

A protocol "API" isn't language-specific; it describes (or ought to) the 
upper and lower layer interactions, e.g., as was done in RFC793.

When we propose an API in the IETF, it should be for that protocol API, 
not for a language API (which is an instance, specific to a language and 
also often an OS, of that protocol API).

(that doesn't preclude the benefit of a liason to a language-standards 
group, but we shouldn't be seeing IETF proposals for such instances IMO).

Joe

---

From: Melinda Shore <[email-masked]>
Date: Wed, 30 Apr 2014 18:36:49 -0800

> group, but we shouldn't be seeing IETF proposals for such instances IMO).

Probably not, but it seems pretty clear that deployment
of some IETF protocols has suffered from either the lack
of a comprehensive API, or crappy API.  I'm thinking of
IPSec, newer DNS features, etc.  I think it's very much
in the interest of the IETF to have someone around who
can talk to some of the language standards bodies about
how to expose protocol features, how to deal with options,
etc.

Melinda

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 Apr 2014 23:05:35 -0400

> how to expose protocol features, how to deal with options,

Its a good idea, but you have to watch out for a dependency that would 
exclude other languages and also platforms out there, especially with 
higher level languages, server-side scripting languages.  If your 
liaison manager is experienced with many languages, that would be a 
plus. Its a difficult task to manage a multiple language API for 
examples of IETF protocols.  But it can be done.

-- 
HLS

---

From: David Morris <[email-masked]>
Date: Wed, 30 Apr 2014 20:16:44 -0700 (PDT)

And the language standards bodies don't define many of the
APIs AFAICT ... the defined to a major degree by the groups
implementing the network libraries. If OpenSSL and someone else
implement an SSL API, it would be really good for it to be the
same C/C++ etc. API.

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 20:21:38 -0700

On 4/30/2014 7:36 PM, Melinda Shore wrote:
> of a comprehensive API, or crappy API.

+1

However, somewhere along the line, AFAICT the IETF started thinking of 
protocol APIs as language implementations, and decided (rightly) that 
the latter was out of scope, and threw the baby out with the bathwater.

IMO, a protocol is *incomplete* without its protocol API.

> I'm thinking of

It is, if you can find someone who knows both and can attend both ;-)

Joe

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 30 Apr 2014 23:36:17 -0500

> IMO, a protocol is *incomplete* without its protocol API.

FWIW, Martin and I understand this, and that's one of the points I've 
been stressing about the IETF 89 TAPS BOF.

I'd like to throw the baby back in. The bathwater can stay gone.

Spencer, who is really disturbed at the word picture he just drew ;-)