List of outstanding issues regarding the RPC proposal

During last week's GETF call I took and "to do" to list the outstanding
issues regarding the RPC proposal.  I've reviewed the e-mails received in
response to my proposal, and here is a summary of the issues that I've seen
raised.  Unfortunately, the W3C mail servers were not responding at the
time that I gathered this information.  Therefore, I am unable to provide
direct links to the pertinent e-mails. Where possible, I have proposed
resolutions to the issues raised:

Concern:  Is it appropriate to do RPC as a "chameleon" binding to HTTP?
Mark Baker, perhaps among others, has expressed nervousness given that HTTP
has its own notion of "method", and SOAP's is different and typically finer
grained.  (There was extensive discussion as to which end of the connection
was determining the operation to be performed, how contracts were
established, etc. I believe that all of those boils down to questioning the
chameleon use of HTTP for RPC).
Proposed resolution: I don't think we have consensus, but for several
reasons I propose that we do retain RPC, in a manner based on my proposal.
Reasons: (a) our charter requires us to produce RPC support (b) this
exercise is primarily to resolve concerns expressed by the TAG -- they did
not take the opportunity to discourage us from doing RPC, but merely asked
us to make appropriate use of GET (c) although we may not have consensus, I
believe that the proposed use of RPC with POST and GET is consistent with
the "chameleon" use of HTTP.  Without trying to repeat the entire argument
here, I believe that SOAP is a MIME type and like HTTP forms has the
opportunity to encode specialized information regarding the intent of the
client in contacting the server.  Of course, in SOAP as in HTML forms, the
server is the ultimate arbiter of what really will happen.  This
explanation is a significant oversimplification of the points pro and con,
but I propose we stick with RPC.  Indeed, I think the case can be made that
it is out of scope for this exercise to consider dropping it at this point.

Concern:  Should the RPC convention support HTTP PUT?
Proposed resolution: no.  The reason that PUT was proposed in the first
place was that I believed it would be the most appropriate way to create a
new resource using HTTP. Henrik and others have convinced me that common
practice in HTTP is to use PUT only in situations where the resource stored
is intended to be essentially isomorphic to the characters or bits
transmitted for the entity.  While I find this somewhat incoherent given
the focus in HTTP on "representational" state transfer, I don't think the
purpose of this exercise to change or to "fix" HTTP, even if my concerns
are correct.  I therefore propose that we not support PUT, at least in this
version of an RPC proposal.  If at some future point PUT were ever to prove
desirable, I believed it could be introduced with no backward
incompatibilities.

Concern:  My proposal declines to establish a specific convention for
mapping resource-identifying RPC arguments into URI's.  We received one
mail strongly endorsing this choice, and another indicating that a standard
convention would be necessary for interoperation.  I can see this both
ways.  Such interoperation was possible in SOAP 1.1, so it is in some
respects a step backward to leave this convention out.  On the other hand,
SOAP is generally not in the business of constructing URI's.  Furthermore,
one can make the case that the best means of constructing URI's might be
dependent on (a) the URI scheme in use (b) whether description languages
are being used (c) whether dynamically typed scripting languages are being
used, etc.  Furthermore, as David Orchard's proposal showed, there are
potentially daunting internationalization issues in determining that a
natural language method name such as "getStockQuote" actually is an
indication to access a "StockQuote" resource.  David proposed merely
stripping off t
he word "get", but I find that somewhat troubling.
Proposed resolution:  either stick with my original proposal to provide a
specific URI mapping, or provide a non-normative appendix explaining at
least one convention that might be used with HTTP URIs.  This would
presumably be based on some combination of the proposals made by Tim Bray
and David Orchard, but acting only on arguments known to be
resource-identifying.  I'm not quite sure what to suggest regarding
internationalization (not an issue, of course, if we do nothing).

Concern: My proposal did not explicitly describe use of MEPs.
Proposed resolution: it was always my intention that POST would continue to
use the request/response MEP, while GET would use the newly-hatched one-way
pull (which I still think should be renamed).  One remaining question is
how to determine whether the HTTP method should be GET or POST?  Two
solutions are possible, and I have no strong feeling: the simplest but
least general is to key on the MEP; an alternative that would be more
scalable would be to introduce a new feature -- call it "REST method" -- to
be implemented by bindings such as HTTP that support REST methods.  This
feature would consist of a single property, an enumeration of methods GET,
PUT, POST, DELETE, etc. Applications (or description languages such as
WSDL) could use this to select the appropriate methods to use.  The current
specification would include an admonition that only GET and POST should be
used with the RPC convention.

Concern: Mark Baker expressed a concern regarding my proposal to use
"constructor" methods when using SOAP to create new resources
Proposed resolution:  to a significant degree, this concern goes away given
the decision not to use PUT.  Nonetheless, we have the opportunity to
consider whether a special idiom should be described for the creation of
new resources as opposed to the updating of existing ones.  I believe the
path of least resistance at the moment is to drop the mention of both PUT
and constructors, and leave it to applications to decide how most
appropriately to use of facilities that we provide.  Constructors were only
a convention in any case.

I think those were the major concerns.  Given that we have a task force
call in 15 minutes I'm going to take the liberty of mailing this out
without further checking, and indeed without needed proofreading.  (Chris:
this one was indeed written with voice recognition software, so when you
find laughable substitutions and homonyms, that's probably the reason this
time.  Last time it was just old age.)  If I have missed any issues, please
let me know.


------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Monday, 3 June 2002 10:59:07 UTC