Re: [Standards] XEP-0045: roomnick case
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 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
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
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. Mridul
Re: [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. 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.
Re: [Standards] XEP-0045: roomnick case
Michal 'vorner' Vaner wrote: > Anyway, I think people are able to recognize the case, you use lower and > upper case in normal writing too… You're probably smarter than most people. I know that server vendors are receiving feature requests to disambiguate roomnicks. If we leave wiggle room in the spec regarding the conflict error (you can be smart about it if you want to apply more advanced conflict-matching rules), then I think we've addressed the need. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: roomnick case
Hello On Fri, Jul 20, 2007 at 07:19:53PM +0200, Remko Tronçon wrote: > > I'm late posting, but case-sensitivity is just one of many ways that room > > nicks can be confusing. "StPeter" vs "St.Peter" vs "St. Peter" vs > > "St Peter", or even "StPeter " -- and then there are all the visually > > confusable Unicode glyphs. ("StΡeter".) It's not obvious to me that > > case-folding is the worst of these. > > That's true. That's why Textshell's proposal of leaving it up to the > server to decide what's duplicate and what not is the best way to go. > A simple implementation does no checking at all, whereas a very > complex implementation could use an algorithm to calculate similarness > of nicknames (taking into account the whole Unicode set and > spaces/dots/characters in between characters, ...), and reject the > ones that are too similar. I would not push it to that extreme - what if your client freezes/crashes/whatever and your nick stays hanging there? Then it is usual to come back as nick_ or something like that. Anyway, I think people are able to recognize the case, you use lower and upper case in normal writing too… -- Fragile. Do not turn umop ap1sdn! Michal 'vorner' Vaner pgp0tzmdAAAZM.pgp Description: PGP signature
Re: [Standards] XEP-0045: roomnick case
Remko Tronçon wrote: >> I'm late posting, but case-sensitivity is just one of many ways that room >> nicks can be confusing. "StPeter" vs "St.Peter" vs "St. Peter" vs >> "St Peter", or even "StPeter " -- and then there are all the visually >> confusable Unicode glyphs. ("StΡeter".) It's not obvious to me that >> case-folding is the worst of these. > > That's true. That's why Textshell's proposal of leaving it up to the > server to decide what's duplicate and what not is the best way to go. > A simple implementation does no checking at all, whereas a very > complex implementation could use an algorithm to calculate similarness > of nicknames (taking into account the whole Unicode set and > spaces/dots/characters in between characters, ...), and reject the > ones that are too similar. Right. And IMHO the implementation would always return the same error for that: http://www.xmpp.org/extensions/xep-0045.html#enter-conflict /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: roomnick case
I'm late posting, but case-sensitivity is just one of many ways that room nicks can be confusing. "StPeter" vs "St.Peter" vs "St. Peter" vs "St Peter", or even "StPeter " -- and then there are all the visually confusable Unicode glyphs. ("StΡeter".) It's not obvious to me that case-folding is the worst of these. That's true. That's why Textshell's proposal of leaving it up to the server to decide what's duplicate and what not is the best way to go. A simple implementation does no checking at all, whereas a very complex implementation could use an algorithm to calculate similarness of nicknames (taking into account the whole Unicode set and spaces/dots/characters in between characters, ...), and reject the ones that are too similar. cheers, Remko
Re: [Standards] XEP-0045: roomnick case
On Fri, 20 Jul 2007, [EMAIL PROTECTED] wrote: 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. I'm late posting, but case-sensitivity is just one of many ways that room nicks can be confusing. "StPeter" vs "St.Peter" vs "St. Peter" vs "St Peter", or even "StPeter " -- and then there are all the visually confusable Unicode glyphs. ("StΡeter".) It's not obvious to me that case-folding is the worst of these. Is there any kind of spec for visually distinguishable strings? (Beyond "case-folding is easy", which is a searching-under-the-streetlight kind of solution.) If not, better to let implementations deal with it, because the problem will evolve over time. --Z -- "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..." * If the Bush administration hasn't subjected you to searches without a warrant, it's for one reason: they don't feel like it. Not because you're innocent.
Re: [Standards] XEP-0045: roomnick case
[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
Re: [Standards] XEP-0045: roomnick case
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. - Martin H.
Re: [Standards] XEP-0045: roomnick case
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
Re: [Standards] XEP-0045: roomnick case
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. :) > 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. Yes, that could be done in the background without the user caring. Nickprep sounds like a good idea. > 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). No objections to room JIDs being GUIDs. Then of course you need a friendly name. The best way to do that is yet to be determined. > 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. Why not? We do have things like the service discovery identity: But perhaps those are not exposed to the user. > 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. Breaking changes are bad. How can we meet people's needs without breaking things? Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: roomnick case
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
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
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.) 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. -- Rachel Blackman <[EMAIL PROTECTED]> Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] XEP-0045: roomnick case
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
[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 smime.p7s Description: S/MIME Cryptographic Signature