RE: Application "core protocol" BOF/WG idea

Amen.

> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@ics.uci.edu]
> Sent: Thursday, February 04, 1999 12:52 PM
> To: discuss@apps.ietf.org
> Cc: Chris.Newman@INNOSOFT.COM
> Subject: 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 18:29:33 UTC