On Mar 29, 2011, at 1:28 PM, Eric Burger <eburger-l@xxxxxxxxxxxxxxxxxx> wrote: > 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. Chris. > 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf