Re: Application "core protocol" BOF/WG idea

On Thu, 4 Feb 1999, Jim Whitehead wrote:
> I agree with this (whoa, I'll bet Roy is surprised :-)  Right away, the
> APPLCORE protocol needs to decide whether it will be a set of protocol
> components for a client to server protocol, or a server to server protocol.

SMTP is both a client->server and a server->server protocol.  The only
distinction in protocol structure I see between client->server and
server->server is that the two are likely to have different security
mechanism requirements (mutual authentication is more important for the
server->server).  But since most IETF protocols are client->server, that's
the direction I'd be biased.

> This design choice has many repercussions, and cannot easily be abstracted
> away.  Similarly, already APPLCORE seems to be biased in favor of a stateful
> protocol.

I'm biased in the direction of stateful protocols; APPLCORE is not (it's
not even an approved BOF yet :-). This may not even be an issue for a core
protocol, except with respect to stateful security services like TLS and
SASL.

> But, since a useful protocol can't be developed without making *some* design
> choices, and since those design choices will not be applicable to all future
> domains of use, perhaps developing a *protocol* as a deliverable is the
> wrong way to achieve the APPLCORE goals.

A core protocol would have structure but no direct operations (with the
possible exception of NOOP :-).  Where design choices are necessary, the
proposed charter would constrain the group to go only in directions that
at least two past successful IETF protocols have gone but otherwise those
design choices would be up to the proposed WG.  Now is not the right time
to discuss design choices at that level.

> A collection of design patterns will speed the development of new protocols,
> since a protocol which makes use of a pattern won't need to repeat all of
> the rationale for the design choice, and will be able to more easily benefit
> at design time from existing protocol experience.  Thus it seems to me that
> a collection of application protocol design patterns can achieve the goals
> of an APPLCORE protocol without needing to create a protocol which will be
> inappropriate for some use cases.  The design patterns approach has much
> broader applicability than just a single protocol.

Perhaps we should have never built TCP, but instead built a bunch of
design patterns for doing retransmission, sequencing and reliability for
raw packets?  It would certainly be more flexible.  But having TCP as a
fixed point in the protocol stack is extremely helpful and leads to a lot
of code reuse.  There are even applications where TCP is far from perfect,
but it's good enough that it's not worth developing a new transport layer. 

If programming cycles were free, your proposal would be superior to mine. 
But what's driving people to abuse existing protocols rather than
carefully design new ones is code reuse.  That has to be factored into the
proposed WGs output.  The goal is to do all the boring gruntwork core
protocol stuff one last time so future protocol designers have the option
of skipping it and there's a code reuse benefit.  It may not fit everyone,
but neither does TCP.

> * An Informational RFC which provides a collection of application protocol
> design patterns, where each design pattern distills the successful solutions
> of application protocols for each entry in the problem identification
> document.  While specific examples from individual protocols will provide
> rationale for the design pattern, each pattern will described in a
> protocol-neutral manner.  The goal of this document is to capture the design
> rationale and solutions for common problems encountered by application layer
> protocols so these "lessons learned" can quickly be applied to the design of
> new protocols.

I predict nobody would work on this sort of document, unless there is some
tangible benefit beyond helping future protocol designers.

To put it bluntly, I'm willing to be the masochist who edits the
"history/problem identification" (or "design patterns" if you prefer)
document only under the condition that the charter permits the group to
create a simple core protocol proposal.  That way, I'd have a good chance
of getting a code reuse benefit in the future.

		- Chris

Received on Thursday, 4 February 1999 19:00:01 UTC