[Standards] XEP-0045: roomnick case

Peter Saint-Andre 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
> considerations.

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...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070719/90903c9d/attachment.bin>

More information about the Standards mailing list