W3C home > Mailing lists > Public > ietf-discuss@w3.org > November 2001

Re: Requirements for reliable message delivery

From: Jim Gettys <jg@pa.dec.com>
Date: Wed, 28 Nov 2001 10:31:31 -0800 (PST)
Message-Id: <200111281831.fASIVVw458609@pachyderm.pa.dec.com>
To: "Marshall T. Rose" <mrose+mtr.netnews@dbc.mtview.ca.us>
Cc: Jim Gettys <jg@pa.dec.com>, Discuss Apps <discuss@apps.ietf.org>, Marshall Rose <mrose@dbc.mtview.ca.us>

> From: "Marshall T. Rose" <mrose+mtr.netnews@dbc.mtview.ca.us>
> Date: Wed, 28 Nov 2001 08:59:05 -0800
> To: "Jim Gettys" <jg@pa.dec.com>
> Cc: "Discuss Apps" <discuss@apps.ietf.org>,
>         "Marshall Rose" <mrose@dbc.mtview.ca.us>
> Subject: Re: Requirements for reliable message delivery
> -----
> > The issue is really that the number of people who have designed protocols
> > for even a large class of applications (e.g. Bob Scheifler's and my
> > development of the X protocol), who are involved in the IETF is very low.
> > For whatever reasons, the development of these general (or domain wide)
> > protocols go on elsewhere.
> i'm wondering if terminology isn't part of the problem here. e.g., i think
> of X as being a protocol that supports one application, windowing, just like
> i think of SMTP as being a protocol that supports one application,
> messaging. how you choose to use the application protocol (e.g., biff, wm,
> etc., vs. stock quotes, love letters, etc.) is up to you, but isn't it all
> the same "application" as far as the network is concerned?

You didn't have to rail against people who wanted to use X as a general 
purpose RPC system, as we did, for example; I can relate other similar 
apparently braindead conversations I have had.  The arguments are AMAZINGLY 
reminicent of what has happened with HTTP, except that we won the arguments, 
and persuaded people to (mostly) go elsewhere.  

Now I wonder if that was the right thing to have done, as the base X protocol 
structural framework is so much simpler than HTTP, it isn't funny.

Firewalls, and the need for some level of security/authentication have 
exacerbated the problem of trying to get people to go elsewhere.

Thousands of graphics apps have been built on top of X: the point being,
for the domain of graphics, one protocol was designed to support (almost)
all comers, and we succeeded at that up until about 1993.  Keith Packard
and I are conspiring to try to update X again to get back to that level
of universality (X, right now, does not include translucent windows,
which it needs, and a few other items, though Keith's recent work has
added antialised text and graphics with alpha blending, based on and
extending beyond Rob Pike's Plan 9 work).

> > We are again observing this with XML/RPC,
> > SOAP, etc.  In fact, there seems to be some hostility toward these classes
> > of protocols expressed by some of the IETF participants, along with
> > some fundamental misunderstandings of requirements of application
> protocols
> > by some truly talented IETF old-timers.

I'll relate a conversation I had with Radia Perlman, who asserted,
until I explained many apps dynamically generate data, that a simple
"type, length, value" binary protocol would be more than sufficient
for anyone's application's need...  I respect Radia (don't always agree
with her), but it came as a "aha" to her when I explained it to her.

> i think the problem is when you juxtapose "application" with "protocol".
> things like xml/rpc are far more interested in the "application" side than
> the "protocol" side. and that's just fine, until you put a network inside
> the application, at that point, you really wish that someone had done
> something about security instead of just figuring that http would take care
> of it.

You won't get much/any argument from me.  But that is the perception people 
have.  And by the IETF's unwillingness to understand application's real 
needs, we will continue to get protocol frameworks that are designed by 
people who do understand what they need to build applications in their 
domain, and short-shrift the transport and security considerations that 
ought to be built in.

> > Unless/until this changes, I don't see the IETF venue being useful beyond
> > formal standardization of such a protocol framework "after the fact",
> > as in what happened with HTTP.
> > ...
> sometimes it's a bad idea to get involved with a "race to the bottom", and
> sometimes the IETF just does take a pass on things...

And you end up with HTTP, as a result....  It is about as low as you can
get, being a kludge on top of MIME, on top of RFC 822, on top of....
Time for a different protocol framework, IMHO.  But right now, the IETF
lacks the expertise, and has been unfriendly to the application community.

So, by inaction, the IETF is likely condemned to the kludge tower growing
ever higher....  Someday it will fall over.  Or maybe it is job security
for us all??? :-)
                             - Jim

Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation
Received on Wednesday, 28 November 2001 13:32:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:01 UTC