Re: Application "core protocol" BOF/WG idea

I think a key question here is how to determine what the requirements are.  You've enunciated a "newness test" for features.  I suspect you don't mean to say that the requirements are "every feature that isn't 'new'".  What we've seen so far is a proposed list of "problems to solve"; on what basis should we argue for a problem to be included or excluded from this list?

I'm skeptical that the given list can really be addressed in 25 pages or less.  For example, ONC RPC (RFCs 1831 and 1832) addresses just about exactly a subset of your proposed problems, isn't very complex, and the two RFCs add up to more than 25 pages.

I also have a couple of things to say about your response to Carl-Uno's question of why ONC RPC didn't succeed.  You wrote: [[
My speculation, which I can't back up with research, is that RPC
mechanisms are a poor choice in general for standards-based protocols.
It's much harder to design an extensible and simple API than it is to
design an extensible and simple wire protocol.  In addition, APIs by their
nature tend to have significant biases in the direction of programming
language or operating system.  Finally, RPCs are designed to "hide" the
network -- I think the network and network latency in particular needs to
be explicitly factored into the design at several levels.  Non-RPC
protocols tend to force that to happen in practice.
]]

I think it's critical to not confuse API design with wire protocol design.  HTTP/1.1, for example, *is* a request-response (i.e., RPC) protocol; it is also a wire protocol (I'm not sure I'd be willing to call it "simple", given that its spec is way over 25 pages).  API design brings in an additional set of problems, which the IETF has traditionally (though not completely --- witness GSS API) avoided.  For example, when I think about this kind of effort, I wonder about things like how to enable flexible mappings into programming languages for the standard data type system of the protocol (experience shows that a single standard mapping will not well serve all apps); I think the right solution is to have a flexible mapping mechanism, which is not a wire protocol problem (although presumption of such a thing may lessen requirements on the wire protocol).

I do think one thing that has hampered adoption of existing general-purpose solutions is their monolithicity (inusually in both spec and implementation; while people do sometimes write subset implementations from scratch, that's a lot of work and sorely tempts the implementor to specialize the protocol).  I think that what we really need is a radically modularized standard protocol (in both spec *and* implementation), so that an application layered over it can get just what it needs and pay for no more.

Mike

Received on Tuesday, 2 February 1999 12:48:25 UTC