RE: [Standards] XEP-0045: direct invitations
The service does have to add the room to the OK list either way, so I agree, in this way they are the same. But if the client is old, and does not recognize the set, it will return an error, which allows you to go to the social technique. If you use a direct invite message, the message will go into the bit bucket. As far as knowing the resource, I think you have to know it either way. Toly -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Saint-Andre Sent: Friday, July 27, 2007 14:26 To: XMPP Extension Discussion List Subject: Re: [Standards] XEP-0045: direct invitations Toly Menn wrote: > Wouldn't you have the same problems with the actual messages that > come from the MUC, i.e., they would be blocked by the client? I am > not familiar with how block list work, but no matter where the invite > comes from, once the client joined the meeting, the client will need > to unblock the room. I think the service would need to be smart about adding the chatroom address to the user's allow list when they join the room. > Would it not be easier to send a "set" iq to the client telling it to > expect an invite from a MUC of the specified name. The client, > having you on its contact list, would get the IQ. The new client > would then unblock the MUC JID for some time (1 minute), reply with > "result" IQ indicating success, and then process the invite as > normal. The old clients will fail as before, but the inviting client > will get an "error" IQ from the old client that it does not recognize > the "set", and will be able to revert to the "social" technique. Yes, that's another way to do it. Not sure if it makes much difference. Using IQ would require you to know which resource you want to invite, and that seems potentially sub-optimal. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0045: direct invitations
Toly Menn wrote: > Wouldn’t you have the same problems with the actual messages that > come from the MUC, i.e., they would be blocked by the client? I am > not familiar with how block list work, but no matter where the invite > comes from, once the client joined the meeting, the client will need > to unblock the room. I think the service would need to be smart about adding the chatroom address to the user's allow list when they join the room. > Would it not be easier to send a “set” iq to the client telling it to > expect an invite from a MUC of the specified name. The client, > having you on its contact list, would get the IQ. The new client > would then unblock the MUC JID for some time (1 minute), reply with > “result” IQ indicating success, and then process the invite as > normal. The old clients will fail as before, but the inviting client > will get an “error” IQ from the old client that it does not recognize > the “set”, and will be able to revert to the “social” technique. Yes, that's another way to do it. Not sure if it makes much difference. Using IQ would require you to know which resource you want to invite, and that seems potentially sub-optimal. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] mutual authentication and XEP 178
Peter Saint-Andre wrote: >> Either way, this may be a good clarification >> in 3920bis as well. > > It's on the way. Might even be in my working copy already, I'll have to > check. Here is a diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/internet-drafts/draft-saintandre-rfc3920bis-04.xml?%40diffMode=u&%40diffWrap=s&r1=1088&r2=1096&u=3&ignore=&k= Or: http://tinyurl.com/353dyd I split the TCP Binding section into subsections (as I've done with most of the other sections in rfc3920bis) and I've attempted to clarify the stream directionality issue. Let me know if you have suggestions for improvement. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] mutual authentication and XEP 178
Hi Toly, Toly Menn wrote: >> An XML stream always goes in one direction, it's just that in the c2s >> case both streams go over the same TCP connection, whereas in the s2s >> case there are two TCP connections. However, as Justin says, the >> directionality matters only for the sending of stanzas, not for the >> sending of XML elements that are used to establish the stream. I'll >> clarify this in the -04 version of rfc3920bis, and will post to the list >> once I have proposed text. > > Going back to StPeter’s original example of the s2s case, server 1 (s1) > sends STANZAs to server 2 (s2) over TCP connection 1 (t1), s2 sends > STANZAs to s1 over TCP connection 2 (t2). I just wanted to confirm that > this applies to ALL stanzas, including IQ stanzas. Correct. > So if s1 sends s2 an > IQ stanza of type “set” over t1, s2 will reply to s1 to that “set” with > a “result” stanza over t2? Yes. > Either way, this may be a good clarification > in 3920bis as well. It's on the way. Might even be in my working copy already, I'll have to check. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] JID Escaping
Matthias Wimmer wrote: > Robin Redeker schrieb: >> I propose to rename the XEP to make clear that this escaping/unescaping >> should >> only happen in very rare cases (only at gateways or heavily specialized >> client >> frontends). And that the terms 'escaping' and 'unescaping' are replaced by >> 'mapping' and 'unmapping', because thats what is happening here. > > +100 Well, it's interesting, on the ejabberd list today someone said they have an existing database of 45k email users and they want to offer Jabber services to that user population, but re-use the same usernames. I'm sure they have some users in there with addresses containing characters like single quote, e.g., tim.o'[EMAIL PROTECTED] In which case I bet that they'll be interested in using JID Escaping. I really feel that this discussion is not going anywhere. The spec is IMHO pretty clear. If you don't like the spec, don't implement it. /psa -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0045: roomnick case
On Thu, Jul 26, 2007 at 09:05:15PM -0600, Jack Moffitt wrote: > At Chesspark we make all public rooms non-anonymous and we always show > the full jid or (if they are in your roster) the roster nick for that > person. That way no one is ever confused who is who. So we've > basically solved this in the client. All this nick stuff stuff is so > IRCish anyway. It's nice if what you want is an anonymous room, but > for everything else, it's just a mess IMO. > > After trying several solutions we found that this was least confusing > to everyone and we have gotten no complaints except for the occasional > jerk that signs up with a name like st.peter or stpeter_, but there's > little you can do about that but ban the offenders. > > jack. For the record, it was considerations like this that drove us at my last job to implement room nockname locking, and get the language for it improved in the XEP. Which works perfectly in a non-federated controlled account setting, and works to a reasonable degree otherwise. -Etan
