Re: XMPP Compatibility

[ned.freed@mrochek.com]

> > SIMPLE has something somewhat similar to the thread-id (SIP's Call-ID) in
> > its own metadata, sure. My point was just that I don't think a lot of
> > critical features are going to be implemented in the metadata (from my own
> > reading of the XMPP drafts, MSGFMT already accommodates most of what the
> > metadata contains - minimal information needed for message routing and
> > transaction correlation).

> The history of RFC822 belies this claim. More and more information
> is getting shoved in the e-mail headers every day.
        
Er, actually, the history of RFC 822 supports this claim rather thoroughly.

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. The vast majority of it falls into the "trace
field" category, that is, it is basically a comment (and often as not it's a
comment on the state of the universe and not on the message itself).

Take a look sometime at how few additional bits of standardized message level
metadata there are that are done using RFC 822 fields. The only three that come
to mind are RFC 2298 disposition notification requests, RFC 3458 message
context labels, and RFC 2919 list identification fields.

Mind you, it would have been interesting has various pieces of message level
metadata actually been defined for use in the RFC 822 environment. For example,
RFC 2156 could have suggested that RFC 822 systems act on the semantics of the
various X.400 fields it maps into into message header fields. But it didn't, so
while they may look important these fields ended up being in effect nothing but
comments.

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. And even
then MIME created a textual convention that made it possible to differentiate
MIME header fields from message header fields. The only field MIME standardized
that provides message-level metadata is MIME-Version, and it was probably a
mistake to have defined it, a mistake we would never repeat, or for that matter
need to repeat, with another message format.

> > add a lot of 'features' to the metadata that would require e2e security,
> > this isn't a very attractive development path, I agree. But I'm not sure I
> > think either XMPP or SIMPLE is likely to do so. Can you substantiate why you
> > think many pieces of e2e 'feature' metadata will be added to XMPP in the
> > future?

> As I said, it's the history of every extensible protocol I know of.
> It's certainly been true of HTTP and RFC822.  And the fact that XMPP
> uses XML so liberally means that it's incredibly easy to add metadata.

Again, this really has not been the case for RFC 822. The fact that it is
incredibly easy to add header fields led to the ad-hoc insertion of a lot of
nonsense, not to the definition and use of lots of standardized message header
level extensions. Instead what has happened has been that routing and handling
extensions have been done at the SMTP level and content labelling and metadata
has been done at the MIME part level.

Indeed, the way message header field use has played out has made it very
difficult to set up a useful message header field registry. Why? Because if you
limit the registry to standardized fields you end up with a message header
field registry that does nothing but recapitulate a short list from a fairly
small number of RFCs. And if you lower your standards to say the fields don't
have to be standardized the floodgates open and you end up with an unacceptable
S/N ratio.

> > The point is, we need to know what metadata actually requires security
> > properties, and what the risks are of not having security properties for
> > some metadata. It isn't immediately clear to me, for example, that an
> > attacker would gain a whole lot by changing the thread-id. Much of the
> > metadata in SIP is explicitly not securable e2e (it needs to be changed by
> > intermediaries), and would never need to pass through a CPIM gateway. Would
> > any intermediary be required to read the thread-id, or is it an e2e
> > property?

This is also true of most of the metadata that's expressed at the SMTP
level.

				Ned