Re: [jdev] seeking help with presence strategy
Am 25.11.2015 um 07:55 schrieb Daniel Dormont: Hi, I have an XMPP-enabled web application. In that I have several screens where a user may see a list of names of several other users. I would like that user to be able to see, in near-real time, basic presence information for all of those names. Right now I've implemented that by sending presence subscriptions to all the names on the list minus those that are already on the current user's roster. Then I've configured my client on the other end to automatically and silently accept all presence subscriptions. This works, but it seems a bit heavy-handed. In particular, it means that the user will continue to get presence updates for everyone whose name has ever popped up on one of these screens, whereas I only really care about the screen they're on right now, which will typically have no more than, say, 30 or so names. One idea I had was to keep the approach I have but periodically drop contacts from the roster who haven't been accessed in a while. But that data isn't there anywhere in the roster-related information that I can see (I use ejabberd). So I'd have to modify the server to incorporate that. Does this seem like a crazy idea? How else might I approach this problem? Create a MUC room for every screen and join / leave it as appropriate. Then display the room roster in place of the users roster you currently have. Much easier :-) ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] seeking help with presence strategy
Create a MUC room for every screen and join / leave it as appropriate. Then display the room roster in place of the users roster you currently have. Much easier :-) Hm, that's clever but I realize I may have misstated the situation a bit. The user doesn't merely need to know whether those other contacts are looking at the same screen as they are. He/she needs to know whether they're online at all Same pattern, use another online@ MUC for tracking everyone who is online. This can be rather noisy if there are many users online but if you limit this one to simple join/leave and don't send away updates to that room it's ok. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] JSXC/WebRTC
Am 15.06.2014 16:25, schrieb Emil Ivov: Hey Marcel, Thanks for responding. I certainly didn't mean to appear aggressive or criticise the client as a whole. I definitely think it is an awesome project and wish you good luck maturing and extending it! I don't really agree with the views you express below http://tools.ietf.org/html/draft-ietf-rtcweb-security-06#section-4.3.1 uses end-to-end keying. But yeah, this is easy to misinterpret so it would probably be better to omit the end-to-end. (I would really like to see some way of using SMP to assert the fingerprints though) ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] New client; update client list
Am 13.06.2014 14:02, schrieb Emil Ivov: Hey Marcel, Congrats for the release. same here, ^5 Klaus! One question On 12.06.14, 18:40, Marcel Waldvogel wrote: * End-to-end encrypted audio and video calls from Firefox and Chrome without plugin Is this referring to WebRTC's use of DTLS-SRTP? Because, if so, end-to-end is a bit misleading given that today's implementation of DTLS-SRTP there is vulnerable to to MitM attacks from the service provider. Well, it's end-to-end. It's not end-to-end with authenticated peers. Guess who is working on that :-p ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] A rapidxml fork for XMPP
Am 04.12.2013 23:49, schrieb Dave Cridland: Since we've been discussing XML parsers a lot... https://github.com/dwd/rapidxml contains a fork of rapidxml that's been randomly hacked^W^Wcarefully optimized to make it more useful in XMPP projects that need particularly fine and/or controlled XML handling. Yai! I've been waiting to see that code for some time now ;-) ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto 0.4
On Thu, 7 Nov 2013, Kwadronaut wrote: That in itself isn't bad at all, rather the opposite, it's great. But yes, what are the implications of a push towards this? Openssl supports and accepts 16-bit DHE-group. [1] Current Java 67 don't like any DHE 1024bits (workaroud exists by using Bouncycastles JCE). Without looking at what is still around as Alexander did, I wonder So you take things like the manifesto, draft-sheffer-tls-bcp-00 and draft-saintandre-xmpp-tls and show it to the people making Java and tell them they need to support it. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto 0.4
Right now the manifesto is praising the merits of PFS too much and not taking these implications into account. Or is there some way I don't know about to make all above moot? It's a manifesto. I suppose it will have to be adapted to match deployment reality after the test runs. I think setting a high level in the manifesto is good. People are free to use whatever workarounds they need to make in order to continue being able to communicate with their contacts. But I think we need to be very clear about saying what is the right way to do things and what should be avoided. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto 0.4
Am 07.11.2013 22:03, schrieb Mathieu Pasquet: On updating software/hardware, I think it is reasonable to assume that anything that runs today is able to negociate TLSv1, which I consider the baseline. The manifesto says that software that endorses it must be able to negociate and prefer TLSv1.2; I consider that as *new versions* of the software, on an up-to-date system. Right. So for example (I had to verify this today), on Windows XP schannel, which is the MSFT API for doing TLS, does TLS 1.0. It's not able to do TLS1.2. When using that OS you probably have other things to worry about. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto 0.4
Am 06.11.2013 21:02, schrieb Alexander Holler: Not exactly the same, but I don't like the part or require cipher suites that enable forward secrecy for the same reason. OpenSSL 1.x isn't around that long, and there are still many systems which do use e.g. Debian squeeze. And I assume the state of OpenSSL on other stable systems like e.g. SLES or RHEL isn't much better (but that's just an assumption from me). DHE/EDH suites have been around at least since 2006 (openssl 0.9.8d is the oldest binary i have access to). ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] TLS Everywhere
Whereas the deployment piece says o require the use of TLS for both client-to-server and server-to-server connections Doesn't that exclude Server Dialback? Please help me understanding this. No. You use this (called starttls+dialback) if, after setting up TLS you notice that you can't trust the peer certificate for strong authentication. So you have an encrypted stream from TLS and the relatively robust spoofing protection from dialback. It's safe from passive attacks. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Heml.is and federation..
Am 16.07.2013 21:36, schrieb Peter Saint-Andre: [...] Also helpful might be an automated service (xmpp.net?) that would give you a report about your domain's s2s security status, if you opt in of course. +1 That would be cool! OK, that sounds like a fun project. ;-) I think buddycloud has something like that, but IIRC it doesn't use s2s yet. Simon? ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Heml.is and federation..
Am 12.07.2013 23:01, schrieb Peter Saint-Andre: But the real problems seem to be in deployments, not implementations. Well, it's an awareness problem. Currently, nothing breaks when an s2s certificate expires. That means those are continued to use for years. Nobody notices. Heh, it still works with jabber.org. We don't even need POSH to solve these problems. Likewise, few people notice when certain deployments suddenly stop offering TLS. Or are surprised some big parties aren't using TLS at all. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
[jdev] ANN: strophe.jingle -- a jingle/webrtc plugin for strophe
mattj thinks this ought to be announced here, too. Announcement text is mostly courtesy of ralphm :-) strophe.jingle is a webrtc connection plugin for strophe.js. Strophe is a popular library for writing XMPP client applications that run on any of the current popular browsers. Instead of the native TCP binding, strophe.js uses BOSH (Bidirectional-streams Over Synchronous HTTP, a variant of long polling) to connect to an XMPP server. Besides enabling anyone to build (federated) IM applications, this opens up the browser as an addressable endpoint for two-way exchange of structured messages, including presence and publish-subscribe applications. Fork it at https://github.com/ESTOS/strophe.jingle This plugin makes it possible to negotiate audio/video streams via XMPP and then relinquish control to the WebRTC support of browsers like Firefox and Chrome for the actual out-of-band media streams. With XMPP/Jingle you get the authenticated, secured and federated media signaling, whereas WebRTC gives you an API to set up the media streams using RTP/ICE/STUN and provide access to cameras and microphones. Features: - mostly standards-compliant jingle, mapping from WebRTCs SDP to Jingle and vice versa. Aiming for full compliance. - tested with chrome and firefox. - trickle and non-trickle modes for ICE (XEP-0176). Even supports early candidates from peer using PRANSWER. - support for fetching time-limited STUN/TURN credentials through XEP-0215. rfc5766-turn-server is a TURN server which implements this method. a sample demonstrating the use of this to build a federated multi-user conference (in full-mesh mode). Thanks to my employer for the permission to release this under MIT license. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Message Read Receipts
On Fri, 10 May 2013, Dave Cridland wrote: On Fri, May 10, 2013 at 2:11 AM, Peter Saint-Andre stpe...@stpeter.im wrote: Thanks for sending your message. Unfortunately, I've only had time to glance at the subject and haven't actually read it. Right - true read receipts are impossible. But receipts are generally about moving responsibility; hence XEP-0198 acks move it to the next hop, XEP-0184 moves it to the client, and a read receipt spec would move it to the user with an explicit ack. I suspect there's actually little practical advantage to most people above a simple response of OK, but in military and other critical environments it could well be useful, since then a client, or server, can see messages have been acknowledged - or have been missed. This might be useful for offline messages, where you typically don't have an active conversation. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] TLS/SSL Stream Resumption and XMPP
has somebody experience with TLS level stream resumption in XMPP software? http://tools.ietf.org/html/draft-cridland-sasl-tls-sessions-00 is still worth reading... Has anybody implement this and made some tests? Is it worth the effort, considering that in some situations (e.g. mobile) you have frequent reconnects? How does it play with STARTTLS? Don't use STARTTLS, just multiplex TLS on port 5222 by peek'ing the first byte (which should be 0x16). jabberd has supported that for ages, it works quite reliably for TLSv1 client hellos (and slightly less for sslv2) ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Presence Subscription to nonexistent contact
Unfortunately, I don't think I'm getting that error response with the version of ejabberd that I'm using. I'll double check it and inquire in the ejabberd list if this turns out to be the case. if the error is delivered to the client the server is doing something wrong. Even though (iirc) 6121 does not explicitly specify how to handle the error, delivering it to a users client without modifying the roster is certainly not the right thing. See http://www.ietf.org/mail-archive/web/xmpp/current/msg00057.html and http://www.ietf.org/mail-archive/web/xmpp/current/msg01406.html for some background information. ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Making sense of different presence info from different endpoints
Matthew Miller typeth: This is not official, and subjective to my personal views, but I would recommend using the following to determine which to display: 1) highest priority (treat a missingpriority/ aspriority0/priority) 2) timestamp, via jabber:x:delay or urn:xmpp:delay (treat a missing timestamp as timestamp==received time) 3) order parsed from the stream Your personal view does not start with 0) if there is a locked resource (XEP 0296) display the presence information from that resource ? :-) ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Are you broken?
Dave Cridland wrote: So the question is, can anyone not see me? I can't see you. But then, I could not see you before because bidi + sasl features on your side, so that does not change anything :-p cheers philipp ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Interop Preparation
Dave Cridland wrote: Different servers do, and do not do, CRL checking. M-Link R14.6 does not, whereas M-Link R15.0 can do (if asked). I don't think servers trust incorrect or expired certificates ever, do they? I don't think any servers trust incorrect or expired certificates (or certificates where the subject does not match the streams from/to) in the sense that they allow them to be used for SASL EXTERNAL. Dialback is used as a fallback in that case, so thing don't break. Most servers do trust such certificates (in a TLS-optional) mode when connecting to a peer server in the sense that they continue to connect (which mean trusting DNS, not x509). Disconnecting and reconnecting without TLS would be rather silly. That interpretation of tls optional has a rather nasty side-effect: it decreases the number of valid and usable s2s certiciates, because nobody bothers to fix things (expired certificates, servers that fail to send the complete certificate chain up to the root) when it just works (TM) with jabber.org. [...] Do we bother with testing dialback, too? May as well. If anyone is doing dialback-without-dialback, I'd be interested. I'll see if I can deploy a server with both dwd and bidi. Dave: if you could generate certificates signed by an intermediate CA that would be nice to test if servers actually send the whole chain. I'm not generating the certificates, but yes, that should be possible. Thanks! philipp ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Interop Preparation
Badlop wrote: bear wrote: We will be setting up a test domain and will be providing a CA, so each server would: - have an issued Certificate(s) 2010/11/10 Philipp Hanckefi...@goodadvice.pages.de: Testing cases where it should not work (like revoked certificates) is more interesting than making sure things work. Testing the verification of domain-based application service identity would be nice, too. For that additional testing, the XSF could provide also wrong certs: one revoked, another for a dummy domain, etc. And then the server administrators setup additional vhosts which use those certs. That requires two modes of operation for the servers: - oh-yeah-tls-is-so-cool: Basically the normal mode of operation as currently used on the public network where servers ignore revoked (expired, ...) certs or the mismatch of the certificate for dummy domain. - tls-as-defined-in-the-specs: if a server connects to another server and does not get a valid and trusted certificate for the expected peer domain it will disconnect. Additionally, that server will not allow another server to use dialback, but require XEP 0178 style authentication. Do we bother with testing dialback, too? Dave: if you could generate certificates signed by an intermediate CA that would be nice to test if servers actually send the whole chain. cheers philipp ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Interop Preparation
bear wrote: I'm starting to gather information and get things in place for S2S (and C2S) Interop and in that vein I would like to find out from the XMPP world who would be able to participate. The following are the thoughts in my head and have not gone thru any formal discussion or XSF Board decisions :) We will be setting up a test domain and will be providing a CA, so each server would: - have an issued Certificate(s) Testing cases where it should not work (like revoked certificates) is more interesting than making sure things work. Testing the verification of domain-based application service identity would be nice, too. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Alternate MUC Authentication Mechanisms
Simon Tennant wrote: Traffic can be intercepted, replayed and whatever... but sharing a secret between users as a way to access a common resource without a per-user audit trail, seems like something that should never fly in the first place. Especially not in 2010. No, that's 1990. The feature was probably introduced in XEP 0045 because IRC can do that without considering that IRC MUST do that because someone decided that nicknames are not owned. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] presence subsription rejection notifications while offline.
Daniel V. Grillo wrote: Hi Folks, I've built a minimal xmpp client to keep track of contacts presence status. In previous versions, if a user asked a contact for a subscription to presence, my client automatically granted it. Now I want to notify a contact of such a request and let them grant or reject it. I have it working according to rfc 3921 section 8. I do have one question/issue though. If a users presence request is denied by the contact while the user is online, he gets notified of the rejection as defined in section 8.2.1 (using the ejabberd server). I can then pop up a notification stating so and so rejected your request. But if the user is offline when the rejection happens, and then logs in, he gets no such notification. He just gets his roster with that contact in the none state with the ask flag stripped and no indication of how that contact got that way. Since a contact can end up in the none state in various ways, I can't use that fact to pop up a notification. So my question is, how can I give a user notification that his subscription requests were rejected while he was offline? I see that psi has the same issue and so does Exodus. They give rejection notifications while the user is online, but not when he got the rejection while logged off and then logs on. Any way to implement such a feature? This might be possible by storing the unsubscribed stanza on the server when the user is offline, ie. adding a rule similar to the fifth rule of section 3.1.3 in section 3.2.3 in 3921bis-06, and then sending this when the roster is fetched. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] wildcards vs. multiple certs
Peter Saint-Andre wrote: [...] As a result, it is possible that admins might feel the need to request multiple Class 1 certs in order to deploy an XMPP service (if they are not able to obtain a Class 2 certificate). For example, at the jabber.org service we might use one Class 1 certificate for the domain name jabber.org and another Class 1 certificate for the domain name conference.jabber.org. This would require our XMPP server software to present the jabber.org certificate when a peer server attempts to open an s2s connection to the jabber.org domain, whereas it would present the conference.jabber.org certificate when someone from a peer server attempts to join a chatroom at the conference.jabber.org MUC service. I do not know of any XMPP server software that can present two (or more) different certs for s2s connections depending on the domain name specified by the peer server. This is how Matthias implemented s2s TLS in jabberd. How would current servers handle this? Do we really need to worry about Nobody cares about the content of s2s certificates when connecting to a remote domain. Therefore nobody bothers to present the right certificate. philipp ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] update on XMPP location (wherein beer is offered)
Waqas Hussain wrote: There is a particularly good reason for this: IQ gets and sets are only allowed to have a single child. Don't 'fix' this, because accepting multiple IQ children would break the XMPP spec. and because XEP 0255 - example 7 shows the right way to do it. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] IMPORTANT www.jabber.org software listings
Peter Saint-Andre wrote:
Because we want to do this:
openssl s_client -connect example.com:5223 -CAfile ca.crt
AFAIK there is no good way to do something similar for STARTTLS
connections. If you know of a way, please do let us know.
adding a xmpp-starttls to s_client is not that difficult...
A patch (diff against good old openssl 0.9.8d) is attached.
Beware, detection of the starttls stream feature is not perfectly
reliable. Usage:
`openssl s_client -connect example.com:5222 -starttls xmpp -starttls_to
example.com`
--- openssl-0.9.8d/apps/s_client.c 2005-11-25 14:46:41.0 +0100
+++ openssl-0.9.8d-patched/apps/s_client.c 2007-02-22 21:39:04.0
+0100
@@ -187,6 +187,8 @@
BIO_printf(bio_err, -host host - use -connect instead\n);
BIO_printf(bio_err, -port port - use -connect instead\n);
BIO_printf(bio_err, -connect host:port - who to connect to (default is
%s:%s)\n,SSL_HOST_NAME,PORT_STR);
+BIO_printf(bio_err, -starttls_to name - use name as 'to' in xmpp
starttls mode, default is host from -connect\n);
+BIO_printf(bio_err, -starttls_from name - use name as 'from' in xmpp
s2s starttls mode\n);
BIO_printf(bio_err, -verify depth - turn on peer certificate
verification\n);
BIO_printf(bio_err, -cert arg - certificate file to use, PEM
format assumed\n);
@@ -249,6 +251,8 @@
short port=PORT;
int full_log=1;
char *host=SSL_HOST_NAME;
+char *starttls_tohost=NULL;
+ char *starttls_fromhost=NULL;
char *cert_file=NULL,*key_file=NULL;
int cert_format = FORMAT_PEM, key_format = FORMAT_PEM;
char *passarg = NULL, *pass = NULL;
@@ -327,6 +331,16 @@
if (--argc 1) goto bad;
host= *(++argv);
}
+else if (strcmp(*argv,-starttls_to) == 0)
+{
+if (--argc 1) goto bad;
+starttls_tohost= *(++argv);
+}
+else if (strcmp(*argv,-starttls_from) == 0)
+{
+if (--argc 1) goto bad;
+starttls_fromhost= *(++argv);
+}
else if (strcmp(*argv,-port) == 0)
{
if (--argc 1) goto bad;
@@ -469,6 +483,10 @@
starttls_proto = 1;
else if (strcmp(*argv,pop3) == 0)
starttls_proto = 2;
+else if (strcmp(*argv, xmpp) == 0)
+ starttls_proto = 3;
+else if (strcmp(*argv, xmpp-server) == 0)
+ starttls_proto = 4;
else
goto bad;
}
@@ -731,6 +749,60 @@
BIO_printf(sbio,STLS\r\n);
BIO_read(sbio,sbuf,BUFSIZZ);
}
+ if (starttls_proto == 3 || starttls_proto == 4)
+{
+int r;
+if (starttls_proto == 3)
+{
+BIO_printf(bio_c_out, using XMPP c2s protocol\n);
+BIO_printf(sbio,stream:stream
+
xmlns:stream='http://etherx.jabber.org/streams'
+ xmlns='jabber:client'
+ to='%s' version='1.0', starttls_tohost);
+}
+else
+{
+BIO_printf(bio_c_out, using XMPP s2s protocol\n);
+BIO_printf(sbio,stream:stream
+
xmlns:stream='http://etherx.jabber.org/streams'
+ xmlns='jabber:server'
+ xmlns:db='jabber:server:dialback'
+ to='%s' from='%s' version='1.0',
+ starttls_tohost, starttls_fromhost);
+}
+BIO_printf(bio_c_out, sent opening stream header\n);
+BIO_printf(bio_c_out, expecting for stream:features\n);
+r = BIO_read(sbio,mbuf,BUFSIZZ);
+mbuf[r] = 0;
+BIO_printf(bio_c_out, READ: %s\n, mbuf);
+while(!strstr(mbuf, starttls
xmlns='urn:ietf:params:xml:ns:xmpp-tls'))
+{
+if (strstr(mbuf, /stream:features))
+{
+BIO_printf(bio_c_out, error: no starttls stream
feature\n);
+goto shut;
+}
+r = BIO_read(sbio,mbuf,BUFSIZZ);
+mbuf[r]
Re: [jdev] Connectivity issues with gmail.com and googlemail.com
Hi Sergei,
5) googlemail.com sends a key over the same TCP connection (!):
That's called piggybacking.
=INFO REPORT 2007-09-19 20:35:32 ===
I(0.5062.0:ejabberd_s2s_in:317): GET KEY: {nes.ru,
googlemail.com,
[],
CAESBxC17cjz0SIaEBnkylXoIZMlEI4Y4qYXHDQ=}
The port is the same 0.5062.0. After that the connection is stalled.
ejabberd never receives anything in this stream.
For me it looks like a severe bug in Google Talk server.
They've been doing that ever since s2s was enabled.
Did someone experienced similar problems with gmail.com and
googlemail.com? May be Google Talk admins read this list and can help?
Cheers!
Happy ejabberd debugging. Dialback is already horrible to debug, but
piggybacking makes it a real nightmare.
Philipp
Re: [jdev] Multiple domain negotiations with SASL?
Artur Hefczyc wrote: On Tuesday 17 April 2007 08:09, Janne Savukoski wrote: So, I guess the dialback has then some scalability advantages over SASL. Naturally, supporting multiple domain connections over a single TCP session lets you cut down the number of sessions to a fraction. As far as I know it doesn't. Dialback needs 2 separate TCP/IP connections for EACH domain. No, see the 'piggybacking' stuff in xmpp-core, 8.3. Apart from google, I dont know many servers who still use this optimization.
Re: [jdev] MUC through IRC
Norman Rasmussen wrote: - ejabberd-ircd: requires irc client, admin chooses muc server/component one more (caution, advertisement follows): - psyced: requires irc client, lets local ircers join local* rooms, and talk to remote xmpp people (using xmpp:[EMAIL PROTECTED] syntax**) and behaves like a more-or-less-compliant xmpp and muc server for remote jabberites. Similar approach as ejabberd-ircd, but much more mature. (*) reason for this restriction are conceptual differences between irc and jabber - room nicknames, join recognition, join procedure, spanning tree vs 'broadcast', ... (**) rewriting those to short nicknames is possible, but requires manual configuration by the user.
Re: [jdev] MUC through IRC
Magnus Henoch wrote: Sometimes the idea to move a discussion channel from IRC to XMPP MUC is brought up, but fails for social and technical reasons: there are more people who know how to use an IRC client than an XMPP client, and IRC clients (and servers) are (allegedly) much better at handling heavy use of such channels. The Jabberites thus start using an IRC transport, and everything is calm again. However, I thought it would be interesting to do it the other way around, so I hacked together an IRC interface to ejabberd. Point your IRC client to basil.cd.chalmers.se and join #talks, to see how it looks. What if a irc user is in two channels, e.g. #talks and #talks2, each of which has a member foo (in jabber terms: [EMAIL PROTECTED]/foo, [EMAIL PROTECTED]/foo). Now the user clicks (or uses tab completion) to start a query with foo in one of the channels and sends a private message... Just displaying the room nick does not work, because this is a concept which irc does not have. On the other hand, irc users will complain that the nicknames are too long if you display full JIDs instead of nicknames only. And just wait until they start complaining about long channel names ;-)
Re: [jdev] Re: MUC through IRC
Magnus Henoch wrote: Indeed. I solved this by silently dropping private messages. I don't know much of the IRC protocol beyond what's in RFC 1459. Is there any way of abusing extending user specifications to achieve something like this? Even though iirc the ABNF in 1459 forbids it, you may use @ in nicks, unless you're expecting lots of people with irssi = 0.8.9. The 'best' encoding of a JID [EMAIL PROTECTED]/res to the irc prefix is [EMAIL PROTECTED]@host or - what you need in muc - [EMAIL PROTECTED]/[EMAIL PROTECTED] Both are clickable and usable with tab-completion... but tend to occupy more than 50% of the screen :-(
Re: [jdev] Question about resource binding to server implementors
Peter Saint-Andre schrieb: I can't remember why we even thought about allowing a client to bind connection-timeout magic which pings the conflicting active resource and hopes for a timeout before session binding happens possibly? multiple resources with the same identifier, since it would play havoc with delivery logic. session binding in xmpp-im does not allow that anyway. If there is already an active resource of the same name, the server MUST either... Sounds to me like a clean-up item for rfc3920bis. and 3921bis, as catching resource conflicts during resource bind implies that this conflict can no longer happen in session establishment.
Re: [jdev] Question about resource binding to server implementors
Vinod Panicker wrote: According to to specification, resource must be unique, therefore it is not allowed to have two same resources. There's no such requirement in the RFC. rfc 3920, section 3.4: An entity MAY maintain multiple connected resources simultaneously, with each connected resource differentiated by a distinct resource identifier. In fact, the RFC states that a server may allow multiple connected resources with the same resource identifier. Where? This is possible after resource binding and before session establishment, but rfc 3921, section 3: If there is already an active resource of the same name, the server MUST either [...] there is never more than one active session per resource identifier. cheers Philipp
Re: [jdev] web presence
On Wed, 8 Mar 2006, Peter Saint-Andre wrote: img src='http://www.jabber.org/users/stpeter.png'/ 0. Image url can be disco'd given a jid. 1. Needs to be opt-in (no presence leaking) Integration with JEP-0070 might also be desirable. 3. Jabber server and web server need to share information alternatively, the jabber server has a built-in webserver. For example, you could be using apache's mod_proxy to proxy requests to http://www.jabber.org/users/* to athena:5280/users/*.
Re: [jdev] S2S questions - from attribute and version support
Justin Karneges wrote: For now, servers implementors seem to be taking matters into their own hands, and so not only do we have 1.0 without SASL, but we have TLS+dialback. What if SASL is implemented but there are no usable methods? Let us assume we have successfully used starttls. The server will only offer SASL PLAIN or DIGEST-MD5 for s2s authentication if there is a shared secret between the two parties. The server will only offer SASL EXTERNAL if the certificate presented by the client (server) meets certain criteria (see http://mail.jabber.org/pipermail/jdev/2005-November/022309.html). What if both mechanisms are not usable (and therefore not offered)? This is why tls+dialback is currently necessary. Philipp
