On 03/29/2011 01:28 PM, Eric Burger wrote:
Would we not be better off just asking (mandating?) at least one open source implementation? That effort would produce a de facto API.
What you need is a reference implementation (i.e. an inefficient but complete
implementation, with a license that permits at least to see the source and
generate a binary) AND a test suite.
On Mar 29, 2011, at 11:17 AM, Sam Hartman wrote:
"Dave" == Dave CROCKER<dhc2@xxxxxxxxxxxx> 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
discuss.
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
application.
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
applications.
Dave> ...
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,
Dave> C++, Javascript, Java, Python, ...?
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
developed later.
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
standardization.
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.
--Sam
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
--
Marc Petit-Huguenin
Personal email: marc@xxxxxxxxxxxxxxxxxx
Professional email: petithug@xxxxxxx
Blog: http://blog.marc.petit-huguenin.org
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf