Re: atompub-multipart-01: browser implementation

[Aristotle Pagaltzis <pagaltzis@xxxxxx>]

* Bill de hOra <bill@xxxxxxxxxx> [2008-06-19 22:20]:
> Tim Bray wrote:
>> On Jun 19, 2008, at 5:56 AM, Bill de hOra wrote:
>>> Short version: I think this draft can't be implemented in a
>>> browser [1].
>>
>> Assuming you're right (although we shouldn't underestimate the
>> ingenuity of the rabble who make browsers do lots of things
>> nobody thought were possible), 
>
> That will be operationally equivalent to a browser exploit.

As is the hidden iframe form.

> Not something for an IETF wg to be hoping on, surely.

I don’t see why this WG would have to do anything more than let
the W3C members figure out an XHR security model more nuanced
than the all-or-nothing deal of current browsers. Pressure to do
so already exists from many directions.

> That's not a valid rationale for me; sheer browser volume make
> other clients look like rounding errors.

What with Microsoft, Google, IBM and Sun already on the Atompub
bandwagon and more sure to join I imagine one of two things will
happen soon enough: either Atompub clients will go up in numbers
enough to be noticable against the browser slice of the pie, or
browsers will assimilate Atompub.

> To be clear, I'm all for this getting onto the standards
> treack, but this is one reason why my initial feedback included
> the suggestion that other multipart options not be excluded by
> design.

Since RFC 5023 itself is not fully implementable in a browser,
I don’t see how that can be a criterion for the multipart spec.
The spec as it currently stands precludes other kinds of
`multipart/related` payloads, but does not preclude any other
sort of packaging protocol.

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