What we are really talking about here is 1) Defining the boundary between one layer and another 2) Specifying a means of reifying that boundary as something that is concrete of which the most familiar form is an API
We discuss APIs all the time in IETF. Some examples: "We can't use X because Javascript does not expose that to the application" "We can't do Y because CryptoLibs don't show that to applications" "We can't move from IPv4 to IPv6 as applications use gethostbyname (x) to do everything" The limitations of the BSD sockets library have affected (nay controlled!) application protocol design for decades. Having the API do too little can make things worse, not better. The current networking API for networks requires applications to be really very aware of whether their transport layer is * IPv4 or IPv6 * Layered over raw TCP, SSL or IPSEC * Uses A record, SRV or URI discovery All of which are things that in my view the application should not care about at all. A pipe is a pipe and the application should be able to abstract above the specific type of pipe. The application MAY care about the trust properties of a pipe but should not be required to care about the precise details of how those trust properties are achieved. Web IDL might be a way to go here. It does at least permit the use of tools and it avoids the risk of a discussion of what the best language to use for specifying an API is. The downside is that people would need the tools for their specific languages. But that is probably not very difficult to write. I have for years written that type of stuff for mapping abstract protocols to XML schema rather than have to re-write a spec every time people come up with a new way to use XML to address the problem. Whatever we go with should be object oriented for specifying interfaces to the application layer and should not be object oriented for lower layers. Modern programming approaches are now object oriented, or at least use inheritance and encapsulation and a number of properties that we have agreed to call object oriented. Even scripting languages tend to have objectish features. At the lower layers, objectish features are probably a bad idea, just like regular expressions and recursive structures and many other powerful tools that are a little too powerful.
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
