Thought some of the IPP folks might find this SWAP posting
interesting, if not familiar. I find it interesting that
the author is from Xerox. ;)
Keith Moore is also the AD for the SWAP WG, by the way.
It'll be interesting to see how this discussion goes.
...jay
--------------3C3DC09861147F55B4DB3275
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from glacier.mcom.com (h-205-217-233-39.netscape.com [205.217.233.39]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id TAA11934 for <jkm@underscore.com>; Fri, 7 Aug 1998 19:53:51 -0400 (EDT)
Received: (from list@localhost) by glacier.mcom.com (8.7.3/8.7.3) id QAA04658; Fri, 7 Aug 1998 16:47:48 -0700 (PDT)
Resent-Date: Fri, 7 Aug 1998 16:47:48 -0700 (PDT)
Message-Id: <3.0.3.32.19980807164540.008285b0@mailback.parc.xerox.com>
X-Sender: jdavis@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 7 Aug 1998 16:45:40 PDT
To: swap-wg@netscape.com
From: Jim Davis <jdavis@parc.xerox.com>
Subject: SWAP should not be an HTTP protocol
Cc: jdavis@parc.xerox.com
Mime-Version: 1.0
Resent-Message-ID: <"YLzWm2.0.k81.Z8vor"@glacier>
Resent-From: swap-wg@netscape.com
X-Mailing-List: <swap-wg@netscape.com>
X-Loop: swap-wg@netscape.com
Precedence: list
Resent-Sender: swap-wg-request@netscape.com
Content-Type: text/plain; charset="us-ascii"
I've read the most recent (May 6 1998) SWAP draft. Based on my current
understand of the intent of SWAP and the state of HTTP, it is my position
that SWAP should *not* be an HTTP protocol. I'll explain why below.
I want to begin though by saying that I am very much in sympathy with the
general aims that SWAP seeks to meet. I certainly would like to see means
of invoking potentially long-running processes across the internet, and
agree that the general scope of the SWAP effort is correct. I just object
to using HTTP to do it.
SWAP should not be an HTTP protocol because it is not really a set of HTTP
extensions. Although SWAP claims to be an "HTTP based" protocol, it does
not actually use any of the features of HTTP. Compare it with, WebDAV or
the content rating extensions. Both of these are truly extensions ot HTTP
because the very domain of operation is Web resources. WebDAV tells you
how to add properties to Web resources, and the content rating extensions
tell you how to keep your kids from reading those resources. But SWAP is
irrelevant to nearly all existing HTTP methods, and for those it does use
(WebDAV PROPFIND and 'PROPSWITCH') it is forced to make changes to the
defined semantics. Furthermore the data objects transported by SWAP will
never be displayed to humans. (While this is also true of WebDAV, WebDAV
remains connected to human-readable content because it is explicitly
intended for the management of such content.)
It appears to me that SWAP uses HTTP as a transport because it is
ubiquitous. SWAP appears to me to be exactly that sort of protocol that
Larry Masinter so deftly parodied in his notorious April Fools RFC 2324
when he wrote:
HTTP 1.1 ([RFC2068]) permits the transfer of web objects from origin
servers to clients. The web is world-wide. HTCPCP is based on HTTP.
This is because HTTP is everywhere. It could not be so pervasive
without being good. Therefore, HTTP is good. If you want good coffee,
HTCPCP needs to be good. To make HTCPCP good, it is good to base
HTCPCP on HTTP.
In addition, it is not at all clear to me that extensions like SWAP are
viable. While HTTP is currently relatively ubiquitous and capable of
flowing through at least some corporate firewalls, this may not remain the
case, particularly if the practise of embedding more and more diverse
functionality into HTTP continues. (Cohen et al make this point in "Don't
Go Postal"
<url:http://info.internet.isi.edu:80/in-drafts/files/draft-cohen-http-ext-po
stal-00.txt>)
I am not subscribed to the swap-wg mailing list, so I ask that anyone who
wishes to discuss this with me include me as a CC.
with all best regards
Jim Davis
------------------------------------
http://www.parc.xerox.com/jdavis/
650-812-4301
--------------3C3DC09861147F55B4DB3275--