[Standards-JIG] Unique room names for JEP-45

Peter Saint-Andre stpeter at jabber.org
Mon Jun 19 19:21:53 UTC 2006

Hash: SHA1

Remko Troncon wrote:
> Hi,
> 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>
> <iq type='result' to='joanna at chotchkies.com' from='conference.initech.com>
>   <query xmlns="http://jabber.org/protocol/muc#unique">
>       <room>f611da2d4a3ba6f57fd9942b708362a7da1aba4a</room>
>   </query>
> </iq>
> 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).

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060619/d1e7f90f/attachment.bin>

More information about the Standards mailing list