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

John C Klensin <john-ietf@jck.com> Thu, 01 May 2014 13:43 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7AE1A8912; Thu, 1 May 2014 06:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Level:
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kr1_OnfG8dK; Thu, 1 May 2014 06:43:05 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id DC4171A6F8B; Thu, 1 May 2014 06:43:04 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WfrGP-000DTA-V5; Thu, 01 May 2014 09:43:01 -0400
Date: Thu, 01 May 2014 09:42:56 -0400
From: John C Klensin <john-ietf@jck.com>
To: Joe Touch <touch@isi.edu>, IAB <iab@iab.org>, IETF Announce <ietf-announce@ietf.org>
Subject: Re: Call for volunteers for C/C++ API liaison manager
Message-ID: <38DA024A43FD1B03BC8FFC42@JcK-HP8200.jck.com>
In-Reply-To: <53618BDD.1080900@isi.edu>
References: <EB423B81-41F2-480D-B1EE-80E1753E1CDB@iab.org> <53618BDD.1080900@isi.edu>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/pBeFagZ5tVpbx-l5u_m8ClZkZD0
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 May 2014 13:43:07 -0000

--On Wednesday, April 30, 2014 16:48 -0700 Joe Touch
<touch@isi.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