Would we not be better off just asking (mandating?) at least one open source implementation? That effort would produce a de facto API. 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