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 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
Peter earlier mentioned that RFC3920bis refers to RFC5952 which recommends using square brackets around an IPv6 address: http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-22#section-4.9.3.19 This is what I was suggesting as well. I think the host:port notation is quite common and [IPv6]:port will be, as well, in an IPv6 world. Cheers, Ben On 2/17/11 2:57 PM, Joe Hildebrand wrote: Was it going to be more clear what to do with port info on the location element? On 2/17/11 11:49 AM, "Peter Saint-Andre" wrote: Any feedback or objections? On 2/11/11 1:56 PM, Peter Saint-Andre 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] XEP-0198 status
On 2/12/11 6:31 AM, Peter Saint-Andre wrote: On 2/12/11 2:46 AM, Ben Schumacher wrote: 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? We don't need XEP-0198 in BOSH because there we have 'rid' attributes and such (in fact XEP-0198 borrows some of its ideas about managing the connection from the BOSH spec). So I would say that in XEP-0198 the client will only ever be told to reconnect to an IP address or hostname, using standard XMPP methods (TCP binding). We may not have a need for the stream ack'ng or stream resumption, necessarily (though I might be willing to argue a case for the latter), but I still think the 'location' bit could be useful. It seems totally reasonable that your description to Kim for the usage of 'location' when load balancing client connections could apply to BOSH-based connections, as well. Cheers, Ben
Re: [Standards] XEP-0198 status
On 2/12/11 5:09 AM, Remko Tronçon wrote: 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. Well, we haven't needed it so far, and this XEP would be the first time we do, but I may be missing something. That's why I'm also in favor of splitting it into a separate attribute. Remko- Splitting is fine with me, but I do believe understanding that IPv6 address in the "host:port" syntax need to be in square brackets (it's really that simple) is going to be necessary for application looking to thrive in an IPv6 world. Otherwise one thing you might be missing the ability to connect to an through a proxy at an IPv6 address. Or the full use of the XEPs that rely on a URI parsing (XEP-0070, XEP-0124, etc). 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-Andre" 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] XEP-283
On 1/30/11 8:26 PM, Evgeniy Khramtsov wrote: 31.01.2011 08:52, tpatnoe wrote: Our team is starting work on using XEP-283. Has anyone else looked at this and do they see any problems with the spec as it is currently written (Version 1.0)? http://xmpp.org/extensions/xep-0283.html One item which came up in our discussion, is linking an unsubscribe from an old JID to a new subscribe from the new JID with a token. However, we decided that just including the new JID in the unsubscribe from the old JID, and the old JID in a subscribe from the new JID were enough. A token provided no more assurance of authenticity. What I really don't like in this XEP is that it contradicts the idea of "keep clients simple". I think we can do the same using server-side redirects (we have such error type already defined in the core RFC). In that case a client just need to set a redirect and his/her contacts should process presence redirects correctly. Also, redirects can be used for temporary migration and not only for account removal. Attempting to "keep clients simple" shouldn't come before all other considerations. In this case I believe that using a redirect so greatly complicates the security model (not to mention the server implementation) that it's necessary to have some work on both sides. There is a widely held belief among protocol snobs that the email system's flexibility in this regard leads to a lot of the exploits that have made it so ripe for abuse. Being able to balance the work between the server and the client for XEP-283 means a user still has the ability to maintain their subscriptions while changing their username but is flexible and scalable enough to work in a globally federated environment and still gives the individual the opportunity to review any action before it is taken. Cheers, Ben
Re: [Standards] [REQ] Offline Status Messages for XMPP
On 11/15/10 12:42 PM, cxzadw fsdfzxca wrote: Hi. I don't know if this is a right place to ask, but when XMPP will have support for Offline Status Messages ? I want to set "I'm off me 3 days" and i want that every people with have me at my contact list see this message every time that they will be online. It should be protocol-server-standard because status messages have same value for communication as normal IM messages. Pls reply. There is a proposed standard (http://xmpp.org/extensions/xep-0109.html) to address this very issue. To specifically address the issue of having it always displayed in the Contact List, you'll need to convince a client developer to render the information in that fashion. Cheers, Ben
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
Re: [Standards] stanza order and MUC
On 9/29/10 7:09 PM, Justin Karneges wrote: On Wednesday 29 September 2010 16:12:59 bschumac wrote: The specification is clearly ambiguous about this, given that it only refers to an "entity" but doesn't define what an entity is. Right. Ordering is important enough that I think this issue deserves more than one sentence in the RFC. It seems our choices are: 1) "Entity" is a Full JID. Resource locking (RFC 3921) and MUC (XEP-0045) need repairs, or we just live with their problems and try not to repeat them. 2) "Entity" is a Bare JID. Everything works as Jeremy Himself intended. Can developers of various servers describe their current ordering policies? It would be interesting to see just how the spec has been interpretted so far. XCP uses the second approach with great success. It is, as you originally stated it, "optimized, threaded, clustered, etc." and from the standpoint of our users works as expected. 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