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.) -- 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 chris.dearlove@xxxxxxxxxxxxxx | 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:ietf-bounces@xxxxxxxx] 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 ----------------------! 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. -------------------------------------------------------- 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 chris.dearlove@xxxxxxxxxxxxxx | 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:ietf-bounces@xxxxxxxx] 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. -------------------------------------------------------- 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 ******************************************************************** 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. ********************************************************************