MIME-RPC (was Re: REST)
Thu, 17 Jan 2002 10:03:13 -0800
[would you mind moving this to rest-discuss? There was near a FORK
rebellion last time]
"S. Alexander Jacobson" wrote:
> On Wed, 16 Jan 2002, Paul Prescod wrote:
> > "S. Alexander Jacobson" wrote:
> > >
> > > Ok. So, if I want to send a message to an HTTP
> > > server and have it call back my HTTP server later,
> > > how do I specify that?
> I don't think you answered this one at all.
> I completely agree. In MIME, that record format
> is called a "content-type". MIME even defines a
> procedure for getting organizations to agree on
> the name for that type. It is RFC 2048. With
> MIME-RPC, you would send e.g.
> content-type: application/x-employee
> OPAQUE DATA THAT IS INTERPRETED BY A MIME-RPC
> IMPLEMENTATION IN ACCORDANCE WITH THE SPEC FOR
> THIS FORMAT -- THE FORMAT MIGHT BE BINARY!!!
Okay, but that's just *MIME*. MIME-RPC is adding no value here!
> MIME-RPC encourages #2. The point is that for
> massive interoperability, applications need to be
> able to send each other messages that may include
> objects of various types packaged together. MIME
> is a well defined and well used mechanism for
> doing exactly that.
Nobody disputes the value of MIME. For a while, even Microsoft was in
favor...before they invented "DIME". I'm asking about the value of
MIME-RPC. Adding RPC to MIME is not exciting to a REST-er since REST is
an alternative model to RPC!