Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On 7/19/11 7:42 PM, Glenn Maynard wrote: On Tue, Jul 19, 2011 at 9:13 PM, Matthew A. Miller linuxw...@outer-planes.net mailto: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- It makes me chuckle to read you say that this negotiation protocol seems like an overcomplication and then immediately follow that with a suggestion that folks should be using BOSH. ;-) Regardless, this is an optional feature and if you feel it is too burdensome for your project, then you're welcome to skip its implementation, but that doesn't mean it doesn't have technical merits for the protocol community, at-large. Cheers, Ben
Re: [Standards] XEP-0198 status
I think using RFC3986 (2732) formatting rules for supporting IPv6 address/port in a single attribute would be fine. Any software that intends to communicate over IPv6 is probably going to need to understand that format at some point. One other important clarification on the address might be a recommendation regarding address resolution. Is the intention for clients to fallback to an SRV lookup on the provided location, or should the information provided give them another hint as to how to use it. What I mean is, is the location also simply an address/hostname and port combination, or might it be an HTTP URI if this protocol is being used in connection with BOSH? On 2/11/11 10:33 PM, Joe Hildebrand wrote: I don't see any description of the syntax or semantics of the location attribute yet. XMPP URI seems like overkill, but since we need to support IPv6, colon-separated probably isn't right. Perhaps we could just split host and port into two separate attributes? For semantics, there needs to at least be a mention in section 5. On 2/11/11 1:56 PM, Peter Saint-Andrestpe...@stpeter.im wrote: OK folks, I've made a first attempt at updating the spec, including Dave's patch. The results are here: http://xmpp.org/extensions/tmp/xep-0198-1.2.html Please review and comment. (IMHO the document doesn't provide a super-clear explanation of what the protocol does and why it matters -- I'll try to add a paragraph like that to the introduction.) /psa On 1/12/11 12:56 PM, Peter Saint-Andre wrote: In preparation for the XMPP Summit in a few weeks, I'm reviewing the status of several XEPs and preparing summaries so that we can quickly come to agreement regarding open issues. First on my list is XEP-0198. Many moons ago (last June, July, and September) there was a discussion thread about this spec: http://mail.jabber.org/pipermail/standards/2010-June/023512.html http://mail.jabber.org/pipermail/standards/2010-June/023525.html http://mail.jabber.org/pipermail/standards/2010-June/023526.html http://mail.jabber.org/pipermail/standards/2010-July/023647.html http://mail.jabber.org/pipermail/standards/2010-July/023649.html http://mail.jabber.org/pipermail/standards/2010-July/023655.html http://mail.jabber.org/pipermail/standards/2010-July/023656.html http://mail.jabber.org/pipermail/standards/2010-July/023648.html http://mail.jabber.org/pipermail/standards/2010-September/023770.html http://mail.jabber.org/pipermail/standards/2010-September/023768.html http://mail.jabber.org/pipermail/standards/2010-September/023769.html http://mail.jabber.org/pipermail/standards/2010-September/023797.html http://mail.jabber.org/pipermail/standards/2010-September/023846.html I see two main points... 1. Dave Cridland helpfully sent in a patch based on implementation feedback in M-Link and Psi, analyzed here: http://mail.jabber.org/pipermail/standards/2010-September/023769.html I don't disagree with anything in the patch, so I think it can be applied, and will plan to do that soon if there are no objections from my co-authors. I'll also add Dave as a co-author, naturally. 2. Folks seem to think it would be good to replace the current rule (based on number of stanzas) with a time-based rule. For example, Matthew Wild wrote: I think the unacked stanza count should be switched for a time-based algorithm. Perhaps something along the lines of the BOSH timeout handshake... IMHO that is a good topic for discussion at the Summit, or of course here on the list before then. It's not reflected in Dave's patch, unless I'm missing something obvious. Are there any other issues we need to discuss regarding XEP-0198? Peter
Re: [Standards] stanza order and MUC
On 9/30/10 3:13 AM, Dave Cridland wrote: On Thu Sep 30 00:12:59 2010, bschumac wrote: Users a...@s/C and b...@s/C are both online and both users begin a conversation with each other at the same time. The server receives messages in this order: 1. a...@s/C sends Yo to b...@s (Bare JID) 2. b...@s/C sends How's it going? to a...@s 3. a...@s/C sends second Terrible. to b...@s/C (Full JID -- resource locked) However server provides incorrect guarantee that only ensures in-order between fullest-possible JID, the messages end up delivered out-of-order: * b...@s/C receives Terrible. * b...@s/C receives Yo. * a...@s/C receives How's it going? I'm in awe of your programming skills. The majority of clients have to wait until they get the response before they resource-lock, and moreover, quite a few users tend to wait until they see a question before they answer it, too. Not me, of course - I wrote this message three weeks ago, and just didn't get around to sending it until now... This is as it should be, though in this case I'm afraid you're simply failing to grok my example and I don't care enough to go through the trouble of making an ASCII sequence diagram. My basic point is that if you're using some sort of threading, queuing, sockets, quantum delivery in your server to make it optimized, threaded, clustered, etc. and you choose which thread, queue, socket, particle based on whichever JID the stanza is address to, rather than a sensible approach that uses a bare JID (ignores the resourcepart, if it exists), stanzas will get delivered in a different order than they were introduced into the system. It may not happen all the time, but it will eventually happen. I'll throw out an alternate ordering rule, and see how people react: Servers MUST ensure in-order processing of the stanzas received on a stream. Servers MUST resolve any ambiguity caused by processing requests (for example, those sent to the bare jid of a connected client); in the case where the result of a request could have an effect on subsequent stanzas, servers MUST suspend processing of stanzas until the request is completed. Servers MUST ensure that any stanzas forwarded from a stream to a particular remote domain are forwarded in order - in particular, this implies that for any given inbound stanza that is addressed to a remote domain, there SHOULD be at most one outbound stream, used consistently. Seems okay to me with the caveat that a stream, when a user is involves, obviously requires a resourcepart and tying the wording too closely to the concept of a stream leaves cases open where I'm sending messages to another user which resource-locked and the users goes offline as I'm sending message (thus breaking the lock). Assuming that my messages are delivered within the context of my stream in-order and then handed off to some construct that represents the other user's stream, but the socket is close before they're delivered, what the expectation for the message with regards to offline storage? As the sender I'd expect the messages to end up in offline in the same order they were originally sent by me, but when the other stream disappears mid-conversation, what's our in-order semantics? I'm maybe a little too close to an implementation here, but I think it's less ambiguous to simply tie in-orderness to a (destination) bare JID rather than a stream. Cheers, Ben
[Standards] Question about XEP-191: Simple Communications Blocking
Peter, et al- I have a quick query about XEP-191. In Section 3, Relationship to Privacy Lists, the XEP states that the new protocol is intended to be a user-friendly front-end to the privacy lists protocol. While I have some personal issues with this stated goal (in particular I don't think that XEP-16's requirement for in-order processing is particularly useful), I do have a specific question about implementation. First, should there be some standard name for a list that is generated by this protocol if it is retrieved via the XEP-16 protocol? Using the URI of the blocking protocol would probably be sufficient (and could provide a hint to sophisticated clients that this list was generated using the simple protocol), but I am curious if there is guidance from the standards body. Additionally, the implications listed in Section 3 state: If all of a user's clients always use simple communications blocking, then the default privacy list will be equivalent to the blocklist and the default privacy list will be a kind of virtual list (in the sense that it is never modified directly by any of the clients). This rule implies to me that there should be some interaction with entity capabilities such that the server knows if the clients support this protocol or not. This would, of course, require that the client publish proper caps in its initial presence and the server will have to defer this decision (i.e. should I be using the Simple Blocking list vs. the list defined as default in XEP-16) until the capabilities information has been cached by the server. Finally, the 5th implication in this section states: If one of a user's clients makes active something other than the default privacy list, the user may receive communications from contacts who are blocked in the default list. Is there an expectation here that a connect client that's using the simple blocking protocol would get the push notifications of the updated blocklist? That question applies to the wider context of the usage of this protocol - should privacy list modification cause simple blocking protocol pushes and vice versa? Thanks for your time. Ben
