Re: Application "core protocol" BOF/WG idea

On Tue, 2 Feb 1999 spreitze@parc.xerox.com wrote:
> 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?

We're looking for problems that have to be solved in many or most
application protocols.  Furthermore, in order to keep such an effort from
spinning off into a research project, it has to be restricted to only
addressing the problems we're familiar with in the initial core document.
Once the core is done, perhaps people will make reusable pieces that can
be layered on top of it, just as people have made a few reusable pieces
that can be layered on TCP (e.g. TLS) -- but a WG has to be narrowly
focused and driven to succeed.

> 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. 

XDR isn't a bad binary data encoding for the wire (certainly better than
ASN.1 BER), but it solves problems (like floating point numbers) which
almost never appear in real protocols.  The RPC spec had to go into a lot
of detail about the model since RPCs are more constraining than
traditional IETF protocols.  So there's a lot of stuff there that a "core
protocol" wouldn't need. 

It may not be possible to do a "core protocol" in under 25 pages, but it's
certainly a goal worth striving for and the proposed charter is worded so
the WG could change the simplicity litmus test by rough concensus as long
as it has one.

> 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. 

Precisely.  I'd clarify that by noting I'd prefer one "front end" spec
which would gather components from others (e.g. SASL, TLS) into a coherent
core protocol. 

		- Chris

Received on Thursday, 4 February 1999 14:08:58 UTC