Re: XMPP Compatibility

[Eric Rescorla <ekr@rtfm.com>]

ned.freed@mrochek.com writes:
> 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.

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

> > If so, I'm not really comfortable with that. Sure, there's tons
> > of stuff that applications stuff in the 822 header,
> > (virus filtering stuff, spam attestations, loop detection),
> > and we may not think that's important. But the person who shoved
> > it in there did and so we ought to provide security for it.
> 
> With the exception of loop detection, which has to be done at the transport
> level, securing this stuff as part of the message content is fine and
> appropriate. But little if any of this stuff rises to the level of needing
> consistent end to end interpretation.
I agree with that, but it's not my point. Rather, what I'm
saying is that we need a way to carry that information in
a way that it can be safely distinguished from the body 
of the message. I'm concerned that what's being currently
proposed won't have that property. 

-Ekr