[JDEV] A piece of MIME?

[Scott Robinson]

Interleaved response.

I'm a jerk at points in this post, so I offer an apology at this point. I
may be acting out of line, but I call them as I see them.

Scott.

* Patrick McCuller translated into ASCII [Tue, Aug 10, 1999 at 10:16:39PM -0400][<019801bee39f$8befb400$1b76c897 at scylla>]
> >
> > > 	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?
> 

I also remember my geometry teacher who, while was mostly right on with
definitions, gave the definition of a line as something that intersected
with any given plane at all possible locations.

> 	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.
> 

Your worry is that the XML-MIME (MIME is probably a bad name, I'm only using
the ideas and concepts MIME gives) addition to the Jabber spec will be weird
and kludgey is valid. I'm happy for alternatives and modifications to the
spec I'm proposing that work better! Moreover, disregarding it with comments
such as "remember the three Rs" doesn't make me very receptive to your
alternatives.

> >
> > > 	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.

I did read it, however it was before the essay paragraph was written. I
would hope that you would at least figure that in a more "modern" (ha!)
sense I was referring to the close of a CDATA. Proper escaping, of course,
handles that.

> 
> 	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.
> 

Give me an alternative.

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

To refute your previous "just place the MIME in the <MIME> tag", multipart
would be a bitch because of forwarding, verbatim, of a jabber message.

Unless you want to put a MIME decoder in and have it then put out another
expat instance that would then decode the message encoded within.

If you do, hey, do it in your client and confusing as hell protocol. I'm
suggesting something a bit more simple.

> 
> Patrick
>