Re: Application "core protocol" BOF/WG idea

On Mon, 1 Feb 1999, Graham Klyne wrote:
> At 12:20 29/01/99 -0800, Chris Newman wrote:
> >On Fri, 29 Jan 1999, Graham Klyne wrote:
> >> Specifically, I find the idea that we can "design a simple core protocol to
> >> address these problems" is something of a tall order.
> >
> >You may be right.  But what if we can?  Just because it might be hard does
> >that mean we shouldn't try?
> 
> I wouldn't say we shouldn't try "just because...".  (I might argue that
> given a choice between useful goals, I'd pick one more likely to succeed.)

We have solved most of the "core" protocol problem every time we've
designed a new application protocol.  Having a generalized "core protocol" 
which was popular would greatly simplify the design of new protocols and
multi-protocol software as well as providing a viable alternative to
abusing existing protocols.  That justifies trying in my book.

> For me, this begs the question:  what are the characteristics of these
> "enough protocols" for which such a framework is maybe "of sufficient
> utility"?  You have already enunciated part of the answer I was seeking:
> "based on the connection-based stateful client-server structure ..."

What protocol facilities are common to most of FTP, HTTP, IMAP, LDAP,
NNTP, POP, SMTP/ESMTP, Telnet and our other successful protocols?  And I
won't answer because I think that's a question the proposed WG should
answer as part of the first draft.

> In my view, this could be seen as a small number of separate work items:
> 
> (a) a small core protocol document could cover (2)-(5).
> 
> (b) A separate document could cover the basic initiation and authentication
> framework, associated server states, request verbs, response codes, etc.
> 
> (c) A guidelines document could describe how to build application protocols
> using (a) and (b), together with other considerations that should be
> addressed by a protocol specification.  (I think this could usefully draw
> upon your -protocol-design- document.)

It could be seen that way.  But why break a 25 page spec into three 15
page specs?  It'd be more useful to have a single "core protocol" document
to reference, even if it's internally structured into the three parts you
suggest.

> In practice, I don't think a core-protocol plus application-specification
> would be a complete application protocol definition.  References to other
> components (e.g. MIME, TLS, SASL, RFC1893, S/MIME, etc.) would, I think, be
> the norm.

The proposed charter certainly permits this.

> I would still like to see
> some separation of concepts in the core components, as indicated above, but
> not fragmentation.

If you think there's something wrong with the proposed charter, please
suggest alternative wording.

> In preparation for undertaking such a design, I do think it would be
> helpful to enumerate some commonly-used current application protocols and
> note their strengths and weaknesses in practical deployment.

That's the point of the first draft described in the proposed charter.

> I also think
> that work from other groups like the HTTP NG effort should be examined for
> suitability before embarking on yet another protocol design effort.

If I end up as chair or co-chair of this effort, I would go to other
groups to get candidate solutions.  A subset of the HTTP NG work might be
a candidate solution if they're far enough along.  The DIAMETER core
protocol is also close to a candidate solution, as is the Earhart draft.
The problem is that each of these efforts is only illuminated by a small
subset of the operational experience we have collectively with application
protocol "cores."

		- Chris

Received on Monday, 1 February 1999 16:19:21 UTC