Re: Application "core protocol" BOF/WG idea

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.  For example,
> "stateful" excludes HTTP and any reasonable transfer protocol for
> the Web.

  There're two basic issues which every application protocol has had to
deal with: the set of actions, and how those actions are represented on
the wire.  On top of that, there's some overlap -- not a lot, but some --
in the set of actions that application protocols support; you need to have
a way to negotiate extensions and security, for example. 

  I would argue that there's some utility in providing a common encoding
and a set of basic commands which application protocols appear to have in
common; this is really the drudgework of designing an applications
protocol, and we *know* how to do it well. 

  Applications could then simply define their specific commands on top of
the basic set and standard encoding, and people could argue about the
interesting things, such as whether the protocol should be stateful or
stateless, or whether it should be a store and forward model, instead of
arguing over whether it should be based on HTTP's syntax or LDAP's syntax
or IMAP's syntax, which to my mind is a fairly boring issue best put aside
as quickly as possible.

  (It's akin to arguing over the transport layer; sure, you can always
design a better one, but TCP's honestly good enough and is relatively kind
to a network, and I'm really glad that everything's based on top of TCP
instead of having each applications protocol specify its own, wildly
different way of getting its messages to where they're supposed to go.)

  )Rob

Received on Tuesday, 2 February 1999 08:30:19 UTC