[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XMPP Compatibility
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.
I think (2) is bad idea because the sender has no way of knowing whether or
not their message will eventually be delivered to an endpoint over a
different underlying protocol (having passed through a CPIM gateway
somewhere along the way). In case (3), however, I think the sender can be
expected to know whether or not they desire e2e security properties for
their message. So I think (3) makes more sense than (2). If you don't need
e2e security, I'm not sure what benefits MSGFMT really confers. MSGFMT is a
wrapper for arbitrary MIME types - so, it is possible than within a MSGFMT
body, a MIME type could be sent that is not understood by the recipient.
It could further be argued that for interoperability between underlying
protocols, we need to decide on some bare-minimum MIME type that will be
supported within MSGFMT ('supported' in the same sense of 'MUST understand
when received, MAY send'). To date, IMPP hasn't yet identified a requirement
for that (the question of supported MIME types is pushed to the using
protocols, at least some of which have MIME-negotiation capabilities). I
imagine that the lowest common denominator MIME type would be text/plain,
which seems like the simplest possible representation of an IM.
-J
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Saturday, March 29, 2003 2:24 PM
> To: iab@ietf.org; iesg@ietf.org
> Subject: XMPP Compatibility
>
>
> Recently I've been looking at the XMPP encryption issue and I've got
> some concerns about compatibility.
>
> Some of this is probably familiar to people who have been tracking
> this, but is added for completeness.
>
> Currently, XMPP transmits messages as self-contained datagrams (called
> stanzas) that look like this:
>
> <message to='warlord@jis.mit.edu/Gabber@JIS.MIT.EDU' type='chat'>
> <body>
> Just sending a test message.
> </body>
> </message>
>
> When message-oriented protection is provided, they just
> encrypt the body. So, you get something that looks like:
>
> <message to='ekr@jis.mit.edu/MIT' type='chat'>
> <body>This message is encrypted.</body>
> <x xmlns='jabber:x:encrypted'>
> hQEOA8Ef5HX92uUXEAP/eaVgfupA3NJh8LIoMot3PK7BPRMc1zwCTK/9ss+6esS+
> hxKAzJ/58A5BX98EXe6MvJ2yFKaqcwUb1BQEBGDQlLBBSZLEuhrk6+Xo/poi1q8G
> w4bLaq0yekgidybYsdoyw9FonYn8VdlaYanSA+xx3KRU35bbUIbiSd667Ys9GL8D
> /3ek15+Rdlg5AGfetrjEFV4Pz1NNcP792LymlH+JTdbFPEmji+Pb/UcpX6t0CIul
> LJHGMVE65o2cwu8Hw1Jed7b6Bi0hYDT9LSa6ZC4Futx80xfeu9vCqCqo0TVuf7hm
> Ql8Hrd9gFohUiGrWEG9lDk2C6UimE/5EqUVwn2X425uw0ogB4MhiWvrsQcStHUkt
> xrkj0d5kdaT0vAzpyWYwbD4hCBNiu17yC6FHtKVRjWRCn5U8CeQjlpmY4cEXeYsd
> lkzCrobNLmrxTr6z7sNzPkJB4wU2cmySOLCH407/ynlgEu4N1QlgqYQzUwpJ+lfq
> BYF1+1F9a4tr6ymooqlCNdDyrN3q7r1xKem3
> =yxOO
> </x>
> </message>
>
> When you unpack the attached PGP message, you just get the actual
> message text. So, the PGP block above is just the encryption of
> "test message".
>
> However, sensitive information is often contained in the stanzas,
> so the current proposal on the table is to wrap the entire stanza
> and then replicate the routing information in the unencapsulated
> stanzas. This would give you something like this. (Note that
> everything in [ ] is in "crypto-vision". I.e. you're seeing
> something that would ordinarily be encrypted.
>
> <message to='warlord@jis.mit.edu/Gabber@JIS.MIT.EDU' type='chat'>
> <x xmlns='http://jabber.org/protocol/e2e/'>
> [
> <message to='warlord@jis.mit.edu/Gabber@JIS.MIT.EDU' type='chat'>
> <body>
> Just sending a test message.
> </body>
> </message>
> ]
> </x>
> </message>
>
> Ignore the horrifying misuse of XML namespaces. That's the way the
> XMPP guys do things. I understand they're fixing it.
>
> Anyway, it's pretty clear that messages of this type will be
> incompatible with other IM implementations. In particular, they'll
> be incompatible with SIMPLE messages. There's obviously no
> problem with the gateway translating the wrapper into whatever
> SIMPLE-oid wrapper is required to indicate that message
> protection has been performed, but this still leaves the embedded
> payload which the gateway can't touch.
>
> The only way that this can work properly is if SIMPLE and XMPP share
> some common format that is what goes in the protected payloads.
>
> Roughly speaking, this leaves 4 choices.
>
> (1) Have XMPP proceed as-is. This means no compatibility btwn
> XMPP and SIMPLE.
> (2) XMPP and SIMPLE both implement some common format, but only
> when they're interoperating.
> (3) XMPP and SIMPLE use some common format in end-to-end encryption
> mode but separate formats otherwise.
> (4) XMPP and SIMPLE have some common payload format at all times.
>
>
> Peter Saint-Andre's message of Mar 27, 2003
> (http://www.jabber.org/pipermail/xmppwg/2003-March/000836.html
) suggests
that he wants to do (2) above. IMHO this is a bad idea. These payload
formats have a tendency to get increasingly bloated and trying to keep
an XMPP and CPIM payload format with different syntax but the same
semantics in sync sounds really awful. (3) seems incoherent for
the same reason. Better to bite the bullet now if we're going to at all.
Note that I haven't specified what that common payload format is, since
that's a somewhat orthogonal issue. My understanding was always that
this was what CPIM MSGFMT (draft-ietf-impp-cpim-msgfmt-08.txt) was for.
I haven't really looked at MSGFMT, but a quick scan suggests it's mostly
adequate. As I understand things, SIMPLE currently uses CPIM.
>From an architectural perspective, it doesn't matter what the common
format looks like as long as there is one.
-Ekr