Re: atompub-multipart-01: browser implementation

[Aristotle Pagaltzis <pagaltzis@xxxxxx>]

* Bill de hOra <bill@xxxxxxxxxx> [2008-06-20 00:20]:
> Aristotle Pagaltzis wrote:
>> The spec as it currently stands precludes other kinds of
>> `multipart/related` payloads, but does not preclude any other
>> sort of packaging protocol.
>
> The markup in 01 doesn't exactly qualify itself; I said this
> about 00. How will another specification indicate support for
> another multipart approach - new boolean attribute?

In this case, surprisingly, I think the boolean attribute is
accidentally helpful: with a non-boolean attribute, care would
have to be taken to allow multiple values in the future when more
than one way of multipart processing is specified and collections
can support several of them. With boolean attributes, you just
make up more of them.

Also, an attribute on app:accept is not the place where I would
have thought to put the server advertisement – and future specs
may well put it some other place.

Neither of these possibilities are great, mind. I’m just saying
they do exist.


* Brian Smith <brian@xxxxxxxxxxxxxx> [2008-06-20 00:55]:
> I would also like to know how an AtomPub server can indicate
> that it supports multipart/* and message/* content

Only if it’s tacit about it. Putting such a MIME type name in
`atom:content/@type` is forbidden per RFC 4287, so you can only
support them if you either use the SHOULD loophole of combining
out-of-line content with an omitted `type` attribute, or you
label them as `application/octet-stream` and use some private
extension to communicate the real media type. Both approaches
ugly and stupid for obvious reasons.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>