Re: Application "core protocol" BOF/WG idea

Roy Fielding wrote:
> I think that it won't be useful to come up with a "core" application
> protocol unless those core components can adapt according to multiple
> interaction styles and multiple underlying transports.  If that is too
> large a scope, then the "common core" being developed must be limited
> to a single interaction style.

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.
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.  How do you resolve the stateful vs. stateless argument without
the problem domain supplying design descriminators?  Or, perhaps as Roy
suggests, the protocol needs to be usable with multiple interaction styles.

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.

The proposed charter states:
> An Informational RFC documenting the problems identified to solve,
> and giving examples of existing deployed IETF protocols which
> succeeded or made mistakes when solving those problems.  A starting
> list of problems for the WG to discuss (the WG may choose not to
> address some of these) follows:

I support this deliverable, since it will provide a useful overview of the
common applications protocol design space.  Although, instead of calling it
the "problem identification" draft, why not call this the "design space"
draft, since it will essentially be sketching the commonly occurring
elements of the application protocol design space.

> A standards track core application protocol specification which uses
> the lessons learned from the informational document and fits the
> litmus test above.  An open source implementation of the complete
> core protocol must exist prior to IETF last call.  The problem
> identification draft (above) must be completed prior to IETF last
> call.

I think that developing one "core" protocol is the wrong approach.

If the intent is to save time in the development of future protocols, a
useful output would be a collection of application protocol *design
patterns* (note that I'm using design patterns in a more general sense that
the typical, heavily tied to object-methodology religion sense.  Substitute
the term "design discussion" if you wish, it's synonymous in my discussion).
These patterns can capture how a given problem has been commonly solved,
giving rationale both for and against the given solution.  A collection of
application protocol design patterns would have the benefit of being easily
applied to a wide range of new protocol designs, yet wouldn't have the
drawback of the APPLCORE of having embedded design decisions (and there will
be implicit design decisions no matter how hard people think they're
avoiding them) which are inappropriate for a given domain of use.
Furthermore, the design patterns will have a focus on design rationale,
rather than creating a protocol where the design rationale is implicit in
the protocol elements (and 25 pages doesn't leave much room for design
rationale).

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.

My recommendation is to replace the "core application protocol
specification" deliverable with this:

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

Why?

- Because design patterns focus on design rationale, not on syntax
- Because design patterns have applicability to more domains of use than a
single protocol
- Because design patterns expose design tradeoffs, rather than hiding them
behind a single normative choice

- Jim

Received on Thursday, 4 February 1999 16:15:08 UTC