[Standards] Comments on the Push XEP

Hi everyone, Following up on the message by Lance asking for comments on https://github.com/legastero/customxeps/blob/gh-pages/extensions/push.md, I've come up with a couple of suggestions/questions. * I still think it's valid to allow a component to proxy more than one proprietary push service.

Re: [Standards] XEP-0045 to Final?

On 2014-03-05 12:48, Winfried Tilanus wrote: > [..] > Well, I *assumed* your MUC implementation did not support this. > > Assuming that, you can try to change your MUC implementation (leaving > alone the question if a change to XEP-0045 is needed). But when you have > to change your MUC implement

Re: [Standards] XSF membership application period Q2 2014

On 05/03/14 12:30, Alexander Gnauck wrote: > > I have setup the membership application Wiki page for the application > period Q2 2014 > > > > Applications are encouraged from developers and others who are > actively involved in the Jabber/XMPP community. To apply, create a > page about yourself o

[Standards] XSF membership application period Q2 2014

I have setup the membership application Wiki page for the application period Q2 2014 Applications are encouraged from developers and others who are actively involved in the Jabber/XMPP community. To apply, create a page about yourself on the Wiki:

Re: [Standards] XEP-0045 to Final?

> Ah, I see, you need the list of members, not the list of occupants. Correct. > Yes, it seems possible that you could modify an implementation to allow > non-occupant members to perform this query. We might even possibly want > to add a note about this to the spec. I guess you refer to "6.5"? I

Re: [Standards] XEP-0045 to Final?

On 05-03-14 11:46, Ralph Meijer wrote: Hi, >> could you elaborate on this proposal a little bit, please? > Agreed. I'm a more of a fan of publish-subscribe than the next guy, > but I don't see how this is a helpful suggestion without > elaboration. OK >>> It would be so much easier to just allo

Re: [Standards] XEP-0045 to Final?

On 3/5/14, 11:25 AM, Christian Schudt wrote: Hi, Could you elaborate a bit on the use case and the need for it? I'm not saying it's bad or irrelevant, but XEP-0045 was not designed to solve every possible problem related to groupchat. A user creates a (members-only) room and adds X contacts f

Re: [Standards] XEP-0045 to Final?

Hi, > Could you elaborate a bit on the use case and the need for it? I'm not > saying it's bad or irrelevant, but XEP-0045 was not designed to solve > every possible problem related to groupchat. A user creates a (members-only) room and adds X contacts from his roster as member and invites them.

Re: [Standards] XEP-0045 to Final?

On 2014-03-05 11:16, Christian Schudt wrote: > Hi, > > could you elaborate on this proposal a little bit, please? Agreed. I'm a more of a fan of publish-subscribe than the next guy, but I don't see how this is a helpful suggestion without elaboration. Going back to the original question, I don't

Re: [Standards] XEP-0045 to Final?

:) A: Because it messes up the order in which people normally read text. Q: Why is top-posting so bad? A: Top-posting. Q: What is the most annoying behavior on email discussion lists? On 3/5/14, 10:16 AM, Christian Schudt wrote: Hi, could you elaborate on this proposal a little bit, please?

Re: [Standards] XEP-0045 to Final?

Hi, could you elaborate on this proposal a little bit, please? The room creator/owner publishes a node to a pubsub service, which contains all room members and each invitee subscribes to this node (which is equal to the room JID?)? What about the case, when a member invites further members? He

Re: [Standards] XEP-0045 to Final?

On 01-03-14 18:04, Christian Schudt wrote: Hi, > I recently was confronted with the following requirement: Create a > (non-public members-only) room, grant membership to X contacts and > send an invitation to these X contacts. > > Then after receiving the invitation, but BEFORE joining the room,