Re: XMPP Compatibility

[ned.freed@mrochek.com]

> ned.freed@mrochek.com writes:
> > What's being claimed here is that implementation of critical features as
> > message level metadata is going to be rare. But that's precisely what we've
> > seen happen with RFC 822: While tons of random dreck is routinely added to RFC
> > 822 message headers, practically none of it is used to implement anything
> > resembling a critical feature.

> I'm not sure what you mean by "critical feature". Are you attempting
> to draw a distinction between things that need security and things
> that don't?

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.

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.

> 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. The sticky case is always the stuff that
rises above the content but doesn't quite make it to the transport. But this
stuff doesn't qualify.

> > I also note in passing that MIME doesn't really fall into this
> > category: It standardizes content labelling and content metadata,
> > which ended up being conflated with RFC 822 fields only as a result
> > of certain concerns about the installed base, concerns that should
> > never apply to any other format.

> I'm not quite sure I understand this either. MIME fields are in
> the header, no? They contain information that the MUA needs
> in order to process the message (like, what the media type is).

First of all, MIME fields aren't always in the message header. And again, to
the extent that they do get conflated with message headers, this was a
pragmatic design choice driven by implementation concerns, not a belief that
they are architecturally equivalent or even similar to the other stuff in a
message header. On the contrary, the understanding from the get-go has always
been that MIME is architecturally quite distinct from RFC 822. And had the
circumstances allowed, this layering would have been clearly expressed in the
syntax -- we would have put all of MIME inside the message content. But the
belief was that that would have resulted in a system nobody would have been
willing to use. And given how MIME succeeded while other systems that
made different choices in this general area failed, well, it is hard to
argue with the wisdom of choosing the pragmatic path.

				Ned