> > There is a very obvious solution to this which everyone seems to be > > overlooking: we need a new element with a guaranteed unique, non-spoofed > > UUID; should a server feel the need to do bad things, it can set the > > 'spoofed' attribute to true and then clients can act accordingly. > what entity would set that element? the sending client? the server of that > client? the server of the receiving client?
It was meant to be a joke about the number of stanza id mechanisms - clearly, the solution is another stanza id mechanism! (I'd hoped the 'spoofed' attribute made it obvious I wasn't serious.) But, being serious: the issue is that both clients and servers need an id for referring to stanzas, and if that id is dependably unique then it solves a number of difficulties; the reason we have problems is that the original RFC-defined 'id' attribute had no such requirements, and so id can't be depended upon. So, if the originator of a stanza (sending client, usually) guarantees that its id is unique (and you also trust that guarantee) then there should be no reason for anyone else to add their own id mechanism - both the client and server can use the id for referencing (servers can still use their own internal ids for indexing and such, but the 'long' id is for all public-facing referencing), and then there's no need for the client to check which id the server gave the stanza (it's the same.) XEP-0359 attempts to do exactly this, but it only works dependably if everyone uses it, and legacy clients don't/can't. If a server does spoof ids for malicious purposes, there is no protection against this (without resorting to cryptographic signatures, which brings its own difficulties) and no amount of additional ids would help (it could spoof those too.) XMPP 2.0 will solve all of these problems, of course.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
