[Standards] Enterprise Users & Groups
Hi All, We are trying to use XMPP in our application where there will be a user group like Finance or HR to which the application would want to add users. We are planning to write a custom XMPP component which would check for presence of the users in the group and should be able to direct queries from some other users to a member of this group. This application would eventually inter-op with an enterprise XMPP server so we would like to reduce the dependency on XMPP server configuration to a minimal. Also, ideally we would like that the users of the group are auto-subscribed and would not require the user to manually send a presence "subscribed" packet. I am not sure if pubsub or group is what we need, please advice. Best Regards +Fasih
Re: [Standards] XEP-0136 modifications
Peter Saint-Andre wrote: > On 2/2/10 12:59 PM, Yann Leboulanger wrote: >> The main problem I faced was that it is currently not possible to stop >> archiving a conversation. The scenario is this one: >> auto archiving is enabled. I start a conversation with a contact, so >> it's archived. I start encrypting the conversation (GPG or E2E). Then it >> becomes useless to archive messages. But currently the only way to do >> that is to stop auto archiving for ALL contacts. > > Yann: > > 1. I agree that we need a way to stop archiving. Cool > 2. Thank you for the patch. You're welcome > 3. My apologies for the delay in replying. No problem, There is no full server implementation for the moment anyway AFAIK. Alexander is re-writing ejabberd module. > One minor comment: I think XEP-0201 is a better reference for ThreadIDs > (instead of XEP-0155). Ok no pb, minor change. > One larger concern: what is the interaction between scope="global" and > the element? It seems to me that they might overlap (or that > implementers might get confused). I think we need to be clear about how > these two interact. Your answer might be: "Peter, you haven't read the > patch carefully enough because we already answered that question." :) element specifies the default value if there is no or element, and specify *what* server should log (body, message...). element specifies *if* server should log or not. It's a boolean value. > Let's answer that question, apply the patch, and then have the Council > decide about accepting the changes. Does this answer suits you? -- Yann
Re: [Standards] XEP-0047: IBB
Just got some doubts having several compatibility issues with block sizes in different implementations (lampiro, some bots, pidgin). All the specs say about it is this sentence: "The data to be sent, prior to any wrapping in the element and IQ or message stanza, MUST NOT be larger than the 'block-size' determined in the bytestream negotiation." There is no indication whether: - the size is the one of the original data or the b64 encode one (for implementations it would easier if it were the non-encoded data) - if each block must be a valid b64 block, i.e. with padding at the end (again for implementation it be easier this solution, since we don't have to buffer incoming stanzas) On Sat, Feb 13, 2010 at 3:26 AM, Peter Saint-Andre wrote: > A few comments on XEP-0047... > > First, it might be useful if the error for "block size too big" provided > more detailed information, because right now the recipient can't tell > the sender what block size would be acceptable (e.g., if the sender > proposes a block size of 4096 and the recipient returns an error, the > initiator might then try a block size of 2048 but the receiver might > still return an error; that seems to require too many round trips). I > propose that we add an application-specific error condition that > specifies the preferred block size:
