Re: IETF and APIs
On Mar 29, 2011, at 1:28 PM, Eric Burger
Would we not be better off just asking (mandating?) at least one open source
implementation? That effort would produce a de facto API.
To co-opt wording from another thread, I think you are conflating an (even de
facto) API with an application. I've seen many applications that implement
protocols without clearly delineating an interface to the protocol as anything
approaching an API. Even if there is a de facto API, it is often unusable
unless it was designed as an API fr the ground up and didn't simply grow out of
the need to abstract the protocol from the application during development.
On Mar 29, 2011, at 11:17 AM, Sam Hartman wrote:
"Dave" == Dave CROCKER <dhc2(_at_)dcrocker(_dot_)net> writes:
Dave> On 3/29/2011 10:13 AM, Sam Hartman wrote:
At the mic at the technical plenary last night, I made a comment that
I strongly supported the IETF doing API work.
I've realized that people may have assumed I meant that it would
be appropriate for the IETF to specify an API and not a protocol
for some given task.
That's not what I meant, so I am writing to clarify.
I think that multiple levels of interoperability will be required
for building blocks used in platforms including the web platform.
Dave> "Multiple levels of interoperability" sounds interesting, and
Dave> very possibly quite important.
One level is the traditional protocol interoperability we normally
Another level shows up when you want to write a cross-platform
application. It's not good enough if Windows has some API. I want to
have confidence that functionality is available on Windows, OSX, Linux
and some of the mobile platforms before I depend on that functionality
in a cross-platform API.
Within the web platform, I want to make sure functionality is available
on multiple browsers before I depend on it in my cross-browser
we're the IETF. We should definitely specify protocols for the
building blocks we create.
However, one problem that hurts interoperability is when
platforms provide different APIs or abstract interfaces to
I think that we should move more into that business. I see no
problem with actually specifying a language-specific API when the
WG involved has the skills to do a good job.
Dave> Wow. What is the list of languages we should work on? C,
Any of the above when it makes sense for a WG to do the work.
I'd expect that typically you'd only specify one or two language
bindings for a given interface.
You should have a need to do the work, have the necessary skills to have
probable success, have the necessary skills to get review and have
people volunteer to do the work.
Dave> Which is not to deny the problem you cite: APIs differ and
Dave> this hurts interoperability.
Dave> One approach to solving it is, indeed, to specify /all/ of the
Dave> APIs that map to the protocol.
Dave> Another is to do more and better interoperability testing and
Dave> let the API developers see their deficiencies and fix them.
Dave> The benefit of this is that it moves the problem to the folks
Dave> with the knowledge and incentives to work on it and it takes
Dave> this very expensive specification task out of the IETF's
Dave> critical path.
My experience is that protocol interoperability testing does not
actually lead to cross-platform interoperability. This is especially
true for building blocks intended to be used by components that are
The issue is that the people doing interoperability testing at the
protocol layer don't tend to be testing for whether things work the same
way between platforms.
It is when you try and build something on top of a building block that
you notice the problem.
You tend to notice at one of two layers.
The first is if you standardize the higher level item and have
participants familiar with multiple platforms involved in the
You can then discover that you don't have sufficient overlapping
functionality on platforms to do what you want.
Another case where you discover the problem is when you implement and
people discover that they cannot do so.
Factors that contribute to cross-platform interoperability issues
include the following. Often, the people designing and implementing the
building block are not the same as the people using the building
block. Often, there is separation in time between building block design
and building block usage. Often, various factors complicate changing the
platform to expose new functionality.
In conclusion, in cases where these types of issues are likely to be
important, I believe we should do work. Work can include work on
abstract interfaces, which will be easier to justify. Work can include
concrete APIs which will sometimes be appropriate. I would prefer that
this work be standards track not information. Discussions of how to
advance MIBs, GSS-API and other standards-track elements already give us
approaches to judge interoperability for such elements.
Ietf mailing list
Ietf mailing list
Ietf mailing list