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

"Dearlove, Christopher (UK)" <> Thu, 01 May 2014 16:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6F6E71A08FE; Thu, 1 May 2014 09:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.103
X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wfYkH654qqUP; Thu, 1 May 2014 09:18:50 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id EEFA31A6F82; Thu, 1 May 2014 09:18:46 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,966,1389744000"; d="scan'208";a="436503565"
Received: from unknown (HELO ([]) by with ESMTP; 01 May 2014 17:18:43 +0100
X-IronPort-AV: E=Sophos;i="4.97,966,1389744000"; d="scan'208";a="50097118"
Received: from ([]) by with ESMTP; 01 May 2014 17:18:43 +0100
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Thu, 1 May 2014 17:18:42 +0100
From: "Dearlove, Christopher (UK)" <>
To: Joe Touch <>, IAB <>, IETF Announce <>
Subject: RE: Call for volunteers for C/C++ API liaison manager
Thread-Topic: Call for volunteers for C/C++ API liaison manager
Thread-Index: AQHPZIfzYYGqauuQQUuAqlgiZmLEnJsqw56AgAEiVHA=
Date: Thu, 1 May 2014 16:18:42 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Cc: IETF <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 May 2014 16:18:51 -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 |

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 [] On Behalf Of Joe Touch
Sent: 01 May 2014 00:49
To: IAB; IETF Announce
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.

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).


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.