[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Draft-gregorio-atompub-multipart on the standards track?

Tim Bray wrote:
> On Jun 15, 2008, at 2:33 PM, Brian Smith wrote:
> 
> > After reviewing this more carefully, I can see that this is almost 
> > exactly a re-invention of XML-binary Optimized Packaging [1]
> 
> I entirely disagree. XOP/MTOM is a means of mapping between a 
> MIME package, including any old binary crap, and an XML 
> infoset.  Its raison-d'etre is so that people who want to see 
> the world through an XML lens can pretend that a standalone 
> JPEG is actually the content of some imaginary XML element.  
> Atompub, on the other hand, lets a JPEG be a JPEG and an Atom 
> entry be an Atom entry.  All that the multipart draft does is 
> propose that these things can be sent together in one package 
> rather than separately.  There is no mapping to any XML 
> infoset.  Thus, there is no meaningful relationship to XOP/MTOM.

Let me explain my idea in more detail. First, for text/* and XML media
types, my method would let us avoid MIME altogether. For example, you could
publish an XHTML document as a media resource like so:

POST /collection HTTP/1.1
Atom-Transform: out-of-line-content
...

<entry ...>
   ...
   <content type='application/xhtml+xml'>
       <html ...>
          <head><title>Example XHTML document</title></head>
          <body>....</body>
       </html>
   </content>
</entry>

You could do the same thing for some "binary crap" like a JPEG, but you
would have to Base-64 encode it in the content element. So, this
"Atom-Transform" header + the existing Atom semantics + a simple way to
advertise the availability of the feature already give us everything that we
need. 

Using multipart MIME can then be seen just as an optimization to avoid
Base-64 encoding, both in XOP and in the multipart draft. The main
difference between the two is how one finds the place in the entry to insert
the binary data. In XOP you look for the xop:include elements. In the atom
multipart draft mechanism, you either look for a cid: link or assume that it
is supposed to be out-of-line (content/@src) content. You could use a XOP
package and set the Atom-Transform header to "out-of-line-content, XOP", or
you could define a "Content-Encoding: XOP"; a smart processor would see the
combination of out-of-line-content and XOP and avoid Base-64 together.

One nice thing about this Atom-Transform mechanism is that multipart MIME
processing is optional; an application can easily implement the
Atom-Transform one-step-creation mechanism for any type of data without
having to implement multipart/related or XOP at all. Another nice thing is
that this mechanism doesn't reserve any mime types for its own use; the
interpretation of the request body is determined by the Atom-Transform
and/or the Content-Encoding header fields.

The Atom-Transform mechanism could actually be used with either XOP or the
Atom multipart draft mechanism; I just chose XOP because it already has been
standardized for a long time.

Regards,
Brian