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
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
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
[Standards] Proposed XMPP Extension: Direct MUC Invitations
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Direct MUC Invitations Abstract: This specification defines a method for inviting a contact to a multi-user chat room directly, instead of sending the invitation through the chat room. URL: http://www.xmpp.org/extensions/inbox/direct-invitations.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
Re: [Standards] Proposed XMPP Extension: Direct MUC Invitations
XMPP Extensions Editor [EMAIL PROTECTED] wrote: URL: http://www.xmpp.org/extensions/inbox/direct-invitations.html Just spotted that typo: The venue/ element is REQUIRED, whereas the password/ and reason/ elements are OPTIONAL. -- Jonathan signature.asc Description: PGP signature
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
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
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] Proposed XMPP Extension: Direct MUC Invitations
On Wed, 13 Aug 2008 08:18:43 -0500 XMPP Extensions Editor [EMAIL PROTECTED] wrote: http://www.xmpp.org/extensions/inbox/direct-invitations.html Hmm, good idea, this simple direct invitation protocol, it makes sense to send invitation to the people I invite. Just a sidenote, couldn't venue be replaced with something more specific and well known in the XMPP community (e.g. conference). It might also come first in the example, as it's the only important (and REQUIRED) element. Also, more about authorization and relation to other XEPs would be nice. Passwords are IMO not a good *default* authorization technique for MUC rooms. It seems MUC authorization was removed from [xep 0235]. Isn't now the time to find a better place for it? Pavel -- Web: http://www.pavlix.net/ Jabber Mail: pavlix(at)pavlix.net OpenID: pavlix.net
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
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 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: presence to='[EMAIL PROTECTED]/nick'' from='[EMAIL PROTECTED]/home' x xmlns='http://jabber.org/protocol/muc'/ unique xmlns='http://jabber.org/protocol/muc#unique' / /presence Server supports unique extension, and the room already existed, so it replies with a new one: presence from='[EMAIL PROTECTED]/nick'' to='[EMAIL PROTECTED]/home' unique xmlns='http://jabber.org/protocol/muc#unique'[EMAIL PROTECTED]/nick/unique x xmlns='http://jabber.org/protocol/muc#user' item affiliation='owner' role='moderator'/ status code='110'/ status code='201'/ /x /presence 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
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-0174: Serverless Messaging: Ending a Messaging Session
Alban Crequy wrote: Hi, In a link-local conversation with XEP-0174, a client A sends the ending stanza to the other end's client B: /stream:stream http://www.xmpp.org/extensions/xep-0174.html#end After that, B continues to send message stanzas to A but never sends the ending stanza. The ending stanza from A is ignored by B. Why? The XEP-0174 seems to say B has to close the stream but there is no MUST or SHOULD. I think that's supposed to be a MUST. The text the other party then closes the stream in the other direction as well is not good specification language. When the user of A wants to send a message, A can't send it using the current connection because the ending stanza has already been sent on this connection and sending stanzas after the ending stanza is obviously not correct. The client A cannot closes the TCP connection while it did not receive the ending stanza from B because it may miss a message. I think that A can indeed close the TCP connection, but will miss some messages. Indeed, we might want to say that A sends /stream:stream and closes the TCP connection immediately. The XEP does not say whether A should open a second stream or should wait the first stream to be closed by the remote end. The second option seems better to me, Agreed. but in this case B MUST closes the stream at some point when A sends the ending stanza (otherwise, A's messages will never be sent). Also agreed. It seems that iChat behaves like the client B in my scenario, i.e. it does not close the stream when it receives the ending stanza. This causes problems when the client A waits the connection to be closed in order to open a new one. I think we hadn't considered the complexities here when we first documented serverless messaging. The fact that clients can get in this state is a problem -- i.e., the state where A won't send stanza to B and does not expect stanzas from B, but B ignores A's stream close and continues to send stanzas to A. I consider this a bug in B, and I think we need to clarify the spec so that B sends a stream close as soon as it receives a stream close from A. We probably also need to define how a client needs to handle stanzas it receives after it sends the closing stream tag (ignore them? show them to the user?). Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] comments on section 8.3, draft-saintandre-rfc3920bis-06.html
Pavel Simerda wrote: On Tue, 12 Aug 2008 00:31:00 -0700 Justin Karneges [EMAIL PROTECTED] wrote: On Monday 11 August 2008 14:04:22 Pavel Simerda wrote: On Mon, 11 Aug 2008 13:45:08 -0600 Peter Saint-Andre [EMAIL PROTECTED] wrote: Server DOM grovelling to look for the right extension? That doesn't sound very appealing to server developers. What about: A: presence type='meeting-request'/ I'm pretty sure any server developer who doesn't want to process the XML inside a presence stanza would also be against adding new presence types. I think if any extending goes on, it would have to be through child elements of the stanza. I believe if the type is really different from the usual availability (which the temporary availability is), we should not stick with the current set of presence types only because it has been like that for a long time. The flow of your protocol is good, though. Thanks. Current implementations would send it to the client (if not instructed to block everything) or no? It's hard to say what current servers would do. Presence stanzas are treated specially in servers, much more than message/iq which are usually just relayed as-is. It wouldn't surprise me if sending new/invalid presence types would cause the receiving server to drop the stanza. Still better than confusion with subscribe. We need two new XEPs: Temporary Presence Exchange (for exchanging caps/resource information with unknown/invisible entities), What more does that involve on top of directed presence containing caps? and Presence-based Privacy (which is TPE-aware). I feel a lot of hoops here. How about a way to send a presence subscription request but indicate that it's intended to be only temporary? presence type='subscribe' temporary/ /presence That'll get through without all sorts of server upgrades etc. That will, without a server upgrade be regarded as a subscription request by the server, which is not a good backwards-compatible scheme either. Or maybe it is a fine backwards-compatible scheme? Clients/servers unaware of temporary subscriptions would at least be able to set up a normal subscription. Which is IMO bad and confusing when you only want temporary presence session. This might even lead to the situation that people are angry because you want subscription and you aren't supposted to. What more, clients can do nothing to prevent it. If you want to extend something, it would be better if it's not subscriptions. We have enough problems with subscriptions without that. (They sometimes don't work as expected and servers sometimes store different subscription states for the same user relation.) Look, we're trying to work around presence blocking. Some servers will only let presence type='subscribe'/ through because of privacy lists (or what looks like a privacy list anyway, a la Google Talk), and a new value for the 'type' attribute won't help here. So either we use subscribe or it won't work anytime soon. Choose one. :) Personally I don't mind having a big roster, and I don't mind having people send me presence subscription requests, long-term or short-tterm, whatever. In fact I'd love to have a flag for short-tterm subscriptions when a presence subscription request comes in -- I'd be more likely to approve it, and maybe the short-term subscription turns into a long-lived subscription. I'm not sure how you present these options to the users (both the subscriber and the subscribee), but I think client developers can work on those issues and we can share those insights. Peter smime.p7s Description: S/MIME Cryptographic Signature
