FW: [JDEV] A piece of MIME?

[Patrick McCuller]

	Scott, I tried to help you reshape this idea in private, but if you want to
take it to the whole jdev list, that's your business. Still, it is generally
polite to ask permission. What I write to you in email privately I may not
want shared with the list or whoever. I'm likely to be more candide and less
formal than I would be if writing for distribution. Now, that said, I do
understand that whatever I write may get shown to anyone - can't help that.
But the burden of politeness is on you.


-----Original Message-----
From: Patrick McCuller [mailto:patrick at kia.net]
Sent: Tuesday, August 10, 1999 10:17 PM
To: Scott Robinson
Subject: RE: [JDEV] A piece of MIME?
Importance: High


>
> > 	I don't want to reply to this in detail before I can
> respond to Jer's documents, but you do realize you're not using MIME,
don't you? Have you
> > read the MIME rfcs? Mangling out the type specification into
> the XML makes it not only NOT MIME, but REALLY FRAGILE as well.
> >
>
> As I stated, it was _very_ rough but gave an idea for what I am
> aiming for. It needs a _lot_ of work to become a MIME-workalike... however
> I've weighed the various options on how to use MIME within Jabber and
"mangling" our
> specification was the only way I could be slightly happy with. (I'm not
> anywhere near happy.)

	The very words 'MIME-workalike' should make you stop and think about what
you're proposing. Remember the three Rs?

	MIMEXML might be a worthy thing. But if you're interested in that, go start
an IETF BOF. Why hack it up here when there's no need to? Clients will have
to make some kind of weird kludgey XML-MIME bridge thing, which smacks of
ugly. It makes it difficult to implement ANY reasonably simple client. That
alone should stop you.

>
> > 	Please consider just putting the MIME block in the message,
> not screwing with the message packet protocol itself unless where
neccessary.
> >
>
> Placing a MIME block in the message is a working solution. Let me
> paste in a paragraph from my essay:
>
> Creating an extension "<MIME>" tag, while appealing, has a
> problem. Placing the MIME'ed text straight into the tag could potentially
cause conflicts
> with the XML. While I am probably (hopefully) wrong on this
> problem, I have yet to see any solutions to the problem if someone places
> "</message>" within their "jab". This also applies to standard messages.
One could place a
> "hack" where all data is BASE64'ed or UUENCODED, but this is ugly in it's
> own right. Also, this would require including a entire MIME decoding
> engine when we already have an XML engine. Wouldn't it be nice to use what
> we already have? Finally, the advantages of "multipart" and forwarding
> Jabber messages verbatim would be killed. (or at least crippled)

	And if you'd actually read in my note where I mention that Jabber is
already addressing this problem by using CDATA Sections, you'd know better
than to try this "</message>" argument with me. What it does is indicate to
me that you don't bother to read an entire message before replying, which is
disheartening, to say the least.

	Also see above where I argue that reinventing MIME would be a lousy idea.
SURE, you've got an XML engine right there. Great. You've also got a socket
library. Whee.

	Kindly tell me exactly how multipart/ messages would be a problem.


Patrick