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.
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. As an
example, when we worked on TLS channel bindings to other protocols, we
realized that not all TLS implementations provided access to the
information we need to construct these channel bindings.
Especially as people are trying to build IETF technologies into
platforms, it would be strongly desirable to specify what interfaces
applications can depend on.
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.
When we do not, specifying abstract interfaces we expect platforms to
provide still has significant value.
That, rather than APIs instead of protocols, is what I advocate.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf