Richard Dobson wrote:
The key is that it is impossible to identify the real @.
Any thoughts?
This was already discussed at length on either this list or might have
been jdev a few weeks ago, your first way is the only valid one as
everything after the first / is the resource pretty much
[EMAIL PROTECTED] schrieb:
I think if we want to solve this in a compatible way we should just
let the muc server block multiple nicks in the same room with only
differ in case (rephrase that in Stringprep section numbers, etc)
If a server works that way (and maybe announces with a status code
Peter Saint-Andre wrote:
Michal 'vorner' Vaner wrote:
So just one last question - how does a client know, when to send direct
or usual presence?
Sends both?
Perhaps. Inviting people to rooms happens infrequently enough that it's
not a bandwidth issue. But it may be confusing for the
[EMAIL PROTECTED] wrote:
On Thu, Jul 19, 2007 at 02:36:25PM -0600, Peter Saint-Andre wrote:
Currently in XEP-0045, roomnicks are case-sensitive. To be precise
roomnicks are handled according to the Resourceprep profile of stringprep:
http://www.xmpp.org/extensions/xep-0045.html#bizrules-jids
Ian Paterson wrote:
*Maybe* we need to consider addressing the valid reasons that Google
Talk feels it needs this policy, rather than handling the symptoms of
the policy? Can we solve the real problem? i.e. can we create enough
anti-spim protocols and/or infrastructure to make Google (and
