On Tue, Jun 11, 2013 at 5:38 PM, Bartosz Małkowski <bmalkow...@tigase.pl>wrote:
> Hi > > I have a problem. > Our MUC Component supports entering to room from many resources (the same > bareJID) with the same nickname. > I don't know what should be sent in attribute jid of element <item/> when > room is Non-Anonymous: > <presence > from='co...@chat.shakespeare.lit/thirdwitch' > id='17232D15-134F-43C8-9A29-61C20A64B236' > to='cro...@shakespeare.lit/desktop'> > <x xmlns='http://jabber.org/protocol/muc#user'> > <item affiliation='none' > jid='ha...@shakespeare.lit/pda' > role='participant'/> > </x> > </presence> > > Let me explain: > > To room joins: > a@b/1 and a@b/2 with nickname XXX. > > 1. New occupant joins to room, then MUC must send to him presence of > occupant "XXX". > Which fullJID should be in attribute jid? Or maybe bareJID? > Or maybe two <item/> with both fulljids? > Or maybe two presences from XXX (with one <item/> element)? > > Anything you like as long as it conforms. I think M-Link picks one fairly arbitrarily, and Prosody might well do the same. Bare jid seems sensible too, and indeed in general rather than just for the nick-share case. > 2. a@b/1 change his presence. What MUC should send to all occupants: > bareJID, fullJID of a@b/1, two <items/>? > Same as above. I *think* that M-Link just sends individual presence changes through, so if nick-shares are alternating, the jid will also change. The more interesting question is what to do with private messages, or - worse - pass-through <iq/> stanzas. Isn't life fun when you take a step or two beyond the standards? :-) FWIW, this all gets even more fun if you're nick-sharing based on role, rather than merely bare jid. So, for example, if you have a "MedEvac" nickname, which can be used by any jid which has an approved (non-XMPP) MedEvac role. You may well want the real jid exposed, still, but it's not at all clear how. What this exposes is that when MUC was designed, it conflated two orthogonal things - addressing and naming. This was itself fine, when there was a 1:1 relationship - but the moment you break that, that causes some interesting fractures. Obviously we don't actually want to break compatibility either - otherwise the solution is rather simple - but what we might want to do is think about the really hard cases (like the MedEvac one I invented above) and figure out what *should* happen there. One thing that would be sensible is if clients could indicate that they understood nick-sharing, and have additional information exposed to them. I should really write this up properly... But in the meantime, just do anything that works as long as it's indistinguishable to clients from the single-fulljid-per-nick case. Dave.
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
