[Standards-JIG] MUC Invitations, Jingle Relays, and Big Problems

Robert B Quattlebaum, Jr. darco at deepdarc.com
Fri Nov 3 00:48:37 UTC 2006

I think that there is a growing problem with respect to the practice  
of filtering stanzas from "unknown" JIDs. This practice is a pretty  
reasonable thing to do, and is simply a case of the server only  
allowing communication with people on your roster, or with people you  
have initiated communication with in the current session. For Google  
Talk users, such filtering is actually mandatory! I can only imagine  
that this policy is going to become more prevalent in the future.

However, there is a serious problem. Some of our protocols were  
written without this specific use case in mind.

For example, MUC invitations are completely broken in such a case. I  
fully understand the reasons why invitations are now handled thru the  
chatroom itself: it gives much more management flexibility. However,  
I think that this well-intentioned goal is quickly coming back to  
bite us.

Long ago, MUC invitations were sent between users. Such an invitation  
system would have worked fine with someone on a "paranoid" server.  
I'm sure that server authors could add a "hack" to make MUC  
invitations work, but I think that it is the wrong solution.

While not quite in the formal protocol, in a recent post Jean-Louis  
Seguineau described a mechanism for negotiating the use of a "jingle  
media proxy", by initiating a jingle session with the proxy, which  
would then initiate the session with the other user. This mechanism  
is broken in the same way MUC invitations are: unless the other user  
has recently used that jingle proxy or has it in their roster for  
some reason, they may never receive the call.

There are likely other examples that I can't think of at the moment.

I don't see this problem getting better—it is going to get worse.  
Filtering communications from unknown JID's is a perfectly reasonable  
thing to do, and I think that we should start making our protocols  
aware of this situation and stop punishing users for it.

Any ideas on how to handle this?

Robert Quattlebaum
Jabber: darco at deepdarc.com
eMail:  darco at deepdarc.com
www:    http://www.deepdarc.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061102/09f1e656/attachment.html>

More information about the Standards mailing list