[Standards] XEP-0045: direct invitations

Toly Menn TMenn at viack.com
Fri Jul 27 03:04:34 UTC 2007

Wouldn't you have the same problems with the actual messages that come
from the MUC, i.e., they would be blocked by the client?  I am not
familiar with how block list work, but no matter where the invite comes
from, once the client joined the meeting, the client will need to
unblock the room.
Would it not be easier to send a "set" iq to the client telling it to
expect an invite from a MUC of the specified name.  The client, having
you on its contact list, would get the IQ.  The new client would then
unblock the MUC JID for some time (1 minute), reply with "result" IQ
indicating success, and then process the invite as normal.  The old
clients will fail as before, but the inviting client will get an "error"
IQ from the old client that it does not recognize the "set", and will be
able to revert to the "social" technique.
Just a though...
Michal 'vorner' Vaner wrote:
> Hello
> On Fri, Jul 20, 2007 at 09:04:11AM +0100, Ian Paterson wrote:
>>  Peter Saint-Andre wrote:
>>> Michal 'vorner' Vaner wrote:
>>>> So just one last question - how does a client know, when to send
>>>> or usual presence? 
>>>> Sends both?
>>> Perhaps. Inviting people to rooms happens infrequently enough that
>>> not a bandwidth issue. But it may be confusing for the receiving
>>> to get two invitations. Then do we need some logic for checking
>>> duplicate invitations? Ick.
>>  This is definitely "Ick". But the other options (Aunt Tillie decides
>>  hardcode @gmail.com) are even worse.
> If the direct was not <invite/>, but something else, like
> <directinvite/> - old clients that do not know it would ignore them as
> they do not know them (anyway, they would try to connect to the
> not the muc, by the "from" address). And client that "knows" would
> receive it, show it to user and while waiting, if the user accepts,
> normal one could come, so it would take its' data as relevant instead
> the direct ones.
> So old client without block would receive the normal one and throw the
> direct one away, new one without block receives both and acts
> to the normal, new one with block gets only direct and old one with
> block is out of luck anyway no matter what we do. Right?
It seems like that might work. :)


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

More information about the Standards mailing list