Re: XMPP Compatibility

[Ted Hardie <hardie@qualcomm.com>]

I think my take on this is somewhere between 2 and 3.  I would say that
we achieve the best result in this current space if we ensure that
there is _at_least_one_ mandatory to support message format
with _at_least_one_ mandatory to support mechanism to ensure
data integrity and _at_least_one_ mandatory to support mechanism
for end-to-end encryption.    Supporting more than one message
format/data integrity mechanism/end-to-end encryption mechanism
seems very, very likely given the place in history we find ourselves;
realistically, I think we should accept that and move on.    In the mean
time, though, I believe that we should expect that any compliant
IM system should be able to handle  the mandatory-to-support
message format (no matter whether from some other IM system or
from a sibling in its own system), that they should be able to check
the data integrity of that message if it has been assured, and that it
should be able to handle the encrypted message if the mandatory
support form has been used and keys or secretes
 have been appropriately exchanged.

I suspect this means CPIM's MSGFMT using text/plain and S/MIME
as a common denominator.  I've gotten three separate threads on this
topic just today, though, so I have no fear that someone will expose
my ignorance if I am off base here.
						regards,
								Ted




On Monday, March 31, 2003, at 02:56 PM, Eric Rescorla wrote:

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