[Standards] XEP-0045: direct invitations

Peter Saint-Andre stpeter at jabber.org
Fri Jul 20 16:26:06 UTC 2007

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 direct
>>>> or usual presence? 
>>>> Sends both?
>>> Perhaps. Inviting people to rooms happens infrequently enough that it's
>>> not a bandwidth issue. But it may be confusing for the receiving client
>>> 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 or 
>>  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 inviter,
> 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, the
> normal one could come, so it would take its' data as relevant instead of
> 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 according
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070720/de72835f/attachment.bin>

More information about the Standards mailing list