[Standards-JIG] Unique room names for JEP-45
stpeter at jabber.org
Mon Jun 19 19:21:53 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Remko Troncon wrote:
> JEP-0045 (Multi-User Chat) describes the possibility of creating
> one-to-one chats into multi-user-chats, a feature present in most of
> today's IM protocols. However, to be able to do this, you need to be
> able to find a unique room name to create a new room, which is pretty
> complex to construct from the client. You can generate a hash of some
> kind, which has a high chance of indeed being unique. However, for
> correctness, you still have to account for it not being unique, which
> boils down to a trial and error protocol.
> How about we extend JEP-45 with support for an extra iq-based query,
> which returns a unique room name that the requester can use. For example:
> <iq type='get' from='joanna at chotchkies.com' to='conference.initech.com'>
> <query xmlns="http://jabber.org/protocol/muc#unique" />
> <iq type='result' to='joanna at chotchkies.com' from='conference.initech.com>
> <query xmlns="http://jabber.org/protocol/muc#unique">
> The MUC component would ensure that that roomname stays valid 'forever'.
> An implementation of this might be based on the SHA1 hash of the
> jid+timestamp, or microids, or ...
> Of course, since this is an extension, it would be an optional feature
> of the MUC component, published in service discovery.
> Any thoughts on this ?
The list consensus seems to be that this is nice but not necessary.
Perhaps it would be helpful to describe a recommended algorithm for
clients to use in creating room JIDs that won't collide? I have no
fundamental objections to asking the service for a room JID, but right
now it doesn't seem necessary to define a wire protocol for it (since
clients have everything they need to create a unique room JID).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards