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

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Aristotle Pagaltzis wrote:
> But the way you said it suggested that using XOP would be 
> less Atom-specific. So let me restate: I didn't and still 
> don't see how using `multipart/related` is Atom-specific in 
> any way that using XOP would avoid.

OK, I see what you mean.  

(a) If a server receives an entry with inline content (base64-encoded), it
can convert that to an out-of-line content if it prefers to do so or based
on some hint from the client. That is true whether or not the multipart
draft moves forward, and I believe that some applications already depend on
that (somebody mentioned Nokia Lifeblog already, which is based on an old
draft of AtomPub). With this in mind, my suggestion was to provide a
standard mechanism for the client with a means to say "Hey, I'd really like
you to rewrite my entry so the content is out-of-line" and a standard
mechanism for the server to say "If you ask me to make the content
out-of-line, I will do so" or "I will always convert entries with content of
types X, Y, and Z to media link entries." Obviously, that is all
Atom-specific but it doesn't have anything to do with XOP.

(b) You could then add to that some mechanism for the client to request a
collection feed where all media link entries were transformed into
equivalent entries with inline content; this effectively gives you a
batch-fetch mechanism for media link entries just like we have for normal
entries. Similarly, you could add a mechanism for the client to ask for a
feed where all entries were transformed into equivalent media link entries;
this gives you a crude way of listing collection members skipping all the
content which I've often found useful. Again, this would be useful even
without multipart/related or XOP.

If you combine XOP with (a) you get an efficient mechanism (no Base-64
encoding/decoding) of uploading binary content with its metadata in one
shot. If you combine XOP with the first part of (b) you get efficient (no
Base-64 encoding/decoding) of batch downloading of binary content along with
its metadata. You could use "Content-Encoding: XOP" and "Accept-Encoding:
XOP" to indicate that XOP is used/supported, which is not Atom-specific.
(Yes, I know there is no registration for XOP as a Content-Encoding yet.) 

In summary, I do think that while XOP is not Atom-specific, it has to be
combined with some Atom-specific extensions to be useful with AtomPub.
However, those Atom-specific extensions are useful on their own even if
Joe's multipart/related mechanism is standardized, so you can't really
attribute the cost of those extensions to XOP. Further, XOP is beneficial
for feeds that contain multiple entries with binary data as well, and XOP is
useful outside of AtomPub. So, I don't think it is better to create another
standard that is very similar to XOP but is less generally applicable (even
for AtomPub) given that XOP exists and it isn't much harder to implement.
However, to rephrase my earlier message, I'd rather see a standard than no
standard so I'm happy to support whatever approach gains consensus, even if
the approach isn't the one that I think is the best.

Regards,
Brian