Option 1: The occupant jid forwards nothing, but has a way of requesting a contact jid.Option 2: The occupant jid forwards everything to the user's bare jid, and their server "deals" with it.
Option 2 seems pretty ok to me. As you said forwarding of iq to fulljid has never had a way of actually working anyway -- it goes to a "random" fulljid of the ones joined. So unless we are going to have sub-addressing (and I think there are good reasons we don't want to if we want to keep semi-anon) I think going to the barejid as the default is all we really can do.
However I don't think we need to write this in a way that makes it impossible for a compliant implementation to make another choice. For example a MUC might intercept BoB requests, know which fulljid sent that originall, and forward there. Or other such advanced case-by-case things. But I think barejid is the right default.
I appreciate the simplicity of Option 1, but I think it's too simple - even for Private Messages I'd need to reveal my identity. If I'm in a sensitive room (say a healthcare related one) I might really want (or need) PMs but not be willing to reveal my identity.
I've long felt that full bidirectional PMs in a semi-anon MUC are more trouble than they're worth, but we do need some way to get eg a chat request through which I think would likely use message stanzas.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
