S. Alexander Jacobson alex@shop.com
Thu, 17 Jan 2002 19:27:23 -0800 (Pacific Standard Time)

On Thu, 17 Jan 2002, Paul Prescod wrote:
> > If the whole point of REST is to re-use what is
> > already in use, why not use MIME types!
> REST uses MIME types. The question is just where the appropriate
> boundary between MIME and XML is. But REST doesn't need a new
> specification to use MIME types. It just uses them.

MIME-RPC is not a new specification of MIME types
it is simply a formalization of common practice.

I am not sure what REST uses because there seems
to be no formal definition of what exactly REST

I think MIME-RPC would be almost identical to
such a formal definition if one were to create it.

> >...
> > No.  That is not my intention.  For highly
> > structured documents, like a purchase order, I
> > assume you define some new mime-type (that may
> > itself be an XML document).
> It is my assertion that most of the interesting web services will be
> organized around these new mime-types (or at least XML namespaces). So I
> don't see MIME-RPC as being a big part of the REST model.

I don't see what you are fighting.  I think we
should be in raging agreement!  If you want to
send a PO in MIME-RPC, just send it with header:
content type: application/x-purchase-order

If you want to send 10 purchase orders, use

If you want to send a tuple of a purchase order,
a signature, and a credit application, use

If you want a credit approval reply sent to a
different location, send a reply-to-url.

>  The nice thing about
> > MIME-RPC is that it defines coherent semantics for
> > passing complex (and perhaps opaque) types between
> > applications.
> >
> > XML-RPC and SOAP both send base64encoded and
> > provide no clear semantics for how to interpret
> > the data sent.
> SOAP with attachments uses MIME types.

No the SOAP semantics are poorly defined.  No
one seems to know whether applications should
interpret the attachment accoding to a type
provided in an XML schema or according the
content-type header associated with the

More generally, SOAP and XML plumbing seem like
ridiculous overhead when you simply want to send
an opaque PO!

> >...
> > They are ugly but they realistically solve major
> > problems with both SOAP and XML-RPC.
> Okay, but REST doesn't really incorporate SOAP or XML-RPC, so they
> aren't the appropriate comparison point.

You seem to be attacking SOAP and XML-RPC so the
appear relevant.  I think MIME-RPC fixes their
problems in a way that should make RESTers happy.

> > REST is wrong about using HTTP methods.
> > 1. You may want to send messages over non HTTP
> >         transports
> A few issues here:
>  * HTTP can be tunnelled over any transport.

Unless you define a protocol for both ends of the
tunnel, you have no reliable way to deliver HTTP
over that transport.  MIME-RPC specifies that
protocol.  If REST ever gets specific, it might
look like MIME-RPC.

(Btw, RFC 1149 describes how to deliver IP
datagrams using carrier pigeon)

>  * AFAIK, there do not yet exist non-HTTP transports that work properly
> with the REST model.

I assume this is because there is no way to do so
within HTTP.

>  * Arguably it is easier to adapt HTTP to new usage modes (through
> extensions or tunnelling) than to adapt other protocols to REST.

I don't think I follow.  Why not just use other
protocols as is.  The main argument for REST seems
to be the existence proof of widespread interop.
Email has the same property.  MIME-RPC uses email
pretty much as is.  It also supports using
e.g. IMAP as a transport or HTTPS!

> > 2. A lot of web infrastructure alread assumes only
> > GET/POST style requests and generic expansion of
> > these limits interop.
> This is true. That's why you must often work around with POST. But if
> you're going to be REST-compatible then you should provide a mapping
> between your workaround and real HTTP methods so that a MIME-RPC DELETE
> is the same as an HTTP DELETE.

Why?  You seem to take REST as normative, but I
don't see why that is so.  I think a transport
independent way of specifying methods allows
more flexibilty.

> > > MIME-RPC's numeric types should probably be XML Schema numeric types
> > > rather than inventing Yet Another Type System.
> >
> > Nothing is stopping you from defining your own
> > mime-types.  The ones in the spec are there for
> > ease of use, readability, and compatibility with
> > deployed applications.
> My point is that XML Schema types are increasingly available in all
> languages. MIME-RPC is going to impair interoperability if it defines
> types otherwise.

These types are there to be consistent with what
web browsers already send to web servers (without
conent-type headers).

More MIME-RPC aware applications are free to send
their own XML Schema derived content-types.

That being said, implementing support for these
types is trivial in most languages so I am not
sure that it matters so much.

> >....
> > A major point of MIME-RPC is that they can send
> > whatever they want in whatever format they want.
> > They just have to document it as a MIME
> > content-type.  One of the reasons for MIME-RPC was
> > the incredible difficulty XML-RPC and SOAP have in
> > sending highly structured data (objects) as
> > arguments.
> Okay, but you agree that the Web as we know it has no such problem. With
> or without MIME-RPC, it is easy to pass highly structured data (objects)
> over the Web. You define a MIME type (or at least an XML namespace) and
> send your data. That's all you have to do!

I do agree.  MIME-RPC is largely a formalization
of existing practice, addressing the needs of
XML-RPC and SOAP people for an easy to reference
spec with which they can declare compliance!

I think we are in agreement.


S. Alexander Jacobson                   i2x Media
1-212-787-1914 voice                    1-603-288-1280 fax