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

Peter Saint-Andre stpeter at jabber.org
Tue Nov 7 16:30:39 UTC 2006


Jean-Louis Seguineau wrote:
> Peter, this is interesting. I am not certain it will answer all cases
> though.

My suggestion about sharing directed presence between conversation
partners who aren't in each other's rosters is simply a good practice
I'd like to see adopted -- it's not intended to solve any problems. :-)

> The original reason for which Robert (Darco) bought up the subject was
> initially related to GTalk filtering out traffic not originating from one of
> your buddies (he called it "paranoid" filtering ;)

Yes, I don't think paranoia is justified on the XMPP network. Yet. ;-)

The key, to me, is working to make the XMPP network high trust, so that
we can (mostly) trust the network itself and not be individually
paranoid about particular addresses on the network (unless we have
reason to be paranoid about them, naturally).

> He also pointed out that more and more features in XMPP are now
> "intermediated", for example MUC invites are sent to a user by the room, and
> PubSub also has case where notifications come from the service.
> 
> So his question was wider than just 1-to-1 user's conversation in an instant
> messaging application. You'll certainly agree that a user cannot have
> unknown MUC rooms in its roster, nor all topics of a PubSub application...
> 
> In the end it brings several questions:
> - How should we approach this issue for non IM applications?
> - If we use it for IM, isn't it going to conflict with other XEPs, such as
> XEP-0155? 
> - How would we deal with "intermediated" features such as MUC, PubSub and
> most probably Jingle.
> 
> What do you think?

See above. I think we need to work on building trust in the network as a
whole. For example, it might help if most servers on the network (and by
extension add-on services hosted at subdomains of those servers, such as
MUC and pubsub services) were identified by X.509 certificates. That's
one reason I've been working on a proposal to establish an intermediate
certification authority for the XMPP network:

http://www.jabber.org/jsf/ica-proposal.html

/psa


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061107/59318dd2/attachment.bin>


More information about the Standards mailing list