RE: XMPP Compatibility

["Peterson, Jon" <jon.peterson@neustar.biz>]

Some notes below.

- J

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Monday, March 31, 2003 2:57 PM
> To: Peterson, Jon
> Cc: iab@ietf.org; iesg@ietf.org
> Subject: Re: XMPP Compatibility
> 

> 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'm not yet persuaded that this is the case. It certainly isn't the case in
SIMPLE that you have a different set of application features available when
you use MSGFMT versus some other body format. As I said, MSGFMT carries
arbitrary MIME bodies. So, if in SIMPLE I wanted to send a .jpg with my
instant message in a multipart MIME body, then if I also wanted security
properties I would take that whole multipart body and put it inside the
MSGFMT body. The same IM features are available in that case. I'm not sure
what sorts of 'features' other than the content of an IM you're concerned
about, though.

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

Well, I'd like an instant messaging protocol to be able to send .jpg's in
MIME bodies, sometimes. I don't want it to be forced to send .jpg's all the
time. It would be nice if I had some reasonable assurance that recipients
would understand .jpgs. The protocol doesn't change when you carry .jpgs
versus text/plain - that's just a format that the protocol carries. Same
with MSGFMT.

People may, for whatever reason, somtimes not want to send secure IMs
(perhaps because they aren't capable of participating in the same PKI as a
particular destination for some reason). It should not be mandatory-to-use.

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

Well, you'll still have to do some protocol translation at the gateway. We
can only prevent that if we've essentially made SIMPLE and XMPP the same
protocol. One important use of MSGFMT is to prevent the operator of a
gateway from reading the contents of an IM. If MSGFMT is encrypted, then its
headers can't be translated. I don't think there's any way around protocol
translation in these interoperability cases.

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

The encryption format is just a wrapper for the same content that would
appear in the cleartext version of the message (along with some metadata for
integrity purposes, and to prevent replay attacks). You need to have a
'cleartext' format anyway because that's what gets secured within the
ciphertext wrapper.

> -Ekr
> 
>