[Standards] [XEP-0045 v. 1.23pre3] outsiders and 'broadcast' invitations

[James Tomson]

On Oct 23, 2007, at 4:31 AM, Tomasz Sterna wrote:

> Dnia 21-10-2007, N o godzinie 15:42 -0400, James Tomson pisze:
>> In addition to 'broadcast invitations', we have added extensions to
>> allow the inviter to cancel its pending invitations at any time, or
>> have the room do it on their behalf after a specified timeout. For
>> the sake of brevity I won't stanza-spam these case unless there is
>> interest :D
> [snip]
> I think, that we should document best practices to do so, and
> standardize the extensions you had described, in sake of
> interoperability.
> So please, do share. :-)  It's the reason this list was created  
> for. :-)

Happy to :D

This is how we specify a timeout for invites -

firstwitch sends 'broadcast' invitation to thirdwitch, set to expire  
in half an hour:
--
<message from='crone1 at shakespeare.lit/desktop'
          to='darkcave at macbeth.shakespeare.lit'
          type='groupchat'>
   <x xmlns='http://jabber.org/protocol/muc#user'
         xmlns:wmi='wimba:muc:invite'>
     <invite to='hag66 at shakespeare.lit'
                  wmi:ttl='1800'/>
   </x>
</message>
--

thirdwitch receives invitation from room, with ttl and timestamp:
--
<message from='darkcave at macbeth.shakespeare.lit'
                     to='hag66 at shakespeare.lit'
                     type='groupchat'>
   <x xmlns='http://jabber.org/protocol/muc#user'
         xmlns:wmi='wimba:muc:invite'>
     <invite from='crone1 at shakespeare.lit/desktop'
                  wmi:timestamp='2007-10-31T23:52:22'
                  wmi:ttl='1800'/>
   </x>
</message>
--

After a half hour passes with no response (thirdwitch does not join  
the room, or send decline), the room will send an invitation  
cancelation to thirdwitch:

note: timeout flag element
--
<message from='darkcave at macbeth.shakespeare.lit'
                     to='hag66 at shakespeare.lit'
                     type='groupchat'>
     <x xmlns='wimba:muc:invite'>
        <cancel-invite from='crone1 at shakespeare.lit/desktop'>
          <timeout/>
       </cancel-invite>
     </x>
</message>
--

room also 'broadcasts' this cancelation to the occupants of darkcave  
(message to secondwitch shown):
--
<message from='darkcave at macbeth.shakespeare.lit'
                     to='wiccarocks at shakespeare.lit'
                     type='groupchat'>
   <x xmlns='http://jabber.org/protocol/muc#user'
        xmlns:wmi='wimba:muc:invite'>
     <item affiliation='owner'
                nick='firstwitch'
                jid='crone1 at shakespeare.lit/desktop'
                role='moderator'/>
     <wmi:cancel-invite to='hag66 at shakespeare.lit>
       <timeout/>
     </wmi:cancel-invite>
   </x>
</message>
--

A policy we've set up is that when the instant-room is destroyed  
(last occupant has left), the room will send <cancel-invite/>  
messages to all jids with pending invites automatically.


In another use case, firstwitch cancels her invitation to thirdwitch  
explicitly:
--
<message from='crone1 at shakespeare.lit/desktop'
          to='darkcave at macbeth.shakespeare.lit'
          type='groupchat'>
   <x xmlns:wmi='wimba:muc:invite'>
     <cancel-invite to='hag66 at shakespeare.lit'>
       <reason>bah!</reason>
     </cancel-invite>
   </x>
</message>
--

then the room will 'broadcasts' this cancelation as a normal  
groupchat message to the occupants of darkcave:
--
<message from='darkcave at macbeth.shakespeare.lit/firstwitch'
                     to='wiccarocks at shakespeare.lit/laptop'
                     type='groupchat'>
   <x xmlns:wmi='wimba:muc:invite'>
     <cancel-invite to='hag66 at shakespeare.lit>
       <reason>bah!</reason>
    </cancel-invite>
   </x>
</message>
--

The difference here is that this explicit cancelation is from  
firstwitch's room resource, and therefore lacks the muc#user <item/>.

To that end, when a new occupant joins, this is what the 'pending  
invites push' message, from the room, contains as many <x  
xmlns='http://jabber.org/protocol/muc#user' /> elements with items,  
and invite child elements, as there are distinct inviters with  
pending invitations.

This last point may benefit from a stanza example, but I am currently  
out of witches :D

-James
----
james at wimba dot com