Re: [Standards] XEP-0045: requesting a unique room name
Maciek Niedzielski <[EMAIL PROTECTED]> wrote: > MUC server doesn't need any complex algorithm to generate a name that > is not used - it can pick a random name and simply check if it's > already used or not ;) On the server side, it doesn't even need to be a random number. It could just be a counter for example. But the client would always need a random number. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] XEP-0045: requesting a unique room name
Pavel Simerda wrote: On Thu, 14 Aug 2008 09:09:28 +0200 Yann Leboulanger <[EMAIL PROTECTED]> wrote: Peter Saint-Andre wrote: But then you have a dependency on the server side, right? Why not just generate a UUID on the client side? Because we don't know all the rooms that are opened, and we can't be sure our room name will be unique. You can't be sure the server won't burn when generating the UUID either... and it would cause more harm. MUC server doesn't need any complex algorithm to generate a name that is not used - it can pick a random name and simply check if it's already used or not ;) -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] XEP-0045: requesting a unique room name
This seems to be a good reason to keep things as they work :). Pavel On Thu, 14 Aug 2008 15:21:22 +0200 Jonathan Schleifer <[EMAIL PROTECTED]> wrote: > Am 14.08.2008 um 15:12 schrieb Kevin Smith: > > > Well, in this case what I imagined was a server that's happy to host > > short-lived one-to-one-to-many-to-many chats at randomly selected > > room names, but doesn't want to be hosting public chat rooms such as > > [EMAIL PROTECTED], but it's probably unimportant. > > > This is exactly what I also had in mind and is very desirable IMO. > Anyway, why change it? It doesn't make it too much more complicated > for the server and there are already clients using that. So why > remove something that is already in use? > > -- > Jonathan > -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0045: requesting a unique room name
Nothing is guaranteed, in practice. On Thu, 14 Aug 2008 15:20:26 +0200 "Remko Tronçon" <[EMAIL PROTECTED]> wrote: > > Um, the whole point of a UUID is that it's universally unique, no? > > No, the point of a UUID is that everybody can generate an ID that has > a (very) high probability of being unique; it's not, however, > guaranteed to be unique. > > cheers, > Remko -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0045: requesting a unique room name
On Thu, 14 Aug 2008 09:09:28 +0200 Yann Leboulanger <[EMAIL PROTECTED]> wrote: > Peter Saint-Andre wrote: > > Yann Leboulanger wrote: > >> Peter Saint-Andre wrote: > >>> Has any MUC implementation coded in support for the "unique room > >>> name request" feature described in Section 10.1.4 of XEP-0045? I > >>> think this feature is unnecessary and (in the interest of > >>> simplification) I would like to remove it from XEP-0045. > >> > >> In our client (Gajim), we use it for chat to muc convertion too. > >> If it's not supported by MUC component, we do nickname + random > >> number, but it's convenient to be sure we won't have a confict. > > > > But then you have a dependency on the server side, right? Why not > > just generate a UUID on the client side? > > > > Because we don't know all the rooms that are opened, and we can't be > sure our room name will be unique. > You can't be sure the server won't burn when generating the UUID either... and it would cause more harm. It's very improbable just as collisions in good UUIDs. -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0045: requesting a unique room name
Kevin Smith wrote: But then you have a dependency on the server side, right? Why not just generate a UUID on the client side? Well - turn this on its head: There are two options on the table. 1) Do it client side, and /probably/ everything works. 2) Do it server side (where it's easier), and everything certainly works, plus the server retains additional abilities, like access control to only server-provided room names. This also obeys 'simple client, complex server'. Currently we have (2) - is there any reason to move to (1). I was trying to remove unused, unnecessary features. Since it seems that this feature is in use and is deemed necessary or desirable, I'm happy to leave it in. :) Case closed. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: requesting a unique room name
Am 14.08.2008 um 15:12 schrieb Kevin Smith: Well, in this case what I imagined was a server that's happy to host short-lived one-to-one-to-many-to-many chats at randomly selected room names, but doesn't want to be hosting public chat rooms such as [EMAIL PROTECTED], but it's probably unimportant. This is exactly what I also had in mind and is very desirable IMO. Anyway, why change it? It doesn't make it too much more complicated for the server and there are already clients using that. So why remove something that is already in use? -- Jonathan
Re: [Standards] XEP-0045: requesting a unique room name
> Um, the whole point of a UUID is that it's universally unique, no? No, the point of a UUID is that everybody can generate an ID that has a (very) high probability of being unique; it's not, however, guaranteed to be unique. cheers, Remko
Re: [Standards] XEP-0045: requesting a unique room name
On Thu, Aug 14, 2008 at 4:50 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> Plus it's conceivable that a muc service would only want to serve >> rooms at addresses it supplies. > What difference does it make if the MUC service generates a UUID or the > client generates a UUID? One UUID is as good as another, I'd think. Well, in this case what I imagined was a server that's happy to host short-lived one-to-one-to-many-to-many chats at randomly selected room names, but doesn't want to be hosting public chat rooms such as [EMAIL PROTECTED], but it's probably unimportant. /K
Re: [Standards] XEP-0045: requesting a unique room name
Matthew Wild wrote: On Wed, Aug 13, 2008 at 6:41 PM, Justin Karneges <[EMAIL PROTECTED]> wrote: There are many places where a UUID may be appropriate, but I don't think this is one of them. You're desiring an unique handle to the MUC service, and the MUC itself is really the authority for that. How about: Client requests to create a room, using the best hash it can muster: Server supports unique extension, and the room already existed, so it replies with a new one: [EMAIL PROTECTED]/nick This saves the round-trip, and the worst case result (the server doesn't support the extension and the hash collides) is the same as what we have now. That seems like a reasonable approach. The only downside I see (other than the fact that we're painting the bikeshed ;-) is that the client might add a privacy rule for [EMAIL PROTECTED] when it attempts to create the room, so it might never receive the presence from [EMAIL PROTECTED] /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: requesting a unique room name
Kevin Smith wrote: I'd buy client-asserted hashes if conferencing was some peer-to-peer thing, but MUC is a client/server design. Plus it's conceivable that a muc service would only want to serve rooms at addresses it supplies. What difference does it make if the MUC service generates a UUID or the client generates a UUID? One UUID is as good as another, I'd think. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: requesting a unique room name
Justin Karneges wrote: On Tuesday 12 August 2008 23:01:13 Kevin Smith wrote: On Wed, Aug 13, 2008 at 12:24 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: Has any MUC implementation coded in support for the "unique room name request" feature described in Section 10.1.4 of XEP-0045? I think this feature is unnecessary and (in the interest of simplification) I would like to remove it from XEP-0045. Without checking, that was in the spec for converting the chat to muc case. I don't see the harm in leaving it there, but I think it'll come down to another argument about the impossibility of collisions on a guid. There are many places where a UUID may be appropriate, but I don't think this is one of them. You're desiring an unique handle to the MUC service, and the MUC itself is really the authority for that. Um, the whole point of a UUID is that it's universally unique, no? /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: requesting a unique room name
>> But then you have a dependency on the server side, right? Why not just >> generate a UUID on the client side? Well - turn this on its head: There are two options on the table. 1) Do it client side, and /probably/ everything works. 2) Do it server side (where it's easier), and everything certainly works, plus the server retains additional abilities, like access control to only server-provided room names. This also obeys 'simple client, complex server'. Currently we have (2) - is there any reason to move to (1). /K
Re: [Standards] XEP-0045: requesting a unique room name
Peter Saint-Andre wrote: Yann Leboulanger wrote: Peter Saint-Andre wrote: Has any MUC implementation coded in support for the "unique room name request" feature described in Section 10.1.4 of XEP-0045? I think this feature is unnecessary and (in the interest of simplification) I would like to remove it from XEP-0045. In our client (Gajim), we use it for chat to muc convertion too. If it's not supported by MUC component, we do nickname + random number, but it's convenient to be sure we won't have a confict. But then you have a dependency on the server side, right? Why not just generate a UUID on the client side? Because we don't know all the rooms that are opened, and we can't be sure our room name will be unique. -- Yann
Re: [Standards] XEP-0045: requesting a unique room name
Yann Leboulanger wrote: Peter Saint-Andre wrote: Has any MUC implementation coded in support for the "unique room name request" feature described in Section 10.1.4 of XEP-0045? I think this feature is unnecessary and (in the interest of simplification) I would like to remove it from XEP-0045. In our client (Gajim), we use it for chat to muc convertion too. If it's not supported by MUC component, we do nickname + random number, but it's convenient to be sure we won't have a confict. But then you have a dependency on the server side, right? Why not just generate a UUID on the client side? /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: requesting a unique room name
On Wed, Aug 13, 2008 at 6:41 PM, Justin Karneges <[EMAIL PROTECTED]> wrote: > There are many places where a UUID may be appropriate, but I don't think this > is one of them. You're desiring an unique handle to the MUC service, and the > MUC itself is really the authority for that. > How about: Client requests to create a room, using the best hash it can muster: Server supports unique extension, and the room already existed, so it replies with a new one: [EMAIL PROTECTED]/nick This saves the round-trip, and the worst case result (the server doesn't support the extension and the hash collides) is the same as what we have now. Matthew.
Re: [Standards] XEP-0045: requesting a unique room name
> I'd buy client-asserted hashes if conferencing was some peer-to-peer thing, > but MUC is a client/server design. Plus it's conceivable that a muc service would only want to serve rooms at addresses it supplies. /K
Re: [Standards] XEP-0045: requesting a unique room name
On Tuesday 12 August 2008 23:01:13 Kevin Smith wrote: > On Wed, Aug 13, 2008 at 12:24 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > Has any MUC implementation coded in support for the "unique room name > > request" feature described in Section 10.1.4 of XEP-0045? I think this > > feature is unnecessary and (in the interest of simplification) I would > > like to remove it from XEP-0045. > > Without checking, that was in the spec for converting the chat to muc > case. I don't see the harm in leaving it there, but I think it'll come > down to another argument about the impossibility of collisions on a > guid. There are many places where a UUID may be appropriate, but I don't think this is one of them. You're desiring an unique handle to the MUC service, and the MUC itself is really the authority for that. I'd buy client-asserted hashes if conferencing was some peer-to-peer thing, but MUC is a client/server design. -Justin
Re: [Standards] XEP-0045: requesting a unique room name
Hello, maybe you could use a hash function (or unique identifier) that has lower probability of random conflicts than the probability of random RAM errors :). Just joking, with computers, you can be never sure, so "almost sure" is usually good enough if it's just a matter of trying it again. (Btw, in my father's work, SAP got down because it sent the time 24:00 to the database :D, it happens rarely but happens.) I believe http://tools.ietf.org/html/rfc4122 is one of the possible ways to go :). Pavel On Wed, 13 Aug 2008 16:30:38 +0200 "Remko Tronçon" <[EMAIL PROTECTED]> wrote: > > How hard is it to generate a UUID or SHA hash? I suppose not all > > clients have access to such utilities... > > It's not generating the hash that was bothering me at the time, it was > more that the hash is not unique in theory, and that you would still > need to have conflict checking code in case it wasn't. But I guess the > likelihood of that happening is immensely close to zero, and if you > have a timestamp in there, it would be even closer to zero happening > twice in a row (i.e. the "Why didn't this work? I must have done > something wrong, let me try again"). So I suppose I should learn to > live with imperfection ;-) > > cheers, > Remko -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0045: requesting a unique room name
On Wed, Aug 13, 2008 at 12:24 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Has any MUC implementation coded in support for the "unique room name > request" feature described in Section 10.1.4 of XEP-0045? I think this > feature is unnecessary and (in the interest of simplification) I would like > to remove it from XEP-0045. > Gloox uses it, and falls back to a simple hash if the server returns an error (ie. doesn't support the request): http://camaya.net/api/gloox-trunk/classgloox_1_1UniqueMUCRoom.html Matthew.
Re: [Standards] XEP-0045: requesting a unique room name
> more that the hash is not unique in theory, and that you would still > need to have conflict checking code in case it wasn't. On the other hand, with the XEP extension you would need an extra step in the query/response flow, which makes the client more complicated anyway. So I changed my mind: you can remove it ;-) cheers, Remko
Re: [Standards] XEP-0045: requesting a unique room name
Peter Saint-Andre wrote: Has any MUC implementation coded in support for the "unique room name request" feature described in Section 10.1.4 of XEP-0045? I think this feature is unnecessary and (in the interest of simplification) I would like to remove it from XEP-0045. In our client (Gajim), we use it for chat to muc convertion too. If it's not supported by MUC component, we do nickname + random number, but it's convenient to be sure we won't have a confict. -- Yann
Re: [Standards] XEP-0045: requesting a unique room name
> How hard is it to generate a UUID or SHA hash? I suppose not all clients > have access to such utilities... It's not generating the hash that was bothering me at the time, it was more that the hash is not unique in theory, and that you would still need to have conflict checking code in case it wasn't. But I guess the likelihood of that happening is immensely close to zero, and if you have a timestamp in there, it would be even closer to zero happening twice in a row (i.e. the "Why didn't this work? I must have done something wrong, let me try again"). So I suppose I should learn to live with imperfection ;-) cheers, Remko
Re: [Standards] XEP-0045: requesting a unique room name
Remko Tronçon wrote: Without checking, that was in the spec for converting the chat to muc case. I don't see the harm in leaving it there, but I think it'll come down to another argument about the impossibility of collisions on a guid. That was indeed the main discussion last time. Pros: it keeps the client very simple (it just has to query a name), and leaves out all the logic for GUID generation and collision detection. Others were arguing that a SHA is simple to generate, and would never collide in pratice anyway. I'm slightly leaning towards the first proposal, as I'm not sure I could sleep at night knowing that in theory, my client can give a weird error. But maybe i should stop being a purist, and accept that the clients have much bigger issues than that ;-) How hard is it to generate a UUID or SHA hash? I suppose not all clients have access to such utilities... Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: requesting a unique room name
> Without checking, that was in the spec for converting the chat to muc > case. I don't see the harm in leaving it there, but I think it'll come > down to another argument about the impossibility of collisions on a > guid. That was indeed the main discussion last time. Pros: it keeps the client very simple (it just has to query a name), and leaves out all the logic for GUID generation and collision detection. Others were arguing that a SHA is simple to generate, and would never collide in pratice anyway. I'm slightly leaning towards the first proposal, as I'm not sure I could sleep at night knowing that in theory, my client can give a weird error. But maybe i should stop being a purist, and accept that the clients have much bigger issues than that ;-) cheers, Remko
Re: [Standards] XEP-0045: requesting a unique room name
On Wed, Aug 13, 2008 at 12:24 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Has any MUC implementation coded in support for the "unique room name > request" feature described in Section 10.1.4 of XEP-0045? I think this > feature is unnecessary and (in the interest of simplification) I would like > to remove it from XEP-0045. Without checking, that was in the spec for converting the chat to muc case. I don't see the harm in leaving it there, but I think it'll come down to another argument about the impossibility of collisions on a guid. /K
Re: [Standards] XEP-0045: requesting a unique room name
Le mercredi 13 août 2008, Peter Saint-Andre a écrit : > Has any MUC implementation coded in support for the "unique room name > request" feature described in Section 10.1.4 of XEP-0045? mu-conference implements it. > I think this > feature is unnecessary and (in the interest of simplification) I would > like to remove it from XEP-0045. The only utility I see for it is when converting a 1 to 1 chat to a chatroom, but the client could also generate the unique room name, so I'm not opposed to this removal. Regards -- Grégoire Menuel xmpp:[EMAIL PROTECTED] GPG: 1024D/D3BF3B20
