--On Wednesday, April 30, 2014 16:48 -0700 Joe Touch
<touch(_at_)isi(_dot_)edu> wrote:
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 (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