Re: [jdev] manifesto 0.4
On 10/30/2013 01:21 AM, Mathieu Pasquet wrote: On Tue, Oct 29, 2013 at 05:09:32PM -0600, Peter Saint-Andre wrote: I just updated the encryption manifesto to incorporate feedback and clarify a few points: https://github.com/stpeter/manifesto/blob/master/manifesto.txt Your feedback (and signatures!) matter. Peter - -- Peter Saint-Andre https://stpeter.im/ Hi, Before signing the manifesto as a software developer, there are a few things that are unclear and I’m not sure we can commit to this just yet: Dropping SSLv2 is all good and I’m not even sure why SSLv2 was supported initially (doesn’t xmpp appear after SSLv3 was standardized?), but dropping SSLv3, while also a good idea, might cause issues with lots of servers (not naming legacy ejabberd or openfire under old debian or centos). Hopefully, we have some time to wake up some admins before the dates set in the manifesto, but I hope the test days will help troubleshooting the ones that don’t get the memo. Do we need, to be consistent, to disable the protocol but indicate to the user he will need to perform an extra action to be able to connect, or do we need to make the connection impossible in any case? I find the other points sensible, so I have nothing to add, except maybe separating clearly clients server requirements. I'd also would like some clarification about removing plain connection. In some situation (you have a local server for ex) the server can allow only non-secure connections to prevent memory consumption. So should we really disable plain connection or just disable it by default, and require some user advanced configuration to enable it? -- Yann ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] manifesto 0.4
On 10/30/2013 05:55 PM, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/13 8:36 AM, Yann Leboulanger wrote: On 10/30/2013 01:21 AM, Mathieu Pasquet wrote: On Tue, Oct 29, 2013 at 05:09:32PM -0600, Peter Saint-Andre wrote: I just updated the encryption manifesto to incorporate feedback and clarify a few points: https://github.com/stpeter/manifesto/blob/master/manifesto.txt Your feedback (and signatures!) matter. Peter - -- Peter Saint-Andre https://stpeter.im/ Hi, Hi Yann! BTW thanks for Gajim -- I've been using it on my new Linux laptop and I might send you some patches before long. ;-) Wow great, we'd be proud to have patches from you ;) I'd also would like some clarification about removing plain connection. In some situation (you have a local server for ex) the server can allow only non-secure connections to prevent memory consumption. So should we really disable plain connection or just disable it by default, and require some user advanced configuration to enable it? As the text is written right now (0.4), requiring channel encryption is something that service operators who sign the manifesto commit to. Software developers commit only to supporting channel encryption and preferring the latest TLS version, cipher suites with forward secrecy, etc. I do think disabling unencrypted streams is a smart default. I don't particularly want to tell client developers how to (or whether to) allow a cleartext connection (e.g., an advanced user setting). Ok nice. Then you can count my signature as Gajim's dev. We'll do our best to improve things, and count on those tests to help finding what's to be improved. -- Yann ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Jingle WebRTC implementation
On 05/16/2012 12:42 PM, Sergey Dobrov wrote: Created a ticket for Gajim to implement SRTP: https://trac.gajim.org/ticket/7157 Gajim doesn't implement any transport itself, it uses farstream for that. So ask Collabora to implement SRTP in farstream instead. -- Yann Leboulanger ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] OTR
On 08/17/2011 03:57 PM, Peter Saint-Andre wrote: On 8/16/11 7:08 PM, Andreas Monitzer wrote: On Dienstag, 16. August 2011 at 23:30, Peter Saint-Andre wrote: Don't forget OTR, too (I might be working on an Internet-Draft about that with some of the OTR folks): http://www.cypherpunks.ca/otr/ I know about OTR, but I don't like the standard. Due to its transport-independence, it doesn't integrate at all into XMPP. For example, there's no discovery for it. The client determines support at the other side by sending encrypted text and waiting whether a wtf by an irritated/confused human or a proper OTR response comes back. Yes, that's an ugly hack, which is needed to work around the lack of discovery protocols in systems like AIM and Yahoo. However, in XMPP we have ways to discover feature support (service discovery and entity capabilities), so it seems to me that we can define an XMPP feature for OTR (properly versioned because OTRv3 is on the way) and simply ignore the hacky text stuff. It also takes over the regularbody/-tag for its binary data instead of using a proper separate tag with its own namespace (like xhtml-im). On this point, I think we can work with the OTR team to define an XMPP binding in OTRv3 or (more likely) OTRv4. The XMPP binding would be more consistent with the Tao of Jabber, and if you're using AIM or Yahoo or whatever then you'd default to stuffing all the data in the message body. The XMPP binding would also enable us to perform whole-stanza encryption for all stanza types (think Jingle negotiation and such), instead of just the body/ element of the message/ stanza. Further, the library's LGPL license is incompatible with Apple's App Store, and so I'd have to implement it on my own… Multiple implementations might be a good thing. :) The XSF might even be able to provide funding for folks to work on a common library (BSD or MIT licensed) that can be used by a wide variety of clients. An OTP plugin has been written for Gajim, and AFAIK, he re-wrote the library in python instead of using the python bindings. But I don't think he did as a separate module code is here: http://hg.gajim.org/gajim-plugins/file/1dd756daba40/gotr -- Yann ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Clients with XEP 198 support
On 08/10/2011 01:11 AM, Kim Alvefur wrote: On Tue, 2011-08-09 at 16:47 -0600, Chris Newton wrote: I'm looking for clients that support XEP 198 to test compatibility with. AFAIK: - A branch of Gajim Indeed it has just been developped, will be merged to trunk as soon as I get some time. -- Yann ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Are you broken?
On 04/14/2011 08:33 PM, Dave Cridland wrote: So, as an experiment, I changed by SRV records the other day - mostly to test our own handling. I now have: ;; ANSWER SECTION: _xmpp-server._tcp.dave.cridland.net. 86400 IN SRV 5 1 5269 peirce-6.dave.cridland.net. _xmpp-server._tcp.dave.cridland.net. 86400 IN SRV 9 1 5269 peirce-4.dave.cridland.net. In layman's terms, that's Try connecting to peirce-6, and if that fails, try peirce-4. Predictably, these are IPv6 and IPv4 single-stack hostnames: ;; ADDITIONAL SECTION: peirce-6.dave.cridland.net. 86400 IN 2001:470:1f09:882:2e0:81ff:fe29:d16a peirce-4.dave.cridland.net. 86400 IN A 217.155.137.61 Actually the same host, as you can see: peirce.dave.cridland.net. 86400 IN A 217.155.137.61 peirce.dave.cridland.net. 86400 IN 2001:470:1f09:882:2e0:81ff:fe29:d16a So the question is, can anyone not see me? An easy way to check is by discoing my server. So far, I have found two server implementations that can no longer see me. ejabberd 2.1.6 doesn't seem to be able to disco your dave.cridland.net ___ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] XMPP on Android, Round #2
On 11/01/2010 07:28 PM, Stephen Pendleton wrote: -Original Message- From: jdev-boun...@jabber.org [mailto:jdev-boun...@jabber.org] On Behalf Of René Treffer Sent: Friday, October 29, 2010 8:56 PM To: jdev@jabber.org Subject: [jdev] XMPP on Android, Round #2 Hi, It's been some time since my last posting. But I didn't stop thinking about XMPP on Android devices. I've always been unhappy with asmack, because it's sort of a hack. It does solve a problem, mainly to reduce the amount of code to be written. But it doesn't solve the problem of nice phone integration. We've ended up with many jabber apps on Android, but none that's as native as e.g. a GTalk service. Very impressive work! I have done a few XMPP implementations on Android using a similar architecture (remote service+intents for stanza event notifications). I will look to switching to this implementation. One thing I think is missing from XMPP Android (and battery constrained devices in general) is the ability to re-establish a data connection only when an interesting event occurs when the application is in the background. In this case, an interesting event would be that a chat message, or other interesting stanza, arrived for me at the server. For example, 95% of the time I am not actively interested in my XMPP app or want to maintain a data connection to my XMPP server but am running my XMPP app in the background on my phone. I only bring it to the foreground when I want to send a message or to read a message. For the former, the XMPP app will re-connect to the XMPP server when I am ready to send my message. For the latter case the google cloud push service (http://android-developers.blogspot.com/2010/05/android-cloud-to-device-mess aging.html) could be employed to notify my client that a message exists for me on the server. When I am ready to read it the XMPP app will re-connect and fetch the message for me. This would require a server component, and also a addition to the android service that could process these messages. Do you have any interest in implementing this idea on the client service side? Thanks Couldn't Stream managment help for that? http://xmpp.org/extensions/xep-0198.html -- Yann ___ 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] Fwd: xep-0201
Le 03/09/2010 11:08, Mark Burton a écrit : Hi all, Below is a short exchange between me and Peter. I'm interested in using the xep-0201 standard to allow true 'threaded' conversations. Combining this with group chats and presence/typing indicators would seem to be a collaborative working dream tool :-) Is anybody aware of a jabber client that supports this? or, indeed, anybody working on it? Cheers Mark. Gajim sends thread element in chat messages, but in the GUI you cannot have 2 conversations with the same resource of a JID at the same time. It also supports XEP-0085: Chat State Notifications. -- Yann ___ 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] GSoC Project Status
bear wrote: So if you are a project admin who wants to be considered a mentor, please apply and if you have already could you please send me a direct email so I can add you to my personal email address book :) Here is the direct mail :) -- Yann Leboulanger ___ 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] gsoc proposal - RAW UDP
Kevin Smith wrote: Hi, On Mon, Apr 5, 2010 at 1:28 PM, Irina Stanescu ironmi...@gmail.com wrote: My name is Irina Stanescu and i'm in my 4th year at Politehnica University of Bucharest . I'm very interested in working with XMPP protocols, and I already worked on a SIP-JINGLE audio gateway for a SIP server. I was going through the gajim source files and I noticed that there is no support in Jingle for RAW-UDP, nor for falling back from ICE-UDP to RAW-UDP. Is this a good idea for a stand alone proposal? Or should i mention that i would like to work on it too in the another proposal i'm going to make for the CAPTCHA Forms project? I don't know the Gajim source, but adding RAW-UDP support to a client that already has ICE-UDP support doesn't sound like a big enough project to justify ~=twelve weeks of full-time work, so it seems to me that bundling this inside another project would be a stronger proposal. Hopefully the Gajim guys can weigh in too. Hi, Indeed gajim doesn't have RAW-UDP, but we don't have ICE-UDP either. In fact we use farsight that handles all that. So to add RAW_UDP to Gajim, we need a bit of refactoring in our jingle code, and then use farsight that already implements RAW-UDP. That could be usefull, indeed, but that's not 12 weeks of work for sure. So a proposition with this + captcha has more chance to be accepted in my opinion. -- Yann ___ 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] about GSOC idea on psi( Jingle RTP Encryption)
yu xue wrote: Hello, everyone I have looked up the GSOC project idea list, and have interest in several project ideas about security. The one that I am most interested in is about Psi---Jingle RTP Encryption. My name is Yu Xue, and I am a graduate student whose major is information security and cryptography. When in university, my major is computer science and technology. I am familiar with C,C++,Python and C#. The project that I prefer to is security-related. Currently my understanding about this project is just to implement in SRTP in Psi, either in avcall module or in a lower module according to the relationship that SPTP needs with the RTP session.Could some developers please give me some detailed or instructions on how to better understand and prepare this project or suggestions on writing proposal.Thank you! ps:Gajim's Jingle File Transfer interests me too. Hi, Here s Gajim's point of view: It seems a student is interested in implementing Jingle FileTransfer in Gajim, and he also seems very interested in implementing encrypted Jingle session. So that would be excellent to be able to test between Gajim and Psi! Now We don't currently know what applications will really be posted, which one will be accepted, but that could be a nice thing to develop that on both clients. -- Yann ___ 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] questions about gsoc: file transfer over jingle
Zhenchao Li wrote: Hi, Yann, Thanks for your reply. Now I see one big advantage of jingle really is it employs much more optional transport methods. To fully utilize this advanntage for file transfer, we need to implement ICE-TCP . But there's the problem: AFAIK there isn't an XEP defined for ICE-TCP http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-08, it's a work in progress. What we have is one for ICE-UDP http://xmpp.org/extensions/xep-0176.html. But unlike voice or video transmission, file transfer needs to ensure packet integrity, which rules out FT using ICE-UDP only. Implementing a ICE-TCP stack requires much design and careful implementation, and even sounds like another gsoc project. After some search I find that the libnice library implements ICE-UDP as well as a pseudo TCP implementation http://nice.freedesktop.org/libnice/pt03.html. Perhaps that's one viable way to transfer file?(At the risk of rewriting this transport method sometime in the furture when ICE-TCP is standardized.) I've also been investigating the possibility of implementing XTLS for encrypting FT streams. XTLS itself is listed as a proposal on the xmpp ideas page, and we have a draft http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02 and an XEP http://xmpp.org/extensions/inbox/jingle-xtls.html for reference. It's not quite complicated and there are some python libraries available(python binding for gnutls, tlslite). Would it be a good idea to add this additional feature?(After implementing and thoroughly testing jingle FT). I don't know how far from latest version ICE-TCP and jingle-TLS are. I don't know if it's worth implementing that or if it will change a lot before standardization. Maybe some other people on the list know more about those specifications. One point is also to know what other clients support. Another thing I don't know is what would be best: implment ICE-TCP or XTLS. XTLS could be used for audio / video and FT, so yes, it's a very nice feature! ICE-TCP is one of the reason to switch to jingle FT, but it may be a bit too early to implement that? BTW another reason to switch to jingle is the ability to change the transfer method. You try socks5, you don't find a host, you fallback to IBB. -- Yann ___ 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] questions about gsoc: file transfer over jingle
Zhenchao Li wrote: As far as I know the jingle protocol is kind of similar to the original stream initiation(xep-0095) conceptually. Apart from jingle being a newer, more general session negotiation protocol(general in the sense that there are already video, voice calls applications built on jingle) and SI practically being used only by SI file transfer(xep-0096), what are the advantages that jingle has over SI? Surely there are already clients that has support for jingle file transfer(pidgin, gtalk) so we definitely will see more clients implementing this, but, is there anything extra that jingle has brought us so we can improve the file transfer process? What's the rationale behind implementing file transfer over jingle given SI file transfer already works fine? Jingle FT allows to use any transport you want, and especially ICE-TCP that allow a better NAT traversal. -- Yann ___ 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] questions about gsoc: file transfer over jingle
bear wrote: On Mon, Mar 22, 2010 at 12:47, bear bea...@gmail.com wrote: at the risk of being labeled a top poster by the others ... ;) Hi! I hope your interested in letting the XSF host your GSoC project. If so, then we need to add it to the Project Ideas wiki page at http://wiki.xmpp.org/web/Summer_of_Code_2010_Project_Ideas so that we can find a mentor for the project and also so that you can get the information together for the GSoC council to vote on your project. and it would seem I have mis-spoken in my first email as GSoC admin ;) The project page is where XSF members list what projects they would like to consider - not GSoC Student candidates - doh! So after you get some discussion going with the devs about your project, we can consider adding the project to that page. Sorry for the spam/bad-info/noise Hi, The project is already listed in the XSF ideas page (in fact in Gajim ideas page, link is on XSF page), and I am willing mentor it. We'll discuss that when all applications will be posted. -- Yann ___ 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] gmail + non-SASL
Nathan Fritz wrote: You must be referring to the 5223 service? The resource hex values indicate the cluster node your session data. I imagine only one of the servers handles old-style jabber connections if it doesn't rewrite your resource. Using the old style auth is NOT xmpp 1.0 compliant while the server rewriting resouces is acceptable in the spec and I think a really neat solution for cluster optimization. Another reason for the lack of resource rewrite in old style jabber is that resource binding didn't exist. In short those connections are not xmpp. No no I mean connected on port 5222, with TLS (not SSL). I'm only talking about the authentication mechanism. Once connected and tls proceeded, I send: iq xmlns=jabber:client type=get id=1query xmlns=jabber:iq:authusernameXXX/username/query/iq instead of auth xmlns=urn:ietf:params:xml:ns:xmpp-sasl mechanism=DIGEST-MD5 / Maybe it's convenient for server admin to have those cluster node in resource, but as a user, I really don't care and don't want to see that. Now the problem is not that the client doesn't support resource binding, just that it's not nice from a user point of view. -- Yann ___ 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 ___
[jdev] gmail + non-SASL
Hi all, A user of my client pointed me that when we log to gmail server without SASL, server doesn't add this annoying chars at the end of the resource. We can at last have the resource we want. Now that means we perform plain text authentication, but over TLS. Any idea why using SASL gmail adds some random chars to resource and don't without SASL? Any opinion if it's a good idea to make the client don't use SASL when it's gmail server? Thanks for your opinion -- Yann ___ 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] Converting one-on-one chat into a multi-user conference
Le 11/12/2009 10:37, jadahl a écrit : Trying out the feature in Gajim, only thing I can see is the two servers I have easy access to without setting up my own server (Openfire and ejabberd), these two has no support for it. Or am I wrong? When gajim asks for a unique room, both of them has no idea of what is going on. Indeed there are not many implementatino supporting unique room jid feature, but in this case, Gajim just use a random room jid, probability that it's not used is high .. -- Yann ___ 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] Converting one-on-one chat into a multi-user conference
Le 11/12/2009 13:16, Jonas Ådahl a écrit : I see, then the reason why it does not work with Openfire XMPP server might be that it does not reply with a /not-supported/ iq error. I never tested with openfire, but indeed replying to every IQ is a RFC requirement, and Gajim indeed wait the answer to know if server supports this feature or not. -- Yann ___ 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] Converting one-on-one chat into a multi-user conference
Le 10/12/2009 13:04, Kevin Smith a écrit : On Thu, Dec 10, 2009 at 11:55 AM, Jonas Ådahljad...@gmail.com wrote: What clients are there that supports this part of MUC, and are developers of other clients planning to add this feature? I believe that Gajim already supports it, and Swift intends to. I confirm: Gajim supports it. -- Yann ___ 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] Any clients with 0115 (Caps) 1.5 support?
Pedro Melo wrote: Hi, I'm looking for clients that support XEP-0115 version 1.5 to test interoperability with my own code. Anyone? Gajim does. Don't hesitate to report interop problems! -- Yann ___ 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] xmppony 0.1 is released!
Anaël Verrier wrote: As I said in previous mail, for v0.2, I plan to revamp simplexml, replace debug with standard logging and get rid of fake inheritance. But I also take a look to rfcs and xeps. Because they evolved since the code was written. For example, I found 2 problems in omega's patch (which was written 4-5 years ago). I also plan to make some unit tests. We already have logging system based on logging module in Gajim We have unittest for some xmpppy things. Have a look at test folder. What about zeroconf? Really sad all that work is duplicated :/ -- Yann ___ 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] xmppony 0.1 is released!
Stephan Erb a écrit : Hey, Gajim has forked xmpppy as well. I guess the main difference is a switch to non-blocking sockets and the implementation of BOSH. Maybe there is a chance here to streamline all those different efforts. Best, steve-e That would be awsome, but I think the diff between Gajim fork and xmpppy is: -* +* We re-arranged all files recently. So it will be a lot of work. ___ 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] Game accouncements and Jabber
ajmas wrote: Can anyone tell me whether any clients have added support for XEP-0196: User Gaming? Maybe because Client dev don't play :) Maybe because it's hard to know whether User is playing (Games don't announce via D-Bus that it's running, like User Tune) Just my 2 cent -- Yann ___ 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 - how often?
Jonathan Schleifer a écrit : Am 11.12.2008 um 09:06 schrieb Dave Cridland: (Which tends to break my connection when I'm on the mobile, but I found out how to turn it off). Ah, so I'm not the only one having this problem :). Maybe the timeout should be increased, like send a ping every 300 sec and wait for the reply 300 sec. In this case it's useless, as it's more or less the TCP timeout ... ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] Presence - how often?
Adi wrote: How often should a client send xmpp presence to a server? I assume most XMPP servers usually have a timeout for client idle and the presence should be sent at a value that is less than this timeout to be optimal. But if you are talking to some third party xmpp server, you wouldnt know their client idle timeout setting, so how do we optimize sending presence? - There is XMPP Ping for this: XEP-0199 We send such a ping after 55sec of inactivity and wait for the answer for 20 seconds before assuming we are disconnected -- Yann ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] jabber localization project?
Peter Saint-Andre wrote: Safa Sofuoğlu (one of our GSoC students) mentioned to me that XMPP clients need to provide localized versions of many protocol terms, but that there is no consistency for those terms. Examples include: 1. Concepts like file transfer and even instant messaging 2. Basic presence states like away and dnd 3. Moods (XEP-0107) 4. Activities (XEP-0108) 5. Chat states (XEP-0085) 6. And many more! Perhaps it would help client developers to create a jabber localization project (jabber-babel?) to make this task easier for everyone? I'd be happy to start such a project on Google Code or wherever. Peter user mood and user activity words are in Gajim's translation file. So for next release we'll ask our dear translators to translate them. As we have many language, we'll get many translations of those files. -- Yann ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] jabber localization project?
Peter Saint-Andre wrote: The question is: would it be helpful for multiple clients to use the same translation file(s)? Peter That could prevent some miss-understanding between people who don't have the same client. -- Yann ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] Reproducability of XEP-0115: Entity Capabilities - 5.3 Complex Generation Example
Ralph Meijer wrote: On Tue, 2008-05-06 at 00:35 +0200, Yann Leboulanger wrote: Peter Saint-Andre wrote: We assume that the client received a dataform of type form and then submitted it (no need to include the types there because the entity you're submitting to sent you the form in the first place), and yes I think the client would need to remember the types it received in the dataform of type form in order to properly parse the result. But we could tighten up the spec on this score if that is desirable. That's not always True. For example in XEP-0128, we get a result form without having previously requested anything, so we have no way to know which type of field it is. This is a problem currently in Gajim as our DataForm parser accept several values element only in list-multi. So it doesn't parse correclty dataforms from XEP-0128. So we can't compute correclty caps hash (it contains those values) But I'm not sure it's a good thing to guess field type from the number of values elements in it ... You can know the types of the fields because of the scoping by the FORM_TYPE field. Yes, this would require you knowing about the fields you can expect, but you need that for further processing anyway. ok so you mean that clients are supposed to hard code registrar from http://www.xmpp.org/registrar/formtypes.html ? You don't need to know about the types for hash calculations, since this is not the place to actually validate the form. It only needs to be well-formed and adhere to the Data Forms schema. Right, but it's sad that we have to write another parser to compute caps and not use our standard data forms parser. -- Yann
Re: [jdev] Reproducability of XEP-0115: Entity Capabilities - 5.3 Complex Generation Example
Peter Saint-Andre wrote: We assume that the client received a dataform of type form and then submitted it (no need to include the types there because the entity you're submitting to sent you the form in the first place), and yes I think the client would need to remember the types it received in the dataform of type form in order to properly parse the result. But we could tighten up the spec on this score if that is desirable. That's not always True. For example in XEP-0128, we get a result form without having previously requested anything, so we have no way to know which type of field it is. This is a problem currently in Gajim as our DataForm parser accept several values element only in list-multi. So it doesn't parse correclty dataforms from XEP-0128. So we can't compute correclty caps hash (it contains those values) But I'm not sure it's a good thing to guess field type from the number of values elements in it ... -- Yann
Re: [jdev] Reproducability of XEP-0115: Entity Capabilities - 5.3 Complex Generation Example
Peter Saint-Andre wrote: Yann Leboulanger wrote: I have another question about this example: how is it possible that the field ip_version which has no type (so should be considered as text-single according to XEP-0004) can have several value elements? Typically the field 'type' attribute is provided in data forms of type form only (so that the software presenting the form can show an appropriate interface) but not in forms of type submit or result (since the FORM_TYPE needs to specify the field types). Indeed I re-read XEP-0004 and it says: For data forms of type form, each field/ element SHOULD possess a 'type' attribute that defines the data type of the field data (if no 'type' is specified, the default is text-single); fields provided in the context of other forms types MAY possess a 'type' attribute as well. So in this case how should a client do? It should remember from previous forms that a form with FORM_TYPE=jabber:bot, the field features is of type 'list-multi' to present the results ? For example in XEP-0055 (Jabber Search) there is the reported tag that tells the type of each fields. -- Yann
Re: [jdev] Reproducability of XEP-0115: Entity Capabilities - 5.3 Complex Generation Example
Stephan Maka wrote: Hi there For a test suite, I am trying to reproduce the complex example from XEP-0115 sect. 5.3. It doesn't work out so far: Why isn't the hidden field FORM_TYPE appended to S? Exclusion of hidden fields is not mentioned. it is appended, it's the first one Why do http://jabber.org/protocol/caps and http://jabber.org/protocol/muc include a trailing white-space, opposed to their representation in the Service Discovery result? I don't see any space, but I don't see where in the disco resutl there is cps support. It's not in the features. Why is it in the S string? I have another question about this example: how is it possible that the field ip_version which has no type (so should be considered as text-single according to XEP-0004) can have several value elements? -- Yann
Re: [jdev] what would you think of this as an SoC project?
jehan a écrit : Hello, for info, what do you mean by analyse chat conversations? Statistics analysis? Or intelligent analysis of the content (so an AI project)? By the way, about IM logs, I often thought that it would be nice to be able to store your chat history on servers. Indeed I often want to retrieve some conversation but I am not always on the same place, the same computer or simply I use different clients for tests (so even on the same computer I get lost to where is this interesting discussion I had with someone). Sometimes also I have to use clients with no log support, or I don't want to store them locally though I don't want them lost. In fact, it would be to XMPP what IMAP is to the emails and enable to separate the content (chat history) from the reader (Jabber client), though they will still have to process the data for displaying, search, etc. What do you think of this? You're not the only one :) And a XEP exists: http://www.xmpp.org/extensions/xep-0136.html -- Yann
Re: [jdev] GSoC: Jingle hack
Magnus Henoch wrote: Sjoerd Simons [EMAIL PROTECTED] writes: What your describing here is basically the way Telepathy works. See http://telepathy.freedesktop.org/wiki/Streamed_Media for a global view of how VOIP works with systems using telepathy. Indeed, I'm building such a stream engine. Would the Telepathy stream engine work for a client which does not use the Telepathy XMPP connection manager? Maybe farsight is what you're looking for ? It's what is used in Gajim to handle Jingle things. -- Yann
Re: [jdev] Google Summer of Code 2008
Peter Saint-Andre wrote: For the fourth year in a row, the XSF has been chosen to participate in the Google Summer of Code: http://wiki.jabber.org/index.php/Summer_of_Code_2008 Yeah ! Cool !! DEVELOPERS/MENTORS If you work on an active Jabber/XMPP codebase but you have not yet posted project ideas at the wiki, please do so as soon as possible. For example, I don't see any ideas for ejabberd, Gajim, gloox, jabberd14, jabberd2, Loudmouth, Openfire, SleekXMPP, Smack, Spark, Tigase, XMPP4R, etc. If you are interested in being a mentor or in helping to choose the GSoC projects, please ping me via IM. Done, I added 2 projects for Gajim. Comments and questiosn are of course welcome. -- Yann
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Pedro Melo wrote: It helps the test scenario you presented us with, unplugging of ethernet cable.. Indeed, but we already have notwork manager implementation. This senario was just an example. Most OSs have some sort of notification for this. I know Mac OS X has, and I think Linux also. And Tomasz mentions windows too. For windows I don't know how to do. I haven't really serched though. For linux we use dbus to communicate with netowork manager. -- Yann
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Tomasz Sterna a écrit : On Pn, 2008-01-21 at 19:34 +0100, Yann Leboulanger wrote: Not really. It's pretty verbose. We generally prefer to send whitespace over the TCP connection. We usually call that whitespace ping. I thought keepalives is a more common name. :-) That won't inform us if connection is brocken or server is down as those whitespace ping don't receive a pong ... Not fully true. You really do not receive pongs at the application level, but you really do not need to. Every sent TCP packed is ACK'ed on the TCP level. If it isn't ACKed it is resent a few times until a timeout is reached and the broken connection is signalled to the application level. hmm interesting, I'll try to see what I can do in python. That's indeed better that XEP-198 and XEP-199 for what I want to do. Other option is immediate detection of broken connection by receiving NACK. This also is signalled to the application level. That sound a bit hard to disconenct when the first packet is not received :) This is all going under the hood and there is no reason to reimplement it at again at application level. The TCP layer implementation is usually very effective. You may want to tune the timeout values though, but most modern OSes have it set up at reasonable defaults. you know what reasonable defaults means ? some minutes ? -- Yann
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Tomasz Sterna a écrit : There are many more. Tuning them requires good knowledge of TCP internals. Ok, XEP-0199 will do that then ;)
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Tomasz Sterna a écrit : On Śr, 2008-01-23 at 17:12 +0100, Yann Leboulanger wrote: So is it really possible to find reasonable values for all those parameters that I don't know what they really do? Is it tunable from python for a particular socket or is it in OS directly? Why do you want to tune it? Because currently if I unplug my internet cable, my client detect connectut after several minutes, and I'd like it to detect it faster. Do you really think that your OS designers and IP stack designers did it wrong and put wrong default values? Of course not, but this timout really depends on the application you do. I understand that in some cases it's good to have longer timeouts. If so, you would know why these values are wrong and what to put there, which you seem not know.
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Tomasz Sterna a écrit : On Śr, 2008-01-23 at 13:32 +0100, Yann Leboulanger wrote: Ok, XEP-0199 will do that then ;) I've been trying to explain that whitespace keepalive is enough. It seems that I failed... You haven't, I also think that it's better, but as you said it's hard to tune the socket correctly, and it depends on the machine you're on, etc. It seems you need to tune many things: timeount for waiting ACK, how many retry before telling application that packet failed, and probably many others. Default values is not good for a jabber client I think. It takes several minutes before we know that connection is broken. So is it really possible to find reasonable values for all those parameters that I don't know what they really do? Is it tunable from python for a particular socket or is it in OS directly? -- Yann
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Tomasz Sterna wrote: On Śr, 2008-01-23 at 17:21 +0100, Yann Leboulanger wrote: Why do you want to tune it? Because currently if I unplug my internet cable, my client detect connectut after several minutes, and I'd like it to detect it faster. a) make whitespace keepalive window shorter I just did a test: I send keepalive packets every minutes, and it took 15 minutes to detect that I unplugged my ethernet link. I'd like to decrease this timeout. b) use NetworkManager to get notifications about network environment changes (new networks, unplugged cables) and react to notifications accordingly. (IIRC Windows has a similar facility too.) That won't help, you can still be connected to your routeur / local network but jabber server is no more available. -- Yann
[jdev] XEP-0199 (XMPP Ping) to test reliability
Is it a good idea for a client to xmpp-ping server every X seconds to test if it's still available, in order to detect server shutdown, connection cut ... ? -- Yann
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Peter Saint-Andre wrote: Yann Leboulanger wrote: Is it a good idea for a client to xmpp-ping server every X seconds to test if it's still available, in order to detect server shutdown, connection cut ... ? Not really. It's pretty verbose. We generally prefer to send whitespace over the TCP connection. We usually call that whitespace ping. Peter That won't inform us if connection is brocken or server is down as those whitespace ping don't receive a pong ... -- Yann
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Sean Gilbertson wrote: Well, doesn't it tell you whether the socket is broken/closed? If you can send successfully, doesn't it mean that the connection is still valid? Sean On Jan 21, 2008 12:34 PM, Yann Leboulanger [EMAIL PROTECTED] wrote: Peter Saint-Andre wrote: Yann Leboulanger wrote: Is it a good idea for a client to xmpp-ping server every X seconds to test if it's still available, in order to detect server shutdown, connection cut ... ? Not really. It's pretty verbose. We generally prefer to send whitespace over the TCP connection. We usually call that whitespace ping. Peter That won't inform us if connection is brocken or server is down as those whitespace ping don't receive a pong ... -- Yann I'm not expert in low level sockets, but I don't think so. The timeout can be very long. -- Yann
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Peter Saint-Andre wrote: Yann Leboulanger wrote: Peter Saint-Andre wrote: Yann Leboulanger wrote: Is it a good idea for a client to xmpp-ping server every X seconds to test if it's still available, in order to detect server shutdown, connection cut ... ? Not really. It's pretty verbose. We generally prefer to send whitespace over the TCP connection. We usually call that whitespace ping. Peter That won't inform us if connection is brocken or server is down as those whitespace ping don't receive a pong ... Right. I have no deep objections to using XEP-0199 -- we defined it to solve these problems! -- but you might want to be smart about how often you send a ping. Some feedback would be helpful about how often people think they need to send pings. P every 30 seconds ? and we can expect an answer in the next 5 seconds ? Does that sound reasonable ? -- Yann
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Peter Saint-Andre wrote: Sean Egan wrote: On Jan 21, 2008 10:38 AM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Right. I have no deep objections to using XEP-0199 -- we defined it to solve these problems! -- but you might want to be smart about how often you send a ping. Some feedback would be helpful about how often people think they need to send pings. Pidgin sends a ping/ every 60 seconds and times out the connection if it doesn't get a response in 20 seconds. I assume you send a ping only if you have not received an inbound packet in that time? Peter In gajim we send whitespace ping if we haven't received or sent anything in the past 55 seconds (cause some nat server close connection if nothing happen in a minute) But whitespace ping are not enough, so replacing it with xmpp-ping with the same time would be nice. about the time for answer, are some network connection or server so slow that it can reply only 20 seconds later? I have no feedback on that, but isn't 5 or 10 seconds enough?
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Michal 'vorner' Vaner wrote: Hello On Mon, Jan 21, 2008 at 07:45:22PM +0100, Yann Leboulanger wrote: every 30 seconds ? and we can expect an answer in the next 5 seconds ? Does that sound reasonable ? Could user turn that off? I'm very glad for the 15 minutes long timeout I get now from low-level TCP timeout. Sometimes, I find an urging need to unplug the cable (for removing knots from my table or so) and the connection just survives it. Besides, I happened to live on a connection with ICMP pings about 15 seconds, so the client would timeout just after the first ping. (I know these are extreme, but in these cases, this solution brings more problems than solve. If I'm on slow connection, I expect to wait, not to get disconnected.) In Gajim the send keep-alive packets is a GUI option, time before sending it is configurable through advanced configuration editor, and time for waiting the answer will be too. -- Yann
Re: [jdev] XEP-0199 (XMPP Ping) to test reliability
Dave Cridland wrote: On Mon Jan 21 18:52:54 2008, Yann Leboulanger wrote: In gajim we send whitespace ping if we haven't received or sent anything in the past 55 seconds (cause some nat server close connection if nothing happen in a minute) But whitespace ping are not enough, so replacing it with xmpp-ping with the same time would be nice. Mhh. Okay. Whitespace pings aren't enough to tell if the connection is actively able to send and receive packets. XEP-0199 tells you not only that, but it also tells you whether the thing you're pinging is willing and able to respond. Both have a use, although for c2s links, XEP-0198 is rather more powerful. Don't confuse those use-cases, because whether or not you use XEP-0199 to test c2s connectivity, whitespace pings are still lighter, and perfect for keeping recalcitrant NATs in line. XEP-0199 is particularly useful when you're expecting a response, but don't seem to be getting anything. about the time for answer, are some network connection or server so slow that it can reply only 20 seconds later? I have no feedback on that, but isn't 5 or 10 seconds enough? HF radio links would need much more, whereas a DSL link would need less. A good rule of thumb might be 10 times the normal RTT. (Which you can detirmine by the usual response to XEP-0199 pings). IMHO, a nice UI would simply note that the latency seemed tremendously high, and offer to reconnect, rather than kill the session - as Michal pointed out, the user often knows what the situation is. Dave. Ha yes I didn't know XEP 198 has a ping section. But we don't get an answer, at least with my ejabberd. And in this case an answer is usefulle to know if server is still alive. So I think XEP 199 is better. -- Yann
