Re: XMPP Compatibility

[ned.freed@mrochek.com]

While Harald's msg about the primary point  of this thread seems to me to be
precisely on target, it has raised a couple of side issues I feel need to
be addresses.


> > Well, my primary point was that your attempt to use RFC 822 as an analogy was
> > seriously flawed in quite a few ways. Far from supporting your claims, it
> > supports the claims others have made that you dispute. In particular, you
> > asserted that there will be abundant reasons for extending the set of e2e
> > metadata in messages and pointed to RFC 822 as an example of this. My response
> > was and is that RFC 822 actually indicates that instances where this particular
> > type of metadata will need to be extended aren't very common.

> Well, I'm not arguing with your history, but I am arguing with
> your interpretation. I don't think that stuff that's documented
> in RFCs is the right benchmark here. Rather, I prefer to look
> at what actually appears in messages.

Looking at what actually appears is fine, but the point you still don't
seem to get is that where this stuff appears is largely accidental: Message
headers were used for this stuff not because that's where it belonged, but
because there was no useful alternative.

Again, most of what appears doesn't need to be at the message level. It
would be much better for it to be carried as part of the content.

> > I'm also attempting to draw a distinction between real e2e metadata
> > and other junk. Most of the added stuff people stuck in an RFC 822
> > header isn't real e2e metadata. And to the extent it belongs in a
> > message at all, it ended up being put in the RFC 822 header not
> > because that was the right place for it but rather because there
> > wasn't any other viable place to put it.

> Which, as far as I can tell, is exactly the situation we are
> poised to replicate with IM.

Then we should fix the problem not by making it convenient to put stuff in
places where it doesn't belong, but rather by extending our content model to
allow this stuff to be put in the proper place.

In any case, I absolutely agree that there's a problem here that needs to be
fixed.

The idea of putting this sort of thing in the content of messages isn't new.
The fact of the matter is that some of this stuff already appears as message
content (usually because it wouldn't fit in the headers). vCards are one
example; winmail.dat files are another.

What's missing is a way to label ports of the content as being ancillary. And
this isn't a new idea either: Back in 1999 Chris Newman proposed an "ancillary"
content-disposition value, intended to be used to label stuff that appears
inside a message that normally should not manifest in the user interface. He
intended it for use with vCards but there's no reason it could not be used
with, say, X-Habeus material. Or with the applefile portion of appledouble.

I just talked with Chris about this and he's going to resurrect the draft that
defined this.

				Ned