[Standards] XEP-0045: roomnick case
stpeter at jabber.org
Thu Jul 19 21:19:09 UTC 2007
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 (user at server) 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
Why not? We do have things like the service discovery identity:
name='A Dark Cave'
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards