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

From: Thomas Nadeau <[email-masked]>
Date: Thu, 1 May 2014 08:12:56 -0400

APIs are not that useful unless there is code behind them.  Are you proposing code that goes with those APIs?  Also the language that you do this in is important depending on the area of applicability. For instance, if these APIs are related to modern applications, C is all but useless because its not used to build most of those; you need Java/python/etc... for these cases.  

	--Tom

> 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: John C Klensin <[email-masked]>
Date: Thu, 01 May 2014 09:42:56 -0400

--On Wednesday, April 30, 2014 16:48 -0700 Joe Touch
<[email-masked]> 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 (and others),

Having spent a significant number of years in language
standards, I agree in theory.  In practice, well, the design and
structure of different languages deal with many or most of the
things that we would describe as APIs in different ways -- some
as semi-external (but sometimes standardized) libraries, others
with built-in functions or even special syntax.  

I don't know anything of the history of this liaison request
other than the "often ... discussed" comment quoted above.  We
should also be aware that what we think of as an API may not be
the same as the way SC 22 uses that term and this is their
effort we are talking about.  I hope we can trust the IAB with
that.  Although I assume some would disagree, I personally don't
think that another long thread on the IETF list in which the
intensity of opinions is exceeded only by the lack of actual
knowledge and context that is likely to be demonstrated is
helpful for getting IETF work done.

The dynamics within ISO/IEC JTC 1/SC 22 have often been
"interesting".  No amount of discussion on the IETF list, or
even statements from the IAB, is likely to discourage SC 22 or
SC 22 subgroups from developing APIs for Internet protocols if
they decide to do so (or that their communities are demanding
it).  Even if we were to set out to develop language-specific
API (which I agree would be undesirable) that would not prevent
SC 22 from developing their own (and we know that competing
standards are rarely a good idea).

In that situation, the only real question ought to be whether
the results are likely to be better with a channel for advice
from the IETF and, if SC 22 and the IAB decide that is useful,
review within this community.   If the answer is "yes, results
are likely to be better" (or even "...less bad") then I think
doing this, assuming an appropriate person can be found, ought
to be obvious.  The only exception would be if we would see
benefit in their failure and saw high enough odds of that
occurring to be useful to us (I don't think either is likely to
be the case, but YMMD).

I can make one suggestion that the IAB might consider and
consider passing along to SC 22 if it is appropriate.  SC 22 has
some history of creating language-independent special efforts
for interfaces to particular types of environments.  Depending
on what is really wanted, if circumstances allow, a "language
independent interfaces to Internet standards" group there (with
a strong IETF liaison) might make sense with the individual
language groups doing only "language bindings" to the resulting
spec(s).  But, if that is not feasible, the question is again
whether whatever is going to be done will be better for the
Internet with our input or not.

best,
   john

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 May 2014 08:02:08 -0700

On 5/1/2014 5:12 AM, Thomas Nadeau wrote:
>
> 	APIs are not that useful unless there is code behind them.

Ultimately, yes. But the code represents an instance of the API.

The "application" layer actions in RFC793 - SEND, RECEIVE, CONNECT, 
LISTEN - are *not* the same as the Unix socket API; Unix sockets are one 
implementation of that interface.

 > Are you proposing code that goes with those APIs?

Yes, just as I would propose code that implements a protocol. But I 
don't think either one is useful in the IETF except as an example - 
definitely never as a specification.

> Also the language that you do this in is important depending on the
> area of applicability.

Just as much (or little) as the physical layer (802.11, ethernet, 
carrier pigeon) is important to IP.

 > For instance, if these APIs are related to modern
> applications, C is all but useless because its not used to build most of
> those; you need Java/python/etc... for these cases.

If you don't have C, you often don't have scripted languages that are 
(often) compiled from C source code.

However, that depends on your compiler and the environment in which you 
develop your languages. That's important for language developers, but 
not the IETF (any more than we spec how to build pigeon coops).

Joe

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 1 May 2014 11:26:41 -0400

> Ultimately, yes. But the code represents an instance of the API.

	That depends on your perspective. These days the code IS the API, in particular open source code. Standards bodies do not need to define the APIs; implementation communities do that already.  The IETF should probably stick to on-the-wire protocols.  

> The "application" layer actions in RFC793 - SEND, RECEIVE, CONNECT, LISTEN - are *not* the same as the Unix socket API; Unix sockets are one implementation of that interface.
> 
> Yes, just as I would propose code that implements a protocol. But I don't think either one is useful in the IETF except as an example - definitely never as a specification.
> 
> Just as much (or little) as the physical layer (802.11, ethernet, carrier pigeon) is important to IP.
> 
> If you don't have C, you often don't have scripted languages that are (often) compiled from C source code.
> 
> However, that depends on your compiler and the environment in which you develop your languages. That's important for language developers, but not the IETF (any more than we spec how to build pigeon coops).

	This is why I personally think this sort of effort would not be very useful; modern applications are simply not built this way any longer.

	--Tom

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 1 May 2014 16:18:42 +0000

I think this is missing the point. This is not about "When we propose an API in the IETF" because that's not the proposal.

>From what I've seen (I track them to some extent) of how ISO/IEC JTC1/SC22 are progressing (having finished C++14, a tidy-up of C++11) _they_ want to create a C++ interface to these things. (Which is, I would guess, likely to be at least in part object-based, not simply function calls.) That would be because people writing C++ programs want to do things that need them, and they would like a standardised way of doing it.

They have then requested input from domain experts (i.e. the IETF) on this. (ISO/IEC JTC1/SC22 are C++ language experts.) This would end up in an ISO standard (I think probably a Technical Report, not the main C++ standard). If the IETF wanted to it could then reference that (or whatever else is allowed) in an RFC, but that's not ISO/IEC JTC1/SC22's business.

So the question here is whether (and if so how) to assist ISO/IEC JTC1/SC22 or not.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: 01 May 2014 00:49
To: IAB; IETF Announce
Cc: IETF
Subject: Re: Call for volunteers for C/C++ API liaison manager

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

> We often see proposals for APIs (most commonly C APIs) discussed in

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 1 May 2014 16:31:48 +0000

For example to see what the thinking is, look at any of the working papers from the Networking Subgroup
on http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/
or http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/

(Looking myself, they've not got far.)

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
Sent: 01 May 2014 17:19
To: Joe Touch; IAB; IETF Announce
Cc: IETF
Subject: RE: Call for volunteers for C/C++ API liaison manager

--
Christopher Dearlove
Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124 [email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: 01 May 2014 00:49
To: IAB; IETF Announce
Cc: IETF
Subject: Re: Call for volunteers for C/C++ API liaison manager

Joe

********************************************************************
This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
********************************************************************

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 May 2014 09:49:20 -0700

On 5/1/2014 8:26 AM, Thomas Nadeau wrote:
> That depends on your perspective. These days the code IS the API, in
> particular open source code. Standards bodies do not need to define the
> APIs; implementation communities do that already. The IETF should
> probably stick to on-the-wire protocols.

A protocol is defined by:

	- internal state
	- message "on the wire" formats
	- upper layer events
	- lower layer events (message arrivals/departures)
	- time events

Leave any of the 6 above out and you have an incomplete spec.

The "on the wire" part is only a fraction of what's needed. If you don't 
believe that, then write a TCP implementation from the header format 
alone, and let's see how well it works.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 May 2014 09:51:52 -0700

>      - lower layer events (message arrivals/departures)

	- rules to relate the above
		(e.g., like a Mealy machine spec.)

> Leave any of the 6 above out and you have an incomplete spec.

(and an email typo ;-)

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 1 May 2014 13:33:13 -0400

On May 1, 2014:12:49 PM, at 12:49 PM, Joe Touch <[email-masked]> wrote:

> The "on the wire" part is only a fraction of what's needed. If you don't believe that, then write a TCP implementation from the header format alone, and let's see how well it works.

	Why do any of those things need a standards-based API to program to?

	--Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 May 2014 10:38:06 -0700

> 	Why do any of those things need a standards-based API to program to?

The API is the upper-layer events. Without that, you can't define the 
semantics of the interaction with the upper layer.

FWIW, I'm talking about IETF standard API, not Unix-standard or 
C-standard. The latter are required to ensure implementation 
compatibility, but can't be defined without the former.

Joe

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 1 May 2014 13:40:44 -0400

On May 1, 2014:1:38 PM, at 1:38 PM, Joe Touch <[email-masked]> wrote:

> The API is the upper-layer events. Without that, you can't define the semantics of the interaction with the upper layer.
> 
> FWIW, I'm talking about IETF standard API, not Unix-standard or C-standard. The latter are required to ensure implementation compatibility, but can't be defined without the former.

	I guess we will have to agree to disagree.  I just don't see why that is going to be useful to anyone.  If you were talking about open source and/or reference implementations that the source was available for, then that makes far more sense to me.

	--Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 May 2014 10:46:10 -0700

On 5/1/2014 10:40 AM, Thomas Nadeau wrote:
...
> 	I guess we will have to agree to disagree.  I just don't see why that is going to be useful to anyone.

Let me know if you think you can implement TCP without knowing about 
CONNECT, LISTEN, etc. (as per RFC793).

When the protocol API isn't not spec'd in the protocol, we end up 
needing to infer the protocol API from the implementation of that API* - 
which is what gets us into trouble with so many of the protocols we've 
spec'd since.

Joe

* a reference implementation is a declaration of that fact (no need to 
infer it) - often explicitly saying "where the code and spec disagree, 
the code is correct" --- which means the spec text is useless, and the 
code *is* the spec.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 May 2014 13:49:45 -0400

> 	I guess we will have to agree to disagree.  I just don't see why that is going to be useful to anyone.  If you were talking about open source and/or reference implementations that the source was a…

It's useful because it enumerates the set of things that a concrete API has to provide, which makes doing the concrete API easier, avoids omissions in the concrete API, and helps to prevent situations where the language bindings for one language are preferable to the bindings for another, and wind up driving the choice of language.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 2 May 2014 09:32:00 +0200

On Wed, Apr 30, 2014 at 11:05:35PM -0400,
 Hector Santos <[email-masked]> wrote 
 a message of 25 lines which said:

> Its a difficult task to manage a multiple language API for examples
> of IETF protocols.  But it can be done.

I'm highly skeptical. For me, an API is always language-specific
because programming langauges are simply too different (typical
examples: parallel languages where concurrency is built-in
vs. programming languages where you need asynchronicity and callbacks,
programming languages with exceptions vs. programming languages with
return codes,etc).

In my experience, so called "high-level" API are not high-level at
all, they always assume a specific programming style, typically the
one of the language the author prefers.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 02 May 2014 14:12:33 +0200

On Thu 01/May/2014 04:36:49 +0200 Melinda Shore wrote:
> 
> 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.

+1.  But I don't think the call refers to "language standards".  C and
C++, in particular, don't standardize such fundamental features as
multithreading.  Although it mentioned WG14 and WG21, the IAB call
didn't say ISO/IEC JTC1/SC22 also participates in the Single Unix
Specification, which would seem a more appropriate place for Internet
related APIs.

Ale

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 May 2014 08:52:59 -0400

> one of the language the author prefers.

The point is not to describe in detail the entry points to an API, but rather to describe the minimum functionality that an API should provide in order to allow the language and programs written in it to fully exploit the protocol.   In MIF we talk about the low-level API and the high-level API; the low-level API is just a list of functions the API has to provide; the high-level API is built on that, and is likely language-specific.   You can't build the language-specific API from just the abstract low-level API—you need to understand the locking/threading behavior of your language, and the memory allocation strategy, and so on.

---

From: Dave Cridland <[email-masked]>
Date: Sun, 4 May 2014 09:41:58 +0100

On 2 May 2014 13:12, Alessandro Vesely <[email-masked]> wrote:

> multithreading.

C++11 has multithreading in both the model and the standard library - I
suspect you may well be a few years out of date.

Dave.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 7 May 2014 09:43:27 +0000

C++ has now standardised multithreading, from the 2011 C++ standard (C++11).

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Alessandro Vesely
Sent: 02 May 2014 13:13
To: [email-masked]
Cc: IAB
Subject: Re: Call for volunteers for C/C++ API liaison manager

On Thu 01/May/2014 04:36:49 +0200 Melinda Shore wrote:
> 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.

+1.  But I don't think the call refers to "language standards".  C and
C++, in particular, don't standardize such fundamental features as
multithreading.  Although it mentioned WG14 and WG21, the IAB call didn't say ISO/IEC JTC1/SC22 also participates in the Single Unix Specification, which would seem a more appropriate place for Internet related APIs.

Ale

---

From: Doug Royer <[email-masked]>
Date: Thu, 08 May 2014 16:00:59 -0600

On 05/01/2014 11:40 AM, Thomas Nadeau wrote:
> I guess we will have to agree to disagree. I just don't see why that 
> is going to be useful to anyone. If you were talking about open source 
> and/or reference implementations that the source was available for, 
> then that makes far more sense to me. --Tom 

With some protocols (thinking iCal) the implementors can produce 
incomparable objects. An API can clarify the object model (Oh this is 
how you use it), simplify application development (I do not have to 
spend time making sure I invent an API that will work with all of these 
object permutations and across vendors and vendor objects),

Look at IMAP, almost everyone started with or at least looked at the 
Mark Crispin code from UofW. If your core business model is making code 
that someone else has already defined, good luck making much money. A 
predefined API allows companies to adopt a protocol and stay focused on 
their core business model.

A working group hashed out API would always be a better starting point 
than alone and in a closet code that sucks cash from a company that 
really wants to produce a product.

And I also think that it would be nice if people would create open 
source code that was reviewed by a working group and referenced or 
hosted by the IETF.

VoIP is another example. It would save a lot of time if I knew I could 
use a thought out API, even if I had to implement the code.

Protocol without API == minimum.
API with out code == useful.
API with code == ideal.

-- 

Doug Royer - (K7DMR.us / DougRoyer.com)
[email-masked]
714-989-6135