On Sun, Jan 31, 2010 at 6:29 AM, Karthik Kailash < [email protected]> wrote:
> >> It's not explicitly spelled out in XEP-0045 one way or the other, but > >> I can't think of a reason it should happen (since the spec says "If a > >> MUC service receives such extended presence information from an > >> occupant, it MUST NOT reflect it to other occupants.") > >> > >> My personal preference is to spell out explicitly that this SHOULD > >> NOT occur (I'm also ok w/ MUST NOT :) ), as I can't see a valid > >> reason for having multiple, and a client-side assurance that there > >> won't be multiple simplifies code. > > > I'm in favor of MUST NOT. > > +1 > I'm probably a little late to the game here, but why does the spec say a > MUC service MUST NOT forward extended presence information to other > occupants? From personal experience, it is a useful business case, for > example when an application is built on top of MUC and its users have > extended identity information that they want to share with the other > application users in the room. > > I think you misunderstood what was being referred to as extended presence information. This is about multiple <x xmlns=" http://jabber.org/protocol/muc#user"/> elements not being allowed. Other information can certainly be included in presence (e.g., MUC avatars are advertised using presence). You are free to have your own custom XML. -- Waqas Hussain
