The service does have to add the room to the OK list either way, so I
agree, in this way they are the same. But if the client is old, and
does not recognize the set, it will return an error, which allows you to
go to the social technique. If you use a direct invite message, the
message will go in
Toly Menn wrote:
> Wouldn’t you have the same problems with the actual messages that
> come from the MUC, i.e., they would be blocked by the client? I am
> not familiar with how block list work, but no matter where the invite
> comes from, once the client joined the meeting, the client will need
>
Peter Saint-Andre wrote:
>> Either way, this may be a good clarification
>> in 3920bis as well.
>
> It's on the way. Might even be in my working copy already, I'll have to
> check.
Here is a diff:
http://svn.xmpp.org:18080/browse/XMPP/trunk/internet-drafts/draft-saintandre-rfc3920bis-04.xml?%40
Hi Toly,
Toly Menn wrote:
>> An XML stream always goes in one direction, it's just that in the c2s
>> case both streams go over the same TCP connection, whereas in the s2s
>> case there are two TCP connections. However, as Justin says, the
>> directionality matters only for the sending of stanzas,
Matthias Wimmer wrote:
> Robin Redeker schrieb:
>> I propose to rename the XEP to make clear that this escaping/unescaping
>> should
>> only happen in very rare cases (only at gateways or heavily specialized
>> client
>> frontends). And that the terms 'escaping' and 'unescaping' are replaced by
>
On Thu, Jul 26, 2007 at 09:05:15PM -0600, Jack Moffitt wrote:
> At Chesspark we make all public rooms non-anonymous and we always show
> the full jid or (if they are in your roster) the roster nick for that
> person. That way no one is ever confused who is who. So we've
> basically solved this i
