Re: [Standards] Chat States as Headlines
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Am 15.03.2011 um 21:53 schrieb Matthew A. Miller: I know a couple of clients where switching the chatstates message/s to type='headline' will break their support; I'm sure there are others since XEP-0082 specifies the states SHOULD NOT be sent in types other than chat and groupchat. And the problem will arise with other protocols, like RTT for example. Well, if most clients work, I think it would be ok to change the XEP. From my experiences with customers, only message/s that contain a body/ required storage; everything else either had other (better) mechanisms for retrieving the data (e.g. pubsub item retrieval), or storing the message/ was worthless. YMMV. There is no standard saying Don't store if there is no body AFAIK and I'm sure there might be legitimate reasons to store a message without a body. - -- Jonathan -BEGIN PGP SIGNATURE- iQIcBAEBAwAGBQJNgJ1lAAoJEMtRg9d5cXHkWLsP/3v9G/S9ek3FTuBYmxe7Y4KF +86RN8XzLGjZ3kR3WWmId631G31iejfxb/Wj9qbltYkR20I5RRnrSpk4XcD5AG8t nHdod9p8wAOX8L8IXmNF3JfYtpoHxlHtE/t2InNv4oyl3z3kenn86N7oZpKrvkQ4 bDKn0ivqD4Sxqi2LuRE7M1RQWk67dRi/6a0MdWkoC2zoSsmH9gJjI37g5dZjtwp7 27qa9HNZlM54Ra7Ur7FGdXF6oLBLGtUSDPa2vp0UaOqJW4XlPHf5MYQqHduHjGIY YpxqAoAfW8fJeMzYObEfBZaeII+hTGqOFtAiZZmbwNQhw1WiMNCjorImp8ZSgv5V rqdGYi+CzpQC0h/jx52j8npPSJhVK54MwQDYoZj1R63j/wYCdsruweNUd04VTzDs KOAiMZFWEBDwcjxVFYWGRWehPxdHnLUrdkxY9cueLtLt1U2VPOt+or2s1Ia/sEuj 2cf1UTEiabECk7Mw2+5f0vSWqBxCCm20ZPAsOsv1UIGSmYCi0WiWBA/EJzHouwB3 J3R1jq0im+G21ll+yJYxNh89XoIU31HusllQeVB3ND2EsfdDY4qRZhq3tMKvPP4J Ta/w+O8P/HoXyKwSQtfHBocHS9D9CfZWVKOz2CmQEd+Qiedt7QZSN55MQvqlJYqZ 2vDmQWllPiOmqC2mJBMS =Qo9b -END PGP SIGNATURE-
[Standards] Chat States as Headlines
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hi. Just having looked at my offline storage, I saw that chat states are stored by the server. But of course they are, as the type is chat and thus the server has to store them. Thinking about it, wouldn't it make sense to set the type to headline? Are there any reasons why we couldn't just test how many clients still work correctly if you just change the type to headline and if most of the clients still accept it change the XEP? And while we're at it, wouldn't the same make sense for PEP? - -- Jonathan -BEGIN PGP SIGNATURE- iQIcBAEBAwAGBQJNf105AAoJEMtRg9d5cXHkIf4QAJDhJbBTcALBkOezfkKxha/J QKbVSZuy21A9k1rZt3YlM1D0byTkWr3wWRCjnjpwmF5R4oTyziHWRwsxkxLdMbRh mGKrLvIxINUtYOYah58Uo4HKpeoeRY2qOYUNNCtXxSpfe42nFH2ZSRjvm68BgHa+ iz6FqQn+fxqyAxjYsIQ5iHZcKGutWrZ4EYDq/0EWvDoRWmtlwII3Z+we606rZZZS 4cvkDXJfqFV0WgjhSRQhMxLzgEuvNMLe8HudfpCZKLCPkUiS8LV/WmrKegHvi420 ZMJa0MaTgsetcsrd/kuXqP9LboymG3Pi4d0+i8wO9WllT4k4V5mnqLy//ju/K3Hv NIbjpb5qJL81gTCByD6qnKBtM9nDZoM/9KaTDf2hkTb2t0iZ9CiSwlHm5r5jx8Wr ll7QPkPSmROIRXpBDy8C86PdGkAq0XwK87DesRZfEoiT63s6HqOzbrHRIywVZY6e kXnQLZe6UhYGOk1SS5jHI15SdyethDT2kr0MgOi3dySfV1TmhF9i3ouUbp1i/7oF tKZ2x230jQEJHn9JzAiBOiKzQuy97Jb/ix4/YBtHAZm115S6CWsDRo8MgJqxsapG q0VBE68wGZ4XQvze5Jr+EgJME5ZbQk0QuRhiM7V5B0HVXbVzEMc2uN8DE/6BsQwX N3oAI4oeqBVpFojPeXPH =d7id -END PGP SIGNATURE-
Re: [Standards] Correcting last message
Am 24.07.2010 um 12:51 schrieb Kevin Smith: I agree. That's why your suggestion is almost a copy and paste of the example in my proposal. Oh, sorry, early in the morning and somehow thought you were referencing the content. NVM then. -- Jonathan
Re: [Standards] Proposed XMPP Extension: Message Carbons
I only had a short look at it now in the bus, but after that short read, it seems like my phone would ring every time I get a message, even though there's another resource where I actually read the message? If I understood it right, it's missing some way to tell the other resources that you accepted a converstaion and are having it on this resource. It should also be possible to release a conversation again so that all resources receive it - for example if the window is closed or there was no message for a specified amount of time. Just my 2 cents. -- Jonathan
Re: [Standards] XEP-0184 business rules for message receipts
Am 17.02.2010 um 05:53 schrieb Peter Saint-Andre: 1. A sender SHOULD NOT include a request for message receipts when sending a message to the bare JID localp...@domain.tld of the recipient, only when sending to a full JID localp...@domain.tld/ resource. 2. A sender SHOULD NOT include a request for message receipts unless it knows (via Service Discovery [4] or Entity Capabilities [5]) that the intended recipient supports the protocol described herein or unless the use of message receipts is negotiated via Stanza Session Negotiation [6]. I agree that those two are not too useful. It might be desirable to send to the bare JID when the user's offline and get a receipt once he gets online again. 3. A sender SHOULD include an 'id' attribute on the message so that the sender can properly track the receipt. I'd even change that to a MUST, because if you don't know which message was received, it's pretty useless. I'm no longer convinced that these rules are helpful. First, IMHO it does no great harm to include a request for a receipt in a message sent to the bare JID, which might be a message of type normal, a pubsub notification, the first message in a one-to-one chat session, etc. Second, we can get rid of the disco/caps requirement if we get rid of the SHOULD NOT on sending to bare JIDs. And the reference to XEP-0155 is not something I think we want to maintain (personally I'd prefer to deprecate XEP-0155 but that's a topic for a different thread). Third, I'd be tempted to make 'id' inclusion a MUST instead of a SHOULD. See above, I have exactly the same views. Therefore +1. -- Jonathan
Re: [Standards] XEP-0136 modifications
Am 03.02.2010 um 19:27 schrieb Yann Leboulanger: Jonathan Schleifer wrote: Am 02.02.2010 um 20:59 schrieb Yann Leboulanger: I start encrypting the conversation (GPG or E2E). While this is true for E2E, it indeed makes sense to store GPG- encrypted message encrypted. Here, the replay attack of GPG becomes useful, as you can still decrypt it later. But for E2E, you can't decrypt it anymore after the session has ended. ejabberd module (the only server implementation I know) only logs body content. And body doesn't contain GPG data. So it's useless if save is not message or stream. So this add more complexity to this already complexe XEP. If a client wants to log encrypted data, I think it's better for it to do it manually after having decrypted the data. I think the whole stanza should be saved, especially as you lose formattings etc. otherwise. Storing it unencrypted on the server is not a good idea - we'd need to move to encrypted archives then. There's already an XEP for that, but unfortunately, nobody seems to implement it. -- Jonathan
Re: [Standards] XEP-0136 modifications
Am 02.02.2010 um 20:59 schrieb Yann Leboulanger: I start encrypting the conversation (GPG or E2E). While this is true for E2E, it indeed makes sense to store GPG- encrypted message encrypted. Here, the replay attack of GPG becomes useful, as you can still decrypt it later. But for E2E, you can't decrypt it anymore after the session has ended. -- Jonathan
Re: [Standards] XMPP server certificate
Alaric Dailey alar...@pengdows.com wrote: um what servers and clients? Most Jabber servers don't check certs at all atm, but those who do usually know the CACert root certificates. For clients, I don't know of any major one which doesn't know about the CACert root certificate. I've never seen a warning about my CACert certificate in Psi, Gajim, Pidgin, etc. - and I tried a lot of clients. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] XMPP server certificate
Maciek Niedzielski mache...@uaznia.net wrote: If Psi didn't complain then you either have CACert root certificate in your system cert store or in psi cert store (which is not there by default - we only bundle startcom/startssl) Hm, that's interesting, as I can't even remember getting a warning on Windows - and I definitely don't have cacert.org in the system cert store there. On Linux, it might very well be that it is there. Anyway, is there a reason for not including it in Psi? I guess 90% of the servers use either StartCom or CACert. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] XMPP server certificate
Dave Cridland d...@cridland.net wrote: Applications shouldn't be installing trust anchors without a lot of confirming with the user. I'm not talking about an application installing a system-wide root certificate. But if the StartCom certificate is included and used for just that app, it only makes sense to add CACert as well. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] XMPP server certificate
Peter Saint-Andre stpe...@stpeter.im wrote: Not really. It depends on what level of trust you have in those anchors. CAs are not interchangeable. Either you include additional CAs and then it makes sense to include others that are used by a lot of XMPP services, or you don't include any additional CAs at all. It does not make much sense to include one that is often used, but refuse to include another one that is used about the same number of service by reasoning that including CAs is evil, even though it has been done for other CAs. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] XMPP server certificate
Tomasz Sterna to...@xiaoka.com wrote: Should I just forget the XMPP Federation thingy and proceed with self-signed certificate? You could also try cacert.org, which is supported by many clients and servers as well. -- Jonathan signature.asc Description: PGP signature
[Standards] [OT] Re: Fun and games with Huffman
Am 04.08.2009 um 11:00 schrieb Dave Cridland: (Oh, and no, I've not written the XML-based decompressor, yet.) Somehow reminded me of this: http://www.hackles.org/cgi-bin/archives.pl?request=310 ;) -- Jonathan
Re: [Standards] [OT] Re: Fun and games with Huffman
Am 04.08.2009 um 13:34 schrieb Dave Cridland: On Tue Aug 4 12:24:26 2009, Jonathan Schleifer wrote: Am 04.08.2009 um 11:00 schrieb Dave Cridland: (Oh, and no, I've not written the XML-based decompressor, yet.) Somehow reminded me of this: http://www.hackles.org/cgi-bin/archives.pl?request=310 ;) Not quite that bad - the basic Huffman decoder is there, and tested, so I'm reasonably confident that I *could* write the decompressor. Maybe the ;) did not make it clear enough that I was joking, my fault. -- Jonathan
Re: [Standards] XEP-0080: User Location
Nicolas Vérité nicolas.ver...@process-one.net wrote: We have now other geolocation technologies, like GSM (cell-id) and wifi (less accurate). This is not exactly true. While GSM cells are very inaccurate, WiFis can be more accurate than GPS if you are inside a building. Especially if there is more than one WiFi in the building. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Initial presence. Was Roster changes
Jiří Zárevúcky zarevucky.j...@gmail.com wrote: Several people lack the understanding of the problem Jonathan was trying to solve. The original problem is that when you connect, you see everyone offline. Even if they are online, you may have to wait several minutes to see it under some circumstances. If you connect just to quicky check someone's availability, you have a problem, because you can't be entirely sure of him *not* being available unless you actually open an XML console of your client and send a probe yourself (and that only for some implementations anyway). Delay only solves the problem of distinguishing delayed and live presences. The way it works now can be lived with, but I've stumbled several times over this particular problem (as a user) and even though it doesn't affect me often, it's very annoying when it does. Thanks for explaining what I meant :). I guess I was a bit unclear, but what you explained is exactly what I meant. Oh, btw, presence probe doesn't help - you're not guaranteed to get unavailable back. So if you get no reply in some amount of time, it could be that the s2s link is still being established or the user is offline - you still don't know for sure. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Roster changes
Am 16.07.2009 um 09:39 schrieb Pedro Melo: You write solve the presence flood and to me that reads as there is a big problem with it. Maybe that problem is obvious to you, but it really doesn't seem a problem to me. Can you elaborate exactly what is the problem with presence flood? Well, basically, it's two problems: The spam of popups when you log in and the delayed presence. I know that having it in the roster (bad idea, I already corrected myself - a new XEP which sends all initial presences in one stanza would make more sense) doesn't fix this. But this would force server developers to cache presences. The real problem with the presence flood is that they come for about 5 minutes for me. It's like there's one wave of available presences every 30 seconds. This is kind of annoying if you just connect to see if somebody is online and don't know Hm, is that person offline or haven't I just received the presence yet? I know that this is also an implementation issue, maybe more of an implementation issue than a protocol issue. But having a protocol that sends all initial presences at once would do two things: 1.) Force server developers to cache. 2.) You know when you got all presences and then definitely know if somebody is online without waiting 10 minutes just in case you didn't get the initial presence yet. The initial-vs-other presence problem (for end-user notification) is solved by the jabber:x:delay namespace. What other problems are there? See above. Is there a solution that will provide the same level of information (show, status, availability, priority and caps) that the current presence flood provides? And that works in a distributed environment? It would basically be one stanza that includes all the presences. It could even keep the presences 1:1. I would like to help and solve this problems with presence flood, but sincerely, I still don't see what they are. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Roster changes
Am 16.07.2009 um 12:08 schrieb Richard Dobson: Having your server cache the presence's isn't going to help you and will infact make things far worse in your case as it seems your server if its taking 10 minutes for some of the presence's to pop through is having serious connectivity issues with the other servers in question and no amount of caching is going to solve that problem, caching is going to make the situation far worse for you as even if you receive that initial presence saying the other contact is online if its taking stanzas 10 minutes to come through then even if your contact logged off 8 minutes ago your server and now you are going to think they are online when they arn't. I would suggest you get the underlying connectivity issues resolved before even thinking about protocol changes that could infact just make the whole situation worse. Rich Those are not really network issues, but protocol issues: When I sign in, about 50 s2s connections need to be opened - and TLS needs to be negotiated on a lot of them. As my TLS key is 4096 bits RSA, this can take quite a while. IMO this is a protocol problem, because s2s links are clossed to fast. Instead, they should be kept open and presences cached. This would really solve the issue. It does not take 10 minutes for a stanza to get through, but 5 minutes until all s2s links are opened and all presences probed. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Initial presence. Was Roster changes
Am 16.07.2009 um 12:04 schrieb Kevin Smith: If it takes 5 minutes for you to get initial presence from someone, that means it's taking 5 minutes to establish s2s and do the presence round-trip. Now, even if the server remembered (and told you) that they're online, wouldn't that mean that the first message you sent would also take the same time for the servers to get it in gear together? In this case it might even be preferable see them as offline, if you wouldn't be effectively able to communicate yet. No, the idea is to keep the s2s link open and the other server always sends presences, even if I'm not online. When I come online, my server could then send me the last presence. The problem here is, as you already said, s2s. When I sign in, about 50 s2s links needs to be opened, which can take quite a while as my TLS key is 4096 bits. If for example an s2s link would only be closed if it has been inactive for 48h, then you know it's really not going to be used anytime soon. I think keeping it for 48h and exchanging and caching presences would be ok and solve the issue. In fact, it would need less resources than the ultra-low timeout of 10 minutes that a lot of servers have. As an aside: I have no idea what would cause a server to consistently take 5 minutes to get presence to you (apart from sever. overloading, or brokenness) - does anyone have any thoughts on this, because it seems to me that this is the underlying problem we're trying to solve here. It's because all s2s links are opened at once, I guess. IMO, we need to specify a lot more for s2s - a lot there is unspecified. For example after how much time a connection should be considered idle. The problem is that even if I'm online, connections might be regarded as being idle and when I change my presence then, all those need to be reestablished. IMO we close way too fast. It might even happen in a conversation with someone that you already hit the idle time and the next message will take a long time to be transmitted. If I look at my server's logs, it's reconnecting to all different servers all the time because the connections were closed due to being idle. When I increase my idle timeout in the source, that doesn't help much because then the other end closes it. And if you got a server with only few users, this becomes a real issue. On a server with many users like jabber.org, it's unlikely a connection to another server with many users is closed due to being idle. But on a server with about 20 users, it basically happens all the time. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Initial presence. Was Roster changes
Am 16.07.2009 um 13:07 schrieb Remko Tronçon: If for example an s2s link would only be closed if it has been inactive for 48h, then you know it's really not going to be used anytime soon. I think keeping it for 48h and exchanging and caching presences would be ok and And which part of that needs fixing in the protocol? Sounds more like a server implementation issue to me. Talk to your vendor. cheers, Remko Even if it is fixed in my server, the problem still exists if every other server still closes the connection after 10 minutes. I think some standarization here would help. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Initial presence. Was Roster changes
Am 16.07.2009 um 14:03 schrieb Richard Dobson: I don't see why a config/policy issue needs standardising, its entirely up to the server administrator to set their own policies, we cant force that on them, if you don't like how an administrator has configured their server then id suggest you get in contact with the server administrators in question and lobby for change. I'm not for forcing everybody to the same value, but having a sane minimum in the spec. Writing every server admin to please change the timeout (for ejabberd, this means even changing it in the source and recompiling) is not an option at all. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Roster changes
Am 16.07.2009 um 14:10 schrieb Richard Dobson: Out of interest, you arn't hosting your own xmpp server at home on an ADSL connection are you? That might explain the slow connection startup, i.e. insufficient upstream bandwidth. I am, but that isn't the problem, as the connection is hardly at 100% use. There's only little traffic. All other services are not affected when I sign in, so this isn't the problem, as they would suffer from insufficent bandwidth as well if it's the ejabberd eating all the bandwidth. If that's the case then that might be the root of your whole problem and what you need to look at resolving and get yourself some more appropriate hosting for your server, it would also explain why the rest of us arn't having similar problems. Well, it's definitely not that I'm the only one having this problem. I've heard it from others who have a small server as well. IIRC, they were mostly running ejabberd. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Roster changes
Am 16.07.2009 um 14:59 schrieb Pedro Melo: 2.) You know when you got all presences and then definitely know if somebody is online without waiting 10 minutes just in case you didn't get the initial presence yet. […] the 2) is possible today. presence with jabber:x:delay are initial presences, in response to presence probes. Without a jabber:x:delay , they are not. Not exactly - you still don't know whether you have received all initial presences yet or if there are still initial presences to come. You are assuming that the server can even have access to all presences at any point in time... Think about server restarts. I think Jabber.org has around 500k accounts. Is the server expected to send a presence probe to each distinct contact in those 500k roster just to have a clear picture of each user roster presence just so you can have your single stanza? It would only need to do that on startup, so not a real problem. Do you really think this is a good idea? Servers shouldn't be restarted all the time anyway, so yes, I think this won't be a big problem. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Roster changes
Am 16.07.2009 um 15:19 schrieb Richard Dobson: Just because a connection isn't being used 100% doesnt mean you wont have problems all sorts of networking issues come into play, i.e. the amount of connections you are opening in quick succession (some OS's, routers and ISPs have rate limits), NetBSD is known to handle thousands of connections without any performance impact. The machine _IS_ the router and the ISP does not have any limits at all - in fact, this ISP even allows running servers and P2P, explicitly. are you running any P2P clients over the same connection? (these can cause problems because of the sheer amount of connections they open) No. just the asynchronous nature of ADSL on its own can cause issues Then the upstream would be used 100%, but the downstream be mostly idle. But this is not the case. ADSL can have serious contention issues especially if you are using one of the cheapo home accounts (i.e. in the UK that would be people like TalkTalk and Tiscali). Not the case here. Have you tried running the server from an alternate location? so you can be sure its not your connection, that would be the first thing I would try when faced with your setup. The connection definitely isn't the problem, as it's mostly idle and with low pings during login. If there's a hardware limitation, it might be the CPU. Well it does sound like either a connection/bandwidth issue or a bug in ejabberd then, just because other people are having the same issue doesn't necessarily mean it isn't something to do with your setup, rather than protocol. Well, it might be fixable by using another implementation, but it would also be possible to have a protocol that wouldn't even allow these flaws. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Roster changes
Am 16.07.2009 um 15:20 schrieb Richard Dobson: Not exactly - you still don't know whether you have received all initial presences yet or if there are still initial presences to come. Why do you need to know that? It sucks to not have certainity whether you got all presences or not. The idea that some might be shown as being offline although their offline is quite scary. Plus you don't know how long you have to wait to be sure if you got all presences. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Roster changes
Jiří Zárevúcky zarevucky.j...@gmail.com wrote: It's possible I guess, but creating a new roster protocol could have another advantages. For example, the current one doesn't communicate the full state. For pending-in, you have to listen for presences and client even has to guess the state sometimes. The presence subscription handling using presence stanzas is another thing I always considered quite weird. A new roster proto could also include the presences of the contacts so you don't get thousands of presences, but get them with the roster. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Roster changes
Remko Tronçon re...@el-tramo.be wrote: IMO, that would needlessly complicate things (duplicated functionality/information/...) at virtually no gain. cheers, Remko There _IS_ a gain: You won't get presences every few seconds for the 5 minutes after you logged in which spam your desktop with notifications etc. Very, very annoying IMO. Initial presences should come all at once, IMO, so the client doesn't need to show a notification for initial presences. Just waiting for 30 secs like Gajim does doesn't work for me, as it takes 5 minutes until I see all presences (which SUCKS!). -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Roster changes
Philipp Hancke fi...@goodadvice.pages.de wrote: So you want to wait for 5 minutes even when you don't have to? The problem with that is that presences are probed when you sign in instead of the server keeping track of presences, which would be far more efficient. Instead of probing, a server could store the state of each contact. Exactly. However, you have problems with presence state desync then which are even more annoying. One of the problems you also have with presences is that you only get presences for only contacts - not for offline contacts. So you can't know if somebody is really offline or if you just haven't got the presence yet. One of the biggest annoyances in XMPP, IMO. btw, smart implementations (jabberd) stamp the reply to presence probes with jabber:x:delay so that a client can tell the difference between a contact thatbecomes available and one that is available. Which still does not solve the presence flood. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Roster changes
Jiří Zárevúcky zarevucky.j...@gmail.com wrote: I agree with Jonathan. Presence flood is VERY annoying. It may not be by including in the roster (that would indeed not be possible for versioned one), but it needs to be solved sooner or later. Right, maybe including it in the roster is indeed not a very good idea, but having a stanza for all initial presences would. This way you can still request the roster without getting a presence flood and can still use versioned rosters. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] Roster changes
Am 15.07.2009 um 18:32 schrieb Richard Dobson: Which still does not solve the presence flood. Yes it does, if its stamped with jabber:x:delay its a response to a probe and thus an initial presence, if not then its not an initial presence, simples. Which still does not solve the presence flood. Only how it is presented to the user. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] XEP-0051 - Renew that spec?
Reading the current XEP, it sounds like the client should do a normal reconnect? This sounds a bit … disrupting to me. Wouldn't it make more sense to also give the client a token and if the client reconnects with that token, the old session is resumed? Something similar to XEP-0198, but with less overload. The idea is that you get a secret token in the XEP-0051 stanza and specify it on connection the server you were redirected to so the new server knows where you come from and thus you don't have to resend roster etc. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Last Activity in initial presence
Am 02.07.2009 um 00:10 schrieb Peter Saint-Andre: There is such a mechanism in MUC, but AFAIK it's not implemented anywhere. We are using it in Buddycloud for the channels stuff to save traffic (the mobile client only requests new messages since the last time it was online). For the server side, we use palaver, so it seems there is at least one server implementation. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] reliable messaging
Am 17.06.2009 um 16:43 schrieb Dave Cridland: Well, I think you'd find that given nobody implements message receipts anyway That's not quite true, there are quite a few doing XEP-0184 at least on the backend. But I have to agree OTOH as well, I think there's no client besides Gajim yet showing it to the user if a message has not been received in some amount of time. But Miranda is working on that AFAIR. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] [Fwd: WG Action: Extensible Messaging and Presence Protocol (xmpp)]
Am 04.06.2009 um 10:39 schrieb Dave Cridland: On Thu Jun 4 03:34:45 2009, Jonathan Schleifer wrote: I'm not quite familiar with how such processes at the IETF work, but if my time allows me to, I will look how the process works and help where I can. (Keep in mind I have no PhD in cryptography, my only concern was that we were reinventing the wheel because we already had stuff that even works. I'm fine with another standard than ESessions, but no matter which standard it will be, it needs to get done ASAP. We've been talking about this for over a year already and there's still no standard everybody agreed on, not even to talk about a client implementing it). Thankfully, the IETF works much the same way as the XSF - there's some mailing lists, you join them, you offer (hopefully sensible) opinions, and the resultant specification is intended to reflect the consensus of the working group - ie, the people on the mailing list. The feel of the working group mailing lists is much the same as this one, although you will end up rubbing shoulders with people who, for instance, have maintained the global email protocols for the past couple of decades. There's no formal membership (at all) in the IETF, although there is, similar to the XSF, a membership organisation called the ISOC (Internet Society), which holds the keys as it were, and formalizes the IETF's existence in legal terms. In fact, the only major difference is that there is a fairly length and complex IPR policy. (Which is, as you'll find out if you participate in the IETF, astonishingly difficult to change due to the delights of the legal system). This policy can be boiled down to essentially two phrases for participants: 1) If you say anything in the IETF - ie, write a post to a mailing list, send a message to one of the MUC chatrooms, physically speak during a meeting - then anyone else can use that for IETF purposes - as in, your words can be used as part of a specification. 2) If you know of, or become aware of, any patents and other ikky stuff, you need to let people know. There's a formal method for doing this, but simply mentioning it on the XMPP WG's mailing list will be enough to trigger the process. This may not mean that the patented method is dropped, although in practise it usually does. Hope this helps, Dave. Thanks for your detailed explaination, this indeed helps. I will join the list :). -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] [Fwd: WG Action: Extensible Messaging and Presence Protocol (xmpp)]
Am 29.05.2009 um 21:43 schrieb Peter Saint-Andre: Goals and Milestones: Mar 2010 Decide upon a direction for server-to-server connection reuse. Aug 2010 Deliver rfc3920bis and rfc3921bis to the IESG. Dec 2010 Decide upon a direction for end-to-end encryption. Jan 2011 Define a framework for SIP-XMPP interworking. Feb 2011 Define a solution for server-to-server connection reuse. Aug 2011 Define a solution for end-to-end encryption. Great, so maybe we see some client being released in a stable version that supports it in about 3 years. I know you hate to hear this, but I think if we would have put some effort into ESessions, we would have had something usable much earlier. In fact, at least one client even has a stable release with ESessions. But it's too late now, things are decided and we have to wait until about the beginning of 2012 to have it in a stable release of a client… -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] [Fwd: WG Action: Extensible Messaging and Presence Protocol (xmpp)]
Am 04.06.2009 um 04:00 schrieb Peter Saint-Andre: Nothing says that we can't finish things sooner than defined by the milestones on the charter (I'm not quite sure how those got defined, because I think we can finish sooner, but Working Group chairs and IETF Area Directors tend to be conservative about milestones). That's good to hear and quite a relief. The current situation of having only XEP-0027 for E2E encryption is quite limiting. Feel free to help in that effort instead of continually beating the dead horse of ESessions. Indeed, once I convert XEP-0210 to an Internet-Draft that specifies our requirements, you are free to write an Internet-Draft that proposes ESessions as the preferred direction for end-to-end encryption to meet those requirements (yes, the IETF is an open standards organization!). I'm not quite familiar with how such processes at the IETF work, but if my time allows me to, I will look how the process works and help where I can. (Keep in mind I have no PhD in cryptography, my only concern was that we were reinventing the wheel because we already had stuff that even works. I'm fine with another standard than ESessions, but no matter which standard it will be, it needs to get done ASAP. We've been talking about this for over a year already and there's still no standard everybody agreed on, not even to talk about a client implementing it). -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] interop testing effort
Am 19.05.2009 um 09:44 schrieb Artur Hefczyc: These are just simple text files describing what has to be sent to the server and what is expected as a response. The TTS is written in Java and part of the TTS code is a loader for these .cot files. Do you parse those text strings and compare the resulting XML elements? Otherwise, this will be pretty limited to one server, as it will even fail if you use instead of ' or vice versa. It's still standard-compliant then, but different. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Call for Experience: XEP-0199 (XMPP Ping)
Dave, are you sure sending pings for keepalive is a good idea? This generates a lot of traffic for mobile devices. Normally, a TCP keepalive or - if not available - sending a space should be sufficient. IMO, pinging should be used to get to know the latency, not as a keepalive. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] How to handle send_last_published_items / on_sub_and_presence for PEP nodes?
Wouldn't make it more sense to only get the PEP events of users who are online and get the last event of a user as soon as he signs in? IMO, this would make more sense and this is also how ejabberd handles it. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] How to handle send_last_published_items / on_sub_and_presence for PEP nodes?
Am 20.04.2009 um 14:04 schrieb Dave Cridland: Lots of rich presence states persist even when the user is offline. The status/ field, for instance, we can even set *when* we go offline, and lots of clients (include Gajim) can make use of this. If I go offline so I can, for example, play games, or because I've gone on holiday, I think that my contacts should get the backdated PEP event telling them so when I'm offline. Makes sense. And plenty of PEP items unrelated to online/offline state exist, too, so to limit PEP to only cases when the contacts are online is simply broken. So again, I'd say: 1) The spec says that you get PEP events for ALL contacts, online or not. 2) The spec doesn't say you get events for newly online contacts. 3) Some client mistakenly rely on odd server behaviour, particular in the case of (2). We remove the PEP event when a user signs off because it would be inconsistent to what you'd get when you sign in again. You wouldn't get the PEP events of offline users then. But as we cleared now that this is an ejabberd bug, I'm happy to change that once ejabberd is fixed. 4) (1) and (2) are not only what the specification says, but also the desired behaviour. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] unavailable presence from bare JID
Robin Redeker el...@x-paste.de wrote: _that_ would be even worse than a bare JID, as the resource part MUST NOT be empty. A resource string is always at least 1 character long. I disagree. Having an empty C string as a resource is most of the time a smaller issue than having it NULL because it's missing entirely. And having an available presence from a bare JID is completely undefined, whereas from a resource is defined. So, this would be only a violation of the naming policies for resources, but not trigger undefined behaviour. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] unavailable presence from bare JID
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Am 09.04.2009 um 00:11 schrieb Justin Karneges: However, transport contacts often have no resource. These are not real logged in XMPP clients, but faked contacts from a server component. You will get presence from='screenn...@aim.transport'/ and have to deal with it. You usually get presence from screenn...@foo.transport/ - so it's not a bare JID, but a JID with empty resource. At least, I haven't seen getting presence from a bare JID so far. - -- Jonathan -BEGIN PGP SIGNATURE- iQIcBAEBAwAGBQJJ3b77AAoJEMtRg9d5cXHkbEgP/RIYaYO1HaP7fzdtHmrHyi96 yKcF41hwEXTUqGYNGILfipRATcPcpJB7hJhQs/oi5dJeh3bEVTrBlan89CTtKhrP 7zauMP72HDUw4PQXtlsZFXgDcD9GfMzIgTVsOk3EgxexefCY8G9MphAUtp16Jusu rybb6H4Xr2OecdPgDTJTECd59DzTWCGzyujYTSKxKYV7ozRUl/pPKJnBJrXpEppo hlfSjI97WW3KH9MyK6Jlx6nWnZOtCEg6dXJ0fTIue4K5etKszVqvf9e013upMoxh JKeNr6C7ZBcaVxVWL6mv97bg55bXOAg/wP3y0lrdC31QQSdTlK2phNDnOdE7B+I4 BZLf/xgF0TGDkGEc/Q9SHH3LFhsyY+CstFatgsoF+TuQJVPYloJqIJ/hzSXO+EFp G4V1fhCILoHSq1l3D0usoYos7GiVg46l1vp9OFEGHPZYvkCnsZgE+rXOgGbsQe3R c0jkQ60aSYgELDFdomWTpb9FM1W+bPrq2HUs5vQGEquXKngkqHPt5dFZeoa4uzQ2 HJZkgxwlpMpspVTp/tzpKVf3NOpT6MmeNi9T7dvVomevDiG8vqnmhqmLFO/T5dFU cTx/xTI4vXmnDPlxbHyLFk/2P8Ffn+H5ABrRd0CaRVmpOUKtPB2eZ8a7xVGDBB9k fcTpU1sW+1Q4P0lOPWgx =MbAW -END PGP SIGNATURE-
Re: [Standards] Section 2.3 of XEP-0107
Am 05.04.2009 um 20:40 schrieb Peter Saint-Andre: Clarified: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0107.xml?%40diffMode=u%40diffWrap=sr1=2467r2=2990u=3ignore=k= Sounds good :). -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
[Standards] Question about XEP-0241
Hi! I've got a question regarding XEP-0241. I have to admit that I haven't completely read it yet, but what I'm wondering is: If I understand it right, auto-archiving has to be enabled for every session manually, even though it's encrypted. Wouldn't it be feasible to make this a permanent option, so that if you turn it on, it's on for every current and future session, as it's encrypted anyway? That would make it possible to also use it with clients that don't support server side history. For example, I could implement XEP-0241 in Gajim and use JWChat when I'm somewhere else. When I return home, I have can see the history in Gajim. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Proposed XMPP Extension: File Transfer Thumbnails
Am 30.03.2009 um 20:39 schrieb XMPP Extensions Editor: The XMPP Extensions Editor has received a proposal for a new XEP. Title: File Transfer Thumbnails Abstract: This specification defines a way for a client supply a preview image for a file transfer. URL: http://www.xmpp.org/extensions/inbox/thumbs.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. Nice, this is exactly what I suggested once (show a picture in the chat window, transfer it when you click it). Two suggestions though: • Specify how the client should handle it. Like show a thumbnail in the chat window and show start the transfer when you click it. • Security considerations: We specify width and height, but the client MUST NOT rely on these, otherwise it can lead to security issues. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] MUC avatar/logo
Am 18.03.2009 um 13:20 schrieb Dave Cridland: Options include: 1) An extended Disco feature of a URI to the room's logo. 2) An extended Disco feature of the room's logo (base64 encoded or something). 3) Define a pubsub root node for rooms, and PEP-for-MUC (MEP, as has been suggested). Then use XEP-0084 on rooms. 4) All of the above. 5.) Create a VCard for the MUC that allows it to have even more than just an avatar :). This might actually work in some clients out of the box. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] MUC avatar/logo
Am 18.03.2009 um 14:43 schrieb Nicolas Vérité: Or MUC Profile? Like User Profile? I think a VCard is exactly what you mean, or what do you mean by User Profile? -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Proposed XMPP Extension: Server IP Check
Why do we need to send what we think is our IP? IMO, this is completely useless, as it doesn't matter at all. It only means extra work for the client developers, which means they need to find a portable way to detect the IP adress on all interfaces. Plus this only allows specifying one IP. I think this puts unnecessary burdens on client developers. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Proposed XMPP Extension: Server IP Check
Am 10.03.2009 um 22:07 schrieb Peter Saint-Andre: On 3/10/09 3:04 PM, Jonathan Schleifer wrote: Why do we need to send what we think is our IP? IMO, this is completely useless, as it doesn't matter at all. We had discussions about this in Brussels. Some people want this. No one says you need to implement it in your client. For which reason do we need that? It only means extra work for the client developers, which means they need to find a portable way to detect the IP adress on all interfaces. Plus this only allows specifying one IP. I think this puts unnecessary burdens on client developers. Another option is not to send the client's IP at all and the server just returns the IP address that it sees as the IP from which the client connected. That's exactly what I proposed - I don't want to worry about getting an IP from the interface for which I know it's wrong in 90% of the cases anyway. -- Jonathan -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Proposed XMPP Extension: Server IP Check
Am 10.03.2009 um 22:37 schrieb Kurt Zeilenga: Which might be an IPv6 address when the client used IPv4, or vice versa. An illustration showing an IPv6 address should also be included. What's the problem with including something like family='AF_INET' or family='AF_INET6' in the query? -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] end-to-end stanza routing
Am 05.03.2009 um 23:50 schrieb Peter Saint-Andre: Right. I really don't see a need for having multiple e2e streams. I do. Imagine the following situation: I want to chat with someone encrypteed, thus I negotiate a session. I do that using IBB (it's the default, right? At least I think we decided on that some while ago :)). Now I want to send that user a file. If I send that IBB, the server administrator will propably kill me ;). So I negotiate another session that is P2P for the file transfer and STARTTLS that as well. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] end-to-end stanza routing
Am 06.03.2009 um 19:24 schrieb Dirk Meyer: Depends on the file. If I send you a small txt file with my notes, IBB is ok. If I send you a mp3 file, IBB is bad, S5B with proxy is ok. If I send you a HDTV recording, the proxy administrator will kill me if I use a proxy. So for file transfer it depends on the file. We should define some rules for that. Always using P2P for file transfers and doing fall backs depending on file size sounds like a good idea. For example, if the file is 100 MB, fall back to proxy, if it 10 KB, fall back to IBB. No. Klaus asked about stanzas. There is only one e2e streams for stanzas. It makes no sense to open a second one. You may open another e2e tls stream for file transfer, but that has nothing to do with the question where to route a message Ah, ok, I was talking about encrypted sessions in general. Misunderstood it then that we are only talking about chat/other XML stuff sessions. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] roster views
Am 28.02.2009 um 15:30 schrieb Mickael Remond: I think the main use case is really to restrict your roster (and presence to a few group). Personnally, that's what refrain me to connect on XMPP sometimes, I want to talk with someone in a company group, but will not be able / have time / be convenient talking to friends or other types of contact. The idea is really that on mobile, you might want to start a quick adhoc session that will be limited to a target group. That should be achieved by other means IMO. For example, you could only retrieve the roster group you are interested in and use a privacy list so that only this roster group receives your presence. The privacy list could also block incoming presences. What you suggest can be done by retrieving the roster normally and enabling a privacy rule. No, what I mean is simply not retrieving the whole roster. For example, I could have a group Bots that I'm not interested in, but which need to see my status. So why retrieve them as part of the roster then? I think retrieving only a part of the roster should not change anything regarding presence. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] roster views
Am 28.02.2009 um 17:16 schrieb Mickael Remond: I think it should. That's what most people do when they want to achieve what I described in a good way: They create several accounts (work, home for example) and use them accordingly. This approach would allow to use one account to achieve the same result: Being able to have several profile that you can use depending Ok, then how do you want to solve the use-case that you have thousands of users who should see you, but you're not interested in their presence? With you're aproach, they wouldn't see you - thus it would miserably fail for this use case. If you DON'T filter presence based on which parts of the roster you received, you can STILL use privacy lists to achieve what you want - BOTH usecases would be possible this way. Regarding the roster, do not forget that you are not forced to get it when you connect. But maybe I _WANT_ parts of it? I for example _WANT_ to see those in the group Friends, but DONT'T want to see those in the group Work when I'm at home, but still want that they can send me messages if there's something important. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] roster views
Am 28.02.2009 um 17:44 schrieb Mickael Remond: End user do not seems to understand privacy lists, and most of all they need to make the effort of building them. They need to have build the privacy list before being able to do what I described. This suppose planning that seems to go beyond what most users are wanting to do, as opposed to Oups, I absolutely need to talk to our sysadmin let's have a quick chat, which is very common and I guess users would love being able to do. I agree that we need an alternative for privacy lists - but this is definitely not partial roster retrival‼ This sounds like a client side feature to me: - Client should only display part of the roster you want to see (for example one groups). - Client should use the cached version of the roster on the client to avoid downloading it. I would still need to get the whole roster to get updates - not a good idea IMO. Why would I download stuff I'm not interested in? That's just wasting traffic and CPU power :). -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] roster views
I think it's a bad idea to filter the presence on that part of the roster that is retreived. For example, you might have 2000 people who all should see you so they can ask you stuff etc. But you got only about 10 people in whose presence you are interested, because you maybe want to start a discussion with them. It would be bad if only those could see you then, becase you are still ok with the others seeing you and asking you stuff if you have questions. Oh, and we need a way to retrieve the list of groups before we can specify which groups we want to receive, I think. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Section 2.3 of XEP-0107
Am 11.02.2009 um 21:34 schrieb Ralph Meijer: If Gajim implements sending along moods in messages, for the sole purpose of replacing PEP, I would consider that a bug. It goes against the very reason we started to define our publish-subscribe specifications for. We had a few discussions about that in the Gajim team and finally could agree that this is not intended. and reverted that diff a long while ago. It seems a few misunderstood the XEP and after re-reading it got it right, so maybe we could add some clarification there. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Password protected rooms
Just a reason NOT to require a PW for the owner: Some admin might have changed it and now the owner can't join the room anymore or change it back. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] Password protected rooms
Am 11.02.2009 um 16:08 schrieb Matthew Wild: That same admin could simply remove the owner from the owner list and be done :) Nope, at least in ejabberd, an admin can't take it from an owner IIRC ;). -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
Btw, I got one suggestion that would fix merging contacts: Give contacts a UUID when you make them a meta contact. That UUID could be shared on the two servers, so the client knows that the contacts from both accounts form one meta contact. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
Am 23.01.2009 um 12:32 schrieb Kevin Smith: Brilliant idea - it's almost as if you'd read the XEP. I'm sure the last time I looked at it it didn't. And IIRC, Gajim doesn't use a UUID there either. At least I can't remember having seen one there when I debugged some meta-contact related bug. -- Jonathan PGP.sig Description: Signierter Teil der Nachricht
Re: [Standards] DEFERRED: XEP-0209 (Metacontacts)
Olivier Goffart ogoff...@kde.org wrote: What would be the need of having different name for sub-contacts inside the same metacontact? If someone got two XMPP accounts, you might append the server name in brackets. Or when using transports, you might want to append something like (ICQ). Or one got a work accound and a private account, you might want to add (Work) and (Home). Or someone still uses his old account, but only for a short amount of time, so you might append (old). Or you added the other account as a fallback, so you might want to append (fallback). There are 1000 of reasons. Thus, I consider the Kopete behaviour rather bad. -- Jonathan signature.asc Description: PGP signature
Re: [Standards] XTLS revisited
+1 That's exactly what I have been promoting for a long time. Why add unnecessary complexity? I'm prefectly fine with something like that and likely to implement that. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] XTLS revisited
Am 15.12.2008 um 18:17 schrieb Justin Karneges: This means that a single transporting stanza might contain multiple message stanzas, and a single message stanza might require multiple transporting stanzas to deliver. Additionally, a transporting stanza may contain both application data (e.g. a message stanza) and TLS data (handshake messages). Maybe we should make it a requirement that one stanza can only include one message. That'd make things a lot easier. Plus we get confirmation *THAT* single message could be decrypted because we got an iq reply for it. I think it will have only benefits to say that one iq may only include one encrypted message. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] XTLS revisited
Am 15.12.2008 um 20:29 schrieb Dave Cridland: No, it doesn't, really, and it also opens up the ability to do traffic analysis somewhat easier. Well, the client wouldn't need to keep a state for every open XTLS connection whether there is a message stanza for which the end is still missing or not. And we'd have a notice that decryption was successful for free. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] XTLS revisited
Am 15.12.2008 um 20:33 schrieb Dirk Meyer: Jonathan Schleifer wrote: Maybe we should make it a requirement that one stanza can only include one message. That'd make things a lot easier. No, you need to have control over your TLS lib to do so. With the current way you just feed your stanzas into your TLS lib and everytime it outputs something, you send it away. As simple as possible. That means the TLS lib might delay a stanza, so that's bad anyway. So we need control over the TLS lib anyway. We wouldn't want to delay a message until another is sent. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] XMPP VPN?
Am 13.12.2008 um 09:57 schrieb Dirk Meyer: I always like the something-over-XMPP idea. This includes HTTP, VNC, and VPN seems crazy but why not. But for everything like this we need more bandwidth. If can not use IBB for that. VPN over XMPP can use the existing ICE-UDP, but this against shows that we need good TCP support for XMPP. Well, I would even call that idea less crazy than HTTP-over-XMPP or VNC-over-XMPP, as this allows to have something like hamachi where you just rightclick and select VPN. And if that's a standard, that would work with more than just one client ;). So this might be once again something where something proprietary (Hamachi) could be replaced by something free using XMPP :). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] XMPP VPN?
Am 13.12.2008 um 10:52 schrieb Dirk Meyer: HTTP over XMPP may be just wrong to do, but VNC over HTTP is very usefull. Think about all the PC users you know who ask your for help from time to time. It is easier if you can just use VNC to show them remotly. But they are always behind a NAT, so VNC does not work. There are solutions to that problem, but providing VNC access by using XMPP and tunnel the VNC data over a Jingle stream is a very ellegant trick. There will be a button Get help from Jonathan and the XMPP client will connect to you, negotiate a Jingle connection and you will see the remote desktop. But that would require a) end-to-end security and b) a TCP-like connection. On the other hand, I would all have less time to do stuff I want if my sister could get help with a single button :) Sorry, I didn't mean that the idea was crazy of VNC via XMPP (whereas HTTP via XMPP sure is), but that VPN via XMPP is even less crazy :). Sure VNC via XMPP is useless, and once again this is where XMPP could replace something proprietary: TeamViewer for example. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] XMPP VPN?
Am 13.12.2008 um 11:53 schrieb Dirk Meyer: Jonathan Schleifer wrote: Sure VNC via XMPP is useless, and once again this is where XMPP could replace something proprietary: TeamViewer for example. usefull? Oops, there was a not missing, sorry. Still too early in the morning ;). And BTW, I guess it would cost me about one day of work to make a prototype and does this. But it will be very slow since my stack only supports IBB as transport. What I want to say here: XMPP can replace many proprietary solutions with a working Jingle stack. Most solutions only exist to help you through the NAT -- we can do that, too Yeah, maybe we really need to push Jingle :). VPN-via-Jingle wouldn't be too hard either on Linux. For win32, I don't know. -- Jonathan PGP.sig Description: This is a digitally signed message part
[Standards] XMPP VPN?
Well, I recently saw that Wippien has VPN support and uses XMPP for the messaging part. I thought that it maybe might be a good idea to have a XEP for VPN via XMPP. I think this could be achieved quite well with Jingle. We would just need a XEP which specifies how the packets should be transfered over the tunnel established by Jingle. What do you think? -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] [jdev] Initial presence and contact capabilities
Presences between servers are indeed a problem and very error-prone. Maybe we should have a XEP that allows better exchange of presence between server, that is when the s2s was just established? It often gives timeout and a XEP that would list all JIDs of users from server A for which users on server B have subscription could come in handy here, it could have something like: presences contact jid=foo type=available/ contact jid=bar type=awaySome nice away message/contact contact jid=offline_user type=unavailableOffline message, if it was specified on disconnection/contact /presences What do you think? -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] [jdev] Initial presence and contact capabilities
Am 04.12.2008 um 16:01 schrieb Tomasz Sterna: This is possible already without any additional XEP. Just push presence/ packets after an S2S connection is established. And it is implementable both sides. Your server could also pull all required presence states with presence-probes to users on rosters of its users. That's the problem, the presences are often not synced when an s2s connection is established. Not all presences are pushed out in the s2s connection. And offline presences often aren't as well, so that people are online for ages. Sending all of them, even the offline ones, in one stanza would fix that. I am not aware of any server that does that though, but I am not familiar with the commercial ones. But... all transports I've written works similar way - pulling all registered users presences with probes after the T2S (Transport-2-Server) connection establishment. pyICQ-t does that, IIRC. It also sends presence for all offline users. PS: I'd prefer to continue this discussion on the standards list. -- Jonathan -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 22:58 schrieb Peter Saint-Andre: Right, and that gets back to the definition of threads and chat sessions, which we've never settled. Oddly, people seem to adjust quite well to the messy reality of not having neat definitions... When I find the time, I'll try to provide a diff for the two XEPs. Feel free to remind me of that if I forget to do it ;). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 20:10 schrieb Peter Saint-Andre: (just make it so that they send bare-JID message to all resources) ejabberd already does this if there is more than one resource with the highest prio. If you have for example two resources with prio 50 and one with prio 30, both with prio 50 will receive messages to the bare JID. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 20:14 schrieb Peter Saint-Andre: Most servers do that. What I'm suggesting is more of the Google Talk behavior -- a message sent to the bare JID gets sent to *all* resources regardless of priority. That is, priority is ignored and maybe even deprecated. I wouldn't want that, I really wouldn't want that. I have an mcabber connected all the time on my router with priority 0. It's rarely used and never used when any other client is connected. When connecting from any of my other machines, the piority is 50 (if I'm using both and none gets idle). So I get new messages to every machine. That's ok. But I wouldn't want to also get it to my router, as there's no need for that and would make merging logs a PITA once we have server- side, encrypted chat logs (I plan to merge the logs of all my clients into server-side logs then, so this will be a real PITA then). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 20:37 schrieb Matthew A. Miller: I assert that message mine-ing would actually solve your problem better than presence priorities. How? IMO, that works perfectly. I don't have to do anything manually. The message usually just goes where I am, thanks to automatically adjusting priority and auto away after 5 minutes. :) -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 21:55 schrieb Joe Hildebrand: Hopefully, adding the XEP-146 interaction section will make this more clear. If we think this important to do without changing presence, we can either reuse XEP-85 gone, or add a new state of moved that is an unlock hint. Maybe we want threads in the core so we can have threads and move them? -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Message Mine'ing
Am 02.12.2008 um 22:02 schrieb Jack Erwin: Blocking inbound messages with privacy lists can give you this behavior. Not a good idea, as they would be silently dropped and no error returned. -- Jonathan PGP.sig Description: This is a digitally signed message part
[Standards] XEP-0071 Security Considerations
Maybe we should add in the Security Considerations that it MUST NOT be used together with XEP-0027. In Gajim, a patch adding XHTML support was recently committed. However, it always attached XHTML to the message when formattings were used. This is not as bad as other clients, who always send XHTML. However, when formattings were used and GPG was enabled, the body was encrypted and an unencrypted XHTML version of it attached. We should explicitely warn about this, IMO, maybe even in both, XEP-0027 and XEP-0071, as this leads the user into false security and is a severe bug. It is sent in plaintext and the user never notices, unless he looks at the XML console. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] FINAL: XEP-0085 (Chat State Notifications)
Am 26.11.2008 um 22:21 schrieb XMPP Extensions Editor: Version 2.0 of XEP-0085 (Chat State Notifications) has been released. Abstract: This document defines an XMPP protocol extension for communicating the status of a user in a chat session, thus indicating whether a chat partner is actively engaged in the chat, composing a message, temporarily paused, inactive, or gone. The protocol can be used in the context of a one-to-one chat session or a multi-user chat room. Changelog: Per a vote of the XMPP Council, advanced specification to Final; clarified the implicit discovery mechanism. (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0085.xml?%40diffMode=u%40diffWrap=sr1=37r2=2536u=3ignore=k= URL: http://www.xmpp.org/extensions/xep-0085.html Damn! We overlooked this one: Upon receiving a gone/ event, a client MUST NOT re-use the same Thread ID and MUST generate a new Thread ID for any subsequent chat messages sent to the conversation partner. This is different to what the Threads XEP says, IIRC. Plus, it's a bad idea to close the session when there's a gone event, as you might close the window in an encrypted session and don't want to end it just because you closed the window. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] C2C TLS
Thanks for that detailed answer. For the last part of your message: Do you mean that, if any other client will implement ESessions, C2C TLS is pretty much dead? That's sad, then I fear it'd be a step back to GPG :(. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] C2C TLS
Am 25.11.2008 um 14:41 schrieb Dave Cridland: Actually, it's not that the problems are ignored, they're simply punted. XEP-0247 simply says Hey, we'll negotiate something that works, and avoids the entire issue, by design. This is a good thing. We're hoping that technologies like ICE-TCP and other transport layer solutions will be developed. This seems pretty reasonable - I'm not convinced by ICE-TCP itself, but we're not tied to TCP, just a reliably ordered stream, which makes life rather simpler. (FWIW, I suspect we could use ICE to setup two-way UDP communications and layer a reliability layer on that - in fact, I think it's been done). What any sane person would realise is that XMPP expertise won't help there at all, and that a good design would allow these additional technologies to be designed by others, and simply slotted in post- facto. IMO, that brings far too much complexity for a such a simple and mandatory thing like end-to-end encryption. A dependency on Jingle really is too much IMO. It should be so simple to implement, be it whether a library like suggest for ESessions or via a very simple protocol that everybody can very easily implement, that even the most simple client could implement it. Thus have no dependencies on any complex XEP etc. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] C2C TLS
Am 25.11.2008 um 15:40 schrieb Dirk Meyer: IMHO Jingle should be part of any client. File transfer over Jingle is much better than the normal one. You can change the transport if it does not work. And Jingle itself is very simple and not that hard to code. If you want to support RTP over Jingle for a VoIP client, it is much more complicated. Jingle itself is just negotiate a session, fire up IBB or SOCKS5 (which you have for file transfer anyway) and that's it. Well, why would a mobile client want that? You won't transfer files from your cell phone, will you? But you will chat with it. And if you chat with it, you want encryption. I guess the problem for Jingle is, that the XEP uses VoIP as example. Take a look at XEP 0234 (Jingle Filetransfer). It is much easier to understand and more similar to the Jingle security stuff. I have to admit that I haven't read Jingle Filetransfer yet, but had a look at the other Jingle XEPs which I consider too complicated. -- Jonathan PGP.sig Description: This is a digitally signed message part
[Standards] C2C TLS
As the discussion was already month ago now and it was said there will be many clients at the end of the year (which we have now), I wanted to ask a few things: 1.) What is the current state of the XEP? Is it even a XEP now? 2.) How many clients implement it? If any, which? 3.) If there are clients, do they use direct connections or use Jingle's inband mode? 4.) How was the SAS problem solved, if it was solved at all? If not, how will it be solved? 5.) How much work was it to implement it? Was it really just 5 minutes of work as some said in the discussion before? 6.) I predicted that it will still take a long time until C2C TLS will reach the state ESessions now has. To me, it seems my prediction was right. Anything I overlooked? -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] C2C TLS
Am 24.11.2008 um 18:44 schrieb Peter Saint-Andre: That proposal was replaced by e2e-streams.html during list discussion and then published as XEP-0246: Thanks. I'll have a read then. Any client already implementing it? I don't really see any specification of SAS in that. It's only mentioned. Will that be a different XEP? -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] C2C TLS
Am 24.11.2008 um 18:50 schrieb Dave Cridland: C2C TLS has numerous carefully audited crypto implementations, and one (or two?) test client implementations. Now, arguably, it might well have more - I'm not sure how many of the existing XEP-0174 clients will simply use TLS if offered, which would count in at least some respects. Please name at least two implementation so I can test those :). Therefore, in many respects ESessions is already lagging behind C2C TLS without anyone actually having done any coding specifically toward it. Well, what about SAS? I still can't see it. And do they use jingle inband or direct connections? If they use direct connections, is NAT traversal implemented, using a STUN server etc.? -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] definition of a chat session (was: Re: Call for Experience: XEP-0085 (Chat State Notifications))
Am 20.11.2008 um 20:52 schrieb Peter Saint-Andre: Jonathan Schleifer wrote: Well, we just talked about sharing it automatically, so there should be a way to revoke it. :) Right. This gets into the definition of a chat session, so I'm changing the subject. IMHO chat session is still a bit vague, and when I have time I'll work to clean that up in rfc3921bis. However for now I would suggest the following modified text: *** When two parties engage in a chat session but do not share presence with each other based on a presence subscription, they SHOULD send directed presence to each other so that either party can easily discover if the other party changes its availability or goes offline during the course of the chat session. However, a client MUST provide a way for a user to disable such presence sharing globally or to enable it only with particular entities. Furthermore, a party SHOULD send directed unavailable to the other party when it has reason to believe that the chat session is over (e.g., if, after some reasonable amount of time, no subsequent messages have been exchanged between the parties). *** What about XMPP sessions, btw? When we end the session / thread, we should also send unavailable. But this is something to add in the Sessions XEP, isn't it? -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Am 20.11.2008 um 18:51 schrieb Peter Saint-Andre: 1. Use disco/caps only (no implicit discovery) for chat state notifications and just wait for XEP-0022 clients to eventually disappear from the network. I vote for that one :) -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Am 20.11.2008 um 19:53 schrieb Peter Saint-Andre: 1. What if you don't share presence with the other party and therefore can't receive caps data? I assume you'd need to send a service discovery request or share directed presence. That is some thing we need to rework anyway, I think. IMO, when we don't share presence, we should send a directed presence directly after the first message - this should be a seperate XEP or even part of XMPP Messaging or Core. When we close the chat window (or manually using some button in the client), we could send an unavailable presence again - and also when we disconnect, of course. Same for invisibility. It is incredible annoying when someone who's invisible messages you and lots of stuff doesn't work therefore (like sending a file). 2. If you don't know (via disco/caps) that the other party supports XEP-0085, does the spec need to say that you (a) MUST NOT or (b) SHOULD NOT send chat state notifications? A MUST NOT would mean all old clients break it, so I think a SHOULD NOT is better. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Am 20.11.2008 um 20:14 schrieb Peter Saint-Andre: In rfc3921bis you will find the following text as a recommended best practice for chat sessions: If a user exchanges message stanzas with another entity but does not share presence with the entity based on a presence subscription, it is RECOMMENDED for the user's client to send directed presence to the other entity. Could we change RECOMMENDED to SHOULD? I don't agree with sending unavailable when you close the chat window. You might close it right before your contact sends you another reply and then what is their client supposed to do? That seems unnecessary. When you go offline your server will send unavailable, and that seems good enough to me. Well, but maybe have an easy way in the GUI to hide your presence from that users again, so you don't need to relog to hide again :). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Call for Experience: XEP-0085 (Chat State Notifications)
Am 20.11.2008 um 20:30 schrieb Peter Saint-Andre: RECOMMENDED means the same thing as SHOULD. :) So the following are equivalent: It is RECOMMENDED for a client to do X A client SHOULD do X To me, it sounds more necessary to implement a SHOULD than a RECOMMENDED :) Don't share presence in the first place. :P Well, we just talked about sharing it automatically, so there should be a way to revoke it. :) -- Jonathan -- Jonathan PGP.sig Description: This is a digitally signed message part
[Standards] Section 2.3 of XEP-0107
Hi! In Gajim, this diff was recently committed: http://trac.gajim.org/changeset/10593 That lead to a discussion in the Gajim team whether that is right. Section 2.3 of XEP-0107 says: “A user MAY provide a mood extension in a specific message in order to lend a defined emotional tone to the text.” To me, this sounds like you can attach a mood to a single message so that the receiving client can present that to the user together with the message somehow, not replacing the global mood set - which, honestly, sounds pretty useless to me. But on the other side, the Gajim diff uses this to attach the mood to every message sent when PEP is not supported, showing it as the global mood when received and replacing a mood received via PEP, if any was received. To me, this sounds wrong. All this brings me to the question: Is Section 2.3 useful or should it be removed? I personally don't think it should be used as a workaround if the server doesn't support PEP, as that's unwanted traffic (attached to every message, even sending when the receiving entitiy doesn't support moods etc.). If it wasn't meant as a workaround if the server doesn't support PEP, I wonder if it should be removed so it won't be abused for that purpose, as its use if used like I understood is questionable. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] FS:Htc touch diamond- 250USD, Nokia luna 8600 - 370USD, eten glofiish dx900-245USD
Am 05.11.2008 um 16:51 schrieb Peter Saint-Andre: The process is that we report the violation to the administrator of JabberForum and he blacklists that user. Which I'm doing by cc'ing him on this message. That won't help. That spam mail means that the captcha - if there was any - has been broken and a lot more will come soon. Basically, it means everyone can post to the ML now as long as the captcha isn't fixed. PS: Your client seems to break UTF-8 when quoting mails… I think I remember that worked once for you :). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] OT: messages from JabberForum
Am 05.11.2008 um 17:06 schrieb Peter Saint-Andre: Why do you assume the CAPTCHA has been broken? A spam user registered at the forum - most likely, a bot, googling for vulnerable versions of the forum software. It then registers itself and spams. I guess this is what happened - so the captcha at the registration seems to be broken. In fact we have received spam to the lists before from JabberForum, but perhaps only one message a month or so. The current process has worked fine. If that is no longer the case, we'll change the process. This is the first time me getting spam from an XMPP list. :) I send and receive as UTF-8 (and convert incoming mail to UTF-8), but I admit that email encoding seems to not always work (and I don't know why). We should debug that off-list. Feel free to mail me some UTF-8 chars :). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] About posting new topics to the same thread
Am 31.10.2008 um 23:38 schrieb Brett Zamir: Jonathan Schleifer wrote: Oh, and if we're already at it, you should stop using TOFU[1], which is considered very impolite on mailing lists. -- Jonathan [1] http://en.wikipedia.org/wiki/TOFU#Top-posting I personally strongly dislike bottom-posting, and the Wikipedia article you cite also indicates there are preference differences out there, including within mailing lists. - If you are sending a reply to a message or a posting be sure you summarize the original at the top of the message, or include just enough text of the original to give a context. This will make sure readers understand when they start to read your response. Since NetNews, especially, is proliferated by distributing the postings from one host to another, it is possible to see a response to a message before seeing the original. Giving context helps everyone. But do not include the entire original! http://tools.ietf.org/html/rfc1855 So there *IS* a standard for mailing lists. The Wikipedia article also states that this is the netiquette. But instead of getting into a fruitless argument about what we think is the right way, how about we consider some way to solve the problem? Given that we already have the benefit of a formal hierarchical structure within XMPP via XML, how about a namespaced child of message type=normal (too late for body) to keep track of hierarchical content within a posting, which besides enabling posting order display to differ by user preference, would also more easily enable scripting to collapse or navigate a section of quotations, differentially auto-color replies from particular users or levels, etc.? Perhaps even XHTML-IM (XEP 0071) could be overloaded for such a purpose via blockquote's @cite attribute (which could use an XMPP URI or email URI to indicate authorship) and/or the @class attribute (e.g., to distinguish citations from the inner thread from those outside of its context). We're using e-mail here, not XMPP :). For that matter, how about some mechanisms to enable forking of threads, even within a post? (along the lines of, and potentially supporting, wikis, discussion forums, blogs, versioning systems, etc., since, to my mind, these all should all only be slightly different in terms of protocol syntax so that one can easily treat one as (or convert one to) the other, as there is a lot of albeit inadequate convergence between them already). (Sorry I am not too well-informed on all of the numerous specs you all have marvelously already put out there, so my apologies to whatever extent this covers ground already covered.) Then we'd need to switch mailing lists to XMPP. Would be a use scenario for PubSub :). -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Probe Responses
Am 29.10.2008 um 12:21 schrieb Maciek Niedzielski: When I become online, my server sends probes to contacts in my roster, right? (ok, maybe it doesn't work this way for contacts on the same server..) This would allow me to know that - for example - a friend went shopping (status message) 1 hour ago, so he'll be back soon. Sounds useful. Also, presence packets in the initial presence flood would contain delay mark, so clients would have an easy way to disable pop ups for them. I agree, this would be a good idea. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Thought For The Day: type=groupchat
Am 27.10.2008 um 18:20 schrieb Dave Cridland: So, should servers be rerouting anyway? type='groupchat' should be dropped if that resource doesn't exist. And, perhaps more interestingly, what should a client which receives an unexpected type='groupchat' be doing with it? (Currently, most clients appear to discard them silently). mcabber shows an Unexpected groupchat message then and assumes you're in that groupchat then. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Smilies and XMPP
Am 23.10.2008 um 22:12 schrieb Peter Saint-Andre: XEP-0038 has not been touched in years. If someone wants to take over authorship of that document (or wants to author a replacement), please let me know. Well, I'd like to take over, but split it into two XEPs: One defining JISP and one defining a core set of smilies. I think it's not necesssary to implemenet JISP just to have a core set of smilies :). JISP might be a good idea, though, it can't hurd to have a standard for smilie sets across the clients. I'd be willing to write a XEP that defines a basic set of smilies. I'd look at various clients and look which smilies they have in common for that. For maintaining XEP-0038, I don't know yet. If I'd maintain it, I'd remove the section with the core smilies from it and make that a separate XEP. -- Jonathan PGP.sig Description: This is a digitally signed message part
Re: [Standards] Smilies and XMPP
Am 24.10.2008 um 23:48 schrieb Adam Nemeth: Hi, I have my outstanding XEP-proto still... https://wiki.sch.bme.hu/bin/view/_Munka/JabberCustomSmileys Haven't touched it in a while for sure, because when I implemented it (anyone can ask for my java implementation) it seemed to me it's pretty hard to implement. I still think that MSN could thank its majority MOSTLY because of custom emoticon handling (one by one, not by set!), and NOT because the more primitive windows messenger was built-in into XP. That's a whole different topic and I think I remember that we already had a XEP for that. -- Jonathan PGP.sig Description: This is a digitally signed message part
[Standards] Smilies and XMPP
Every network has it's static set of smilies. Sure, this isn't very customizable. But it solves the issue of different smilie codes. Don't get me wrong, I don't advocate static smilie sets for networks, but I think we could need some standarization on the smilie codes. What do you think? I thought about creating a XEP that defines a basic set of emoticons, which code to use for them and how to render them that SHOULD be implemented by a client showing smilies as graphics. And that also tells to use the transport-specific emoticons, if there are any. Just to give you an idea, I thought having a table like this: Icon | Name | Codes | Description An example smilie | tongue | :P or :-P | A smilie showing its tongue If there's interest, I'll try to create a XEP defining a basic list of smilies that a client SHOULD implement - it's free to implement more than that. That would get some consistency into emoticons among XMPP clients. The XEP could also specify optional smilies that many clients implement, but aren't really necessary. -- Jonathan PGP.sig Description: This is a digitally signed message part
