[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XMPP Compatibility

"Peterson, Jon" <jon.peterson@neustar.biz> writes:
> > 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.
Whatever happens to be in the headers. For instance, XMPP stanzas
have a thread-id in the meta-data. 

> 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.
I think we're talking past each other. I expect there to be substantial
amounts of meta-information in the IM messages, as in the thread ID
above.

> 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.
I want to distinguish between messaging protocols and message
transport protocols. The analogy is to RFC822/MIME versus SMTP.

> 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.
Yes. I want that to be the same whether encryption is used or not.


Let's be concrete for a moment here. At the moment, XMPP messages
are sent in stanzas like this:

<message to='warlord@jis.mit.edu/Gabber@JIS.MIT.EDU' type='chat'>
  <body>
    Just sending a test message.
  </body>
</message>
 
If we use MSGFMT to send this, there are two choices:
---------
To: warlord@jis.mit.edu/Gabber@JIS.MIT.EDU

Content-Type: text/xml

<body>
  Just sending a test message.
</body>
----------

Or:
---------
To: warlord@jis.mit.edu/Gabber@JIS.MIT.EDU

Content-Type: text/jabber-xml

<message to='warlord@jis.mit.edu/Gabber@JIS.MIT.EDU' type='chat'>
  <body>
    Just sending a test message.
  </body>
</message>
----------

I think you're endorsing something like the second approach.  The
problem with this second approach is that it doesn't really work. The
receiver actually needs to be able to read Jabber's format in order to
display the message. This defeats the purpose of using MSGFMT.

On the other hand, if we use something like the first approach, what
happens when we want to add another kind of meta-data, like 
thread id. There's no defined place to put this in MSGFMT,
so we either have to use the extensions mechanism or fall
back to the second approach, which ruins compatibility.
So, the extensions mechanism it is. But now we have two 
parallel lines of message format development, one for MSGFMT
with extensions and one for XMPP proper. Yuck.

Or have I misunderstood you?
-Ekr