Re: [Standards] XEP-0045: roomnick case

2007-07-27 Thread Robin Redeker
On Fri, Jul 27, 2007 at 09:17:03AM +0530, Mridul Muralidharan wrote:
 Jack Moffitt 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
 
 This means that the following roomnicks are all different:
 
 StPeter
 stpeter
 STPETER
 
 Some people have pointed out that this can be confusing to end users.
 
 Not only this, but it's very easy to steal someone's identity when
 they are not there.  You just log in with their normal nick.
 
 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 in the client.  All this nick stuff stuff is so
 IRCish anyway.  It's nice if what you want is an anonymous room, but
 for everything else, it's just a mess IMO.
 
 After trying several solutions we found that this was least confusing
 to everyone and we have gotten no complaints except for the occasional
 jerk that signs up with a name like st.peter or stpeter_, but there's
 little you can do about that but ban the offenders.
 
 jack.
 
 Unless rooms are not anonymous, clients have no way to validate who the 
 participants are anyway - so it is not really stealing : you dont 
 register the nick, it is not tied to your jid in any way.
 In anonymous rooms you dont know who the participants are - so relying 
 on nicks to give a hint of the identity would be wrong.

I guess the problem here is to explain this to the users.


Robin


Re: [Standards] XEP-0045: roomnick case

2007-07-27 Thread Etan S. C. Reisner
On Thu, Jul 26, 2007 at 09:05:15PM -0600, Jack Moffitt wrote:
snip
 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 in the client.  All this nick stuff stuff is so
 IRCish anyway.  It's nice if what you want is an anonymous room, but
 for everything else, it's just a mess IMO.

 After trying several solutions we found that this was least confusing
 to everyone and we have gotten no complaints except for the occasional
 jerk that signs up with a name like st.peter or stpeter_, but there's
 little you can do about that but ban the offenders.

 jack.

For the record, it was considerations like this that drove us at my last
job to implement room nockname locking, and get the language for it
improved in the XEP.  Which works perfectly in a non-federated controlled
account setting, and works to a reasonable degree otherwise.

-Etan


Re: [Standards] XEP-0045: roomnick case

2007-07-20 Thread Peter Saint-Andre
[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

 This means that the following roomnicks are all different:

 StPeter
 stpeter
 STPETER

 Some people have pointed out that this can be confusing to end users.

 
 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 on
 join) the clients MAY do local case folding as they like.
 
 I think this should be allowed without changing the muc XEP at all,
 it's just something the implementation would need to code.
 
 We could solve it by applying the Nodeprep profile of stringprep, but
 that would forbid things like whitespace and the ' and : characters.
 (Naturally, those characters could be escaped using XEP-0106 if desired.)

 
 I don't think we should restrict nicks more. Or rather i think
 nick restrictions should be left to the implementation and it's
 admins/muc owners.

That seems like a very reasonable approach.

I'll work up some language along those lines for the spec.

/psa


smime.p7s
Description: S/MIME Cryptographic Signature


[Standards] XEP-0045: roomnick case

2007-07-19 Thread Peter Saint-Andre
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

This means that the following roomnicks are all different:

StPeter
stpeter
STPETER

Some people have pointed out that this can be confusing to end users.

We could solve it by applying the Nodeprep profile of stringprep, but
that would forbid things like whitespace and the ' and : characters.
(Naturally, those characters could be escaped using XEP-0106 if desired.)

Thoughts?

/psa



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [Standards] XEP-0045: roomnick case

2007-07-19 Thread Peter Saint-Andre
Peter Saint-Andre wrote:

 We could solve it by applying the Nodeprep profile of stringprep, but
 that would forbid things like whitespace and the ' and : characters.
 (Naturally, those characters could be escaped using XEP-0106 if desired.)

Er, that's wrong. XEP-0106 is for node identifiers only.




smime.p7s
Description: S/MIME Cryptographic Signature


RE: [Standards] XEP-0045: roomnick case

2007-07-19 Thread Chris Mullins
The underlying problem, I believe, is one that's come up before - resources 
that have semantic meaning are very limiting. 

I think the IDEAL option is MEP:

- The MUC room defines a PubSub Node of the same ID. Everyone in the room is 
listed as a subscriber. Everyone visible in the room is defined as a publisher. 

- You nickname is stored in the PubSub Node. When you change it, it gets pushed 
to everyone. 

The actual push format would probably conform to User Location (XEP-0080) or to 
User NickName (XEP-0172).

I wouldn't be opposed to creating a new RoomNamePrep profile that (on the 
server) checked for duplicate names. The visible portion of the names would 
be left alone for user display, but the server would be normalizing them, and 
checking for (and forbidding) dupes. This profile would probably do: Case 
Folding, KC Normalization, and RLCat checking, and very minimal prohibited 
character checking. I know for us, creating a new stringprep profile is 
trivial, so long as it uses a subset of the StringPrep tables that already 
exist. 

To go one step further, I would like to see room names defined this way as 
well. This means the actual room name ([EMAIL PROTECTED]) would be a GUID, and 
the PubsubNode name would also be that same guid. On that node is the room name 
- complete with spaces, and visible in many language (New User Room, 
Nouvelle Pièce D'Utilisateur, 新しいユ�`ザ�`部屋, etc). 

One of the things I see that frustrates users is creating new rooms - they 
don't know what to name it. I would really like to default to a GUId for the 
room name (guaranteed unique), and a friendly name of Chris's Room or 
Chris's Room 958, but can't due to stringprep considerations. 

I do realize these are breaking changes, and MUC has been awfully stable for a 
long time now. The limitations we're starting to see with MUC could be largely 
solved by tying a PubSub node to it, and moving forward from there. 

--
Chris Mullins

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Saint-Andre
Sent: Thursday, July 19, 2007 1:36 PM
To: standards@xmpp.org
Subject: [Standards] XEP-0045: roomnick case

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

This means that the following roomnicks are all different:

StPeter
stpeter
STPETER

Some people have pointed out that this can be confusing to end users.

We could solve it by applying the Nodeprep profile of stringprep, but
that would forbid things like whitespace and the ' and : characters.
(Naturally, those characters could be escaped using XEP-0106 if desired.)

Thoughts?

/psa



Re: [Standards] XEP-0045: roomnick case

2007-07-19 Thread Peter Saint-Andre
Rachel Blackman 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

 This means that the following roomnicks are all different:

 StPeter
 stpeter
 STPETER

 Some people have pointed out that this can be confusing to end users.

 We could solve it by applying the Nodeprep profile of stringprep, but
 that would forbid things like whitespace and the ' and : characters.
 (Naturally, those characters could be escaped using XEP-0106 if desired.)

 Thoughts?
 
 My thought is that if roomnicks are to be treated as generic resources,
 then we should rethink the idea that resources are not visibly
 meaningful to the end user.  (In most cases, I'm in favor of the
 resources being visually meaningless, but the same rules do not apply to
 roomnicks.)

Yes, roomnicks *are* meaningful by the very way that MUC was designed
(and groupchat 1.0 before that).

 Otherwise, I think we may want to come up with a separate 'visually
 identifying resource' profile which is basically a case-insensitive
 resourceprep, and use that for MU-C roomnicks,
 cooperative-browsing/virtual chatroom roomnicks, and so on.

Yeah, I was just thinking that we may need Nickprep. It could also be
applied here:

http://www.xmpp.org/extensions/xep-0172.html

/psa


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [Standards] XEP-0045: roomnick case

2007-07-19 Thread Robin Redeker
On Thu, Jul 19, 2007 at 03:19:09PM -0600, Peter Saint-Andre wrote:
 Chris Mullins wrote:
 
  I think the IDEAL option is MEP:
 
 If we were redesigning things from scratch, probably.
 
 But we're not redesigning things from scratch. :)

What are we're doing then? Patching/Hacking up nearly 10 year old
standards so that they do something similiar to what we want?

(I don't neccessarly vote for Nicks over Pubsub here,
even though it's a nice application of Pubsub once again,
I think it should at least be tried in a sample implementation.
Unfortunately that would be a lot of work for nothing.)

 Breaking changes are bad.
 
 How can we meet people's needs without breaking things?

By breaking the people.


Robin