- From: Chris Newman <Chris.Newman@innosoft.com>
- Date: Thu, 04 Feb 1999 10:28:18 -0800 (PST)
- To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
- Cc: discuss@apps.ietf.org
On Mon, 1 Feb 1999, Roy T. Fielding wrote: > It has been my experience that an application protocol must match > the interaction style of the application components. Otherwise, it will > fail to meet the minimal performance requirements of that application > and be replaced by an application protocol that does. It's not uncommon in the IETF to hear similar mantras. Every protocol needs it's own custom framework. Every protocol needs it's own custom security protocols. Perhaps we should encourage every protocol to use something other than TCP since TCP isn't a perfect fit for most protocols? Then you hear the flip side -- people who want to layer everything on top of HTTP because there's too much work to do if you start with raw TCP and they want to reuse code. There is an eternal tension between "everything has to be perfectly designed for the task from the ground-up" and "let's reuse as much of what's out there as possible regardless of how well it fits." Building apps on TCP is a bit too far in the former direction for today's environment and building apps on HTTP is much too far in the latter direction. We need to achieve a better balance. > 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. Obviously an adaptable modular core would be more useful than a very restrictive core. But that's not a justification to avoid the problem. > If that is too > large a scope, then the "common core" being developed must be limited > to a single interaction style. Besides, if you are going to limit the > core to things occurring in two or more successful IETF protocols, then > the only application being supported is store-and-forward messaging. > I think a "store-and-forward core" is far more likely to be usable by > future protocols than a general application core that only considers > a subset of applications. Although SMTP is used to create a store-and-forward messaging model, it looks very similar in protocol structure to FTP and POP3 both of which use a direct client-server command-response model. The "core" is intended to capture common protocol structure and provide a foundation for new application protocols, not to provide high-level application services like store-and-forward messaging, web browsing or the like. - Chris
Received on Thursday, 4 February 1999 13:36:18 UTC