Re: XMPP Compatibility

[Eric Rescorla <ekr@rtfm.com>]

"Peterson, Jon" <jon.peterson@neustar.biz> writes:
> Yes, MSGFMT was designed explicitly to be a common format, and I think it
> should be satisfactory as a format for any RFC2778/RFC2779-compliant instant
> messaging protocol. However, the scope of the MSGFMT document is something
> more like your (3) below. I'm not sure that (3) is really so problematic -
> actually (4), that XMPP or SIMPLE must use MSGFMT and only MSGFMT, seems
> more troublesome to me. Customarily, for things like this we standardize
> what is mandatory-to-implement, but not what is mandatory-to-use for
> implementations. I'm not sure I would be comfortable prohibiting XMPP or
> SIMPLE from using payloads other than MSGFMT. I think mandatory-to-implement
> can and should imply, however, that receivers of XMPP/SIMPLE/whatever
> messages should be capable of handling MSGFMT, and that senders may send
> MSGFMT. This is more or less what RFC3428 (the SIP MESSAGE method) says now.
Jon,
The problem with (3) is that it provides an entirely different
set of *application* features when encryption is turned on than
when it is turned off. That is likely to discourage people from
using encryption, which doesn't seem to me to be desirable.

I don't really see this as a mandatory-to-implement vs.
mandatory-to-use issue. The issue isn't whether or not 
a protocol supports a given feature but rather what the
protocol itself should be. We say "this is the protocol,
it's what you do" all the time.

> If you don't need
> e2e security, I'm not sure what benefits MSGFMT really confers.
That you don't have to do protocol translation for the message
at some gateway. This sort of message translation has been
a nightmare in the e-mail world.

Even if you don't consider this an important feature, the benefits
of only having one format instead of one for encryption and
one for cleartext seem rather substantial.

-Ekr