Re: FW: LC Comments: Web Method Feature

On Mon, 2002-07-08 at 18:52, Paul Prescod wrote:
> Gavin Thomas Nicol wrote:
> > 
> > On Friday 05 July 2002 11:15 pm, Amelia A. Lewis wrote:
> > > Keep in mind, too, that ten and fifteen years ago there were vocal
> > > opponents of ftp-to-email gateways and of MIME.  "SMTP is a *message*
> > > protocol.  If you want to transfer files, use a *file* *transfer* protocol.
> > > "  The glorification of HTTP as the highest possible layer in the stack
> > > seems to reflect those attitudes.
> > 
> > Funny.... I used the gatekeeper ftp to email gateway to very good effect to
> > circumvent firewall limitations 10 years ago. I never thought of that as
> > equivalent to SOAP over HTTP before. I can see the analogy though.
> The only reason there even existed a concept of an FTP to SMTP gateway
> fifteen years ago was because FTP and SMTP used different addressing
> models and different method names/semantics. If those were unified into


FTP and SMTP have dramatically different semantics: synchronous versus
asynchronous, "push" versus "pull" (much as I dislike that distinction).

SMTP was used for retrieval of file data because that could get the
files "through the firewall," where "firewall" meant a network segment
not able to support FTP data transfers, for some reason (for instance, a
non-IP segment, or a segment that wasn't 8-bit clean).

SMTP was the first killer application on the net.  It was also the
first, and still the most often, to be tunneled through, and to be used
for purposes significantly other than its design parameters.  A user
equipped with Windows 3.1, no tcp/ip stack, and no network connectivity
except a mailbox (accessed via proprietary protocol, but gated through
to the internet by the company server).  As the most wide-reaching and
ubiquitous of protocols, it was inevitable that it be used for things
*other* than sending messages.

> a single application protocol with URIs and a single set of methods you
> could have used an "FTP client" to talk to your "SMTP server". Really an

An interesting possibility, and one that happened quite often, in the
complete absence of the definition of URIs.  On the other hand, using an
SMTP client to talk to an FTP server required something quite different
(a server that could receive mail, then act as an FTP client to retrieve
a file, then act as an SMTP client to send it ... this adapts a
synchronous protocol to asynchronicity, and a pull protocol into a push
(more or less, and this is where those terms start breaking)).

Adding URIs would have done zero good, at that point.  If you can't use
TCP/IP, or don't have an eight-bit clean connection, a library's worth
of URIs don't solve any problems.

Incidentally, URIs also typically suggest a strongly client-server
model, a pull model, and synchronous interactions.  All of those may be
good reasons to speculate on how to extend URIs, or what good addressing
semantics are for asynchronous, or push, or strongly peer-to-peer

> "ftp client" would be just a different user interface for the shared
> protocol. Therefore, our views are diametrically opposed to those of the
> people that Ameilia quotes above. We are not trying to stop people from
> solving problems. We are trying to encourage them to solve them *in the
> most interoperable way*.

I remain unconvinced.  I'm not convinced, from the above, that the folks
currently pushing REST so hard are even aware of the design parameters
and history of the rest of the stack (discussion of the OSI model, in
the context of the discussion of protocol design for the TCP/IP stack,
makes me extremely suspicious).

Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.

Received on Tuesday, 9 July 2002 10:06:05 UTC