Fw: Binary (and XHTML, and *ML ...) attachments to XP

ps: I forgot to include xml-dist-app :(

Henrik Frystyk Nielsen
mailto:frystyk@microsoft.com

----- Original Message -----
From: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>
To: "Mark Baker" <mark.baker@canada.sun.com>
Cc: <rayw@netscape.com>; "Frank DeRose" <frankd@tibco.com>
Sent: Monday, January 22, 2001 12:12
Subject: RE: Binary (and XHTML, and *ML ...) attachments to XP


> Henrik Frystyk Nielsen wrote:
> > I realize that there are use cases where MIME makes sense but saying
> > that it makes sense all the time is simply not true.
>
> I don't believe that's what Ray was saying.  If it was, I
> disagree.  But
> in the context of XP, and the problems we're trying to solve
> with it, I
> do believe it makes good sense to at least consider.

I hope I have made it clear that despite my reservations for MIME multipart in
general, I do agree that there is a place for it in connection with XML
Protocol.

In fact, as mentioned in [1], I think there are cases where one would
want to specify a binding that includes support for MIME multipart and
that for example this makes a lot of sense in SMTP. In addition, I have
no problem saying that there should be support for MIME multipart in HTTP.

However, what I read from Ray's mail [2] is that he in fact has a
completely different protocol model in mind that is fully based on MIME
and always require it as the wrapper - in other words make MIME the
protocol. This speaks against everything that the XML Protocol WG has
produced so far as well as against the WG charter.

My second concern is that we as a WG has very little time to produce the
already chartered deliverables and that the SOAP attachment spec in fact was
written after the SOAP spec itself and I can't see why this can't be
done with XML Protocol as well.

> > Why is it that HTML
> > and all inlined images etc are not often wrapped into a
> MIME multipart?
>
> As I understand it, because pre-existing MIME processors in
> the browsers
> weren't able to independantly dispatch off the multiparts as they were
> parsed, only once the entire multipart document (images included) had
> been parsed.  This meant that the user had to wait longer to see
> anything rendered.  User frustration = failure.

That is certainly one reason but even more importantly, caching,
buffer-management, content-negotiation, the fact that images can come from
anywhere etc. are fundamental reasons why it wasn't used in the first place.

Henrik

[1]http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0107.html
[2]http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jan/0121.html

Received on Monday, 22 January 2001 17:25:37 UTC