-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mostly just thinking aloud here... ;-)

I've been thinking more about the multi-resource case, i.e., allowing
multiple full JIDs to have in-room sessions associated with the same
roomnick. For the moment I'm focused on presence. If a user has
multiple devices associated with a roomnick, I'd like to share the
device capabilities (XEP-0115 data) with all the room occupants. I
*think* this works OK if the MUC room simply passes the presence data
through to the room...

<presence from='[email protected]/user1'>
  <c xmlns='http://jabber.org/protocol/caps'
       hash='sha-1'
       node='http://code.google.com/p/exodus'
       ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
</presence>

<presence from='[email protected]/user1'>
  <c xmlns='http://jabber.org/protocol/caps'
       hash='sha-1'
       node='http://example.org/someclient'
       ver='JdyUr+T6oM2/7QiI5K0BriU0BdY='/>
</presence>

The room occupants might get confused because it might seem that the
user's single endpoint has changed capabilities. However, even in an
anonymous room the occupants could track capabilities if the caps
'node' values are different. Life is easier in a non-anonymous room
because then the full JID appears:

<presence from='[email protected]/user1'>
  <c xmlns='http://jabber.org/protocol/caps'
       hash='sha-1'
       node='http://code.google.com/p/exodus'
       ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none'
          jid='[email protected]/foo'
          role='participant'/>
  </x>
</presence>

<presence from='[email protected]/user1'>
  <c xmlns='http://jabber.org/protocol/caps'
       hash='sha-1'
       node='http://example.org/someclient'
       ver='JdyUr+T6oM2/7QiI5K0BriU0BdY='/>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='none'
          jid='[email protected]/bar'
          role='participant'/>
  </x>
</presence>

Here, occupants' clients can tell that the first presence comes from
the "foo" resource whereas the second presence comes from the "bar"
resource. Receiving clients would need to perform some kind of
client-side composition if they want to offer an interface to the
differing capabilities of the sender's devices, but that's really no
different from the non-MUC case.

OK, I've convinced myself that there's no problem here, but feel free
to disagree with me (heck, I often disagree with myself!). ;-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDSJU4ACgkQNL8k5A2w/vxeJQCcCuHun8UTDWVghiSJl3TXwFns
2mUAnjkuR/LQiVVq4o3w6lAU5oQWkCma
=POxs
-----END PGP SIGNATURE-----

Reply via email to