Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Tue Jul 19 08:09:42 2011, Jacek Konieczny wrote: On Mon, Jul 18, 2011 at 03:23:26PM -0600, Peter Saint-Andre wrote: FYI, I've created version 0.0.2 of this ProtoXEP: http://xmpp.org/extensions/inbox/compliance2012.html I would prefer the 'Core' term to be left for the XMPP Core. XMPP is not IM only, and 'Core server' seems a good name for an entity witch implements only RFC 6120 (which is already 'XMPP Core') and RFC 6122 (required by 6120) – that is good enough for some non-IM communication purposes. This does not need to be defined in a XEP. I thought it was 'basic client' and 'basic server' in the XEP-242,243, but now I see it was already 'core'. Though, I think it still can be changed in the new XEPs. We switched to Core/Advanced some time back, when I was on Council. I pushed for the change, and asked Will (Sheward) to come up with new names. The problem is that - and I admit this hasn't really happened - these compliance XEPs are worthless unless they're used by implementers, consultants, and consumers to indicate high-level functionality, and nobody wanted to describe their server, for instance, as Basic in their marketing literature. (And by marketing literature, I include open-source project websites, for the avoidance of doubt). Core is a much more palatable term to use, and Advanced is obviously just fine. However, neither term has really caught on, and the XSF is not using it internally, even. If we choose to publish this document, I think we should consider adding implementer compliance statements to the software lists, to promote their use. I'd be happy to work on a specification to allow that, as well as (with my Isode hat on) provide such a statement. My plan would be that implementers would host an XML description of their compliance levels, which the XSF's software listings would consume and render into the software list. This would mean that most changes (latest version, Core/Advanced, XEPs) would be implementer-driven. If there is interest, I'll sketch this out in more detail. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Tue, Jul 19, 2011 at 09:00:36AM +0100, Dave Cridland wrote: On Tue Jul 19 08:09:42 2011, Jacek Konieczny wrote: On Mon, Jul 18, 2011 at 03:23:26PM -0600, Peter Saint-Andre wrote: FYI, I've created version 0.0.2 of this ProtoXEP: http://xmpp.org/extensions/inbox/compliance2012.html I would prefer the 'Core' term to be left for the XMPP Core. XMPP is not IM only, and 'Core server' seems a good name for an entity witch implements only RFC 6120 (which is already 'XMPP Core') and RFC 6122 (required by 6120) – that is good enough for some non-IM communication purposes. This does not need to be defined in a XEP. I thought it was 'basic client' and 'basic server' in the XEP-242,243, but now I see it was already 'core'. Though, I think it still can be changed in the new XEPs. We switched to Core/Advanced some time back, when I was on Council. I pushed for the change, and asked Will (Sheward) to come up with new names. The problem is that - and I admit this hasn't really happened - these compliance XEPs are worthless unless they're used by implementers, consultants, and consumers to indicate high-level functionality, and nobody wanted to describe their server, for instance, as Basic in their marketing literature. (And by marketing literature, I include open-source project websites, for the avoidance of doubt). Core is a much more palatable term to use, and Advanced is obviously just fine. Right. This is more about marketing than technology. Core and Advanced is fine with me. I also think that 2012 might be the year for us to define a Media suite for clients However, neither term has really caught on, and the XSF is not using it internally, even. If we choose to publish this document, I think we should consider adding implementer compliance statements to the software lists, to promote their use. I'd be happy to work on a specification to allow that, as well as (with my Isode hat on) provide such a statement. My plan would be that implementers would host an XML description of their compliance levels, which the XSF's software listings would consume and render into the software list. This would mean that most changes (latest version, Core/Advanced, XEPs) would be implementer-driven. If there is interest, I'll sketch this out in more detail. Sounds intriguing. /psa
[Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Whitespace Keepalive Negotiation Abstract: This specification defines a method for negotiating how to send keepalives in XMPP. URL: http://www.xmpp.org/extensions/inbox/keepalive.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
[Standards] LAST CALL: XEP-0296 (Best Practices for Resource Locking)
This message constitutes notice of a Last Call for comments on XEP-0296 (Best Practices for Resource Locking). Abstract: This document specifies best practices to be followed by Jabber/XMPP clients about when to lock into, and unlock away from, resources. URL: http://www.xmpp.org/extensions/xep-0296.html This Last Call begins today and shall end at the close of business on 2011-08-05. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
Re: [Standards] Request for Clarification on the Editor's Job Description
On 7/9/11 5:18 AM, Carlo v. Loesch wrote: On Wed, Jul 06, 2011 at 11:21:22AM -0600, Peter Saint-Andre wrote: It was published without Jeremie's approval as a co-author, too. :P As far as I could tell, the Extensions Editor has been Your complaint is not about the role of the XMPP Extensions Editor, but with me personally. I also serve in these roles: - Executive Director - list admin of this list - hostmaster of xmpp.org - etc. You could just as well say you want clarification about the role of the XSF's Executive Director. Further, your concern is about a particular specification (XEP-0220), not about all specifications. So you have a complaint about me as a XEP author, not as XMPP Extensions Editor. Now that we've cleared up that little question of scope... 1. editing XEPs and adding himself to the list of authors accordingly, at times without asking permission by the original authors. May not be the case with the XEP currently in question. That does not apply to XEP-0220. To which XEPs does it apply? 2. publishing substantial (not necessarily in size but in semantics) changes to XEPs without consulting the original authors or seeking permission from them. When you say original authors are you referring to XEP-0220 or to some other specification(s)? 3. publishing changes that make the XEP dysfunctional and, since there is no independent Extensions Editor but himself, advanced these changes for examination by the XSF Council. XEP-0220 underwent a Last Call. Feedback was received. I was incredibly busy with finishing the XMPP RFC revision process, and did not process that feedback until many months had passed. I tried my best to incorporate the feedback, but perhaps I did not succeed. 4. ignoring requests by the original author to make changes (fix errors) to the XEP. Some requests by one of the (not original) authors I did not process because I disagreed with them. Other requests were not incorporated because of oversights on my part. I may be wrong, this is just the impression I got from the distance since I don't have all that much time to devote to XMPP. I also am not sure if there is anything wrong with these 4 behaviors, so let us look up the XSF documentation on the Editor's job: Neither in http://xmpp.org/extensions/xep-0001.html nor in http://xmpp.org/about-xmpp/xsf/xsf-people/#extensions do I see a description of the job of the Extensions Editor sufficiently specific to make it clear if the behaviors described above are either legitimate or inappropriate according to XSF regulations. One passage of Appendix C: Legal Notices might at best be applicable, but I don't know exactly how: Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. So I would kindly like to ask if the 4 behaviors described above are expected legitimate behavior of the XSF Extensions Editor according to the regulations of the XSF. If this is the case, I would recommend Philipp to apologize to Peter for the snarkiness. See above. This is not a matter of the role of the XMPP Extensions Editor, but a matter of me personally. I found Philipp's comments to be unnecessarily snarky. That is a matter of common courtesy, not a matter of XSF rules and regulations. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On 07/19/2011 10:19 PM, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Whitespace Keepalive Negotiation Abstract: This specification defines a method for negotiating how to send keepalives in XMPP. URL: http://www.xmpp.org/extensions/inbox/keepalive.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. hmm I'm not sure this XEP is really usefull. How can server guess the network configuration between client and server? Client may be on a network that cuts connections after 30 seconds of inactivity and server propose a timeout between 60 and 120. That means we cannot connect to this server? Or send whitespace every 30 seconds and be a bad client? the 2nb point of implementation notes is hard to respect: server and client may not know network configuration between them. Whitespace are very small things, is it really usefull for the server to say don't send that too often? I can understand that for xmpp ping (XEP-0199), but for whitespace ... I'm not sure very vague information re usefull. Like a period of time significantly longer than the negotiated value That doesn't help implementors to choose this time. But maybe it's not good to force this time in the XEP. Conclusion: I can understand this XEP for xmpp ping (quite long stanza), but I don't find it very usefull for whitespace ping. Just my opinion -- Yann
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tue, Jul 19, 2011 at 6:31 PM, Yann Leboulanger aste...@lagaule.orgwrote: Whitespace are very small things It doesn't matter how small the things are, if a single packet causes a battery-powered device to wake up WiFi and drain battery for a while before it goes back into a power saving state. Bursting ten packets isn't likely to be much more expensive than sending one. I'm not sure why the server needs to be involved in this, though. Keepalives should be sent from client to server; that's enough to keep the TCP connection and, more importantly, any NAT alive. I don't know why the server would also send keepalives to the client--and without that there's nothing to negotiate. -- Glenn Maynard
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tuesday, July 19, 2011 05:02:30 PM Glenn Maynard wrote: On Tue, Jul 19, 2011 at 6:31 PM, Yann Leboulanger aste...@lagaule.orgwrote: Whitespace are very small things It doesn't matter how small the things are, if a single packet causes a battery-powered device to wake up WiFi and drain battery for a while before it goes back into a power saving state. Bursting ten packets isn't likely to be much more expensive than sending one. I'm not sure why the server needs to be involved in this, though. Keepalives should be sent from client to server; that's enough to keep the TCP connection and, more importantly, any NAT alive. I don't know why the server would also send keepalives to the client--and without that there's nothing to negotiate. Whitespace keepalives serve two purposes: 1) Keep connections from being killed by routers. 2) Inducing TCP cleanup, in the event the peer is gone but you were never notified. If a client leaves the network without disconnecting from the XMPP server, then in theory the client session could last forever. The session will only terminate when the server's TCP stack fails while sending data to it, which will happen either at the next stanza or with whitespace. Justin
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tue, Jul 19, 2011 at 8:19 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: Whitespace keepalives serve two purposes: 1) Keep connections from being killed by routers. Client-originated keepalives normally deal with this, so negotiation isn't needed here--just send keepalives at the needed rate (typically 10-15 minutes). 2) Inducing TCP cleanup, in the event the peer is gone but you were never notified. The server might want to send keepalives for this, but infrequently; on the order of 30-60 minutes. I don't think negotiation is useful in either case, since the keepalives of each side are determined by that side's own requirements. -- Glenn Maynard
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Jul 19, 2011, at 18:55 , Glenn Maynard wrote: On Tue, Jul 19, 2011 at 8:19 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: Whitespace keepalives serve two purposes: 1) Keep connections from being killed by routers. Client-originated keepalives normally deal with this, so negotiation isn't needed here--just send keepalives at the needed rate (typically 10-15 minutes). 2) Inducing TCP cleanup, in the event the peer is gone but you were never notified. The server might want to send keepalives for this, but infrequently; on the order of 30-60 minutes. I don't think negotiation is useful in either case, since the keepalives of each side are determined by that side's own requirements. Sending at that rate will result in a disconnected socket for most of the networks I've seen. There are still an exorbitant number of routers, proxies, firewalls, and load balancers deployed and configured such that they will (silently!) drop a connection if there is no traffic for 5-10 minutes. A number of clients will send a keepalive (whitespace or otherwise) every 60-120 seconds; a number of server deployments will send their own at roughly the same rate. This is great for desktops, but less than ideal for mobile. - mm
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tue, Jul 19, 2011 at 9:13 PM, Matthew A. Miller linuxw...@outer-planes.net wrote: Sending at that rate will result in a disconnected socket for most of the networks I've seen. There are still an exorbitant number of routers, proxies, firewalls, and load balancers deployed and configured such that they will (silently!) drop a connection if there is no traffic for 5-10 minutes. I've never encountered a network that'll disconnect with 10-15-minute keepalives; there may be some, but I doubt most. A number of clients will send a keepalive (whitespace or otherwise) every 60-120 seconds; a number of server deployments will send their own at roughly the same rate. This is great for desktops, but less than ideal for mobile. But, this doesn't require negotiation. If a client needs to send keepalives more frequently (due to broken routers) or less frequently (battery life), it doesn't need to discuss that with the server; it can just do it. If a server is unfortunate enough to be behind broken software that drops connections too quickly, it can likewise adjust its own keepalive interval to compensate, without any negotiation; otherwise it should send them infrequently (if at all). Servers shouldn't be sending keepalives every 60-120 seconds. This just seems like an overcomplication that isn't likely to actually negotiate values that make sense. It also seems to assume that the client and server will always send keepalives at the same rate. (Of course, mobile clients should really be using xbosh anyway, which avoids these and other issues, but it seems like the bosh/xbosh specs have stalled...) -- Glenn Maynard
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tue, 2011-07-19 at 19:13 -0600, Matthew A. Miller wrote: This is great for desktops, but less than ideal for mobile. Perhaps a generic please apply resource policy $foo-spec could be thougt up? So you could tell the server that you're on a constrained link and have it activate various measures. Or do we have this already? identity category=client type=phone/ ? How about a Informal XEP about applying ping/keepalive/buffering based on that? -- Kim Alvefur z...@zash.se
[Standards] BOSH vs. TCP for mobile
On 7/19/11 7:42 PM, Glenn Maynard wrote: (Of course, mobile clients should really be using xbosh anyway, which avoids these and other issues, Opinions vary on that score. We had some discussions about this years ago at one of the XMPP Summit meetings in Brussels and the guys from Nokia reported that TCP was actually much better for mobile apps because there are magical ways to manage long-lived TCP connections without waking up the device, which is not true for the more chatty BOSH protocol. Naturally, YMMV. but it seems like the bosh/xbosh specs have stalled...) How so? The specs are stable so there's probably no need to change them frequently. However, there has been discussion on the b...@xmpp.org list over the last few months and that might lead to some small changes and clarifications. Let's wrap up those threads and see if we need to publish a revised version of XEP-0124 (and perhaps XEP-0206). Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] BOSH vs. TCP for mobile
Hello, I'm a software developer for mobile devices too, and it also varies by method of TCP. For BlackBerry, there are actually several ways to connect, including over BIS (carrier based proxy), BES (corporate BlackBerry Enterprise Server, letting it be the firewall for your BlackBerry), and regular mobile TCP/IP. Many mobile software XMPP clients, such as Beejive, allows these various different methods to be selected. My experience is that some of these methods time out pretty quickly (especially BIS) without keepalives, while some services such as BES have a configurable timeout. Now, a properly optimized TCP/IP connection without a timeout can stay alive for a long time with a mostly dormant mobile radio. The pings can actually wake up a radio, causing the radio to begin consuming more power, unless special design considerations are done to use a lower idle-state bitrate. BOSH, while it solves other things, makes this WAY worse because of the chattiness of BOSH. On the other hand, timeouts exist in many mobile implementations, and thus, some form of keepalive is needed. From a battery perspective on a properly designed mobile device, an open idle TCP connection uses no more battery power than having no TCP connections. There is less chattiness with a once-a-minute ping (sent only if no XMPP transmissions done), than with doing BOSH on a mobile device. Take a look at XEP-0286 XMPP on Mobile Devices. This is accurate battery consumption advice, and my mobile experience agrees with this spec. It's quite annoying detail, really, but this has to be considered. Mark Rejhon (Author of XEP-0301, which also happens to being considered for assistive needs by multiple companies in a multimedia NG911 system on mobile phones.) On 7/19/11, Peter Saint-Andre stpe...@stpeter.im wrote: On 7/19/11 7:42 PM, Glenn Maynard wrote: (Of course, mobile clients should really be using xbosh anyway, which avoids these and other issues, Opinions vary on that score. We had some discussions about this years ago at one of the XMPP Summit meetings in Brussels and the guys from Nokia reported that TCP was actually much better for mobile apps because there are magical ways to manage long-lived TCP connections without waking up the device, which is not true for the more chatty BOSH protocol. Naturally, YMMV. but it seems like the bosh/xbosh specs have stalled...) How so? The specs are stable so there's probably no need to change them frequently. However, there has been discussion on the b...@xmpp.org list over the last few months and that might lead to some small changes and clarifications. Let's wrap up those threads and see if we need to publish a revised version of XEP-0124 (and perhaps XEP-0206). Peter -- Peter Saint-Andre https://stpeter.im/ -- Sent from my mobile device
Re: [Standards] BOSH vs. TCP for mobile
According to careful inspection of XEP-0286, relevant section 4.2 It would be beneficial if there was *some* standardized way to send a keepalive packet in less than 70 bytes (including the entire stanza -- message /message) This causes a 3G radio in a mobile phone to use a low-power low-bitrate mode. In fact, the last sentence of section 5 of XEP-0286 says Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible. So, does anyone recommend a standardized method of a sub-70-byte keep alive message ? NOPE! The whitespace technique is the only reliable way to do this -- say, sending a single space character between messages, is only 1 byte. That makes the low-power 3G radio state possible, instead of the high-power 3G radio state. So, I say, whitespace technique has merit -- it can approximately double the battery life of a cellphone running an idling XMPP client 24/7 that runs keepalive pings. (Ideally, keepalives shouldn't be necessary, but, unfortunately, it is in many situations) However, http://xmpp.org/extensions/inbox/keepalive.html neglects to reference XEP-0286 section 4.2 as a STRONG rationale for using the whitespace method. I do suggest that a reference to XEP-0286 be added, to strenghten the justification of an XEP for whitespace keepalive best-practices. Thanks, Mark Rejhon On Tue, Jul 19, 2011 at 11:08 PM, Mark Rejhon marky...@gmail.com wrote: Hello, I'm a software developer for mobile devices too, and it also varies by method of TCP. For BlackBerry, there are actually several ways to connect, including over BIS (carrier based proxy), BES (corporate BlackBerry Enterprise Server, letting it be the firewall for your BlackBerry), and regular mobile TCP/IP. Many mobile software XMPP clients, such as Beejive, allows these various different methods to be selected. My experience is that some of these methods time out pretty quickly (especially BIS) without keepalives, while some services such as BES have a configurable timeout. Now, a properly optimized TCP/IP connection without a timeout can stay alive for a long time with a mostly dormant mobile radio. The pings can actually wake up a radio, causing the radio to begin consuming more power, unless special design considerations are done to use a lower idle-state bitrate. BOSH, while it solves other things, makes this WAY worse because of the chattiness of BOSH. On the other hand, timeouts exist in many mobile implementations, and thus, some form of keepalive is needed. From a battery perspective on a properly designed mobile device, an open idle TCP connection uses no more battery power than having no TCP connections. There is less chattiness with a once-a-minute ping (sent only if no XMPP transmissions done), than with doing BOSH on a mobile device. Take a look at XEP-0286 XMPP on Mobile Devices. This is accurate battery consumption advice, and my mobile experience agrees with this spec. It's quite annoying detail, really, but this has to be considered. Mark Rejhon (Author of XEP-0301, which also happens to being considered for assistive needs by multiple companies in a multimedia NG911 system on mobile phones.) On 7/19/11, Peter Saint-Andre stpe...@stpeter.im wrote: On 7/19/11 7:42 PM, Glenn Maynard wrote: (Of course, mobile clients should really be using xbosh anyway, which avoids these and other issues, Opinions vary on that score. We had some discussions about this years ago at one of the XMPP Summit meetings in Brussels and the guys from Nokia reported that TCP was actually much better for mobile apps because there are magical ways to manage long-lived TCP connections without waking up the device, which is not true for the more chatty BOSH protocol. Naturally, YMMV. but it seems like the bosh/xbosh specs have stalled...) How so? The specs are stable so there's probably no need to change them frequently. However, there has been discussion on the b...@xmpp.org list over the last few months and that might lead to some small changes and clarifications. Let's wrap up those threads and see if we need to publish a revised version of XEP-0124 (and perhaps XEP-0206). Peter -- Peter Saint-Andre https://stpeter.im/ -- Sent from my mobile device
Re: [Standards] BOSH vs. TCP for mobile
So, does anyone recommend a standardized method of a sub-70-byte keep alive message ? A space character? And how much is xep-199 pings? Or a 198 ack? And with compression? -- Sent from my totaly awesome N900 :P
Re: [Standards] BOSH vs. TCP for mobile
On Tue, Jul 19, 2011 at 10:41 PM, Peter Saint-Andre stpe...@stpeter.imwrote: On 7/19/11 7:42 PM, Glenn Maynard wrote: (Of course, mobile clients should really be using xbosh anyway, which avoids these and other issues, Opinions vary on that score. We had some discussions about this years ago at one of the XMPP Summit meetings in Brussels and the guys from Nokia reported that TCP was actually much better for mobile apps because there are magical ways to manage long-lived TCP connections without waking up the device, which is not true for the more chatty BOSH protocol. Naturally, YMMV. I don't know of anything like that on Android, unfortunately. Being able to seamlessly tolerate network changes, eg. 3G to WiFi, is also very useful. I think XMPP session management can do that too, but it's harder to implement since, as it involves reauthentication, it's not a cleanly separable transport-layer mechanism. I wish it used a session-ID based mechanism like BOSH. I've also considered attempting to combine BOSH with Android's C2DM for wakeup notifications, which would allow shutting down the TCP connection completely when idle, reducing battery overhead to zero. How so? The specs are stable so there's probably no need to change them frequently. However, there has been discussion on the b...@xmpp.org list over the last few months and that might lead to some small changes and clarifications. Let's wrap up those threads and see if we need to publish a revised version of XEP-0124 (and perhaps XEP-0206). There didn't seem to be much interest in the protocol feedback I sent, at least. (I meant to ping that thread, but I havn't had much spare time for XMPP/BOSH projects lately.) It would be beneficial if there was *some* standardized way to send a keepalive packet in less than 70 bytes TCP keepalives do that; they're nothing but an empty TCP packet with a redundant ACK, to cause a keepalive with the minimum possible packet size and without inserting garbage into the stream. -- Glenn Maynard
Re: [Standards] BOSH vs. TCP for mobile
Glenn Maynard wrote 2011-07-20 05:53: It would be beneficial if there was *some* standardized way to send a keepalive packet in less than 70 bytes TCP keepalives do that; they're nothing but an empty TCP packet with a redundant ACK, to cause a keepalive with the minimum possible packet size and without inserting garbage into the stream. Some conclusions can be carried over from the same discussion for SIP, documented in RFC 5626 http://tools.ietf.org/html/rfc5626#section-4.4.1 There, the keepalive frequency for TCP is recommended to be 14 minutes for the mobile case and the keepalive packet contents is recommended to be CRLF. /Gunnar
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
Hi, Following are the thoughts: Each side can send its own keep-alive whitespace packet intelligently considering the traffic and the reqmt to keep persistent connections. Devices specifically should intelligently see the n/w behind which they are and keep on calibrating the keep alive whitespace until they reach a point where connection does not break. So this is application specific reqmt and would differ from app to app. Thanks Regds, Amandeep On Wed, Jul 20, 2011 at 7:17 AM, Kim Alvefur z...@zash.se wrote: On Tue, 2011-07-19 at 19:13 -0600, Matthew A. Miller wrote: This is great for desktops, but less than ideal for mobile. Perhaps a generic please apply resource policy $foo-spec could be thougt up? So you could tell the server that you're on a constrained link and have it activate various measures. Or do we have this already? identity category=client type=phone/ ? How about a Informal XEP about applying ping/keepalive/buffering based on that? -- Kim Alvefur z...@zash.se
