JEP-0045: 6.3.3 Presence Broadcast
If the service is able to add the user to the room, it MUST send
presence from all the existing occupants' room JIDs to the new
occupant's full JID, including extended presence information about
roles in an <x/> element qualified by the
'http://jabber.org/protocol/muc#user' namespace and containing an
<item/> child with the 'role' attribute set to a value of "moderator",
"participant", "visitor", or "none" and with the 'affiliation'
attribute set to a value of "owner", "admin", "member", or "none" as
appropriate:
what would a client be expected to do if it receives the following xml:
<presence
from='[EMAIL PROTECTED]/thirdwitch'
to='[EMAIL PROTECTED]/pda'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none' role='none'/>
</x>
</presence>
in case you missed the conflict: the presence type is available, but
the role is none. Clearly a conflict, but there don't even seem to be
any business logic rules indicated in the JEP on how to deal with this
case.
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
