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