On Tue, Aug 25, 2009 at 3:05 PM, Bernd Fondermann<bf_...@brainlounge.de> wrote: > ok, that's a slight relieve that the problem is not neccessarily with me.
he > there must be a way to defer the full jid at the moment the user is > entering the room, more specifically from the directed presence stanza. Well, yes and no. If the client send a full JID, that is true. But, as in the case of Smack, the client might not send a "from" attribute at all, in which case we will need to figure out a resource anyways (not sure yet what the best way is or if the spec says this somewhere). Also, the spec allows for a user to be in a room with multiple resources. Here's what the spec says: "However, if the bare JID <localp...@domain.tld> of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm)." /niklas
