MIME-RPC (was Re: REST)

Paul Prescod paul@prescod.net
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.

Sorry. http://groups.yahoo.com/group/rest-discuss/message/38

>...
> 
> 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!

 Paul Prescod