[Standards] XEP-0045: direct invitations

Peter Saint-Andre stpeter at jabber.org
Thu Jul 19 22:18:56 UTC 2007


Michal 'vorner' Vaner wrote:

> On Thu, Jul 19, 2007 at 03:55:53PM -0600, Peter Saint-Andre wrote:
>> Understand that the main driver here is Google Talk. You can't receive
>> messages in Google Talk unless you add the sender of the incoming
>> message to your roster first. That doesn't work with random chat rooms,
>> with the result that Google Talk users can't join chatrooms on the
>> Jabber network. That's a shame. Direct invitations would enable us to
>> work around that.
> 
> I got that. I just don't like workarounds from the principle. But it is
> just my opinion.

I agree -- in principle. :)

> So just one last question - how does a client know, when to send direct
> or usual presence? 

I don't know. :/

> 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.

> Or user chooses? 

Probably not a good idea to force the user to choose.

> Or some heuristics?
> (@gmail.com -> direct, otherwise usual?)

Well @gmail is only one example. Other services may do that, too.

I understand why Google Talk has this policy, so I'm not going to argue
them out of it. But it does introduce complications.

Maybe your suggestion is best -- ask the MUC room what you should
include in the invitation and it tells you. If you include the invitee's
JID, the service could add the invitee to the member list at the same time.

But that's not the road we went down in 2002 or whatever, so changing it
now introduces potential incompatibilities.

/me ponders

Peter

-------------- 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/20070719/06659e05/attachment.bin>


More information about the Standards mailing list