>> 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.

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.

Of course, this could also be implemented by users sending broadcast messages 
to the room with the custom extension included, but the presence method has a 
2-fold advantage:

1. Meaning.  Information relating to identity just makes a lot more sense when 
it is in a presence message.
2. Caching.  I believe MUCs cache the most recent presence from their members, 
so now when a new person joins and receives the presence information of 
everyone else in the room, they are already caught up with the custom extension 
data as well, versus the clients having to send a new empty message with the 
custom extension out to the room.

Our application uses this functionality for users to share their identity 
information with the room, so I might be a little biased here :)

But, I do want to show that there is a legitimate case for using this, so a 
MUST NOT seems a little strong...a SHOULD NOT seems better.  Then again, 2 of 
the 3 XMPP server implementations we have tested with allow this behavior to 
occur.

I'm curious, what's the reasoning behind a MUST NOT here?

Cheers,
Karthik

Karthik Kailash | Product
SocialVision, Online Television Becomes a Social Experience
CELL • 408.768.7704  | WEB • www.socialvisioninc.com | FACEBOOK • 
facebook.com/socialvision | TWITTER • twitter.com/socialvision


Reply via email to